10/ 13/ 2009 | 1 10/ 13/ 2009 | 2 Course outline Requirements Engineering Requirem ents Engineering Unit 6: Requirem ents Engineering process Use case approach for requirements management Requirem ents elicitation › Department of Computer Science / Peng Liang Requirem ents docum entation Requirem ent Requirem ent › Rijksuniversiteit Groningen (RUG) negotiation analysis Requirem ents m anagem ent › http:/ / www.cs.rug.nl/ ~liangp/ teaching/ courses/ RE2009Fall/ Requirem ent validation Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 3 10/ 13/ 2009 | 4 Last Unit Contents Requirem ents › From use cases to implementation specification & validation › From use cases to test cases This Unit › Tracing requirements Requirem ents › Managing requirements change m anagem ent Next Unit Agile requirem ents Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 5 10/ 13/ 2009 | 6 Use case centric requirements management design From use cases to implementation Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 7 10/ 13/ 2009 | 8 From use cases to implementation From use cases to implementation › Simple requirements can be directly mapped to › BUT most of requirements are orthogonal with design design and code and implementation • UC-01 : “edit field” • FR-01: “ user shall edit fields in accordance w ith the user privileges established by system adm inistrator ” Disp la y the • NFR-01: “ the system shall handle up to 100,000 users p rogress ba r sim ultaneously” Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 9 10/ 13/ 2009 | 10 Object orientation UML diagram series So how to map complex use case to implementation? traceability Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 11 10/ 13/ 2009 | 12 Object orientation example From use case to interaction diagram › FR-01: “ user shall edit fields in accordance w ith the user privileges established by system adm inistrator ” File Adm inistration System Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 13 10/ 13/ 2009 | 14 Identify classes from interaction diagram Architectural views Security engineer Water Engineer Structural Engineers Electrical Engineer Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 15 10/ 13/ 2009 | 16 4+1 architectural view sta kehold ers The “newer” 4+1 view and SOA (web service) Cla ss, com p onent Structural Packaging/Implementation sub sy stem s Service interface (WSDL) and Classes and Components (EJB) usage semantics. Includes service that physically represent policy definitions the service and metadata Use cases, Test case/ Use ca se Validation Criteria Service Contract(s) Behavioral Infrastructure/ Environment Workflows showing how the service Deployment on .Net and/or sta techa rt d ep loy m ent fulfils a logical business-unit-of- J2EE – emphasis on reliability, work (BPEL). Also includes intra- availability and security. service behavioral models › P. Kruchten . Architectural Blueprints—The “ 4+1”View Model of Softw are Architecture . IEEE Software, 12(6):42-50, 1995. Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 17 10/ 13/ 2009 | 18 Role of use case in software architecture › Use cases • Drive the design • Link all architectural view From use cases to test cases • Check the implementation • Project control (baseline/ iteration) Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 19 10/ 13/ 2009 | 20 Scenarios in a use case From use cases to test cases › Use case is a natural assets for testing process › A use case execution wherein a user executes the use case in a specific way • actor, interactions, steps • black-box › Use cases provide template for writing test cases Scenario-0 1: Basic flow, Alternate flow 1, Alternate flow 2 Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 21 10/ 13/ 2009 | 22 Deriving test case from use case Step1: Identify the use case scenarios › Step1: Identify the use case scenarios SN Originating Flow Alternate Flow Next Alternate Next Alternate SN1 Basic flow › Step2: For each scenario, identify one or more test SN2 Basic flow Alternate flow 1 cases SN3 Basic flow Alternate flow 1 Alternate flow 2 › Step3: For each test case, identify the conditions that SN4 Basic flow Alternate flow 3 will cause it to execute SN5 Basic flow Alternate flow 3 Alternate flow 1 › Step4: Complete the test case by adding data values SN6 Basic flow Alternate flow 3 Alternate flow 1 Alternate flow 2 SN7 Basic flow Alternate flow 4 SN8 Basic flow Alternate flow 3 Alternate flow 4 Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 23 10/ 13/ 2009 | 24 Step2: Identify the test cases Step3: Identify the test conditions specific conditions that cause the test case to execute Test Scenario/ Data Data Data Expected Actual Case ID Condition Value 1 Value 2 Value N Result Result Test conditions TC1 Scenario 1 TC2 Scenario 2 TC3 Scenario 2 Valid Invalid N/ A Lighting Control System TC2: 0 -7 TC3: >8 Scenario2: The user enters the desired lighting sequence for each day of the w eek up to a m a xim um of sev en different daily settings. The system confirm s acceptance of each daily entry w ith a beep. Step4: Add data TC2: correct num ber of daily settings is entered, Sequence saved w ith a beep values to test case TC3: invalid num ber of daily setting is entered, Error m essage Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 25 10/ 13/ 2009 | 26 Tracing requirements › Benefit specification • high-assurance software process • improving the software quality Tracing requirements to software artifacts architecture and reliability › Shortage design • High cost for producing and im plem entation maintaining traceability (value vs. cost) testing Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 27 10/ 13/ 2009 | 28 Generalized traceability model based on UC Tracing requirement to requirement business goals › Traceability Matrix: Tracing Features to Use cases Use Case 1 Use Case 2 Use Case i Use Case k High level Feature 1 X requirem ent Feature 2 X X NFRs, Feature n Design Feature m X X Constrains Use case 1 is a gratuitous use case Feature n needs to be defined by som e use case Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 29 10/ 13/ 2009 | 30 Tracing requirement to requirement Tracing requirements to implementation Feature 1 . . . Feature i Feature k Goal-01 X Goal-02 X X Goal-03 X X Goal-04 X System wide NFR … NFR-01 . . . NFR-0p Requirement 1 X X Requirement 2 X X Requirement n X X X Requirement m X Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 31 10/ 13/ 2009 | 32 Tracing requirements to testing Tracing use cases to test case scenarios UC: Control › Tracing use cases to test cases light • Scenario are thread of concrete operations TS: v erify ing tha t a user to get valuable result is a ble to op en the light • Test cases are set of input and output given to the system TC3: current electricity w ill turn on the light TC1: user can push the open light button TC2: pushing the button, the electricity w ill be current Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
10/ 13/ 2009 | 33 10/ 13/ 2009 | 34 Using requirements traceability tools REWiki › Traceability matrix generation and maintenance Traceability from stakeholders to requirements › Conflict and completeness analysis › For a small project (1-10 person.year, KLOC) • Spreadsheet, database, REWiki › For larger project (above 100 person.year, MLOC) • Specialized requirements management tools Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall 10/ 13/ 2009 | 35 10/ 13/ 2009 | 36 Telelogic DOORS IBM Rational RequisitePro Use ca ses Fea tures Architectura l User Design Requirem ents Sy stem Requirem ents Tra cea bility Ma trix traceability http:/ / www.ibm .com / developerworks/ downloads/ r/ rrp/ Peng Liang Requirements Engineering 2009 Fall Peng Liang Requirements Engineering 2009 Fall
Recommend
More recommend
