Maturity Levels of the Requirements Management Process

From me : Watching software development projects in companies of various sizes, I established myself in the belief that requirements are the basis of success. If a company or project team does not devote time to identifying and managing requirements for the software product they are developing, then the quality of the product will inevitably decline, and such an organization will not be able to remain competitive for a long time. Despite this, most project managers have an extremely superficial understanding of the role of requirements in the software development process, if not at all.

While working on an article on the role of requirements in the software development process, I discovered a scale of maturity levels of the requirements management process (management maturity 'requirements ), proposed in 2003, one of the specialists to work with the requirements of Rational Software Human Jim ( Jim Heumann ).

I want to share this classification with habrahabr readers.

Introduction


The term " maturity " is defined as the complete, completed development of a system. Since any development requires costs, in the context of business this means that the organization makes a decision on the amount of investment in its own development, clearly understanding what benefits it gets.

The following is a scale of maturity levels of the requirements management process, built in analogy with the CMMI model. These models are in no way interconnected, but have some intersection. So, achieving Level 5 (Integration of Requirements) of the maturity of the requirements management process will allow you to get at least Level 3 (Processes are defined at the level of the entire organization) according to the CMMI model. However, this is not a direct consequence, since achieving a high level of maturity in one process does not guarantee a general increase in the maturity of the organization as a whole.

Maturity scale


Level 0. Lack of requirements

This level is typical for teams who believe that the main thing in the software development process is programming (coding), and the absence of requirements is quite acceptable.

In this case, the project team believes that she knows everything in order to immediately begin to develop a software product, and that thanks to the time saved at the stage of collecting, analyzing and documenting requirements, in the future she will be able to pay more attention to programming, since they need to put too much \ too little functionality.

The result is a product that:
  • does not have the required functionality;
  • has excessive functionality;
  • has low quality.

Often, due to the lack of requirements, disputes and misunderstandings arise between members of the project team, and when the staff changes, some of the requirements may simply be lost.

Level 1. Documentation of requirements

The first step in moving from a complete lack of requirements to their appearance is the identification and documentation of requirements. At this stage, the requirements description form is not of particular importance, but the fact of the existence of requirements creates the basis for further work.

Starting to record and save requirements, the project team receives the following benefits:
  • A set of documents appears, from which it clearly follows how the project team understood the needs of the customer. Having agreed with the customer the list of requirements, the project team can unambiguously establish the boundaries of the project, determine the budget and timing of the decision.
  • A document appears, which is the basis for the work of all members of the development team. For example, designers and architects can start working on interfaces and architecture, and testing specialists can prepare test scripts for future functionality.
  • A source of knowledge about the functionality of the created application for new project participants appears.
  • Recording and saving requirements allows you to restore them at any time, which reduces the risks associated with the change of personnel and loss of requirements.

Often at this stage the quality of documents describing requirements (requirements specifications) is low, so project teams resort to checking requirements by subject matter experts or the customer.

Level 2. Organization requirements

Having the documents describing the requirements, the project team is faced with the task of obtaining a set of requirements that clearly, consistently and unambiguously describes the desired behavior of the developed product. In order to receive requirements with the specified quality criteria, it is necessary to adhere to the accepted rules for drawing up specifications, to store them in a place accessible to all project participants, to differentiate access rights to requirements and to keep a history of changes.

If, due to time savings, insufficient attention is paid to the design of specifications, poorly designed text can render even the detailed requirements unnecessary. Observance of elementary rules for formatting documents, such as the use of headings, numbering of figures, the availability of a table of contents, etc., already allows you to make a document readable, understandable, and easy to use. The use of templates adopted at the level of the developer company or provided by the customer can greatly simplify the task of preparing a description of requirements.

The assignment of identifier requirements makes the requirements unique . Placing specifications in a single repository makes requirements accessible, and the delineation of access rights to documentation allows us to guarantee changes only to authorized persons, which ensures integrity requirements . Versioning allows you to provide the project team with the opportunity to work with the current version of the specifications, view the history of requirements change, and also record the persons and the reason for the change in requirements.

At this stage, the main focus is on training the project team in new working methods and additional verification of specifications by testing specialists for completeness and verifiability . As a result, the requirements become better, which leads to a reduction in cost and development time.

Level 3. Structuring requirements

Due to the fact that the nature of the requirements for a software product differs, it is customary to classify them by type. In turn, each type is characterized by a specific set of attributes. Attributes are added as an extension to the textual description of the requirements and contribute to their structuring and increase manageability. Using attributes allows you to track the status of requirements, identify repetitions and contradictions.

Since the types and attributes of requirements are highly dependent on the type of project, the agreements worked out before the start of the project regarding the types of requirements, their attributes, the set of necessary documentation and tasks related to requirements management are made out in a document called the Requirements Management Plan .

Thus, at the third level of maturity, activities are carried out to plan the requirements management process and group the identified requirements by type in accordance with the unifying features, which facilitates management and leads to a better understanding of the requirements for all project participants.

At this level of maturity, it may be necessary to use specialized tools designed to work with requirements.

Level 4. Trace requirements

Achieving the previous three levels of maturity will lead the project team to the fact that it will be possible to determine the relationship between the requirements. Setting relationships ( tracing ) allows you to track the effect of requirements on each other ( impact analysis ) and determine redundant and unaccounted requirements ( coverage analysis ).

Impact analysis is to track the effect of changes in one requirement on changes in other requirements.

Coverage analysis allows, after preparing a set of requirements, to unambiguously determine that the requirements of the upper level (function) are fully detailed and described in the requirements of a lower level (software requirement).

Relationship determination rules and coverage analysis are also defined in the requirements management plan.

Level 5. Integration of requirements

It often happens that the requirements are intended only to develop an agreement with the customer about the desired behavior of the software product being developed, but they are not involved in the development process. This leads to the fact that by the end of the project requirements are becoming obsolete, and the implemented software does not meet user expectations. Therefore, to create software that meets the requirements of the customer, it is necessary that the project team use the requirements as the main input for the development process.

The goal of the fifth maturity level is precisely the integration of the requirements management process into the processes of change management, design, development, testing and project management as a whole.

Of course, such a tight integration is needed in large projects and requires significant costs for the purchase of specialized tools used in software development.

From me again: As mentioned earlier, the decision to achieve a certain level of maturity of the requirements management process should be balanced and based on a clear understanding of the goals and objectives facing the project team or company. Obviously, it is unnecessary to trace the requirements in a startup team consisting of 3-5 people. However, in Russian reality there are still companies that have been developing software for a long time, without even bothering to document. Of course, in such companies the maturity of related development processes is extremely low, which certainly affects the quality of the software products.

Also popular now: