Before moving to requirements management, let’s understand what a requirement is? A requirement can be anything from an abstract need to a well drilled down implementation detail of a system. Essentially it can be considered the detailed view of a need under consideration. IEEE Standard Glossary of Software Engineering Terminology defines a requirement as a condition or capability needed by a user to solve a problem or achieve an objective; or a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; or a documented representation of a condition or capability as in former two. Thus what a requirement essentially represents depends on to whom we are talking to – it could be the need to a client; a business requirement for customers; a system requirement for vendors or a specification for a developer and tester. We will come to the different types of requirements later. Requirements Management can be considered the management of requirements essentially from when a customer provides the needs or a product development process is started. It includes managing the definition, elaboration and changing requirements during the development cycle and systems development. Peter Zielczynski, a requirements management expert defines the following major steps in requirements management (Requirements Management Using IBM® Rational® RequisitePro®, Peter Zielczynski).
- Establishing a requirements management plan
- Requirements elicitation
- Developing the Vision document
- Creating use cases
- Supplementary specification
- Creating test cases from use cases
- Creating test cases from the supplementary specification
- System design
This is the first part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation