Categorization of requirements means that you group them into meaningful clusters. The question is, why should you consider doing this?

WHY IS REQUIREMENTS CATEGORIZATION IMPORTANT?

Let me first tell you a story about my grandfather. He was a passionate philatelist – he collected stamps. It was his life hobby. Do you collect anything? As a teenager, I collected fossils and postcards with dog breeds. I believe that you have collected something in your life, too. Right?

What do collectors do with their collections? They organize them into meaningful groups.

Photo by Robert Linder on Unsplash

The reason for grouping is to learn about the collection. My grandfather organized his stamps for the following reasons:

When the stamps were organized into groups according to specific characteristics, he had control over them and was consciously exercising his hobby.

Image by Frauke Riether from Pixabay

ANALOGY BETWEEN COLLECTING STAMPS AND REQUIREMENTS

A requirements engineer is like a philatelist. He discovers the requirements by working with stakeholders, writes them down, and organizes them. Organizing (categorizing) requirements offers several benefits. Let us discuss some of them:

1. Better understanding of requirements. When requirements are categorized, it is possible to see patterns and relationships between requirements being a part of the group.

2. Effective communication. Different classes of requirements are essential to different groups of stakeholders. Requirements classes help communicate requirements effectively.

3. Helps to find conflicts and overlaps. Conflicts and overlaps are the most common between requirements in the same class. Categorizing requirements facilitates detecting these two problems with requirements. Additionally, it may facilitate finding requirements that are very similar and can be combined, so-called duplicates.

4. Helps finding omissions. Next to conflicting, overlapping, or duplicate requirements, requirements grouping helps find missing requirements, too. When studying requirements within a particular group, it is easier to spot a missing aspect than if the requirements are a plain, long list without any groupings.

5. Helps with impact analysis. When a change to a requirement is evaluated, the requirements within the same class must be checked to determine whether they are affected, too. It is much easier if these requirements are grouped.

6. Helps with prioritization. Within a particular class of requirements, not all requirements are equally important. Having all requirements for a specific class listed together allows their prioritization within this class. Additionally, we can prioritize requirements classes, e.g., stating that reliability requirements have higher priority than portability requirements. This facilitates better resource allocation and utilization and gives focus to the development team.

7. Contributes to requirements completeness. Predefined categories encourage the team to look at the system from the perspective of each of these categories. It helps to ensure the completeness of a set of requirements.

The INCOSE Guide to Writing Requirements [1] explicitly states that the requirements must be categorized. The guide defines 41 rules to be applied when writing the requirements so that the requirements and the specifications comply with the INCOSE characteristics. The rules that promote the requirements categorization are:

• Rule 29 for an individual requirement recommends allocating requirements to a specific category according to the aspects of the problem or system it addresses,

• Rule 40 for a set of requirements recommends documenting related requirements together.

IMPLEMENTING REQUIREMENTS CATEGORIES

So, how do you implement the requirements categories in your requirements specification?

Karl Wiegers and Candase Hokanson, in their newest book [3] “Software Requirements Essentials – Core Practices for Successful Business Analysis,” also name the importance of adequately grouping the requirements. In practice 15, “Organize requirements in a structured fashion,” they recommend two implementation approaches to requirements grouping:

1. Use well-structured requirements templates where chapters represent the requirements categories. Then, write down requirements that belong to a specific category in a dedicated chapter.

2. If the Requirements Management Tool (RMT) is available, create an attribute containing the predefined categories and fill it in during the requirements analysis.

The starting point for requirements categorization is to identify the relevant and appropriate categories of requirements. As Karl Wiegers and Candase Hokanson [3] suggested, the chapters’ and sections’ titles from the requirements specification form a good starting point. The consequence of this approach is one-dimensional categorization – a requirement belongs to only one category.

Practice teaches us that a requirement does not always neatly fit into one class, so requirements engineers may find requirements categorization difficult. So, are there alternatives?

MULTI-DIMENSIONAL CLASSIFICATION

Sommerville [2] recommends the multi-dimensional classification (a faceted approach). This classification approach allows the assignment of multiple categories to one requirement. The categories are mutually exclusive and collectively exhaustive aspects of a system. New aspects (categories) can be added without a problem. You can compare it to the concept of requirements tagging.

The faceted classification is a flexible scheme. It allows stakeholders to create different views on requirements based on a facet (category) or facet combinations they are interested in. This approach helps stakeholders select groups of requirements most relevant to them. This certainly contributes to effective communication. The contribution to finding omissions, conflicts, or missing requirements increases as different groupings of requirements can be checked.

INCOSE [1] proposes the following aspects (categories):

–Function + Performance represents what the solution shall do with associated performance.

–Fit is the ability to interface with / interact with the external environment within which the solution is intended to operate in different stages of its life cycle.

–Form relates to shape, size, dimensions, as well as programming language or memory usage for software,

–Quality reflects fitness for use (e.g., aspects of ISO 25010),

–Compliance with standards and regulations.

Following this scheme, a requirement can be classified as Function + Performance and Compliance simultaneously.

The categories suggested by INCOSE form a robust basis for projects to start defining their own classification scheme. It is recommended to start with five or six aspects. If one of the categories is perceived as too big then, it is then recommended to split it into sub-aspects, like in the case of quality, we could split into subcategories ISO 25010:

-Functional suitability,

-Performance efficiency,

-Compatibility,

-Usability,

-Reliability,

-Security,

-Maintainability, and

-Portability.

This split of quality aspects would be a new attribute of a requirement.

CONCLUSIONS

There are many benefits of categorizing requirements, as listed earlier in this article. The faceted (multi-dimensional) approach to requirements categorization is recommended to benefit the most from the categorization.

The implementation of this practice requires the following effort:

1. Effort required to define the facets (categories) that are mutually exclusive and collectively exhaustive aspects of a system,

2. Training effort to explain the categories to the users,

3. The application of categories to requirements is just a part of the regular requirements analysis process; no extra effort is expected. However, multiple iterations may be required to finalize the categorization.

Finally, if organizations work document-based, implementing this concept might be slightly more difficult as searching based on categories is challenging to realize in word processing applications. Organizations that work information-based and use requirements management tools gain the most benefits.

References

[1] INCOSE RWG, Guide to Writing Requirements

[2] Ian Sommerville and Pete Sawyer, Requirements Engineering: A good practice guide

[3] Karl Wiegers and Candase Hokanson, Software Requirements Essentials – Core Practices for Successful Business Analysis