What Are Common Requirement Attributes?
How can you specify what you need? And how can you best work with attributes?
An attribute is a requirement property like e.g. its name or its priority. What attributes you need for your requirements can be specified in their simplest form in tables (templates).
Depending on the project, organization, application area but also the type of requirement, the attributes that you can use for their documentation are different. Here you can see a selection of the most commonly used ones.
Specific information can be determined for each requirement. Structured logging of this information is a tried and tested method for ensuring that this information is documented consistently and changes to it can be traced at any time. The IREB tasks are a useful point of reference when working with requirement attributes. These will be summarized below.
How Do You Specify Attributes?
A variety of attributes can be used for requirements. You can create templates to define which ones you need. A template could be a table structure, for example, in which you list attribute types with a short description. Make sure that the attributes can be differentiated between according to attribute type: for example, different information has to be documented for functional requirements than for non-functional.
A more visually appealing alternative is defining attributes with class diagrams. Then the requirement is simply a class that you can specify the desired properties for. The advantage of this method is that you can model relationships to other elements straight away, for example, the relationship between requirement and risk (by the way, you can also specify attributes for risks and other entities like use cases, test cases or change requests).
A short definition of requirement attributes:
An attribute is a property in which information can be stored systematically.
Common Requirement Attributes
Below is a list of the most common attributes that can be used as a template (suggested by IREB):
- ID
- Name
- Description
- Version
- Author
- Source (e.g. the goal or stakeholder from which the requirement comes)
- Reason
- Stability (e.g. stabile, fixed, consolidated)
- Related risks
- Criticality
- Priority (e.g. low, medium, high, critical)
More Possible Attributes
There are additional attributes for requirements, for example:
- Person in charge
- Requirement type (e.g. functional requirement, performance requirement, quality requirement)
- Verification status
- Workload
- Release
- Legal obligation (e.g. obligation, desire, intention)
- Cross references
How To Work with Requirements Attributes in Practice
Learn more about requirements engineering with objectiF RPM or objectiF RM »
How Do You Decide the Attributes You Need?
The attributes you select depend on the following four factors:
Projektmerkmale
Wie groß ist das Projekt? Welche Risiken birgt das Projekt?
Eigenschaften und Vorschriften des Anwendungsgebiets
Welche Referenzmodelle gibt es? Gibt es Vorschriften zur Modellierung?
Unternehmensvorgaben
Welche Standards setzt das Unternehmen ein? Welche Vorschriften hat es?
Randbedingungen und Restriktionen des Entwicklungsprozesses
Müssen Sie das Haftungsrecht beachten? Gibt es Prozessstandards?
Project Features
How large is the project? What are the hidden risks?
Business Provisions
What are the business’s standards? What provisions does it have?
Properties and Regulations of the Field of Application
What are the reference models? Are there modelling instructions?
Frameworks and Development Process Restrictions
Do you have to observe liability laws? Are there process standards?
Document Information for Requirements
In practice, requirements or information for different attributes are normally documented with one tool: MS Excel. There, you can create a table and define individual columns as requirement attributes. But requirements engineering comes to its limits pretty quickly with this tool: references to other elements like templates for requirements have to be maintained manually, for example, as soon as a new folder structure is created or a file moved. That’s a lot of work in large and complex projects that sometimes have thousands of requirements.
It is more efficient to work with a special requirements engineering tool where it’s easier to create attributes for requirements of different types (functional vs. non-functional, etc.) and later fill them in with information. At the same time, such a tool ensures traceability of requirements and can, for example, quickly list changes of attribute information between different versions of a requirement. Here, you can see a comparison:
Comparison of two versions of requirements – changes to individual attributes are listed in detail.
In such a requirements engineering tool, you often use forms that provide the definied attributes to capture requirements. They are similar to views on the requirements that only display specific attributes, for example. You can even create relationships to other project results such as goals or test cases in these forms:
Knowledge to go
Handling requirements and their attributes with software – objectiF RM
The Biggest Advantage of Attributes: Simple Evaluation
Once the requirements information is recorded with structure via attributes, you can specifically access them according to your needs. A simple example: Display all the requirements with their derived test cases if available and only with the ID, name and state of these elements. This way, you can keep an overview, despite large projects and increased complexity.
Example: A list with requirements and linked test cases
