Business.com
The year, 1998. The place, some nameless IT office. A young man is preparing for his first day of work. He has no idea what a business analyst does, but he knows it has something to do with computers and will mean gainful employment for him. His mentor sits him down and says, “Are you familiar with IEEE 830.” He was not. The mentor begins an intense interpretive reading session,
“1.2) The system shall allow a user to buy a cake with a credit card
1.2.1) The system shall accept Visa, MasterCard, and American Express
1.2.2) The system shall charge the credit card before the cake is made
1.2.3) The system shall give the user an order number…..zzzzZZZzzzzzzzZ”
Things have changed a lot since 1998
IEEE Standard 830 was last updated in 1998. The internet was in its infancy, mobile phones were used to make calls and calls only, and your 17 year old nephew was a newborn.
In the meantime, the development of software has become more complex and more connected, while business costs and competition have increased. Michael E. Porter of the Harvard Business Review writes, “… new types of products alter industry structure and the nature of competition, exposing companies to new competitive opportunities and threats.” If you created the requirements for a 5 year program in 2006, there is a complete change of events you could not have accounted for. IEEE 830 was created in a time where you wrote requirements once and only once, and put a great deal of effort into “getting it right the first time”. You didn’t have to worry about the industry being upended by the time the project was completed.
In the last 17 years, we have learned a lot about software projects and specifically requirements. Namely, it’s very difficult to get them right the first time, up front. If we know they won’t all be right the first time up front, then we need a mechanism to constantly assess requirements against our original hypothesis and new information. This is where ongoing software requirements specification refinement comes into play.
It helps keep other supporting documentation up to date
A bad side effect of “nailing down” requirements up front is that we create reams of documentation that quickly begins to rot. Meanwhile, the analyst who was engaged with the project for the first 6 weeks during the requirements phase has moved on. And no one wants to take on the task of updating requirements, lest they be saddled with that duty forevermore. Since the documentation is out-of-date, no one reads it. Since no one reads it, it rots faster. After a few months of this, the “real” information is in people’s heads (and in the code), and the requirements documentation is for suckers and newbies.
If requirements were revisited every 2 weeks on a cycle, it would be much easier for them to keep up with code changes because we would only have to incorporate 10 business days of “new stuff” into the requirements.
It helps continuously align requirements to business priorities
One of the reasons the software changes after it has been spec’d is because there are emergent business priorities and opportunities that don’t care that the requirements have already been signed off. One example of this is McKinsey’s article (full disclosure: I’m a McKinsey alum) that describes Amazon’s advanced customer segmentation — a technique that has only become available in recent years because of the explosion of online interactions and data processing capabilities.
A “rolling wave” of requirements refinement would allow an “opening” to re-prioritize emergent needs against existing requirements, allowing us to take advantage of innovations in mobile, analytics and cloud technology. Of course, this is heavily dependent on the requirements being prioritized to begin with. But that is another story for another day.
Until Next Time,
Stay Agile, My Friends
(266)
