While I could try to analyze various methods according to various statistics, it would still only give a one-sided view on the subject. In addition I only know a few methods very well so that would leave out other methods.
A different approach, the one that we take here, is to ask you, the participant in the requirements process.

By sharing our experiences we can get a better picture of the strengths and weaknesses of each method in several areas, according to people who have practical experience.

The results of the survey will be posted on this blog.

Survey

Now, without further ado, please visit the survey at:

http://www.surveymonkey.com/s.aspx?sm=zcNO2GNsgSNmjW5UTJ5gxg_3d_3d

and answer the questions.

Further explanation is provided in the survey.

That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. The “how” can become the “what” and vice versa.

For example,
What: “The system should bring me from A to B”
How: “The system should consist of a car”

Now consider:
What: “I need to be able to have meetings with people at different locations”

In this case, “The system should bring me from A to B” can be a valid “how”, as can “The system should provide teleconferencing capabilities”. Which one of those would be best depends on other needs of the stakeholders, not on “how” or “what”.

In his book “Just Enough Requirements Management”, Alan M. Davis defines two aspects of a requirement that I find very useful.

He states: “A requirement is an externally observable characteristic of a desired system”.

In other words, it must be possible to check that the requirement is fulfilled from outside of the system. The second aspect of a requirement is that it should fulfill some need of a stakeholder.

A requirement like “The car should be produced in the colors red, yellow and blue” can be valid. It is surely externally observable. If it turns out that these are the most popular colors among the buyers of the car, and that the painting installation can only handle three different colors, then it also satisfies the needs of more than one stakeholder.

Almost any aspect of a system can be externally observable (in the right context, from the perspective of a particular stakeholder). Take an extreme one, “no method in the Java programming language shall exceed 1200 characters in length (excluding spaces)”. This can be valid, from the viewpoint of maintainability of the code. Perhaps a tool is used that doesn’t support that many characters or the stakeholder has good reason to believe that this will make it easier to maintain the code. In that case it is a requirement. It should still be balanced against the needs of other stakeholders, of course.

So to determine if a requirement is good, you don’t focus on the simple mantra “is it a design, then it is not a good requirement”. What matters is how far it satisfies a need of a stakeholder, and a better requirement satisfies more needs, or more important needs, than a worse requirement.

An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.

The traditional way to achieve this, is performing extensive requirements analysis before a project starts. All involved in the systems that is going to be built (the stakeholders) should tell upfront what they expect of the system, and after carefully balancing all needs, a list of requirements is delivered which is sent to the software design and development teams.

In an agile approach, many of the requirements gathering techniques used in traditional requirements management still make sense. The upfront analysis approach does not, as it does not take into account the fact that requirements change. People change their minds or gain a better understanding of their needs, laws change, budgets change, political landscapes change.
The usual agile approach is to finalise the requirements, and their relative prioritities, for one iteration just before that iteration starts. Refinement is even possible within the iteration. The requirements should be as detailed as necessary; not more, not less. This means that a requirements engineer not only talks with business stakeholders, but also with his primary customers: the developers, who are going to use these requirements.

Many agile (and non-agile) projects however start too fast, forgetting to think about issues that do need to be addressed before the first iteration. The risks of producing the wrong software are too big if these issues are ignored.

These issues include the business purpose of the project, the list of people and systems involved (the stakeholders), the scope of the work and the most critical constraints.
Depending on your organisation, this could be written down on one or two sheets of paper, or require a more rigorous analysis and report.

If you don’t, you run this risk of:

• making something that doesn’t fulfill a business purpose, so it will be seen as a waste of money even if something is delivered [business purpose]
• leaving out stakeholders and their requirements, leaving people unhappy at best, and making the result useless because it omits important functions or interfaces at worst [stakeholders]
• including costly features that are outside of scope and could have been more economically implemented in another project or system (or leaving out important features that could have made the system more worthwhile – because of an incorrect assumption about the scope) [scope]
• getting the wrong people on board, like oracle developers to extend a java system, or not being able to run on existing infrastructure, or not working towards an important deadline [constraints]

So in any project, even in an agile project, take time for a project blast-off in which these important issues are addressed, or else the success of your project is a complete gamble, no matter how good the team is.

After the blast-off, requirements management is part of the agile process, managed by the product owner, who is a true part of the agile development team.