Requirements

Atomic symbol in book

Make Your Requirements Atomic!

I’m pleased to say that my most recent blog article has been published on “Bridging-the-gap.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.   Excerpt: “I have to admit that I have a rather eclectic music… 

Image of a man walking a tightrope in a circular blackhole

Avoiding the Security Black Hole with Non-Functional Requirements

  • Adrian Reed 
  • 2 min read

I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site. A short excerpt is shown below. Excerpt: As an avid Skype user, I couldn’t believe… 

Aspirin tablets

How to Help Project Stakeholders Avoid the Aspirin

  • Adrian Reed 
  • 2 min read

I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.   Excerpt: “Kent McDonald recently wrote an excellent article encouraging project teams to… 

Shadow of a human head

7 tips for virtual requirements workshops

  • Adrian Reed 
  • 3 min read
Shadow of a human head

Virtual facilitation can be tricky…

Increasingly, projects teams are dispersed and may be working not only in different cities, but potentially different countries, continents and time zones.  Working in a dispersed team undoubtedly creates additional challenges when facilitating requirements elicitation sessions. In fact, people may even have an initial reluctance to attend virtual meetings.  These challenges certainly aren’t surmountable, and here are some concrete tips that can help:

Pair of scissors

Cutting through the requirement prioritisation nightmare

  • Adrian Reed 
  • 3 min read
Pair of scissors

Prioritisation doesn’t have to mean cutting out requirements

Requirement prioritisation can be a difficult exercise.  Often, stakeholders will insist that every requirement is essential and prioritising or de-scoping requirements can feel like asking colleagues to part with their most treasured and sentimental personal possessions!  In this article I’m going to outline three considerations that make prioritisation significantly easier.  I’m going to refer to the MoSCW prioritisation framework throughout the article.

 

1. Get the foundations right

When prioritisation is difficult, this suggests that there isn’t a shared understanding of the business value and the customer value that the project will deliver.  This suggests that the foundations of the project are shaky—perhaps insufficient enterprise analysis took place.  In these cases, it’s worth taking a step back and asking “What problem or opportunity are we trying to address here?”.  If that isn’t clear, then make sure this is resolved before moving forward.  Jeff Patton touches on this in his article How I Stopped Worrying and Learned to Love Prioritization and he underlines the fact that business goals must be explicitly stated.

 

Businesspeople having conversation

Playing the Critical Friend Through Enterprise Analysis

Successful projects start with a good and clear understanding of the organisation’s goals and objectives and over time develop a clear understanding of the project’s requirements.

 

One significant challenge with projects can be the gap between what the stakeholders ask for, what they need, and what they can afford. There can be a further gap between what the stakeholder expects and what is actually delivered. Good quality business analysis helps to plug this gap.

 

Although the discipline of business analysis is young, it isn’t new. Requirements engineering is older still—yet history is still littered with examples of expensive IT project failures and projects where the users haven’t received what they expected. How can this be? And how can these types of project failure be avoided?

 

Dictionary definition of success on white page

Are SMART Goals Smart Enough?

A key skill within business analysis is the ability to define and set goals and objectives. It might not always be referred to as “goal setting,” but every time you help the business determine the business value that would be achieved for a particular initiative, you’re really helping them to define goals and objectives. When defining acceptance criteria and non-functional requirements, you’re also setting quantifiable objectives that a solution should meet.

 

A common way of approaching business and project goal setting is to use the SMART technique. This technique encourages the setting of goals that are specific, measurable, achievable, realistic, and time-bounded. The SMART approach has many uses within projects and beyond. But is SMART enough?

 

Dictionary definition of success on white page

How do you define success in projects?

I was recently fortunate to attend a useful and inspirational training course where I was introduced to a new technique (and acronym) for goal setting. This technique, designed for setting personal goals and objectives, is designed to be used in coaching. However, with some subtle adjustments, it works equally well in a project or business environment.

 

The acronym is PECSAW, which stands for:

 

Debate: The danger of “negative” requirements

I recently read a thought-provoking thread on the IIBA LinkedIN forum, relating how Business Analysts should state requirements.  The conversation centred around one main topic:  Is it advisable to define a system by stating what it shouldn’t do, or should these “negatively framed” requirements be avoided. 

 

There’s no hard and fast answer on this, and there are certainly varying views on what constitutes a well-written requirement. However, I firmly believe that it is highly preferable to define systems in terms of what they can do (rather than what they can’t).

 

I’ll illustrate this with a real life—but non IT—example.  I live in Portsmouth, on the south coast of the UK.  Near the seafront, there’s a really steep hill.  Given the number of pedestrians that are in the area, cyclists are banned from using the path downhill (as it’s likely they’d lose control and collide with an unsuspecting passer-by).  A picture of the start of the hill is shown below. Trust me, it’s much steeper than it looks in the picture!

 

Painted text on the ground saying "No cycling, no skateboarding"

Should negative requirements be avoided?

 

Business woman with arms crossed

The tough truth: Your stakeholders don’t want a BA

I’m pleased to say that my most recent blog article has been published on “Bridging-the-gap.com”, where I have contributed as a guest author. This article focuses on business analysis from the perspective of SMEs and stakeholders… and has caused some controversy! I’d love to hear what you think, so please take a look and add a comment…