Level of maturity requirements management process
From me : Observing software development projects in companies of different scale, I became convinced that requirements are the basis of success. If a company or a project team does not spend time identifying and managing the requirements for the software product they develop, the quality of the product will inevitably decline, and such an organization will not be able to remain competitive in the market for a long time. Despite this, most project managers have a very superficial understanding of the role of requirements in the software development process, or even none 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 ( requirements management maturity ) proposed in 2003 by one of the Rational Software requirements writer Jim Heumann .
I want to share this classification with habrahabr readers.
')
The term “ maturity ” is defined as the complete, accomplished development of a particular system. Since any development requires costs, in the context of business, this means that the organization makes a decision about the amount of investment in its own development, clearly understanding what benefits it receives.
Below is the scale of maturity levels of the requirements management process, similar to the CMMI model. These models are not related to each other, but have some intersection. Thus, the achievement of Level 5 (Integration of Requirements) of the maturity of the requirements management process will allow to obtain at least Level 3 (Processes defined at the level of the entire organization) using the CMMI model. However, this is not a direct consequence, since achieving a high level of maturity in one process does not guarantee an overall increase in the maturity of the organization as a whole.
This level is typical for teams that consider that in the process of developing software the main thing is programming (coding), and the absence of requirements is quite acceptable.
In this case, the project team believes that it knows everything to start developing a software product immediately, and that, thanks to the time saved during the requirements collection, analysis and documentation of requirements, in the future it will be possible to pay more attention to programming, since they need to deliver too much \ too little functionality.
The result is a product that:
Often, on the basis of lack of requirements, disputes and misunderstandings arise between members of the project team, and when changing staff, some of the requirements may simply be lost.
The first step in the transition from the complete absence of requirements for their appearance is the identification and documentation of requirements. At this stage, the form for describing requirements does not matter much, but the fact that there are requirements creates a basis for further work.
By starting to record and save requirements, the project team gains the following benefits:
Often at this stage, the quality of documents describing requirements (specifications of requirements) is low, so project teams resort to checking the requirements by subject matter experts or the customer.
Having the documents describing the requirements, the project team faces the task of obtaining such a set of requirements that is understandable, consistent and unambiguously describes the desired behavior of the product being developed. In order to obtain requirements with the specified quality criteria, it is necessary to adhere to accepted rules for specifying specifications, store them in a place accessible to all project participants, delineate access rights to the requirements and keep a history of changes.
If, due to time savings, the issue of specifying the specifications is not given enough attention, a poorly designed text can make even the detailed requirements described as useless. Observance of elementary rules of formatting documents, such as the use of headings, numbering of pictures, the presence of a table of contents, etc., allows us to make the document readable, understandable and convenient to use. Using templates adopted at the developer’s company level or provided by the customer can greatly simplify the task of preparing a description of requirements.
Assigning identifiers to requirements gives uniqueness to the requirements. Placing the specifications in a single repository allows you to make the requirements accessible , and delimiting the access rights to the documentation ensures that changes are made only to authorized persons, which ensures the integrity requirements. Versioning allows the project team to work with the current version of specifications, view the history of requirements changes, as well as record individuals and the reason for changing requirements.
At this stage, the focus is on teaching the project team new work methods and additional specifications checks by the testing and completeness specialists. As a result, the requirements become better, which leads to a reduction in the cost and development time.
Due to the fact that the nature of requirements for a software product differs, they are usually classified by type. In turn, each type is characterized by a specific set of attributes. Attributes are added as an extension to the text description of requirements and contribute to their structuring and increase manageability. The use of attributes allows you to track the status of requirements, to identify repetitions and contradictions.
Since the types and attributes of requirements are highly dependent on the type of project, the agreements developed 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 documented in a document called the Requirements Management Plan .
Thus, at the third level of maturity, activities on planning the requirements management process and grouping the identified requirements by type in accordance with the unifying characteristics are performed, 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 the requirements.
Achievements of the previous three levels of maturity will lead the project team to the fact that it will be possible to determine the relationship between requirements. Setting relationships ( tracing ) allows you to track the impact of requirements on each other ( impact analysis ) and to determine redundant and unrecorded requirements ( coverage analysis ).
Impact analysis is to track the impact of changes in one requirement to changes in other requirements.
Coverage analysis allows, after preparing a set of requirements, to unambiguously determine that the upper level requirements (function) are fully detailed and described in the lower level requirements (software requirement).
Interconnection rules and coverage analysis are also defined in the Requirements Management Plan.
It often happens that the requirements are intended only to work out an agreement with the customer about the desired behavior of the software product being developed, and in no way participate in the development process. This leads to the fact that by the end of the project requirements become obsolete, and the implemented software does not meet the expectations of users. Therefore, to create software that meets customer requirements, it is necessary for the project team to use the requirements as the main input for the development process.
The goal of the fifth level of maturity is precisely the integration of the requirements management process into change management processes, design, development, testing and project management in general.
Of course, such tight integration is needed in large projects and requires substantial costs for the purchase of specialized tools used in software development.
Again from me : As mentioned earlier, the decision to achieve a certain level of maturity of the requirements management process should be weighed and based on a clear understanding of the goals and objectives of the project team or company. It is obvious that it is unnecessary to engage in tracing requirements in a startup team consisting of 3-5 people. However, in the Russian reality there are still companies that have been developing software for a long time, not even bothering with documentation. Of course, in such companies, the maturity of related development processes is extremely low, which undoubtedly affects the quality of the released software products.
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 ( requirements management maturity ) proposed in 2003 by one of the Rational Software requirements writer Jim Heumann .
I want to share this classification with habrahabr readers.
')
Introduction
The term “ maturity ” is defined as the complete, accomplished development of a particular system. Since any development requires costs, in the context of business, this means that the organization makes a decision about the amount of investment in its own development, clearly understanding what benefits it receives.
Below is the scale of maturity levels of the requirements management process, similar to the CMMI model. These models are not related to each other, but have some intersection. Thus, the achievement of Level 5 (Integration of Requirements) of the maturity of the requirements management process will allow to obtain at least Level 3 (Processes defined at the level of the entire organization) using the CMMI model. However, this is not a direct consequence, since achieving a high level of maturity in one process does not guarantee an overall increase in the maturity of the organization as a whole.
Maturity scale
Level 0. No Requirements
This level is typical for teams that consider that in the process of developing software the main thing is programming (coding), and the absence of requirements is quite acceptable.
In this case, the project team believes that it knows everything to start developing a software product immediately, and that, thanks to the time saved during the requirements collection, analysis and documentation of requirements, in the future it will be possible to pay more attention to programming, since they need to deliver too much \ too little functionality.
The result is a product that:
- does not have the required functionality;
- has excessive functionality;
- has low quality.
Often, on the basis of lack of requirements, disputes and misunderstandings arise between members of the project team, and when changing staff, some of the requirements may simply be lost.
Level 1. Documenting Requirements
The first step in the transition from the complete absence of requirements for their appearance is the identification and documentation of requirements. At this stage, the form for describing requirements does not matter much, but the fact that there are requirements creates a basis for further work.
By starting to record and save requirements, the project team gains 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 the timing of the implementation of the decision.
- A document appears that 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 staff changes and loss of requirements.
Often at this stage, the quality of documents describing requirements (specifications of requirements) is low, so project teams resort to checking the requirements by subject matter experts or the customer.
Level 2. Organization requirements
Having the documents describing the requirements, the project team faces the task of obtaining such a set of requirements that is understandable, consistent and unambiguously describes the desired behavior of the product being developed. In order to obtain requirements with the specified quality criteria, it is necessary to adhere to accepted rules for specifying specifications, store them in a place accessible to all project participants, delineate access rights to the requirements and keep a history of changes.
If, due to time savings, the issue of specifying the specifications is not given enough attention, a poorly designed text can make even the detailed requirements described as useless. Observance of elementary rules of formatting documents, such as the use of headings, numbering of pictures, the presence of a table of contents, etc., allows us to make the document readable, understandable and convenient to use. Using templates adopted at the developer’s company level or provided by the customer can greatly simplify the task of preparing a description of requirements.
Assigning identifiers to requirements gives uniqueness to the requirements. Placing the specifications in a single repository allows you to make the requirements accessible , and delimiting the access rights to the documentation ensures that changes are made only to authorized persons, which ensures the integrity requirements. Versioning allows the project team to work with the current version of specifications, view the history of requirements changes, as well as record individuals and the reason for changing requirements.
At this stage, the focus is on teaching the project team new work methods and additional specifications checks by the testing and completeness specialists. As a result, the requirements become better, which leads to a reduction in the cost and development time.
Level 3. Structuring requirements
Due to the fact that the nature of requirements for a software product differs, they are usually classified by type. In turn, each type is characterized by a specific set of attributes. Attributes are added as an extension to the text description of requirements and contribute to their structuring and increase manageability. The use of attributes allows you to track the status of requirements, to identify repetitions and contradictions.
Since the types and attributes of requirements are highly dependent on the type of project, the agreements developed 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 documented in a document called the Requirements Management Plan .
Thus, at the third level of maturity, activities on planning the requirements management process and grouping the identified requirements by type in accordance with the unifying characteristics are performed, 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 the requirements.
Level 4. Tracing requirements
Achievements of the previous three levels of maturity will lead the project team to the fact that it will be possible to determine the relationship between requirements. Setting relationships ( tracing ) allows you to track the impact of requirements on each other ( impact analysis ) and to determine redundant and unrecorded requirements ( coverage analysis ).
Impact analysis is to track the impact of changes in one requirement to changes in other requirements.
Coverage analysis allows, after preparing a set of requirements, to unambiguously determine that the upper level requirements (function) are fully detailed and described in the lower level requirements (software requirement).
Interconnection rules and coverage analysis are also defined in the Requirements Management Plan.
Level 5. Integration requirements
It often happens that the requirements are intended only to work out an agreement with the customer about the desired behavior of the software product being developed, and in no way participate in the development process. This leads to the fact that by the end of the project requirements become obsolete, and the implemented software does not meet the expectations of users. Therefore, to create software that meets customer requirements, it is necessary for the project team to use the requirements as the main input for the development process.
The goal of the fifth level of maturity is precisely the integration of the requirements management process into change management processes, design, development, testing and project management in general.
Of course, such tight integration is needed in large projects and requires substantial costs for the purchase of specialized tools used in software development.
Again from me : As mentioned earlier, the decision to achieve a certain level of maturity of the requirements management process should be weighed and based on a clear understanding of the goals and objectives of the project team or company. It is obvious that it is unnecessary to engage in tracing requirements in a startup team consisting of 3-5 people. However, in the Russian reality there are still companies that have been developing software for a long time, not even bothering with documentation. Of course, in such companies, the maturity of related development processes is extremely low, which undoubtedly affects the quality of the released software products.
Source: https://habr.com/ru/post/240433/
All Articles