Requirements Engineering-Software modeling and analysis reading notes 2

After writing my first reading note, I read the one-week requirement engineering-software modeling and analysis, and felt that something had to be written down before it could turn out to be.

Demand engineering has three main tasks: first, the requirements engineering must demonstrate that the software system will be applied to the environment of extreme objectives, the software functions used to achieve these goals, but also to describe in the design and implementation of these functions when the context of the software to complete the task of the method, the restrictions and constraints imposed by the methods, It is also necessary to explain what the software needs to do and why it needs to be done. Second, demand engineering must reflect the objectives, functions and constraints in the software system, mapping to the feasible software behavior, and the software behavior of the accurate specification. Requirements specification is the most important achievement, is the project planning, design, testing. User manual writing and many other subsequent software development phases of the work of the Foundation. Thirdly, the real world is a changing world, so demand engineering needs to properly deal with the evolution of objectives, functions and constraints over time. At the same time, in order to save expenses and reuse the requirement specification, the requirement engineering needs to consider and deal with the evolution and distribution of the target, function and restraint in the SOFTWARE product family.

The last read of the seventh chapter of the interview on the method of acquiring demand. Interviews make it a very effective way for our software engineers to get the user's needs, and one of the most widely used methods. It is a form of question and answer, a direct dialogue with a specific purpose. , using the Interview method: we can get 1 facts and questions 2 the views of the interviewees 3 the feelings of the Met 4 organizational and personal goals. There are two types of problems in the general interview: 1 Open problem 2 closed problem. Interview structure: 1 pyramid structure 2 funnel structure 3 diamond structure

Interview subjects: System-related stakeholders, and are representative to ensure that each role is covered. How to get stakeholders: who pays for the system and buys the system? Who uses the system: who is affected by the results of the system, and who oversees the system? Who will maintain the system?

Interview questions: the need to ensure that the background is not relevant to ensure the fairness of access to information. The questionnaire can not replace the role of interview in the stage of demand acquisition, the questions and answers of the questionnaire have some guidance, which will affect the result in some way.

      Requirements prototyping: Prototypes are a tool that is widely used in software development and plays a very important role in many stages of development of software systems. The prototype method is to build a system of ancestral roughness as soon as possible, which realizes some or all of the functions of the target system, but the system may be defective in reliability, interface friendliness, or other directions. The purpose of building such a system is to look at the feasibility of a particular aspect. such as the feasibility of the algorithm, the feasibility of the technology, or whether to meet the needs of users and so on. Prototypes are a partial reality before the final system is produced, allowing people to effectively communicate on specific issues based on artifacts, thus helping people to solve the various uncertainties of software development as early as possible. There are two main categories: 1-level prototypes are also called "Behavioral prototypes," which we and business people often talk about as prototypes   Explore some specific behaviors of the expected system and achieve the purpose of refining the requirements. When users consider whether the functionality presented in the prototype can enable them to complete their respective business tasks, the prototype gives the user a more specific view of the issues they are discussing. It starts with business requirements and applies to the requirements phase. 2 Vertical prototypes   is also known as the proof of a structured prototype or concept, enabling a subset of application functions. A vertical prototype can be developed when there may be a technical risk in the expected implementation phase. Vertical prototypes are more commonly used in the design phase of software to reduce risk than in the software's requirements development phase. From the prototype existence life time is divided into discarded prototype and prototype, discarded prototype is not part of the final product, just as exploratory answer some demand questions, refine the requirements and improve the quality of demand. Since these prototypes will eventually be discarded during the development phase, it does not take much effort to build the prototype. Evolutionary prototypes provide a solid development foundation for developing progressive products, as part of the implementation of the product, in the context of clearly defined requirements. Compared to the quick and rough features of a discarded prototype, an evolutionary model must initially have robustness and product-quality-level code. Therefore, it takes more time to build an evolutionary prototype than to build an abandoned prototype for describing the same functionality. An evolutionary prototype must be designed to be easy to upgrade and optimize, so you must focus on the design principles of software system and integrity. There is no shortcut to achieving the quality requirements of an evolutionary prototype. Evolutionary prototypes are typically used when working with schemas.

In short, demand acquisition is the process of acquiring requirements from people, documents, or the environment. The main task of demand analysis needs analysis is to integrate various information through modeling so that people can understand the problem better.

Requirements Engineering-Software modeling and analysis reading notes 2