1、 2010 Sichuan University All rights reserved. | Confidential1Chapter 5 Requirements Engineering Requirements Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Requirements ManagementContent 2010 Sichuan University All rights reserved. | Confidential2Requirement

2、s Engineering TasksInceptionask a set of questions that establish basic understanding of the problemthe people who want a solutionthe nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developerElicitationelicit r

3、equirements from all stakeholdersElaborationcreate an analysis model that identifies data, function and behavioral requirementsNegotiationagree on a deliverable system that is realistic for developers and customers 2010 Sichuan University All rights reserved. | Confidential3Requirements Engineering

4、TasksSpecificationcan be any one (or more) of the following:A written documentA set of modelsA formal mathematicalA collection of user scenarios (use-cases)A prototypeValidationa review mechanism that looks forerrors in content or interpretationareas where clarification may be requiredmissing inform

5、ationinconsistencies (a major problem when large products or systems are engineered)conflicting or unrealistic (unachievable) requirements. Requirements management 2010 Sichuan University All rights reserved. | Confidential4InceptionIdentify stakeholders“who else do you think I should talk to?”Recog

6、nize multiple points of viewWork toward collaborationThe first questionsWho is behind the request for this work?Who will use the solution?What will be the economic benefit of a successful solutionIs there another source for the solution that you need? 2010 Sichuan University All rights reserved. | C

