Exercise 1a: Requirements and project kick-off

Storlek: px

Starta visningen från sidan:

Download "Exercise 1a: Requirements and project kick-off"

Britta Blomqvist
för 7 år sedan
Visningar:

1 Exercise 1a: Requirements and project kick-off INGENJÖRSPROCESSEN METODIK ETSA01 VT13 Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 5 Exercise Sessions Ex 1a: Requirements introduction, project requirements specification kick-of or how to enter a garage with a bike Ex 1b: Requirements evaluation workshop Ex 2: Project Plan & Inspection Ex 3: Test I Ex 4: Test II Ex 5: (project feedback) Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 2

2 täckning täckning Agenda for exercise 1a and 1b: 1a Requirements introduction and overview Requirements elicitation (ex. R.1 - R.4, R.6) ER diagram (ex. R.5) Use case Project work kick-off 1b Requirements evaluation workshop Evaluation:» Usecase» Functional requirements» Quality reguirements Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 3 Why and how to produce a good SRS? SRS System Requirements Specification Importance of the SRS Agreement between client and supplier Basis for implementation of the system Reference for validation of the final product Prerequisite for high-quality software A high-quality SRS reduces the development cost Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 4

3 täckning täckning Phases of requirements process Identifiera krav Analysera krav Dokumentera krav krav Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 5 R1: Assignment Identifying stakeholders for a course administration system Source of requirements on the system Possible conflicts between stakeholders needs/ requirements Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 6

4 täckning täckning R2-3: Quality Criteria for Functional and Quality Requirements Good requirements should be: Correct Complete Unambiguous Verifiable Consistent Necessary Traceable Ranked for importance and/or stability Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 7 R2-3: Functional vs. Quality requirements for a bike computer Functional requirements Quality requirements Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 8

5 täckning täckning R2-3: Functional vs. Quality requirements for the bike computer Functional requirements The system shall have a function to determine the current speed The system shall have an alarm clock function Quality requirements 4 out of 5 random cyclist should be able to correctly set the alarm after studying the manual for 5 minutes 95% of the time, the system should respond within 0.1 second after pressing a button The distance measure may diverge 0,5% Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 9 R4: Why should requirements be formulated on different levels? Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 10

6 täckning täckning R4: Why should requirements be formulated on different levels? Various types of stakeholders understand only some levels of abstractions Different purposes for different abstraction levels Corresponds with the different steps of writing requirements, from high-level to more detailed To build a consistent document structure Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 11 R5: ER diagram for course administration system-system Course Course occasion Teacher Student Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 12

7 täckning täckning R5: ER diagram for course administration system-system Course Course occasion Teacher Student Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 13 R5: ER diagram for course administration system-system Course 1 takes place * Course occasion * * is responsible for reads Teacher 1 * Student Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 14

8 täckning täckning R6: Add maintenance to the can machine DRINK Cola, Water, Beer, Abort COINS CanUnavailable GiveCoins, KeepCoins, Coins Can dispenser Control unit Money handler Can Coin, NoChange SYSTEM Interaction requirements describe the interactions between two functions of the system = combinations. It often also collects all strange cases (e.g. unlikely exception scenarios) Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 15 Example Use Case for a Can Machine System UC1: User is buying a beer Primary Actor: User Precondition: User has enough money to buy a beer, can machine is ready Main success scenario: 1. User presses the beer button 2. User inserts 2 times 10 KR and 2 times 1 KR coins 3. The beer can is released to the user Exception scenarios: 1a. Machine is out of beer cans * System displays a message Out of cans * System returns all coins as soon as they are inserted 3a. User has inserted too much money * System displays message Change released * System calculates the change and releases it through the coins return Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 16

9 täckning Requirements evaluation Bike computer Correct Complete Unambiguous Consistent Verifiable Necessary Traceable Ranked F1 The system shall have a function to determine the current speed? - F2 The system shall have an alarm clock function? -? - Q1 4 out of 5 random cyclist should be able to correctly set the alarm after studying the manual for 5 minutes ⅔? - Q2 95% of the time, the system should respond within 0.1 second after pressing a button ⅔? - Q3 The distance measure may diverge 0,5%? - Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 Spårbarhet I projektet Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 18

