18 January 2008

Requirements Analysis

This topic doesn’t get spoken about too often. And in the recent Carnival of Business Analysts I published I felt that the actual step of analysing the requirements for value and thus for importance wasn’t well addressed. So I looked further afield and came up with this information.

In a Master’s thesis (Rashid Awan 2005) I recently read “Requirements Analysis” was bundled with “requirements negotiation” which makes sense. Rashid Awan explains these ideas as the process of determining what is and isn’t in the scope of the technical solution.

How do you know what requirements are most important?

What will rarely work is asking people which requirements are most important. A common answer is that they are all important, otherwise they wouldn’t be requirements. This view makes sense and often sensible and mature stakeholder have already demonstrated discipline by not bundling in any unnecessary requirements.

What follows is a brief discussion on some requirements analysis techniques. I expect it will be useful for new analysts, and that more experienced analysts may pick up one out two new ideas they can try out.

If you have a particular technique you would like to share, leave a comment or send me an email and I’ll add it to this post.

Mandatory and Optional

Many analysts categorise requirements as mandatory or optional. Typically without the mandatory requirements fulfilled the solution simply won’t work. The optional requirements tend to be about optimising the solution, and are often related to customer or user experience.


Ranking is a useful tool when only limited resources are available. Ranking requirements is core to Agile development which is a resource and time constrained mode of development. If we only have 2 weeks to build the next iteration what are the most important things to develop.

Value Analysis

Which requirements contribute the greatest part of the value? The challenge with this approach is that it is often hard to isolate requirements and link them to specific value. It can often be done with effort but, as an example, how do you attribute a value to rules on passwords and how do you manage to determine that value on tight timeframes?

Requirements Risk Analysis

Last week I wrote an article on Requirements Risk Analysis for Modern Analyst. Some of the ideas in the article included identifying requirements that introduced risk to the project and thinking whether you should drop them as a way of avoiding the risk. Modifications and mitigations are also discussed as ways to manage requirements risk.

Kano Analysis

I like this model and have written about it before. It’s about identifying what is going to delight a customer if delivered, and what is going to leave them dissatisfied if not delivered. There are various hybrid approaches to this model that make it simpler to deploy that the original model.

Basically ask you customers to rate requirements on Likert scale on two metrics; how much they like the requirement and how much they would be unhappy if it were omitted. You then plug them into the model and get insight into how the requirements are going to affect your client’s perceptions of success.

Stakeholder impact analysis

Stakeholders have an enormous affect on whether projects are seen as successful or not. Different stakeholders have different views on what is important. If you take the time to understand who cares about which requirements and how they influence the end view of project effectiveness you can play to the right preferences.

(This is the reason why user interfaces for back office systems are often sacrificed; back-office process workers are paid to turn up and work with the systems they have, and typically don’t complain much about systems as long as the appropriate change management activities are used.)

PERT Analysis

In more complex projects where there are several components, or in projects which are built iteratively you need to sequence solution components in a particular order to accommodate functional dependencies.

Sometimes it’s other issues that cause work to be scheduled in a particular way (eg resource availability.) Sequencing means some things up front and some things at the back. And some things are not done at all. (Read more about PERT here.)


Analysis leads to understanding what is most important and what can be left out of the solution. It also gives insight into the order things should be developed and the architecture of the solution.

Requirements analysis is a topic that does not have enough written about it. Take this as an opportunity to write about your favourite techniques, tips and insights. (And link to your article from the comments here.)


  1. Anonymous3:12 am


  2. "Mandatory" and "Optional" requirements? If you require something, isn't it, by definition, mandatory? "Optional Requirement" simply sounds like an oxymoron. I know it's just language, but wouldn't "Requirement" and "Desire" better capture the difference?

    We *require* that the system does X.
    We *desire* that it can do Y.

  3. Andrew I agree. Personally the term requirements feels almost universally inappropriate to me.

    Perhaps it is only things like brand compliance, security (and things that are often called 'non functional requirements') that are truly non negotiable.