Chapter 10. Documenting the requirements
At the launch of a large project to build a commercial software company’s next-generation flagship product, a senior manager convened about 60 employees in a daylong off-site “voice-of-the-customer workshop.” These employees worked with facilitators to generate ideas for the new product. The manager compiled the results of these brainstorming sessions into a 100-page document. He called this a requirements specification, but in fact it was nothing more than a pile of information.
The information from the brain dump by all these smart people wasn’t classified into various categories, organized logically, analyzed, or otherwise processed into anything that described a proposed software solution. Developers ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access