10 täckning : Ta in cykel i garaget - beställning Korrekt Heltäckande? Otvetydigt Konsistent? Verifierbart? 1: Cykelägare lämnar in cykel i garaget Huvudaktör: Cykelägare Förhandsvillkor: Cykelns streckkod finns i systemet och är inte registrerad som inlämnad Nödvändigt? Spårbart? Rankat Framgångsscenario: 1. En cykelägare kommer med en cykel till garagets ingång. 2. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid ingången. 3. Ingångsdörrens lås öppnas. 4. Cykelägaren placerar sin cykel i garaget och låser sin cykel. 5. Cykelägaren lämnar garaget genom extrautgången. Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 19 Project work before requirements evaluation workshop Now: Plan the week and W2 1. Set up project wiki User permissions Project header SRS Create Use Case 1: Bike owner enters the garage Actors Preconditions Success scenario Exception scenarios 3. Write functional requirements 4. Write quality requirements 5. Discuss business and product goals 6. Evaluate and redo 7. Pinpoint responsible for the document? 8. Bring print-outs for all project members to Requirements evaluation workshop Thursday 21/ Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 20

11 Uppdrag till imorgon torsdag kl 13 ETSA01: Ingenjörsprocessen metodik VT2013 Nu: detaljplanera vem-vad-när-var! to kl Läs in projektbeskrivningen avsnitt 1-4 V tid K K K K K lö sö 12 Student Ö0a F1 Ö0b Ö1a Ö0c Ö1b Få igång projektgruppen wikisida Projekt 1,0 L1 spec 1,0 2,0 1,0 1,0 1,0 0,5 Utveckla användarfallet i wikin Handledare -> fb0 15 Student F2 Ö2 Projekt Utveckla beteendet spec 1,0 3,0 1,0 G1 Formulera undantag och förslå respons från systemet Handledare fb > fb2 Formulera relaterade och förtydligande funktionella krav och kvalitetskrav 16 Student F3 Ö3 Projekt spec > L3 Projekthandledarna tittar in i wikin kl Testplan Ta med utskrifter av användarfall och Skall-krav till övningen Handledare > fb3 17 Student F4 Ö4 Projekt Projektgrupp: spec G2 > L4 L2 vt 2013 måndag tisdag onsdag torsdag fredag L4 Testplan G3 Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 21 G4 Code Handledare > fb4 18 Student Ö5 Projekt spec Start på tidplan xls-version kurswebben Testplan > L5 > L5 Code Test Handledare > fb5 19 Student F5 Projekt spec Ta med datorer och utskrifter Testplan måndag tisdag onsdag torsdag fredag Code tid K K K K K lö Test udent Ö0a F1 Ö0b Ö1a Ö0c Ö1b Startman. jekt 1,0 L1 avspec Handledare 1,0 2,0 1,0 1,0 1,0 0,5 ndledare 20 Student F6 -> fb0 Projekt udent F2 Ö2 spec jekt L2 avspec 1,0 3,0 1,0 G1 jektplan Testplan ndledare fb > fb2 Code udent F3 Ö3 Test Startman Schemalagd utan lokal Wikisupport i E:3308 Handledare -> F Schemalagd föreläsning Ö Schemalagd övning L Leverabel från projektet G smöte? fb Återkoppling T Tentamen 1,0 Timmar per projektmedlem Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 22

12 täckning Hints For structuring the use-case, functional requirements and quality requirements Study the order Discuss business and product goals Study Jalote, Ch 4 Study cource compendum Study example in these handouts Study example in lecture handouts Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT13 Exercise 1 23

Relevanta dokument

Exercise 1a: Requirements and Project Kick-off ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15

Exercise 1a: Requirements and Project Kick-off ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15 2 4(+2) Exercise Sessions Ex 1a: Requirements introduction, project requirements specification kick-off or how