Requirements Engineering

Transcription

1 Meage from the coure aitant 2 Requirement Engineering Don t forget to regitrer for the lab in TDDC88 Lecture 2 Software Engineering TDDC88/TDDC93 autumn 2010 Kritian Sandahl Department of Computer and Information Science Linköping Univerity, Sweden kria@ida.liu.e A Software Life-cycle Model Which part will we talk about today? 3 Maintenance What i a oftware requirement? 4 Requirement Sytem Deign (Architecture, High-level Deign) Module Deign (Program Deign, Detailed Deign) Validate Requirement, Verify Specification Implementation of Unit (clae, procedure, function) Verify Sytem Deign Verify Module Deign Verify Implementation Unit teting Acceptance Tet (Releae teting) Sytem Teting (Integration teting of module) Module Teting (Integration teting of unit) Project Management, Software Quality Aurance (SQA), Supporting Tool, Education Software expre the and contraint placed on a oftware product that contribute to the olution of ome real-world problem. (Kotonya and Sommerville 2000) Example: When the uer enter the degree in Farenheit, the ytem hall calculate and write the degree in Celiu. Functional and non-functional 5 Quality factor 6 Functional decribe the function that the oftware i to execute. Can be teted by giving input and checking the output. Non-functional : Deign contraint Quality, poible to meaure Correctne Reliability Efficiency Uability Integrity Maintainability Flexibility Tetability Security Portability Reuability Interoperability Survivability Safety Manageability Supportability Replaceability Functionality Price? 1

2 Feature 7 The role of in the life-cycle 8 A ditinguihing characteritic of a ytem item (include both functional and nonfunctional attribute uch a performance and reuability). (IEEE Std 829) Higher level tuff: The ytem hall have an SMS-ervice Carol the cutomer elicitation fuzzine Tim the teter time Diana the developer pecification modelling formaliation 9 Elicitation 10 Carol the cutomer Purpoe: Undertand the true of the cutomer Trace future implementation to Source: Goal Domain knowledge Stakeholder Environment Robert the engineer Technique: Interview Scenario Prototype Facilitated meeting Obervation Interview Proce: Start Q & A Summary teach-back Thank you! What next Kind: Structured Untructured Tip Be 2 interviewer hift role Plan the interview Don t tick to the plan ue feeling Let the cutomer talk Prepare ice-breaker Probe thinking Look for body language Think of human bia Why do you get the anwer you get? 2

3 Goal 13 Requirement claification 14 Detect and reolve conflict btwn Dicover bound of oftware Define interaction with the environment Elaborate high-level to derive detailed Functional v non-functional Source Product or proce Priority Scope in term of affected component Volatility v tability Conceptual Modelling 15 Ue-cae modelling 16 Repreentation in emi-formal notation Often diagrammatic repreentation Example: Object-orientation, ue-cae, tate-machine Activity diagram Data flow diagram Entity-relationhip model Require a paradigm hift to give full advantage A ue-cae i: a particular form or pattern or exemplar of uage, a cenario that begin with ome uer of the ytem initiating ome tranaction of equence of interrelated event. Jacobon, m fl 1992: Object-oriented oftware engineering. Addion-Weley Ue-cae diagram 17 Ue-cae diagram for the coffee-machine 18 Actor: a uer of the ytem in a particular role. Can be human or ytem. CoffeeDrinker Aociation Ue-cae name Decription of ue-cae Buy a cup of coffee Ue-cae A CoffeeDrinker approache the machine with hi cup and a coin of SEK 5. He place the cup on the helf jut under the pipe. He then inert the coin, and pre the button for coffee to get coffee according to default etting. Optionally he might ue other button to adjut the trength and decide to add ugar and/or whitener. The machine procee the coffee and bell when it i ready. The CoffeeDrinker take hi cup from the helf. CoffeDrinker boundary TeaDrinker Buy a cup of coffe Get coin in return Pour hot water CoffeeMachine Clean the Machine Add ubtance Collect coin Brew a can of coffee name Service Porter 3

