From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Slides for: Software requirements - Styles and techniques Soren Lauesen 1. Introduction and basic concepts January 2007 © 2002, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Contract Analysis Reqspec Op & maint Design Program Test Fig 1.1 The role of requirements Demands Elicitation Stakeholders Verification Validation Tacit demands & reqs Tracing: Forwards... Backwards... Req. management: Changing reqs

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.2 Project types Project types CustomerSupplier In-houseUser dept.IT dept. Prod. devel.MarketingSW dept. Time & materialsCompanySW house COTSCompany(Vendor) TenderCompanySupplier Contract devel.CompanySW house Sub-contractingSupplierSW house UnknownInhouse? COTS?

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudo-code, activity diagram Screen prototype, support tasks xx to yy System Platform: HW, OS, DB Spreadsheet Ext. products: Sensors, dev. Special SW Fig 1.3 Contents of ReqSpec User groups Quality reqs: Performance Usability Maintainability... Other deliverables: Documentation Install, convert, train... Managerial reqs: Delivery time Legal Development process... Helping the reader: Business goals Definitions Diagrams... Interfaces Data requirements: System state: Database, comm. states Input/output formats

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Krav 47: Det skal være muligt at knytte en kode omkring vagttype (forvagt, bagvagt mv.) til den enkelte medarbejder. Krav 144: Leverandøren skal opdatere systemet så det følger nye overenskomster senest en måned efter frigivelsen. Krav 475: Systemet skal kunne beregne regnskabsmæssige konsekvenser af en given vagtplan - i timer og i kroner. Krav 479: Systemet skal advisere hvis en vagtplan indebærer samlet anvendelse af en vikar ud over tre måneder. Krav 669: Systemet skal give forståelige meddelelser i klar tekst ved fejl og vejlede i hvad brugeren bør gøre. Støttes arbejdsopgaverne? Nås de forretningsmæssige mål? Frihed til leverandøren? (Fig 1.4A) Traditionelle krav, vagtplansystem

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Delopgaver og varianter: 1.Dan ny vagtplan. 2.Registrer ferie. To slags ferie... Nuv. problem: Små lapper med ønsker mange måneder frem. 3.Bemand vagter. Sørg for rette kompetencer, ferie, overenskomster og undgå tillæg. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. 3a.Vikarer endnu ikke i systemet. 3b.Skaf medarb. fra anden afdeling. 4.Send planen til kommentering. 5.Ret planen og frigiv den. Eksempler / løsning: Automatisk ud fra sidste plan... Systemet kontrollerer feriereglerne. Systemet har en tidshorisont på flere år. Systemet foreslår bemanding af ubemandede vagter. Advarer om brudte regler og unødige tillæg. Støtter "puslespillet" med undo og flere forsøgsudgaver. Viser ledige fra andre afdelinger. En udskrift af planen er nok. (Fig 1.4B) Ny slags krav: Støt arbejdsopgaven (task) T1.2: Lav vagtplan Hyppighed:Hver 14. dag. I nogle afdelinger... Svært:Ferieperioder.

Product Platform Control computers Fig 1.5A Domain and product level (context diagram) User activities Domain I/O Product I/O Domain Clients “Business” domain Actors? Elevators Product-level requirements: The product shall accept the following input: Accept invitation... Domain-level requirements: The product shall support the following user activities: Plan a meeting...

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Product Control computers Fig 1.5B Redefined limits (context diagram) User activities Domain Clients “Business” domain

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 (Fig 1.5C) Design-level requirements R4:The product shall have these screen pictures:

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.6A The goal-design scale R1. Our pre-calculations shall hit within 5% R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have screen pictures as shown in app. xx Goal-level requirement Domain-level requirement Product-level requirement Design-level requirement Which requirement to choose? If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers?

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.6B Ask “why” Neural diagnostics System shall have mini keyboard with start/stop button,... Why? Possible to operate it with “left hand”. Why? Both hands must be at the patient. Why? Electrodes, bandages, painful...

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.6C Recommendation: why + how Measuring neural response is a bit painful to the patient. Electrodes must be kept in place... So both hands should be at the patient during a measurement. R1:It shall be possible to perform the commands start, stop,... with both hands at the patient. Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc. Domain - why Req. Example - how

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.7A Typical project models Traditional: Product-level reqs Ask users, study documents,... extract features/functions. Intro, [business goals]... System limits, e.g. context diagram Data reqs, e.g. data model, data descr. Product-level funct. reqs, e.g. features Critical quality reqs Fast approach: Domain-level Describe user tasks, study documents... Intro, [business goals, BPR tasks]... System limits, e.g. context diagram Data reqs, e.g. verbal data descr. Domain-level reqs, e.g. Tasks & Support [Trace analysis: goals to tasks] Critical quality reqs Two-step approach: Domain-level + design-level All the fast-approach stuff + Design-level reqs, e.g. prototypes, comm.protocols

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.7B Recommended project models Project type:Trad.DomainTwo-step In-house?OKOK Product dev.?OK Time & mat.?OKOK COTS business?OK COTS toolsOK Tender COTS?OK Tender tailor?OK  OK  Contract COTS?OK Contract tailor?OK  OK  Sub-contractOKOK MaintenanceOK  Variable price ? Used, but dubious Project model

