软件需求-中职.ppt

1、Requirements Engineering,Du Yugen ,Objectives,After completing this unit, you should be able to know: Requirements Engineering Requirements Engineering Tasks Requirements Management Traceability Tables Initiating Requirements Engineering Process Eliciting Requirements Elicitation Work Products Devel

2、oping Use-Cases Analysis Model Negotiating Requirements Requirement Review (Validation),Requirements Engineering需求工程,InceptionEstablish a basic understanding of the problem and the nature of the solution. ElicitationDraw out the requirements from stakeholders. ElaborationCreate an analysis model tha

3、t represents information, functional, and behavioral aspects of the requirements. NegotiationAgree on a deliverable system that is realistic for developers and customers. SpecificationDescribe the requirements formally or informally. ValidationReview the requirement specification for errors, ambigui

4、ties, omissions, and conflicts. Requirements managementManage changing requirements.,Inception先启阶段,Ask “context-free” questions Who is behind the request for this work? Who will use the solution (product/system)? What will be the economic benefits? How would you characterize “good” output from the s

5、ystem? What problems does this solution address? What environment will the product be used in? Are you the right person to answer these questions? Are these question relevant? Can anyone else provide additional information? Should I be asking you anything else?,Getting Requirements Right,“The hardes

6、t single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” Fred Brooks “The seeds of major software disasters are usually sown within the first three months of commencin

7、g the software project.” Capers Jones “We spend a lot of timethe majority of project effortnot implementing or testing, but trying to decide what to build.” Brian Lawrence,Eliciting Requirements引发需求,Why is it so difficult to clearly understand what the customer wants? Scope The boundary of the syste

8、m is ill-defined. Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives. Understanding Customers are not completely sure of what is needed. Customers have a poor understanding of the capabilities and limitations of the computing environment. Customers d

9、ont have a full understanding of their problem domain. Customers have trouble communicating needs to the system engineer. Customers omit detail that is believed to be obvious. Customers specify requirements that conflict with other requirements. Customers specify requirements that are ambiguous or u

10、ntestable. Volatility Requirements change over time.,Collaborative Requirements Gathering协作需求采集,Meetings are attended by all interested stakeholders. Rules established for preparation and participation. Agenda should be formal enough to cover all important points, but informal enough to encourage th

11、e free flow of ideas. A facilitator controls the meeting. A definition mechanism (blackboard, flip charts, etc.) is used. During the meeting: The problem is identified. Elements of the solution are proposed. Different approaches are negotiated. A preliminary set of solution requirements are obtained

12、. The atmosphere is collaborative and non-threatening.,Quality Function Deployment质量功能部署,Function deployment determines the “value” (to the customer) of each function required of the system. Information deployment identifies data objects and events. Task deployment examines the behavior of the syste

13、m. Value analysis determines the priority of requirements.,Elicitation Work Products,Statement of need and feasibility. Statement of scope. List of participants in requirements elicitation. Description of the systems technical environment. List of requirements and associated domain constraints. List

14、 of usage scenarios. Any prototypes developed to refine requirements.,Use-Cases用例,A use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system. Each scenario answers the following questions: Who is the primary actor, the seconda

15、ry actor(s)? What are the actors goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the story is described? What variations in the actors interaction are possible? What system information wil

16、l the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?,Elements of the Analysis Model分析模型元素,Scenario-based elemen

17、ts Use-caseHow external actors interact with the system (use-case diagrams; detailed templates) FunctionalHow software functions are processed in the system (flow charts; activity diagrams) Class-based elements The various system objects (obtained from scenarios) including their attributes and funct

18、ions (class diagram) Behavioral elements How the system behaves in response to different events (state diagram) Flow-oriented elements How information is transformed as if flows through the system (data flow diagram),Use-Case Diagram用例图,Activity Diagram活动图 for RE,Class Diagram类图,State Diagram,Analys

19、is Patterns,Pattern name: Captures the essence of the pattern. Intent: What the pattern accomplishes or represents. Motivation: A scenario that illustrates how the pattern solves a problem. Forces and context: External issues (forces) that affect how the pattern is used, and external issues resolved

20、 when the pattern is applied. Solution: How the pattern is applied to solve the problem; emphasizes structural and behavioral issues. Consequences: What happens when the pattern is applied; what trade-offs exist during its application. Design: How the pattern can be achieved via known design pattern

21、s. Known uses: Examples of uses within actual systems. Related patterns: Patterns related to the named pattern because they are commonly used with the named pattern; they are structurally similar to the named pattern; they are a variation of the named pattern.,Negotiating Requirements,Identify the k

22、ey stakeholders These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions” Win conditions are not always obvious Negotiate Work toward a set of requirements that lead to “win-win”,Validating Requirements,Is each requirement consistent with the ob

23、jective of the system? Have all requirements been specified at the proper level of abstraction? Is the requirement really necessary? Is each requirement bounded and unambiguous? Does each requirement have attribution? Do any requirements conflict with other requirements? Is each requirement achievab

24、le in the systems technical environment? Is each requirement testable, once implemented? Does the model reflect the systems information, function and behavior? Has the model been appropriately “partitioned”? Have appropriate requirements patterns been used?,Example CRG Meeting,First CRG meeting of t

25、he SafeHome project. After Q&A session (inception meeting), stakeholders write a two page product request, which is delivered to those attending the first CRG meeting. Attendees are asked to make a rough list of objects, services, constraints, and performance criteria for the product. At the meeting

26、, a combined list is created in each topic. Subgroups write mini-specifications for each list item. Relevant features in mini-specifications are added to the list.,Example CRG Meeting,Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The

27、first SafeHome function we bring to market should be the home security function. Most people are familiar with “alarm systems” so this would be an easy sell. The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry, fire, flooding,

28、 carbon monoxide levels, and others. Itll use our wireless sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.,Example CRG Meeting,Objects control panel, smoke detectors, window and door sensors, mot

29、ion detectors, an alarm, an event (sensor has been activated), a display, a PC, telephone numbers, a telephone call, Services configuring the system, setting the alarm, monitoring the sensors, dialing the phone, programming the control panel, reading the display, Constraints System must recognize wh

30、en sensors are not operating, must be user friendly, must interface directly to a standard phone line, Performance criteria Sensor event should be recognized within one second, an event priority scheme should be implemented, ,Example CRG Meeting,Mini-specification for Control Panel The Control Panel is a wall-mounted unit that is approximately 9 X 5 inches in size. The control panel has