What are the levels of requirements management maturity?

Demand management is an important part of the whole life cycle of software development, we all know its importance, but it is not easy to do well, I also wrote an online book business analysis and requirements. PDF to explain requirements related content. For each technique and method, as I have written in the Enterprise Architecture Maturity Model (EAMM), we can not be proficient at all, but according to a learning curve progress, this article mainly describes the requirements management maturity of the six levels.

Level 0: No need (no requirements)

There is no clear need to be documented, they assume that they know what to build and want to save time for development, but this is bound to bring confusion to the development effort, because the requirement is a more complex project and it is not possible to define the software function by assuming Doing so is likely to result in a product that is not needed by the user.

Level one: Recorded requirements (written Requirements)

One step up from the messy lack of demand level is simply writing out the requirements. While it's just a simple writing requirement, there are a lot of benefits to be felt compared to the lack of demand levels:

Have a basic agreement with the customer. If written well, the requirements can clearly describe your understanding of the needs of the customer, they can read the requirements to check whether with their thinking of the same development team each member through the need to support their work well. Architects and designers can begin to consider how to architect systems to support customer expectations, or to enable testers to start test cases early, and, of course, to support developers in understanding software requirements to write code requirements that enable new members to quickly understand what the system is

To get these benefits, we also need to pay some costs:

Need someone to take the time to write requirements in order to ensure the timeliness of demand, need to continuously maintain the requirements

Level Two: Organized needs (organized)

The purpose of the requirement is to communicate clearly with users, customers, and other stakeholders, such as the development team, on the solution to the problem. Level two focuses on requirements quality, formatting, security, and storage, and versioning.

Quality: Good demand easy to let you understand, architects, developers and testers can also be very good use of it, the poor demand will lead to a more ambiguous, understanding of differences and so on. Formatting: Requirements must be described in a uniform manner, such as serial numbers, headings, fonts, tables, and so on, to make the document easier to read, understand, and use, and document templates can help us to develop accessibility, security, and versioning in a unified format: when there are many requirements, We often encounter the need to find a place where we don't know where we want to be, and we need to have a unified management requirement.

Level Three: structured requirements (structured)

Level three starts to categorize requirements, are they functional or non-functional requirements? Business requirements or system requirements? Is it a feature or a software requirement? What are the customer, market, and user requirements? Distinguishing these can help us better understand and manage requirements. The previous levels are described in some literal language, and level three is a structured requirement, such as adding some attributes to the requirement.

Level four: Traceability requirements (traced)

Demand itself is hierarchical, from business requirements to user requirements to system requirements, while requirements are associated with development and testing, through traceability management, we know what child requirements and related sibling requirements are affected when a requirement is changed, and what development and test content is affected.

Level Five: Integrated requirements (integrated)

Usually we do a lot of requirements, but there is no integrated approach to bringing requirements directly into development, which can lead to something else. Integrated requirements management processes can be directly imported into software design, change management, testing, and project management. The team takes the requirement as the primary input, and if the requirements are modeled, we can develop the application by modeling the requirements, Openexpressapp is modeled to structure the requirements, and its goal is to make it possible for business engineers to develop applications.