Functional requirements and acceptance testing

Transcription

1 Functional requirements and acceptance testing Lecture 3 Software Engineering TDDC88/TDDC93 autumn 2007 Department of Computer and Information Science Linköping University, Sweden

2 Message from the course assistant 2 Don t forget to registrer for the lab in TDDC88 I II V

3 Theory Lecture Plan 3 L1 - Course Introduction and Overview L2 - Project Management L3 - L4 - Acceptance Testing and Quality Factors L5 UML L6 - Design Patterns L7 - System Design and Architecture L8 - Testing Theory L9 - Testing in Practice L10 - Inspection L11 - Software Life Cycles and Configuration Management L12 - Software Quality Management L13 - Course Summary, Exam examples, Questions I II V

4 A Software Life-cycle Model Which part will we talk about today? Maintenance 4 Validate, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Verify System Design System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Verify Module Design Verify Implementation Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing Project Management, Software Quality Assurance (SQA), Supporting Tools, Education I II V

5 The role of requirements in the life-cycle 5 fuzziness Tim the tester Carol the customer Diana the developer modelling time formalisation I II V

6 Agenda - What will you learn today? 6 I II V I II V

7 7 Elicitation I II V

8 Elicitation 8 needs needs Purpose: Understand the true needs of the customer Trace future implementation to needs Sources: Carol the customer Goals Domain knowledge Stakeholders Environment Robert the requirements engineer Techniques: Interviews Scenarios Prototypes Facilitated meetings Observation I II V

9 Interviews 9 Process: Start Q & A Summary teach-back Thank you! What s next Kinds: Structured Unstructured Tips Be 2 interviewers shift roles Plan the interview Don t stick to the plan use feelings Let the customer talk Prepare ice-breakers Probe thinking Look for body language Think of human bias Why do you get the answers you get? I II V

10 10 I Analysis I II V

11 Goal 11 Detect and resolve conflicts btwn requirements Discover bounds of software Define interaction with the environment Elaborate high-level requirements to derive detailed requirements I II V

12 classification 12 Functional vs non-functional requirements Source Product or process requirements Priority Scope in terms of affected components Volatility vs stability I II V

13 Conceptual Modelling 13 Representation in semi-formal notation Often diagrammatic representation Examples: Object-orientation, use-cases, state-machines Activity diagrams Data flow diagrams Entity-relationship models Requires Requires a paradigm paradigm shift shift to to give give full full advantage advantage I II V

14 14 Use-case modelling A use-case is: a particular form or pattern or exemplar of usage, a scenario that begins with some user of the system initiating some transaction of sequence of interrelated events. Jacobson, m fl 1992: Object-oriented software engineering. Addison-Wesley I II V

15 Use-case diagram 15 Actor: a user of the system in a particular role. Can be human or system. CoffeeDrinker Association Use-case name Description of use-case Buy a cup of coffee Use-case A CoffeeDrinker approaches the machine with his cup and a coin of SEK 5. He places the cup on the shelf just under the pipe. He then inserts the coin, and press the button for coffee to get coffee according to default settings. Optionally he might use other buttons to adjust the strength and decide to add sugar and/or whitener. The machine processes the coffee and bell when it is ready. The CoffeeDrinker takes his cup from the shelf. I II V

16 Use-case diagram for the coffee-machine 16 CoffeDrinker Subject boundary Subject Buy a cup of coffe Get coin in return CoffeeMachine Clean the Machine Add substances Collect coins Subject name Service TeaDrinker Pour hot water Brew a can of coffee Porter I II V

17 Identifying classes: noun 17 A CoffeeDrinker approaches the machine with his cup and a coin of SEK 5. He places the cup on the shelf just under the pipe. He then inserts the coin, and press the button for coffee to get coffee according to default settings. Optionally he might use other buttons to adjust the strength and decide to add sugar and/or whitener. The machine processes the coffee and bell when it is ready. The CoffeeDrinker takes his cup from the shelf. machine real noun handled by the system cup unit for beverage coin detail of user and machine shelf detail of machine pipe detail of machine button handled by the system sugar detail of coffee whitener detail of coffee cup of coffee handled by the system indicator not discovered I II V

18 Beehive Exercise 18 5 minutes beehive! 1. Individually Write a use case and draw a use-case diagram of a railway ticket booking system 2. Give the use case to a neighbour Do you understand the use case you just got? Can you give a suggestion for improvement? I II V

19 The single class model 19 CoffeCustomer name: String class name attribute numberofcoins() : Integer buy(c:cupofcoffee) operations I II V

