A popular Agile phrase goes like this.
...it's important to know what Not to build
This begs the question, who's building things that other people don't want? Where's the process for assessing what people want? Seems pretty obvious that if you're building thing that you shouldn't be building you're not doing a very good job of requirements management.
Software requirements are a weak link in the chain of software engineering technologies. Requirements are usually incomplete and change at rates in excess of 2% per calendar month. For many years one common definition of quality has been “conformance to requirements.” However this definition ignores the fact that some requirements are hazardous or “toxic” and should not be included in software applications. Since clients themselves may not realize the dangers of toxic requirements, software engineers have a professional and ethical responsibility to point out the hazards of dangerous requirements and ensure that they are safely eliminated. An example of a “toxic requirement” is the famous Y2K problem which did not originate as a coding bug but rather as an explicit but dangerous user requirement.
Capers Jones, Vice President and CTO, Namcook Analytics LLC
So how is it decided if a requirement is toxic or not. Well it's pretty straight forward:
This is the role of a requirements elicitation and management process. One based on an actually process, not just some made up, some cockamany approach to writing things done on sticky notes and asking the next passing person what they think. An actual, true to life requirements engineering process.
This starts with a simple concept:
A requirement is a statement that identifies a capability, characteristic, or quality factor for a system for it to have value and utility to a customer or user.
If we don't know these capabilities are, their attributes, characteristics, or other factors are, we won't recognize them before the money runs out. Can we over specify the requirements? Perhaps we can. Can we under specify the requirements? It's done all the time to the detriment of the project. We need to find a way to specify the requirements in a sweet spot. Not too much, not too little.
Research shows the average investment in requirements elicitation and management is 2% to 3% of the total project cost. Research also shows this is wholly inadequate for success and is one of the root causes of failure on any non-trivial project. This research shows that projects that expended 2% to 3% on requirements experienced a 80% to 200% cost overrun. Those projects that expended 8% to 14% on requirements elicitation and management experienced 0% to 50% cost overruns.
We must be crystal clear here. Requirements may emerge, but the needed capabilities at the needed time are a critical success factor for any project, no matter the domain. As Yogi reminds us. If you don't know where you're going, you might not get there.
I'm not going to tell you how to develop requirements,. There are many ways, starting with the guidance listed below and endless other books articles, and papers. But if there is a notion that requirements are not needed - let's let them emerge and we'll start coding to see what comes out - it's going to be a rough ride before the money runs out.
[1] The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2004
[2] Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John Wiley & Sons, 1997
[3] Succeeding with Agile: Software Development Using Scrum, Mike Cohn Addison-Wesley, 2010.
[4] Project Management the Agile Way: Making it Work in the Enterprise, John C. Goodpasture, J. Ross, 2010.
[5] Agile Estimating and Planning, Mike Cohn, Prentice Hall, 2006
[6] Agile Project Management for Government, Brian Wernham, Maitland & Strong, 2012.
