- Requirements Defined
- Good Practices for Requirements Engineering
- Who Does All This Stuff?
- Some Recurrent Themes
- The Life and Times of Requirements
- Getting Started
This chapter is from the book
This chapter is from the book
This chapter is from the book
Good Practices for Requirements Engineering
The domain of requirements engineering is broadly divided into requirements development and requirements management. Requirements development encompasses the activities a team performs to identify, understand, and communicate requirements knowledge. Requirements management deals with taking care of requirements once you have them in hand. Requirements management activities include handling the inevitable changes, tracking versions of requirements and their status over time, and tracing individual requirements to related requirements, design components, code, tests, and other elements.
Requirements development is further partitioned into four subdomains:
Elicitation |
Activities to collect, discover, and invent requirements. Sometimes called gathering requirements, but elicitation is much more than a collection process. |
Analysis |
Activities to assess requirements for their details, value, interconnections, feasibility, and other properties to reach a sufficiently precise understanding to implement the requirements at low risk. |
Specification |
Activities to represent requirements knowledge in appropriate and persistent forms so that they can be communicated to others. |
Validation |
Activities to assess the extent to which requirements will satisfy a stakeholder need. |
These four sets of activities are not simply performed in a linear, one-pass sequence. As Figure 1.2 illustrates, they are interwoven and repeated until a particular set of requirements is understood well enough that the development team can build and verify that part of the solution with confidence. Requirements development is an incremental and iterative process by necessity, frustrating though that can be for the participants. Exploring requirements is an investment that reduces uncertainty and improves efficiency. The process might feel slow, but requirements thinking saves time in the end.
)
Figure 1.2 Requirements elicitation, analysis, specification, and validation are performed incrementally, iteratively, and often concurrently.
Each of the requirements engineering subdomains encompasses numerous discrete practices. That’s what this book is about. It describes twenty core practices that are particularly strong contributors to success on nearly all projects. Whether you lead requirement efforts, take part in them, or depend on them to perform your own work, you’ll be more effective if you apply these core practices. Several of the practices refer to templates, spreadsheet tools, checklists, and other work aids, which you may download from the website associated with this book at www.informit.com.
We’ve grouped the practices by requirements engineering subdomain, four for requirements development and one for requirements management. Chapter 3 addresses requirements elicitation, Chapter 4 describes analysis practices, Chapter 5 deals with requirements specification, and Chapter 6 discusses key validation practices. The most important requirements management practices appear in Chapter 7. Each practice description presents numerous practical techniques, identifies related practices, and suggests several Next Steps to help you put the practice into action right away. The practice descriptions are relatively short, so we’ve provided many references to other sources where you can get more detailed information.
Some practices in the elicitation chapter also describe related analysis and specification activities for topics like quality attributes and data. This grouping underscores the intrinsic entanglement of these requirements subdomains. It’s not a clean separation.
You might have noticed that we skipped past Chapter 2. That chapter discusses five additional requirements-related activities that every project should perform to lay a solid foundation for a successful outcome. You’re well served to conduct those activities early on to align all the stakeholders toward common goals, rather than going back to address them later when the team runs into problems.
This set of practices does not constitute a one-size-fits-all requirements process. When developing software, whoever leads the requirements work should work with other leaders to decide which requirements approaches will be most effective. Factors to consider include the project’s nature and size, the team’s experience with similar products, the access the team will have to stakeholders, particular areas of requirements risk, constraints, and organizational cultures (IIBA 2015). Select those practices that you believe will add the most value to the work, and adapt the practice descriptions from this book and other sources to best meet your specific needs.
The Appendix lists all twenty practices we address. These are by no means the only available requirements techniques. Numerous comprehensive (meaning long) books describe dozens of practices for requirements engineering and business analysis. These are some of the most useful resources:
Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty (Microsoft Press, 2013)
Mastering the Requirements Process: Getting Requirements Right, 3rd Edition by Suzanne Robertson and James Robertson (Addison-Wesley, 2013)
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffingwell (Addison-Wesley, 2011)
Business Analysis: Best Practices for Success by Steven P. Blais (John Wiley & Sons, Inc., 2012)
Business Analysis, 4th Edition by Debra Paul and James Cadle (BCS, The Chartered Institute for IT, 2020)
A Guide to the Business Analysis Body of Knowledge (BABOK Guide), 3rd Edition (International Institute of Business Analysis, 2015)
Business Analysis for Practitioners: A Practice Guide (Project Management Institute, Inc., 2015)
The PMI Guide to Business Analysis (Project Management Institute, Inc., 2017)
We encourage you to refer to books like those for more information on the topics we discuss here, as well as to learn about other practices you might find helpful. A professional in the requirements field must accumulate a rich tool kit of practices and techniques, along with the experience to know which tool is the best one to use in each situation.
Some books or development frameworks recommend that you discard certain established practices and replace them with others. That’s poor advice. You should add new practices to your tool kit, discarding older ones only when you can replace them with something that’s demonstrably better in all situations. If something works for you, why throw it away?