chapter-4(软件工程双语).pptVIP

Chapter 4 Capturing the Requirements Learning objectives Explain why it is necessary to elicit requirements from software customers, and the role of requirements in the software life-cycle Identify the characteristics that make individual requirements good or bad; Describe the types of requirements that should be included in a requirements document; Describe the notations and methods that can be used for capturing requirements Explain how and why requirements reviews should be done to ensure quality Describe how to document requirements for use by the design and test teams 4.1 THE REQUIREMENTS PROCESS requirement A requirement is an expression of desired(渴望的) behavior The goal of the requirements phase is to understand the customer’s problem and needs During the specification phase, we will decide which requirements will be fulfilled(履行) by our software system; During the design phase, we will devise a plane for how the specified behavior will be implemented The person performing requirement tasks usually is called requirements analyst or systems analyst 4.1 THE REQUIREMENTS PROCESS Process for capturing the requirements, 4.2 REQUIREMENTS ELICITATION Requirements elicitation is an especially critical part of the process. We must use a variety of techniques to determine what the users and customers really want.It is only by discussing the requirements with everyone who has a stake in the system, coalescing(接合) these different views into a coherent(粘在一起的, 一致的, 连贯的) set of requirements and reviewing these documents with these stakeholders that we all come to an agreement about what the requirement are. So who are the stakeholders(股东) Clients Customer Users Domain experts Market researchers Lawyer or auditors Software engineers 4.3 TYPE OF REQUIREMENTS functional requirement describes requirement behavior in terms of required activities. A quality requirement, or nonfunctional requirement, describes some quality characteristic that the software solution