REQM guidance matrix

Who needs REQM?

A look at how this subject has been treated in various reference guides for different disciplines.

REQM in Enterprise Architecture

Togaf (The Open Group Architecture Framework) places requirements management at the centre of its Architecture Development Method (ADM), supporting and interacting with all other phases of the process. ^[1]

REQM's primary purpose is to manage the architecture requirements identified during any phase of the ADM cycle and ensure that they are available for use in the next phases. ^[1]

REQM in Business Analysis

To the IIBA (International Institute of Business Analysis) the purpose of requirements life cycle management is to ensure that business, stakeholder, and solution requirements and designs are aligned to one another and that the solution implements them. ^[2]

In order to achieve this purpose, REQM should not only manage information about requirements (representation of needs), but also about design (solution representation), implementation (solution items) and the stakeholders - or, indeed, any other information relevant to understanding and monitoring the change in its broader, business context. Therefore, the term "requirement" in REQM must be understood as something broader.

The management of requirements does not end once a solution is implemented. Throughout the life of a solution, requirements continue to provide value when they are managed appropriately. ^[2]

Therefore, REQM must be considered not only in a single project context, but throughout the life cycle of a business product, which may be created from an initial project and evolved through several maintenance and improvement stages until discontinued. Every requirement also evolves and is versioned in multiple projects.

REQM in Software Engineering

The SWEEBOK recognizes that the requirements process is not merely a front-end task in software development, but spans the whole software life cycle. ^[3]

From a Software Engineering perspective, change has to be managed by ensuring that proposed changes go through a defined review and approval process and by applying careful requirements tracing, impact analysis, and software configuration management. ^[3]

The Software Requirements knowledge area part of the guide does not have a specific process for REQM, but it directs you to another knowledge area: Configuration Management.

Configuration Management (CM) is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle. ^[3]

Software configuration management (SCM) is a supporting software life cycle process that benefits project management, development and maintenance activities, quality assurance activities, as well as the customers and users of the end product. ^[3]

In this context, some types of requirements are identified as configuration items and kept updated throughout the software lifecycle.

REQM in the Process Maturity Model

CMMI positions Requirements Development in the Engineering Process Area, which covers the development and maintenance activities that are shared across engineering disciplines (as Software Engineering, for example).

However, REQM and CM are positioned in different process areas: ^[4]

In the CM process, work products are identified as configuration items to be stored, traced and kept up to date. As with code, product specifications, hardware and many others, requirements are also presented as an example of possible work products. Therefore REQM and CM overlap, but the former focuses on the project lifecycle and the latter on the product lifecycle.

My personal experience about REQM

Many organizations I've worked with as a consultant or trainer dream of an efficient and well-structured requirements management process, capable of maintaining requirements as configuration items both during projects and product life cycles. I have seen several initiatives to elaborate artefact templates and requirements databases that should be capable of storing all the relevant information for a project or product, and thus, reduce conflicts between clients and suppliers and avoid rework.

Among the expectations of these organizations that invest in REQM, I highlight four different objectives:

1. Structured evaluation and follow-up on investment proposals through a process of prior validation of the initiatives to be carried out (defined review and approval process from ^[3]) with requirements that describe measurable and well-defined objectives that can be pursued during - and measured at the end of - projects.

2. Retention of business knowledge in a knowledge base (as configuration items described in ^[4]) that allows the client team to be independent of the providers who built the solution, with no need to reverse engineer code. The knowledge available from the mapped requirements during previous projects should be used as a source of information to understand the current business rules and the flow of activities in the process.

3. Clear definition of project scope by atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized and intelligible requirements (as recommended by ^[2]), thus maintaining unambiguous agreements between customers and providers to reduce conflicts in the advanced project stages, ensure compliance with deadlines and allow quality control.

4. Impact analysis of each change on current organizational process assets (configuration items), identifying which new assets will need to be created, which ones should be reused, and which ones will need to be modified (as proposed in ^[1]). This analysis makes it possible to speed up maintenance projects a great deal by eliminating the work of re-specifying something that already exists. Only the changes to the new version should be described.

The 5 most common mistakes I've noticed

1. MISTAKE: Exclusively focusing REQM efforts in specifying and maintaining system requirements (functional and non-functional).
   
   This focus assists in achieving success in objective 3 (Clear definition of the project scope for negotiation with providers), but usually fails in the 3 others.
   
   To reach all objectives, requirements should be considered in a broader context than just the system (or software) needs to be implemented in a project.

