As the subtitle indicates, the book cracks open some of the puzzling and frustrating aspects of requirements analysis and has a focus on "topics that are chronic areas of difficulty and confusion for practitioners."
I like the authors segregated definition of "requirements":
- Business Requirements: defines why the business is creating the software - the benefits expected and the business value.
- User Requirements: Defines what will users be able to do and the users' goals.
- Functional Requirements: Defines what is to be built and what the software shall do.
Even if your requirements process is solid, you'll find food for thought and ideas for improvement. If your requirement process is lacking, then you've got a treasure trove of information and practical advice.
In addition, the author provides links to numerous artifacts - templates, checklists, etc. - that can help jump start your process improvement.
Whether you have immediate requirements issues or longer-terms goals, this book will be an excellent addition to your reference library.
2 comments:
I'm curious about quality attributes / non-functional requirements. Does the book discuss them? I didn't see it in the segregated requirements definition.
The book briefly discusses system properties/attributes as part of User Requirements. System properties/attributes define quality and how well the system does its job.
Post a Comment