"Ten Steps to software Requirements" reading notes three

"Ten Steps to software Requirements" reading notes three

Recently read the "Ten Steps to software requirements" the final part, respectively, is the management of the chapter, organized.

Management Chapter

1. Demand management Ideas: demand-engineering requirements The operational activities consist of a total of 10 business activities, comprising 6 operational activities and requirements development in demand planning, which constitute the business line of demand engineering. The goal of demand management activities in demand engineering is to ensure that demand business activities are able to produce high-quality software requirements based on progress requirements, quality requirements and cost requirements.

2. Demand versioning: The software requirements baseline is the integration of the work results document for each stage of the requirements business activity and the version number of the content within the document. The implementation of the baseline work for software requirements is achieved through these work results documents and part of the content version number in the document.

3. Manage change requests: For software development work, every requirement change is not an addition, but a multiplication, although the multiplier is 1, but the multiplier will be due to the level of change in demand to enlarge. So a change in demand is a very serious job.

4. Demand tracking capability: build demand capability matrix The matrix can be used to traverse the various work elements associated with the change requirement when the actual demand change occurs, without being trapped in the demand change. In addition to being able to easily respond to requirements changes, the requirements matrix can also be based on a requirement engineering global management view.

Organizational Chapter

1. Call for the establishment of a demand analysis system "CHOUFSO everyone Light" This does not pay attention to the concept of software needs reflected in a software project is only the appearance, its crux lies in the long-term "light business, heavy technology" concept has been deeply rooted.

2. Organizational structure of the demand analysis sector "what kind of job function will decide what kind of organizational structure to build".

3. Demand Analysis Department management Needs Analysis department management idea is "grasping at both ends, promote the middle, a line of business, specialization division of labor."

4. The Business Work requirement Analysis Department of Demand Analysis department is composed of two parts: demand business and demand development business.

Development is based on demand, and demand development is the main basis for demand planning results. The first thing to do in software requirement development is to obtain the demand, get the target, the system correlation and the use case analysis, secondly, the requirement analysis, the feasibility of the software system, the user interface, the system function, the data, the priority and so on are all in the requirement analysis, then summarizes the requirement analysis specification; Develop a specific development plan.

Demand acquisition is a work activity that identifies and understands the requirements and constraints of different user classes and is the most difficult, critical, and error-prone part of a demand development effort, with the close integration of the requirements architect and the developer to ensure that the work is done with high quality. Requirements Architect collects the customer's laws and regulations, work summary, business planning and information construction guidance and other documents, on the basis of a comprehensive and detailed analysis of these materials, through to the customer's senior and functional departments at all levels to tell their business and listen to their feedback, in the carding results are revised.

Editing the project view and the scope of the document should stand in the technical perspective, and the description of the issues and objectives in the requirements planning should be in the business perspective. Documentation of the project view and scope must be a reference to the outcome of the requirements plan. The description of the project view and scope makes a definition of the scope of the system to be developed.

Use case analysis is a part of the results of demand planning and system correlation analysis of the system using the main body, use case entry, in the use case diagram or use case specification to describe the use case. Force analysis and description are divided into three steps: Collating the system users, refining the use case entries that the system uses for the subject's expectations, and normalizing the description using use case diagrams and use case descriptions. Realism and deduction are the means of comprehensive use of use-case entry refinement.

Demand acquisition is a comprehensive analysis of business matters, and one of the main tasks of demand analysis is to classify and analyze software systems. Demand analysis is based on demand planning and demand acquisition. Functional requirement analysis is the core work of demand analysis is a function of the concept of functional requirements analysis is a functional conceptual design and preliminary logic design, conceptual design of the system is derived from the name and function of the component, the logic is initially set to the system device as a gray box, can see the internal components, just do not know what the component material is. Here the author mentions the white box and the black box many times, the different stage compares the system to the different box, very vividly shows the degree which we can see in the different stage system.

"Ten Steps to software Requirements" reading notes three