From: Soren Lauesen: Software Requirements © Addison-Wesley 2002 Fig 1.7C Contracts and prices Contract typeAnalysisDesignProgram Analysis only T&M or Fixed Design & dev. Fixed and/or variable All-in-one T&M orVariable Fixed Development Fixed Tender: Same supplier?

Krav 1: Systemet skal kunne vise patientens diagnoser som en hierarkisk struktur. Ved klik på plus og minus skal man kunne se under- og overordnede diagnoser. (Fig 1.8A) Detaljeringsniveau (Elektr. Patientjournal) For detaljeret. Kun een leverandør. For overordnet. Mindst lige så meget kundens ansvar. Evt. partnerskab Tilpas. Man kan se om opgaven støttes godt nok. Tilpas detaljeret, men er løsningen god nok? Krav 4: Systemet skal kunne vise en oversigt over patientens diagnoser. Krav 2: Systemet skal sikre at antallet af fejlmedicineringer reduceres fra nuværende 10% til 5%. Krav 3: Systemet skal støtte arbejdsopgaverne A1 til Axxx. [A1: Henvendelse inden patientens ankomst... A5: Klinisk session... ]

Krav 5: Systemet skal være let at bruge. (Fig 1.8B) Præcise krav (verificerbare) Verificerbart Verificerbart nogen tid efter leveringen Verificerbart, men på 13- skalaen Verificerbart, men ret ligegyldigt Ikke verificerbart Krav 1: Systemet skal kunne vise patientens diagnoser som en hierarkisk struktur. Ved klik på plus og minus skal man kunne se under- og overordnede diagnoser. Krav 4: Systemet skal kunne vise en oversigt over patientens diagnoser. Krav 2: Systemet skal sikre at antallet af fejlmedicineringer reduceres fra nuværende 10% til 5%. Krav 3: Systemet skal støtte arbejdsopgaverne A1 til Axxx. [A1: Henvendelse inden patientens ankomst... A5: Klinisk session... ]

Use case 2.1: Vis diagnoser Start:Brugeren ønsker at orientere sig om patientens helbredstilstand. Eksempel: sygeplejerske der starter på vagten. Kritisk:Skal kunne kaldes hele tiden og vise overblik gennem kortfattede konklusioner/sammenfatninger. Startbetingelse: Mindst én spontan oplysning skal være tilknyttet. Slutresultat: Den sundhedsfaglige person har fået overblik over... Delopgaver og varianter: 1. Vis diagnosehierarki. 2. Vælg visning (f.eks. hierarki eller Gantt-diagram) 3. Vælg detaljeringsniveau (komprimer eller ekspander niveauer) 4. Vælg at se dele af diagnosehierarkiet... åbne/alle, tidsinterval Vis diagnosens historik. 6. Vis detail oplysninger for en udpeget diagnose · Fokuserede oplysninger vises på en oversigt med... · Diagnostiknotatet vises på en oversigt med... · Eksterne årsager vises på en oversigt Vis tilknyttede ydelser. Ydelsens status skal fremgå... (Fig 1.8C) Typisk use case - ikke en afsluttet opgave I alt tre A4 sider Masser af data indføres her For detaljeret. Kun een leverandør.

Delopgaver og varianter: 1.Vurdér patientens tilstand. (Overskue data i D2-D5) Problem: Overskue journalen 2.Giv ydelser på stedet 3.Følg op på planlagte ydelser 4.Juster diagnoser 5.Planlæg nye ydelser. Se lange delopgaver i A10, A11, A12. A5: Klinisk session Start:Kontakt med patienten, fx stuegang, skadestue. Eller konference om patienten. Slut:Når det der kan gøres nu er gjort. Hyppighed:Totalt: ca. 5 mio/år. Pr. bruger: Op til 20/døgn. Vanskeligt:Katastrofesituationer med mange tilskadekomne. (Alle delopgaver er valgfri og kan gentages. Rækkefølgen er også valgfri) (Fig 1.8D) Arbejdsopgave (en større use case) I alt een A4 side Eksempel eller tilbudt løsning:Kode Overblik over diagnoser og resultater Registrer resultater straks Overblik over bestilte ydelser Registrer straks Rekvirer straks. Afstem med alles kalender... Krav: Støt dette godt Skriv jeres løsning her - evt. via bilag. Vi vælger den der har den bedste løsning