4 Identifying clae: noun analyi 19 The ingle cla model 20 A CoffeeDrinker approache the machine with hi cup and a coin of SEK 5. He place the cup on the helf jut under the pipe. He then inert the coin, and pre the button for coffee to get coffee according to default etting. Optionally he might ue other button to adjut the trength and decide to add ugar and/or whitener. The machine procee the coffee and bell when it i ready. The CoffeeDrinker take hi cup from the helf. machine real noun handled by the ytem cup unit for beverage coin detail of uer and machine helf detail of machine pipe detail of machine button handled by the ytem ugar detail of coffee whitener detail of coffee cup of coffee handled by the ytem CoffeCutomer name: String numberofcoin() : Integer buy(c:cupofcoffee) cla name attribute operation indicator not dicovered Aociation between clae 21 Cla model 22 role aociation CoffeCutomer buy CupOfCoffee CoffeCutomer conumer buy conumable CupOfCoffee Generaliation aociation multiplicity A multiplicity can be: an exact number 1 a range of number unpecified number denoted by * Porter buy CanOfCoffee Data model: ER-diagram Student Enrolled-in Name Peronal number Curriculum Requirement pecification Coure Coure code Max-enrolment 4

5 Advice toward a good pecification 25 SRS content 26 Carol the cutomer SRS Robert the engineer There i no perfect pecification, but you can write a good one The RS, or SRS avoid many miundertanding The RS i of pecial importance in outourcing programming 1 Introduction 1.1 Purpoe 1.2 Scope 1.3 Definition, acronym and abbreviation 1.4 Reference 1.5 Overview 2 Overall decription 2.1 Product perpective 2.2 Product function 2.3 Uer characteritic 2.4 General contraint 2.5 Aumption and dependencie 2.6 Lower ambition level 3 Specific 3.1 Interface Uer interface Hardware interface Software interface Communication interface 3.2 Functional 3.3 Performance 3.4 Deign contraint 3.5 Software ytem attribute 3.6 Other 4 Supporting information 4.1 Index 4.2 Appendice Individual 27 Requirement pecification 28 Requirement are: Numbered Inpected Prioritied Unambiguou Tetable Complete Conitent Traceable Feaible Modifiable Ueful for: operation maintenance cutomer developer. Define a tandard document tructure 29 Explain how to ue the document 30 Benefit: Reader can reue knowledge from previou RS in undertanding Writer checklit Tool can be adapted to generate RS Cot: Finding the right tandard Configure variant Periodically review tandard Developer can have a bad attitude againt tandard There are many reader of a RS: Cutomer Manager Software engineer Teter Maintenance taff Technical writer Subcontractor Part of introduction Type of reader Technical background ed Section for different reader Section kipped 1 t time Order of ection Dependence between ection Take an hour to write 5

6 Include a ummary of the 31 Make a buine cae for the ytem 32 Better than forward reference Focu attention on critical and prioritied Map to find pecific Highlight mot important in a lit Table of claification Graphic preentation with relation Per chapter bai Though for large number of Help undertanding Help change aement Special document, ection or part of introduction Require that top management have an agreement Define pecial term 33 Ue a data dictionary 34 Reader and writer might have their own meaning of term Requirement engineer develop a jargon that to be explained Ue a gloary, tart with a tandard one, adapt and maintain Highlight term in the text that can be found in the gloary A gloary for variable and term in diagram Often well-upported in tool Often forgotten in tudent-rs Need maintenance and adherence Can develop into an ontology => maive information exchange, earch and checking Name of entity Aliae Type Decription Rationale Contraint Unit Tolerance Value range Error value Relation Link Lay out the document for readability 35 Help reader find information 36 Many, many reader jutify the invetment Meanwhile, ue your tandard template of your word proceor and common ene It i worthwhile to buy profeional training for newly hired peronnel Create table of content Create index Eay to find upport for automatic generation Human-made indice are till better 6

7 Make document eay to change 37 Summary - What have we learned today? 38 Requirement will be changed Quite eay with tool Paper-baed pecification ome thinking: Looe-leaf binder Change bar Short, elf-contained chapter Refer to label, not page Elicitation i a very human-centered phae A written pecification i read far more often than it i written Ue-cae decribe the maintream flow of event 7