Requirements As Artifacts

An artifact is a uniquely identifiable object complemented with metadata that describes its attributes. If a requirement is labeled with a unique id and is supplemented with additional attributes, it effectively becomes an artifact - it could be stored in a database and queried. However, not all requirements are managed as artifacts. Some requirements are not standalone objects, they cannot be referenced, and a relationship to other requirements cannot be created. In the following example, the "Select Existing Customer" wizard step requirement is an artifact that has attributes and is stored in the requirements repository. On the other hand, the requirement for paging is just a note, so it is not an object, it cannot have attributes and cannot be traced to other requirements.

For small projects or projects where the requirements are clear and stable, requirements could be managed as a bullet list or in a simple excel sheet. However, when the number of requirements is big or when the project applies a formal requirements management, it might be necessary to record the requirements in a repository as objects so that it is easier to generate requirements reports and trace requirements to other artifacts.

Requirements Granularity

Requirements are never a flat list of "System shall" statements. Some are more general than others, so they typically form hierarchies, trees of requirements, each level holding requirements of different level of detail:

The question is, which levels of requirements should be stored in the requirements repository as objects. In the example above, all requirements are represented as identifiable objects, so the granularity is high in this case. They all have a unique id such as "REQ1-1-1", they all could hold additional attributes and could be automatically processed - it is possible to query them, export them, or track relationships between them. In general, the more granular the requirements are, the more automation could be applied because even the smallest requirements are represented by an object and hence can hold additional attributes. However, it comes at a price. The average project could contain hundreds of requirements and managing each of them separately as an object would present an enormous overhead. Therefore, the goal is to capture the requirements in the most lightweight form, which still enables you to track the information you need in the given situation. In practice, not all requirements need to be stored as objects in the database. If all child requirements come from one stakeholder, it will be implemented in the same release, and they share the same attributes, there is no point in storing them as objects and adding up complexity. The analyst should choose an approach that will best meet the needs of a particular project.

Requirements hierarchy above holds the same information as the previous one, but in this case, only half of the requirements are objects with an id, the rest is captured in the form of a note. Such setup is more lightweight, presents less maintenance overhead yet is still sufficient for this project.

Requirement Attributes

Think of the requirement artifacts as objects with properties. These objects have a textual description and also attributes which specify their characteristics. They can be stored in a document, in a spreadsheet, or in some kind of a database. Of course, storing them in a tabular form instead of documents has advantages as it is possible to query, sort, and filter them - for example, it is possible to filter all "Requirements which were created in 03/2018" and sort them by the author's name. The amount of metadata should not be ordered and should be selected in accordance with the needs of the particular project: for example, if all requirements are requested by a single stakeholder, it does not make sense to record the "Author" attribute for every requirement. Similarly, if the project is done in one phase, filling a "Phase" attribute is a pure waste of time. The following table shows the most common requirements attributes: