Requirements Engineering-Software Requirements mode reading notes 2

Having read the second part of the book today, I feel that there are a lot of things worth studying.

First, 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.

Next, information is the source of business system vitality, the habit is called data processing, but the information has a broader meaning, not just data; two names reflect the core nature of information-input, storage, presentation, reporting, etc., in most systems, especially those that have a role in business operations, So defining the needs of the data and how to deal with it, plays a vital role in the definition of the system. 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.

I need to understand. 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.

Finally, we need to be familiar with demand patterns. The basic demand mode is as follows: 1. Inter-system interface requirement mode 2. Inter-system interaction Demand mode 3. Technical requirement Mode 4. Conform to standard requirements Mode 5. Refer to the demand mode.

Requirements Engineering-Software Requirements mode reading notes 2