Attributes of Requirements
From Requirements Management School
Attributes of Requirements are the specific characteristics that each attribute has in common that you want to track and monitor as part of the requirements engineering process. Our overly cautious nature tells us that we want to track everything. Do not fall into that trap. We only need to track and monitor the data that is going to be useful to us. We should only be capturing the significant data that will help us monitor the progress of the project; the status of the requirements; and what items are still outstanding sorted by various criteria.
Of course in order to track and monitor these attributes they have to exist. So we have to create the attributes. You will first need to define the ones that you are going to need. You could start with a few key attributes, as long as you have a system in place that allows for expansion. In reality you should really get all the attributes in place upfront. Even if you cannot start capturing the information until later in the process. You are not going to try and capture unnecessary data this means that most of it should exist already.
Requirements Attributes
Here are the attributes that you will want to be capturing for each requirement in the normal course of events:
- Unique ID – the id of the specific requirement this must be a unique.
- Date Created – when the requirement was created . This helps to indicate whether or not the requirement was part of the requirements baseline or a later addition.
- Current Version – version control is important to ensure that everyone is working on the same version of the requirement.
- Requirement Author – the name of the user or class of user that raised the requirement.
- Assigned To – the person to whom the design/development task has been delegated. This allows the generation of reports by person so that progress and workload issues can be monitored effectively.
- Requirements Status – this should indicate the stage at which the requirement is for example proposed; verified; approved; deleted; implemented; and rejected.
- Priority – this should indicate either the system priority (mandatory/critical/optional) or the priority in relation to other requirements (High/Medium/Low).
- Complexity/Difficulty/Risk – the risk level of this requirement in relation to the success of the project.
- Origin/Source of Requirement – where the requirement originated.
- Requirement Rationale – the reason for inclusion/rejection of the requirement.
- Stability – the likelihood to the requirement changing for instance mature; stable; or still changing.
- Due Date – the date of delivery for this particular requirement.
- Requirement Stakeholders – the stakeholders that should be involved should any change requests be made that impact this requirement.
Additional Characteristics
These are some additional requirements characteristics that you may want to consider:
- Comments – it is always useful to have a place for comments to aid the memory.
- Product – If you have a multiphase release you may want to indicate to which release the requirement is allocated.
- Verification – having the due date tells you when a requirement is due to be released for testing. It can be useful to have the verification method indicated for workload scheduling. So demo; analysis; inspection; walkthrough; and so on.
- Subsystem(s) – the subsystem(s) to which the requirement is allocated.
The above set of characteristics should potentially cover every eventuality. The only other decision you need to make is how you are going to capture this information. That really depends on the size and complexity of the project. For small projects you may be able to use spreadsheet or database software. On larger projects you may want to consider a database or a piece of software that is specifically designed to manage the requirements engineering process.