7、onfidential5Eliciting RequirementsMeetings are conducted and attended by both software engineers and customersRules for preparation and participation are establishedAn agenda is suggested A facilitator (can be a customer, a developer, or an outsider) controls the meetingA definition mechanism (can b

8、e work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is usedThe goal is to identify the problempropose elements of the solutionnegotiate different approaches, andspecify a preliminary set of solution requirements 2010 Sichuan University All rights

9、 reserved. | Confidential6Eliciting Requirements 2010 Sichuan University All rights reserved. | Confidential7Quality Function DeploymentThree types of requirementsNormal requirementsExpected requirementsExciting requirementsFunction deployment determines the “value” (as perceived by the customer) of

10、 each function required of the systemInformation deployment identifies data objects and eventsTask deployment examines the behavior of the systemValue analysis determines the relative priority of requirements 2010 Sichuan University All rights reserved. | Confidential8Elicitation Work ProductsA stat

11、ement of need and feasibility.A bounded statement of scope for the system or product.A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the systems technical environment.A list of requirements (preferably organized by function) and the do

12、main constraints that apply to each.A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.Any prototypes developed to better define requirements. 2010 Sichuan University All rights reserved. | Confidential9Elaboration: Building the A

13、nalysis ModelElements of the analysis modelScenario-based elementsFunctionalprocessing narratives for software functionsUse-casedescriptions of the interaction between an “actor” and the systemClass-based elementsImplied by scenariosBehavioral elementsState diagramFlow-oriented elementsData flow dia

14、gram 2010 Sichuan University All rights reserved. | Confidential10Use-CasesA collection of user scenarios that describe the thread of usage of a systemEach scenario is described from the point-of-view of an “actor”a person or device that interacts with the software in some wayEach scenario answers t

15、he following questions:Who is the primary actor, the secondary actor (s)?What are the actors goals?What preconditions should exist before the story beginsWhat main tasks or functions are performed by the actor?What extensions might be considered as the story is described?What variations in the actor

16、s interaction are possible?What system information will 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? 2010 Si

17、chuan University All rights reserved. | Confidential11Use-Cases Diagram 2010 Sichuan University All rights reserved. | Confidential12Class DiagramFrom the SafeHome system 2010 Sichuan University All rights reserved. | Confidential13State Diagram 2010 Sichuan University All rights reserved. | Confide

18、ntial14Data Flow DiagramConfiguration Information AssessagainstsetupReadsensorFormatfordisplayGeneratealarmsignalDialphoneSensorstatusSensor ID,typeConfigurationdataSensor IDtype, locationSensorinformationAlarmdataAlarmtypeTelephonenumberTelephonenumber tones 2010 Sichuan University All rights reser

19、ved. | Confidential15Analysis PatternsPattern name: A descriptor that captures the essence of the pattern. Intent: Describes what the pattern plishes or represents Motivation: A scenario that illustrates how the pattern can be used to address the problem.Forces and context: A description of external

20、 issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied. Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.Consequences: Addresses what happen

21、s when the pattern is applied and what trade-offs exist during its application.Design: Discusses how the analysis pattern can be achieved through the use of known design patterns.Known uses: Examples of uses within actual systems.Related patterns: One or more analysis patterns that are related to th

22、e named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern. 2010 Sichuan University All rights reserved. | Confidential16Negotiating RequirementsIdentify the key stakeholdersThese are the peo

23、ple who will be involved in the negotiationDetermine each of the stakeholders “win conditions”Win conditions are not always obviousNegotiateWork toward a set of requirements that lead to “win-win” 2010 Sichuan University All rights reserved. | Confidential17Validating Requirements-1Is each requireme

24、nt consistent with the overall objective for the system/product?Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?Is the requirement really necessary or does it represent an a

25、dd-on feature that may not be essential to the objective of the system?Is each requirement bounded and unambiguous?Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? 2010 Si

26、chuan University All rights reserved. | Confidential18Validating Requirements-2Is each requirement achievable in the technical environment that will house the system or product?Is each requirement testable, once implemented?Does the requirements model properly reflect the information, function and b

27、ehavior of the system to be built.Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consiste

28、nt with customer requirements? 2010 Sichuan University All rights reserved. | Confidential19Requirements ManagementFeature traceability tableSource traceability tableDependency traceability tableSubsystem traceability tableInterface traceability tableA set of activities that help the project team id

29、entify, control, and track requirements and changes to requirements at any times. 2010 Sichuan University All rights reserved. | Confidential20ExerciseIn requirements validation the requirements model is reviewed to ensure its technical feasibility. TrueFalseIn win-win negotiation, the customers nee

30、ds are met even though the developers need may not be. TrueFalseWhich of the following is not one of the context-free questions that would be used during project inception? What will be the economic benefit from a good solution? Who is against this project? Who will pay for the work? Who will use th

31、e solution? The use of traceability tables helps to debug programs following the detection of run-time errors determine the performance of algorithm implementations identify, control, and track requirements changes none of the above 2010 Sichuan University All rights reserved. | Confidential21Exerci

32、se5. The system specification describes the Function, performance and constraints of a computer-based system implementation of each allocated system element software architecture time required for system simulation 6. Use-case actors are always people, never system devices. a. True b. False 7. Which

33、 of the following is not one of the requirement classifications used in Quality Function Deployment (QFD)? exciting expected mandatory normal 8. Develop a complete use-case for one of the following activities.Making a withdrawal at an ATM Using your charge card for a meal at a restaurant Searching f

34、or books (on a specific topic) using an on-line bookstore 2010 Sichuan University All rights reserved. | Confidential22Chapter 6 Requirement Analysis An overview of requirements analysis Analysis Modeling Approaches Data Modeling Flow-Oriented Modeling Object-Oriented Analysis Scenario-Based Modelin

35、g Class-Based Modeling Creating a behavioral model Specification guidelinesContent 2010 Sichuan University All rights reserved. | Confidential23Requirements AnalysisRequirements analysis specifies softwares operational characteristicsindicates softwares interface with other system elements establish

36、es constraints that software must meetRequirements analysis allows the software engineer (called an analyst or modeler in this role) to:elaborate on basic requirements established during earlier requirement engineering tasksbuild models that depict user scenarios, functional activities, problem clas

37、ses and their relationships, system and class behavior, and the flow of data as it is transformed. 2010 Sichuan University All rights reserved. | Confidential24A Bridge 2010 Sichuan University All rights reserved. | Confidential25Rules of ThumbThe model should focus on requirements that are visible

38、within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.Delay consideration of in

39、frastructure and other non-functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be. 2010 Sichuan University All rights reserved. | Confidential26Domain AnalysisDefine the dom

40、ain to be investigated.Collect a representative sample of applications in the domain.Analyze each application in the sample.Develop an analysis model for the objects. 2010 Sichuan University All rights reserved. | Confidential27Analysis Modeling ApproachesStructured AnalysisData and ProcessesObject-

41、oriented AnalysisClasses and Unified Process (UML)Analysis ModelCombine features of above both approaches Use-cases textUse-case diagramsActivity diagramsSwim lane diagramsScenario-basedelementsClass diagrams Analysis packagesCRC modelsCollaboration diagramsClass-basedelementsState diagramsSequence

42、diagramsBehavioralelementsData flow diagramsControl flow diagramsProcessing diagramsFlow-orientedelementsAnalysis Model 2010 Sichuan University All rights reserved. | Confidential28Data Modelingexamines data objects independently of processingfocuses attention on the data domaincreates a model at th

43、e customers level of abstractionindicates how data objects relate to one another 2010 Sichuan University All rights reserved. | Confidential29What is a Data Object?Data Object: something that is described by a setof attributes (data items) and that will be manipulated within the software (system)eac

44、h instanceof an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the systemi.e., the system could not function without access to instances of the objecteach is described by attributes that are themselves data items 2010 Sichuan University All rights rese

45、rved. | Confidential30Typical Data Objects external entities (printer, user, sensor) things (e.g. reports, displays, signals) occurrences or events (e.g. interrupt, alarm) roles (e.g. manager, engineer, salesperson) organizational units (e.g. division, team) places (e.g. manufacturing floor) structu

46、res (e.g. employee record) 2010 Sichuan University All rights reserved. | Confidential31Data Objects and AttributesA data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the objectobject: automobileattributes: Make Model ID number Body type Color

47、Owner 2010 Sichuan University All rights reserved. | Confidential32What is a Relationship?relationship: indicates “connectedness”; a fact that must be remembered by the system and cannot or is not computed or derived mechanicallyseveral instances of a relationship can existdata objects can be relate

48、d in many different ways 2010 Sichuan University All rights reserved. | Confidential33ERD Notationobjectobjectrelationship1211objectobjectrelationship121nobjectobjectrelationship12nm 2010 Sichuan University All rights reserved. | Confidential34The ERD: An Example1norderCustomerProductconsistsofm1Par

49、tsworkersproducedbykpselectedfromCompanyw1 2010 Sichuan University All rights reserved. | Confidential35Flow-Oriented ModelingRepresents how data objects are transformed at they move through the systemA data flow diagram (DFD) is the diagrammatic form that is usedConsidered by many to be an old scho

50、ol approach, flow-oriented modeling continues to provide a view of the system that is uniqueit should be used to supplement other analysis model elements 2010 Sichuan University All rights reserved. | Confidential36The Flow ModelEvery computer-based system is an information transform .computerbaseds

51、ysteminputoutput 2010 Sichuan University All rights reserved. | Confidential37Flow Modeling Notationexternal entityprocessdata flowdata store 2010 Sichuan University All rights reserved. | Confidential38External EntityA producer or consumer of dataExamples: a person, a device, a sensorAnother exampl

52、e: computer-basedsystemData must always originate somewhereand must always be sent to something 2010 Sichuan University All rights reserved. | Confidential39ProcessA data transformer (changes inputto output)Examples: compute taxes, determine area,format report, display graph Data must always be proc

53、essed in some way to achieve system function 2010 Sichuan University All rights reserved. | Confidential40Data FlowData flows through a system, beginningas input and be transformed into putetriangle areabaseheightarea 2010 Sichuan University All rights reserved. | Confidential41Data StoresData is of

54、ten stored for later use.look-upsensordatasensor #report requiredsensor #, type, location, agesensor datasensor numbertype, location, age 2010 Sichuan University All rights reserved. | Confidential42Data Flow Diagramming: Guidelinesall icons must be labeled with meaningful namesthe DFD evolves throu

55、gh a number of levels of detailalways begin with a context level diagram (also called level 0)always show external entities at level 0always label data flow arrowsdo not represent procedural logic 2010 Sichuan University All rights reserved. | Confidential43Constructing a DFD Ireview the data model

56、to isolate data objects and use a grammatical parse to determine “operations”determine external entities (producers and consumers of data)create a level 0 DFD 2010 Sichuan University All rights reserved. | Confidential44Level 0 DFD Exampleuserprocessing requestvideosourceNTSCvideo signaldigitalvideo

57、processorrequestedvideosignalmonitor 2010 Sichuan University All rights reserved. | Confidential45Constructing a DFDIIwrite a narrative describing the transformparse to determine next level transforms“balance” the flow to maintain data flow continuitydevelop a level 1 DFDuse a 1:5 (approx.) expansion ratio 2010 Sichuan University All rights reserved. | Confidential46The Data Flow HierarchyPabxyp1p2p3p45abcdefglevel 0level 1 2010 Sichuan University All rights reserved. | Confidential47Flow Modeling Noteseach bubble is refined until it does just one thingthe expansion ratio decr