02 Software Requirement mode

Requirement Pattern: A method that defines a specific type of requirement. Demand patterns are applied to a single requirement, helping to define a single requirement at a time. Benefits of using the demand model: first, the requirements model provides guidance on what information to include, to advise, to alert common flaws, and to identify other issues that should be considered. Second, the demand pattern saves time: there is no need to write each requirement from the beginning, because the pattern gives the right starting point and the basis for development. Thirdly, the demand pattern promotes consistency of the same type of demand. Providing guidance is of the greatest value. Saving defined time and increasing consistency is good, but reasonable guidance can get better demand and avoid the big trouble in the follow-up work.

The requirements model provides guidance that is often more thorough than just "for example". It gives insight into what's going on. It can help raise questions. In some cases, it can lead to writing one (or more) requirements that are very different from first impressions. Answering a big question often leads to a lot of small problems. The demand model answers the big questions and turns them into smaller problems.

Some demand patterns require or encourage the definition of additional requirements: including follow-up requirements: the need to expand the initial requirements, and the system-wide requirement of universality: the need to support the model itself. This checks to see if each requirement needs additional support requirements and whether they are already defined.

Patterns have different levels of detail and value. Some types of requirements can be defined in very detail, and their instances are almost the same. Other types of demand, while there are some things that are generally valuable, are so changeable that they cannot even describe what should be expressed. These changes are normal. The pattern only needs to prove itself to be valuable; it doesn't have to do all the things that the pattern might do. On the other hand, repeated encounters with a particular demand do not imply that this pattern of demand is inherently valuable. If it is difficult to generalize the commonality of this requirement, it is difficult to guide how to define this type of demand.

Demand patterns need to describe when to use patterns and how to write requirements based on patterns. It also provides hints on how to implement and how to test this requirement. Each requirement pattern consists of the following elements: 1) Basic details 2) Applicability 3) Discussion 4) content 5) template 6) Instance 7) additional requirements 8) Development Considerations 9) Test considerations.

The demand model is free to use infrastructure in other areas. But it is best to avoid interdependence, so if one domain relies on another, then the latter area should not be dependent on the previous one-if it can be avoided. One infrastructure can also rely on another infrastructure. Each infrastructure overview is divided into the following subsections: 1) to explain the rationale for the existence of the infrastructure and the role it plays. 2) Call for recommendations on requirements definitions of how the system interacts with the infrastructure-the infrastructure must provide these capabilities to the system-and other capabilities expected by the system. The required functionality can be seen as an interface that the infrastructure provides to the caller. 3) The idea of implementing the requirements in order to get the infrastructure to stand up for some of the features needed for the foot. These are relatively brief, just to remind you of the possible major functional domains to consider when defining the infrastructure.

When several requirements patterns have a common feature, you can create a requirement pattern group that describes their common aspects without having to repeat them in each pattern. A demand pattern group is not a requirement pattern: this type of requirement cannot be established. However, a group can contain any of the following occurrences in the definition of a requirement pattern: "Additional requirements", "Development Requirements", and "Test requirements". The principle of including which part and omitting other parts is whether there are some things worth saying. At any time, if a part appears in the demand mode group, the corresponding part of the pattern should contain a note that reminds you of the requirement pattern group.

The difference between a domain and a demand pattern group is that the patterns in the domain share a theme, whereas patterns in a pattern group have common detail characteristics. Patterns in a group do not necessarily belong to the same domain.

When using a demand pattern, you should describe everything you need to know to build this type of demand. But a pattern may refer to other schemas for some reason. There are two basic types of relationships between demand patterns: 1) Referencing a requirement pattern can refer to another pattern in the definition. 2) Expand one requirement pattern to develop on the basis of another model. In object-oriented terminology, this is an inheritance relationship. In addition to extending another pattern, the requirement pattern can be extended to a demand pattern group.

Keep the initial requirements, but split them into multiple parts, making them additional requirements, which is refining the main requirements. Each refinement requirement should define a particular aspect. Each refinement should define the requirements it relies on.

02 Software Requirement mode