20 Associations between classes 20 roles association CoffeCustomer consumer 0..* buys consumables 0..* CupOfCoffee multiplicity A multiplicity can be: an exact number 1 a range of numbers unspecified number denoted by * I II V

21 Class model 21 CoffeCustomer 0..* buys 0..* CupOfCoffee Generalisation association Porter 0..* buys 0..* CanOfCoffee I II V

22 Data model: ER-diagram 22 Student Name Personal number Curriculum Enrolled-in Course Subject Course code Max-enrolment I II V

23 Formalisation 23 Continue decreasing fuzziness to 0 Represents requirements in a mathematical notation Interpretation with logic gives possibilities: Consistency check Proof of correctness System simulation Unambiguity Examples: Z, VDM, OCL,... Requires Requires thorough thorough education education I II V

24 Z example 24 I II V

25 25 I II V

26 26 I II V

27 27 I II V

28 28 II I II V

29 Advice towards a good 29 needs needs Carol the customer Robert the requirements engineer SRS There is no perfect, but you can write a good one The RS, or SRS avoids many misunderstandings The RS is of special importance in outsourcing programming I II V

30 SRS contents 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview 2 Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 2.6 Lower ambition levels 3 Specific requirements 3.1 Interface requirements User interfaces Hardware interfaces Software interfaces Communication interfaces 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements 4 Supporting information 4.1 Index 4.2 Appendices 30 I II V

31 Individual requirements 31 I II V

32 32 are: Numbered Inspected Prioritised Unambiguous Testable Complete Consistent Traceable Feasible Modifiable Useful for: operation maintenance customer developer. I II V

33 Beehive Exercise 33 5 minutes beehive! 1. Individually Write down one functional and one nonfunctional requirement of a mobile telephone 2. Give the requirements to a neighbour Do you understand the requirements you just got? Is there room for mis-understanding? I II V

34 Define a standard document structure 34 Benefits: Readers can reuse knowledge from previous RSs in understanding Writers checklist Tools can be adapted to generate RSs Costs: Finding the right standard Configure variants Periodically review standard Developers can have a bad attitude against standards I II V

35 Explain how to use the document 35 There are many readers of a RS: Customers Managers Software engineers Testers Maintenance staff Technical writers Subcontractors Part of introduction Types of reader Technical background needed Sections for different readers Sections skipped 1 st time Order of section Dependence between section Takes an hour to write I II V

36 Include a summary of the requirements 36 Better than forward references Focus attention on critical and prioritised requirements Map to find specific requirements Highlight most important requirements in a list Table of classification Graphic presentation with relations Per chapter basis Though for large number of requirements I II V

37 Make a business case for the system 37 Helps understanding Helps change assessment Special document, section or part of introduction Requires that top management have an agreement I II V

38 Define special terms 38 Readers and writers might have their own meaning of terms engineer develops a jargon that need to be explained Use a glossary, start with a standard one, adapt and maintain Highlight terms in the text that can be found in the glossary I II V

39 Use a data dictionary 39 A glossary for variables and terms in diagrams Often well-supported in tools Often forgotten in student-rss Needs maintenance and adherence Can develop into an ontology => massive information exchange, search and checking Name of entity Aliases Type Description Rationale Constraints Units Tolerance Value ranges Error values Relations Links I II V

40 Lay out the document for readability 40 Many, many readers justify the investment Meanwhile, use your standard templates of your word processor and common sense It is worthwhile to buy professional training for newly hired personnel I II V

41 Help readers find information 41 Create table of contents Create index Easy to find support for automatic generation Human-made indices are still better I II V

42 Make documents easy to change 42 will be changed Quite easy with tools Paper-based s needs some thinking: Loose-leaf binders Change bars Short, self-contained chapters Refer to labels, not pages I II V

43 Alternative: continue with use-cases 43 Get the benefits from modelling Less ambiguity Possible to generate code Better traceability Sometimes easier to change Sometimes easer to understand Textual requirements are few Example from OpenUP/Basic: pec_withdraw_cash.pdf I II V

44 44 V Validation I II V

45 Validation of requirements 45 Before design and coding Inspections Cross-referencing Interviews Checklists Scenarios Proofs Model Simulation Prototyping After (some) design and coding Prototyping Overcomittment Teach-back Alfa test Beta test Acceptance test I II V

46 Further reading - References 46 IEEE-std 830 I II V

47 Summary - What have we learned today? 47 Elicitation is a very human-centered phase A written is read far more often than it is written Use-cases describe the mainstream flow of events Always let someone else look at your requirements I II V