2. MISTAKE: To believe that business information is known and trivial to all business stakeholders.
   
   The business model, its processes, definitions and rules often only exist in the minds of a few privileged individuals, and there are always inconsistencies between their respective understandings of these.
   
   This information should be mapped and managed within the scope of REQM, including respective traceability mappings to other types of requirements.

3. MISTAKE: To use a single standard model for requirements specification, usually defined in a template, which covers only a subset of requirements types.
   
   Quality assurance processes usually obligate analysts to document in the same format, even if the documentation does not add any value. Alternative forms of documentation are rarely evaluated.
   
   There are different requirement types and each one should be mapped and stored differently. The use of varied modelling techniques may greatly help to understand requirements from different perspectives and to show relationships amongst them.

4. MISTAKE: To consider only the project lifecycle
   
   In the prevailing practices that I observe, REQM typically considers only the current project life cycle and not the life cycle of the product itself. Even when there is a repository representing the product (or business solution, process, service, capacity or system - please generalize the term “product” here), for each project that evolves the product a new specification is generated containing only the changes involved in the project. This specification is added to the product repository in order to "retain the aggregated knowledge". However, the result of this effort is not a complete and up-to-date documentation of the product, but rather, a plethora of project documentation stacks, useless for understanding the whole.
   
   Product information should be identified as configuration items and versioned in each related project in a proper branch repository representing the project.

5. MISTAKE: To define mandatory documentation based on characteristics of each project.
   
   Some companies intend to keep up-to-date documentation of their products, but this update is only done on large projects. Minor adjustments or evolutionary maintenance are excluded from this obligation. Even the changes negotiated during the course of a project are not updated in the documentation. Soon, the product documentation is out of date and falls into disrepute.
   
   The configuration items identified for a product should be updated in each change, regardless of the size or nature of the change.

Two dimensions to guide REQM

My proposal to guide REQM decisions is based on the classification of requirements over two different dimensions as described below:

• Dimension 1: Project x Product
• Dimension 2: Need x Solution

Dimension 1: Project x Product

Projects and Products have different Life Cycles (^[1], ^[3], ^[4]). A project is a temporary endeavour undertaken to create a unique result ^[5]. This result can be the creation of a new product or service, or the modification in an existing product or service. A product undergoes evolution from several projects during its life cycle.

When a requirement is specified, it can be done in the context of a project, or in the context of a product. See some examples:

• Requirement in a project context: "Include the email field in the customer registry."
• Requirement in a product context: "Register customers with name, phone, date of birth and email."

In the first case, the verb to include indicates an action that should be performed only once by the project team over the life of the project. This is probably part of the scope of an initiative to improve a current product.

In the second case, the verb to register refers to a function present in the product, which is executed by a user or an automated system and that will be performed several times while this product exists.

The example I used above is quite simple because the purpose here is to be didactic. I could give other examples at other levels of requirements or using more elaborate modelling techniques, but the important thing you must understand is that there are two ways to write requirements, and both are important. One of them directs the project team to know what needs to be done. The other guides the operation team and retains knowledge about the product.

Dimension 2: Need x Solution

Projects and Products are created and maintained to meet needs.

"A need is a problem to be solved or an opportunity to be explored. A solution is a specific way of meeting one or more needs within a context". ^[2]

Ideally, we start a project by understanding the needs and, from them, we identify different solution alternatives. Next, we detail the solution that best meets the needs considering all the constraints of the current context.

I said "ideally" because (those with a little experience know this) a lot of projects are designed to develop a solution pre-defined in some diffuse process of undocumented analysis that, supposedly, already occurred "somewhere in the past".

Requirements on these projects, created without a clear definition of needs, do not describe the business model, processes and rules. They only declare what must be built. Usually the declared objective of these projects is the development of solutions, rather than meeting needs.

• Example of project objective with emphasis on a solution: “Create XPTO system".
• Example of project objective with emphasis on a need: "Decrease the service time by 20%".

When requirements focus only on the solution, the project team is misled. What were the needs that required this XPTO system? Nobody knows. Or someone knows, but it's not written anywhere. The fact that this information is not available prevents project personnel from asking the following questions:

• "Does the system we are developing meet the needs it should meet?"
• "Is this the best way to meet these needs?"

In the context of REQM, consider that the term requirements needs to encompass both needs and solutions representation. Both may be identified and maintained in a REQM repository, because both can add value. Solutions must be traced to the needs they attend.

