In order to prevent misunderstandings like this there are 2 important things you need to know:
- how to define requirements clearly and
- how to keep track of changes during the development.
How to Define Requirements
Depending on the way you work you need to describe requirements in different ways. In Scrum for example you create User Stories, in waterfall projects use cases or other forms of requirement documentation. Regardless of formal aspects you need to ensure that you have all information that are required for the implementation. To achieve this you only need to follow these 5 steps:
- Identification of stakeholders: To assure that you get all relevant requirements you need to make sure that you know all stakeholders.
- Collect requirements: There are different ways you can find out about requirements, e.g. you can use interviews, case scenarios or prototypes. No matter which method you’re using, you should always find answers to these questions:
- What is the product supposed to do?
- How well should it do it? (e.g. +/- limits, quality, measurable terms)
- Under what conditions? (e.g. environment, states)
- Categorization of requirements: To get a good overview of the requirements you should categorize them. The two major categories are functional and non-functional requirements.
- Interpretation and recording of requirements: Only well defined requirements can be considered adequately in the product. For each requirement you should…
- … define the requirement in detail.
- … prioritize the requirement.
- … analyze the impact of change.
- … resolve conflicting issues by talking to the stakeholders.
- … analyze the feasibility.
- … specify test cases.
- Sign off: Before implementing a requirement you should get the ‘Go’ from the stakeholders.
After you talked to the stakeholders, identified requirements, defined and prioritized them, you have an evaluated list of aspects that need to be considered in the product.
Keep Track of Changes
It is one thing to capture all requirements for a project. The other thing is to ensure that all the requirements are met by the product. The Requirements Traceability Matrix can help you to keep track of all the requirements and associated test cases. The matrix links requirements with derived product specifications and test cases. This is what the matrix looks like:
| ID | Priority | Description | Type | Risks | Specifications | Test Cases |
|---|---|---|---|---|---|---|
| Unique identifier | Priorization | A short description | Functional or non-functional | Associated risks | Link to the detailed description | List of associated test cases (unit, integration, system, user tests, etc.) |
To make sure that a requirement is truly considered in the product, it is necessary that it is described in the product specifications and that it is associated with at least one test case.
If requirements change you have two different options:
- Adjust the requirement specification accordingly and document the changes.
- Add the changed requirement as a new item to the list and treat it like a new requirement.
No matter how you’re dealing with changes, the Requirements Traceability Matrix provides an overview of requirements and associated specifications. So if a specification changes, you can easily see which requirements are involved, and vice versa.
Requirements need to be tracked
Finding out about all requirements of a product and ensuring their implementation is the key to a happy customer. Therefore it is advisable to invest enough time into investigating and defining requirements. In addition to that it is necessary to ensure that the final product meets all requirements. This can only be achieved by considering them in the product specifications and by testing the specifications. This can be ensured by using a Requirements Traceability Matrix.
Top comments (0)