Exercise 1b - Lunds Tekniska Högskola
Exercise 1b - Lunds Tekniska Högskola
Exercise 1b - Lunds Tekniska Högskola
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Exercise</strong> <strong>1b</strong>:<br />
Requirements evaluation<br />
INGENJÖRSPROCESSEN METODIK ETSA01 VT13<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1<br />
Agenda for exercise 1a and <strong>1b</strong>:<br />
1a Requirements introduction and overview<br />
– Requirements elicitation (ex. R.1 - R.4, R.6)<br />
– ER diagram (ex. R.5)<br />
– Use case<br />
– Project work kick-off<br />
<strong>1b</strong> Requirements evaluation workshop<br />
– Evaluation:<br />
» Usecase<br />
» Functional requirements<br />
» Quality reguirements<br />
V-modellen för programvaruutvecking<br />
Idé<br />
Affärsmål<br />
Validera<br />
Produkt-<br />
Användarfall<br />
mål<br />
Tidplan Funktionella krav<br />
Resurser<br />
Kvalitetskrav<br />
Risker<br />
Verifiera Kravtäckning<br />
Projekt-<br />
Krav<br />
plan<br />
Verifiera<br />
Lund University | Computer Science | Jonas Wisbrant | ETSA01 Ingenjörsprocessen metodik<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 2<br />
Granskning<br />
Design<br />
Gränssnitt hårdvara<br />
Kodgranskning<br />
Gränsvärde<br />
Utvärdering<br />
Underhåll<br />
Release Support<br />
Releasebeslut<br />
Acceptanstest<br />
Whitebox<br />
Ekvivalensklasser<br />
Återanvänd kod<br />
Integrationstest<br />
Programkod Blackbox Kodtäckning<br />
Versioner<br />
Verifiera<br />
Applikation<br />
Varianter Konfigurationer Enhetstest<br />
Testdokumentation<br />
Felrapport<br />
Systemtest
Användarfall:<br />
Ta in cykel i garaget - problem<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Huvudaktör: Cykelägare<br />
Förhandsvillkor: Cykeln har streckkod och är inte i garaget<br />
Framgångsscenario:<br />
1. En cykelägare kommer med en cykel till garagets ingång.<br />
2. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid<br />
ingången.<br />
3. Ingångsdörrens lås öppnas.<br />
4. Cykelägaren placerar sin cykel i garaget och låser sin cykel.<br />
5. Cykelägaren lämnar garaget genom extrautgången.<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ?<br />
Konsistent ?<br />
Verifierbart ?<br />
Nödvändigt ?<br />
Spårbart ⅔<br />
Rankat<br />
Diffust för<br />
systemet<br />
Irrelevant<br />
för systemet<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 3<br />
Användarfall:<br />
Ta in cykel i garaget - systemet<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Huvudaktör: Cykelägare<br />
Förhandsvillkor: Cykelns streckkod finns i systemet och är inte<br />
registrerad som inlämnad<br />
Framgångsscenario:<br />
1. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid<br />
ingången.<br />
2. Ingångsdörrens lås öppnas.<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget<br />
genom extrautgången.<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ✔<br />
Konsistent ?<br />
Verifierbart ✔<br />
Nödvändigt ✔<br />
Spårbart ⅔<br />
Rankat<br />
Tydligt för<br />
systemet<br />
Vill och kan<br />
verifiera<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 4
Användarfall:<br />
Ta in cykel i garaget - begrepp<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Huvudaktör: Cykelägare<br />
Förhandsvillkor: Cykelns streckkod finns i systemet och är inte<br />
registrerad som inlämnad<br />
Framgångsscenario:<br />
1. Cykelägaren läser cykelns streckkod m h a streckkodsläsare<br />
vid ingången.<br />
2. Ingångsdörrens lås öppnas.<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget<br />
genom extrautgången.<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ✔<br />
Konsistent ✔<br />
Verifierbart ✔<br />
Nödvändigt ✔<br />
Spårbart ⅔<br />
Rankat<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 5<br />
Användarfall:<br />
Ta in cykel i garaget<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Huvudaktör: Cykelägare<br />
Förhandsvillkor: Cykelns streckkod finns i systemet och är inte<br />
registrerad som inlämnad<br />
Framgångsscenario:<br />
1. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid<br />
ingången.<br />
2. Ingångsdörrens lås öppnas och cykeln registreras som<br />
inlämnad.<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget<br />
genom extrautgången.<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ✔<br />
Konsistent ?<br />
Verifierbart ✔<br />
Nödvändigt ✔<br />
Spårbart ⅔<br />
Rankat<br />
Heltäckande<br />
?<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 6
Användarfall:<br />
Ta in cykel i garaget – komplett?<br />
Verifierbart<br />
Tre MYCKET viktiga frågor:<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Nödvändigt<br />
✔<br />
✔<br />
Huvudaktör: Cykelägare<br />
1. Är det VERKLIGEN så<br />
Spårbart<br />
Förhandsvillkor: Cykelns streckkod finns i systemet och är inte<br />
beställaren vi ha det? Rankat<br />
registrerad som inlämnad<br />
Affärsmål<br />
⅔<br />
Framgångsscenario:<br />
Produktmål<br />
1. Cykelägaren läser cykelns streckkod 2. Finns m h a streckkodsläsare det bättre lösningar? vid<br />
ingången.<br />
2. Ingångsdörrens lås öppnas och cykeln 3. Finns registreras det undantag som eller<br />
inlämnad.<br />
varianter?<br />
3. Cykelägaren placerar sin cykel i garaget - och Användarmisstag?<br />
lämnar garaget<br />
genom extrautgången.<br />
- Säkerhet?<br />
- <strong>Tekniska</strong> problem?<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ✔<br />
Konsistent ?<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 7<br />
Användarfall:<br />
Ta in cykel i garaget<br />
Korrekt<br />
Heltäckande ?<br />
Otvetydigt ✔<br />
Konsistent ?<br />
Verifierbart<br />
Några undantag och varianter:<br />
Användarfall 1: Cykelägare lämnar in cykel i garaget<br />
Nödvändigt<br />
✔<br />
✔<br />
Huvudaktör: Cykelägare<br />
Dörren öppnas inte Spårbart<br />
Förhandsvillkor: Cykelns streckkod finns • i systemet Cykeln registrerad och är inte som Rankat inlämnad<br />
registrerad som inlämnad<br />
• Garaget var fullt<br />
⅔<br />
• Streckkoden finns inte i systemet<br />
Framgångsscenario:<br />
• Streckkoden trasig<br />
1. Cykelägaren läser cykelns streckkod • Låset m h a streckkodsläsare trasigt vid<br />
ingången.<br />
• Streckkodsläsaren är trasig<br />
2. Ingångsdörrens lås öppnas och cykeln • Garaget registreras är inte som i bruk<br />
inlämnad.<br />
• Ägaren är avstängd<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget<br />
genom extrautgången. Cykeln lämnas inte<br />
Ägaren går in med PIN-kod<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 8
Produkt-<br />
Användarfall<br />
mål<br />
Tidplan Funktionella krav<br />
Resurser<br />
Kvalitetskrav<br />
Risker<br />
Projekt-<br />
Krav<br />
plan<br />
Verifiera<br />
Granskning<br />
Design<br />
Gränssnitt hårdvara<br />
Projektet väljer och formulerar:<br />
Återanvänd kod<br />
Programkod<br />
Affärsmål – produktmål – (projektmål)<br />
I kravspecifikationen<br />
Affärsmål: Vad vill beställaren/ägaren uppnå med systemet?<br />
– Vinst? Nytta? Goodwill? Spridning?<br />
Produktmål: Vad vill användarna uppnå med systemet?<br />
– Komfort? Prestige? Underhållning? Hjälp?<br />
I projektplanen<br />
Projektmål: Vad vill utvecklingsorganisationen uppnå med projektet?<br />
– Vinst? Kompetens? Goodwill? Kodbas? [tid-kostnad-kvalitet]<br />
Lund University | Computer Science | Jonas Wisbrant | ETSA01 Ingenjörsprocessen metodik<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 9<br />
Affärsmål för cykelgaraget - idéer<br />
Public service: Kostnadsfritt för den pendlande användaren med smidig<br />
access, låg säkerhet och utan garantier.<br />
Gated community: Betalande användare som garanteras plats och en<br />
säker förvaring av sina exklusiva cyklar.<br />
Skalbarhet: Förberett för uppskalning till en serie sammanlänkade<br />
garage där cykelägaren har fri tillgång.<br />
Billig drift: Stabilt och enkelt att underhålla, låg service till cykelägarna<br />
Cykelgarage som produkt: Ägaren ska enkelt kunna generera och<br />
konfigurerar nya och inbördes oberoende garage.<br />
Idé<br />
Affärsmål<br />
V-modellen för programvaruutvecking<br />
Validera<br />
Verifiera<br />
Kodgranskning<br />
Kravtäckning<br />
Gränsvärde<br />
Utvärdering<br />
Underhåll<br />
Release Support<br />
Releasebeslut<br />
Acceptanstest<br />
Whitebox<br />
Ekvivalensklasser<br />
Integrationstest<br />
Blackbox Kodtäckning<br />
Versioner<br />
Verifiera<br />
Applikation<br />
Varianter Konfigurationer Enhetstest<br />
V-modellen för programvaruutvecking<br />
Idé<br />
Affärsmål<br />
Validera<br />
Produkt-<br />
Användarfall<br />
mål<br />
Tidplan Funktionella krav<br />
Resurser<br />
Kvalitetskrav<br />
Risker<br />
Verifiera Kravtäckning<br />
Projekt-<br />
Krav<br />
plan<br />
Verifiera<br />
Lund University | Computer Science | Jonas Wisbrant | ETSA01 Ingenjörsprocessen metodik<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 10<br />
Granskning<br />
Design<br />
Gränssnitt hårdvara<br />
Kodgranskning<br />
Gränsvärde<br />
Whitebox<br />
Ekvivalensklasser<br />
Återanvänd kod<br />
Integrationstest<br />
Programkod Blackbox Kodtäckning<br />
Versioner<br />
Verifiera<br />
Applikation<br />
Varianter Konfigurationer Enhetstest<br />
Testdokumentation<br />
Felrapport<br />
Systemtest<br />
Utvärdering<br />
Underhåll<br />
Release Support<br />
Releasebeslut<br />
Acceptanstest<br />
Testdokumentation<br />
Felrapport<br />
Systemtest
Användarfall:<br />
Ta in cykel i garaget – undantag?<br />
Framgångsscenario:<br />
1. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid ingången.<br />
2. Ingångsdörrens lås öppnas och cykeln registreras som inlämnad.<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget genom<br />
extrautgången.<br />
Undantag:<br />
1a. Streckkoden finns inte i systemet<br />
3a. Cykeln lämnas aldrig I garage<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 11<br />
Användarfall:<br />
Ta in cykel i garaget – undantag?<br />
Framgångsscenario:<br />
1. Cykelägaren läser cykelns streckkod m h a streckkodsläsare vid ingången.<br />
2. Ingångsdörrens lås öppnas och cykeln registreras som inlämnad.<br />
3. Cykelägaren placerar sin cykel i garaget och lämnar garaget genom<br />
extrautgången.<br />
Undantag:<br />
1a. Streckkoden finns inte i systemet<br />
* PIN-kodsterminalens LED blickar rött i 2 sekunder<br />
* Systemet registrerar den okända koden som ett intrångsförsök<br />
* Dörren öppnas INTE<br />
3a. Cykeln lämnas aldrig I garage<br />
* Cykeln registreras som inlämnad (felaktigt)<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 12
Funktionella krav och kvalitetskrav:<br />
Ta in cykel i garaget<br />
• Hur lång är PIN-koden<br />
• Är koden unik per användare?<br />
• Ska den kombineras med användar-ID?<br />
• Hur länge ska dörren vara öppen?<br />
• Hur snabbt ska dörren öppnas<br />
• Hur många försök får man?<br />
• Hur ger vi återkoppling på PIN-kodsterminalen?<br />
• Hur ofta får streckkodsavläsning misslyckas?<br />
• Ska vi logga alla försök?<br />
Kvalitetskrav<br />
• Tillförlitlighet<br />
• Användbarhet<br />
• Effektivitet<br />
• Underhållsbarhet<br />
• Portabilitet<br />
• Uppfyllandegrad<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 13<br />
Funktionella krav: Ta in cykel i garaget<br />
Krav UF1a:<br />
PIN-koden bör vara fyrsiffrig.<br />
Krav UF<strong>1b</strong>:<br />
Inmatning av PIN-kod sker på formen *nnnn#<br />
där n står för ett godtyckligt nummer 0-9<br />
Krav UF1:<br />
Om cykelägaren slår en felaktig PIN-kod lyser<br />
terminalens LED i tre sekunder.<br />
Krav UF2:<br />
Efter tre misslyckade PIN-kodsförsök lyser<br />
teminalens LED i fem sekunder och<br />
cykelägarens konto spärras i 10 minuter.<br />
• Hur lång är PIN-koden<br />
• Är koden unik per användare?<br />
• Ska den kombineras med<br />
användar-ID?<br />
• Hur länge ska dörren vara<br />
öppen?<br />
• Hur många försök får man?<br />
• Hur ger vi återkoppling på PINkodsterminalen?<br />
• Hur ofta får streckkodsavläsning<br />
misslyckas?<br />
• Ska vi logga alla försök?<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 14
Kvalitetskrav: Ta in cykel i garaget<br />
Krav UQ1:<br />
99,8 % av försök att läsa en korrekt<br />
streckkod ska ge rätt PIN-kod till<br />
systemet.<br />
ETSA01: Ingenjörsprocessen metodik<br />
VT2013<br />
Krav UQF2:<br />
Vid lyckad PIN-kodsinslagning eller<br />
streckkodsavläsning skall dörren vara<br />
fullt öppnad efter 2 sekunder.<br />
Krav UQF3:<br />
Senast 15 sekunder efter strömavbrott<br />
ska streckkodläsaren var i full drift.<br />
• Hur lång är PIN-koden<br />
• Är koden unik per användare?<br />
• Ska den kombineras med<br />
användar-ID?<br />
• Hur länge ska dörren vara<br />
öppen?<br />
• Hur många Tidplan försök får vt man? 2013<br />
• Hur ger vi återkoppling på PINkodsterminalen?<br />
• Hur ofta får streckkodsavläsning<br />
misslyckas?<br />
• Ska vi logga alla försök?<br />
V tid 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K lö sö<br />
12 Student Ö0a F1 Ö0b Ö1a Ö0c Ö<strong>1b</strong><br />
Projekt 1,0 L1<br />
Kravspec 1,0 2,0 1,0 1,0 1,0 0,5<br />
Handledare -> fb0<br />
15 Student F2 Ö2<br />
Projekt L2<br />
Kravspec 1,0 3,0 1,0 G1 •<br />
Projektplan<br />
Handledare fb1 |- - - -> fb2<br />
16 Student F3 Ö3<br />
Projekt<br />
Kravspec • • • • •> L3<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 15<br />
Projektplan<br />
Testplan<br />
Design<br />
Handledare |- - - - - - - - - - - - -> fb3<br />
17 Student F4 Ö4<br />
Projekt<br />
Kravspec G2 • • • • • • • •> L4<br />
Inför vecka 2<br />
Projektplan L4<br />
Testplan G3 • •<br />
Design G4 •<br />
Code<br />
Handledare |- - - -> fb4<br />
18 Fredag Student kl 24: L1 i wikin: Användarfallet + Funktionlla Ö5 krav + kvalitetskrav<br />
Projekt<br />
V2 Kravspec – efter påsk<br />
Projektplan<br />
Tisdag kl 8 återkoppling från oss på L1<br />
Testplan • •> L5<br />
Design • •> L5<br />
Tidag kl 13 förläsning i E:A<br />
Code<br />
Test<br />
Onsdag kl 12 L2 kravspecifikation – sanity check<br />
Handledare |- - - - - - - - -> fb5<br />
19 Student F5<br />
Torsdag kl 8 återkoppling från oss på sanity check<br />
Projekt<br />
Kravspec<br />
ETSA01: Fredag Ingenjörsprocessen kl 16? metodik Projektintern Projektgrupp: granskning efter omarbete???<br />
Projektplan<br />
VT2013<br />
Testplan<br />
Design<br />
Projektgrupp:<br />
måndag tisdag onsdag torsdag fredag<br />
V Code tid 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K lö sö<br />
12 Test Student Ö0a F1 Ö0b Ö1a Ö0c Ö<strong>1b</strong><br />
Startman. Projekt 1,0 L1<br />
Kravspec<br />
Handledare<br />
1,0 2,0 1,0 1,0 1,0 0,5<br />
Handledare<br />
20 Student F6<br />
-> fb0<br />
15 Projekt<br />
Student F2 Ö2<br />
Kravspec<br />
Projekt L2<br />
L6<br />
Projektplan<br />
Kravspec 1,0 3,0 1,0 G1<br />
L6<br />
•<br />
Projektplan<br />
Testplan L6<br />
Handledare fb1 |- - - -> fb2<br />
Tidplan vt 2013<br />
måndag tisdag onsdag torsdag fredag<br />
Design L6<br />
16 Code Student F3 Ö3<br />
L6<br />
Test Projekt<br />
L6<br />
Lund University | Computer Science | ETSA01 Ingenjörsprocessen - Metodik VT13 | <strong>Exercise</strong> 1 16<br />
Startman Kravspec • • • • •> L3<br />
L6<br />
Projektplan<br />
Handledare |-><br />
F<br />
Testplan<br />
Schemalagd föreläsning<br />
Design<br />
Ö Schemalagd övning L Leverabel från projektet G Granskningsmöte? fb Återkoppling T Tentamen 1,0 Timmar per projektmedlem
Change language