Requirement
In this chapter, we described various ways of documenting requirements and explained that requirements could be represented by anything between a simple textual statement and a complex business workflow model. For this reason, there cannot be a universal template for documenting something as abstract as a requirement, so the template below limits just to a description of requirement attributes and related artifacts.
The following table lists the most common requirements attributes. Some are set automatically, some are entered manually by the analyst, but all of them are stored in the EA requirement element and automatically generated to the page:
| Attribute | Description | Filling |
|---|---|---|
| Date Created | Date when the requirement was added into repository | Filled automatically by EA, predefined EA field |
| Author | Person who created the element | Filled automatically by EA, can be manually changed, predefined EA field |
| Status | Requirement status, for example proposed or verified | Manually set, predefined EA field |
| Priority | Indicates which requirement should be implemented first | Manually set, predefined EA field |
| Difficulty/Complexity | More complex means bigger effort | Manually set, predefined EA field |
| Origin | Can be a stakeholder name, reference to a requirements workshop, etc. | Manually set, tagged value |
| Due Date/Phase/Release | Requirements don't need to be implemented in one go. Indicates product version, release, or just the date when it needs to be implemented. | Manually set, predefined EA field, tagged value if the value needs to be constrained |
| Stakeholders | Stakeholders who contribute to the requirement or who are affected by it | Manually set, tagged value |
Note: None of the attributes is mandatory. The presented list shows just attributes that could be used if the information is important. For example, it does not make sense to fill Stakeholders if all requirements are defined by a single person.