But distinguishing need and solution may not be an easy task. This distinction depends heavily on the point of view. What is considered a solution by one stakeholder may be a need for another one. See the example below for different understandings about need and solution from different perspectives.

In the above example, I used the different perspectives proposed in Zachman's Ontology ^[6] to represent how a need of a stakeholder can be derived from a solution of another one. How could we simplify this continuum? In the 2-dimensional model proposed here, I suggest the following distinction:

• need: client viewpoint
• solution: provider viewpoint

The representation of needs must use terms recognized and well understood by the client and provide an understanding of what represents value from the client's point of view. This representation allows the abstraction of the implementation form leaving free alternatives to the providers.

The representation of the solution must use precise technical terms to give clarity to the provider about the context under analysis and the implementation structure adopted (current or future).

For example, in an IT organization (provider) developing and maintaining information systems for other business areas (customers), requirements could be specified:

• focusing on the need: mission, vision, goals, objectives, business processes, business policies and business rules, user manual, product folder, concept model...
• focusing on the solution: system specification, functionality, system components, use cases, data model, systems interfaces...

The 4 quadrants of the REQM guidance matrix

Each requirement may be classified according to the two dimensions presented above. Since each dimension has two different viewpoints, a requirement may be classified into one of the following four quadrants:

While quadrants I and III describe requirements to be consumed by the actual project, which may be discarded after being implemented, quadrants II and IV describe requirements that will be maintained and versioned in every project dealing with the same evolving product.

While the requirements of quadrants I and II use specific terms of the business communities (or users), those in quadrants III and IV tend to use a more technical language, familiar to the technical community (or IT).

The blue arrows represent some possible traceability to be mapped among requirements of the different quadrants.

Requirements examples mapped in the REQM guidance matrix

The illustration below presents an example for a software improvement project for a pizza delivery company. Different requirements types are maintained and tracked in different quadrants of the matrix:

Each cell describes requirements differently, meeting different REQM objectives. It is possible to maintain traceability among all requirements to understand how the different views are related.

This is a simple example to clarify the differences between the quadrants of the REQM guidance matrix. The matrix is not intended to be a template for documenting requirements. Each cell represents a different REQM repository that maintains different types of information. These types must be customized according to the methodology of each organization willing to manage requirements.

A list of possible types of requirements to be maintained in the repositories represented by each different quadrant of the matrix may include:

Objectives x Dimensions

If your organization is investing in an initiative to manage requirements, it is important to first think about what requirements type you are talking about. Each quadrant requires a different specification format and a different management process. The requirements of each quadrant will be read and validated by a different group of stakeholders. Traceability is the feature that will maintain consistency among them. There is no single format that describes requirements in one repository across all dimensions.

Now, do you remember those four objectives presented at the beginning of this article that represent the different expectations I highlighted for REQM? Well, now comes the cool part: each quadrant favours one of them. Look at the chart below and compare the examples noting the relationship.

To achieve only one of these goals, it is not necessary to maintain requirements in formats and repositories other than the one associated with the desired objective.

Conclusion

Requirements may be described and managed in four different ways based on two different dimensions (Project x Product and Need x Solution). Each supports a different objective.

If your organization prioritizes one of these objectives and does not care about the others, do not be shy about focusing your efforts on this one alone and leaving aside other forms of documentation and REQM that will not add value for you.

But, if all of these goals are important to your organization, you will need to manage requirements across all four quadrants. In this case, define your methodology clearly to cover this whole scope and avoid mixing requirements from different quadrants in the same artefact or repository. Keep requirements of different types traced, but as independent configuration items.

This 2-dimensional matrix can help you to think about your goals and REQM plans in a more structured way. It is not intended to be a methodology for managing requirements, but rather as a guide for the development of specific methodologies in each organization.

References

• [1] The Open Group, Open Group Standard, TOGAF® Version 9.1, 2011
• [2] IIBA, BABOK Guide v3 - A Guide to the Business Analysis Body of Knowledge version 3, 2016
• [3] IEEE Computer Society, SWEBOK - A Guide to the Software Engineering Body of Knowledge, Version 3.0, 2014
• [4] CMMI Product Team, CMMI-DEV v1.3 - Capability Maturity Model® Integration for Development, Version 1.3, 2010
• [5] PMI, PMBOK Guide - A Guide to the Project Management Body of Knowledge 4th edition, 2008
• [6] Zachman International, The Zachman Framework for Enterprise Architecture, The Enterprise Ontology, 2011.