Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 5. Special interfaces - combined styles.

Præsentationer af emnet: "Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 5. Special interfaces - combined styles."— Præsentationens transcript:

1 Plancher til Anskaffelse og kravspecifikation, Forår 2007 Lauesen: Software requirements - Styles and techniques 5. Special interfaces - combined styles Nogle af plancherne stammer fra lærebogen, andre fra kompendiet, del D. Står planchens nummer i parentes, er planchen en tilføjelse til lærebogen eller kompendiet.

2 Eksterne rapporter R1:Systemet skal trykke lønsedler med formatet vist i bilag xx. Klart formål Eksisterende rapporter - uklart formål Nye rapporter From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 R2:Systemet skal vise prognoser over værelsesbelægningen til den månedlige vagtplanlægning. Formatet kan fx være som i xx. R3:Leverandøren bedes vedlægge en liste over de rapporter der findes. R4:Leverandøren skal udvikle op til 200 simple rapporter (som yy) til en pris af kr._____ pr. rapport og op til 50 komplekse rapporter (som zz) til en pris af kr._____ pr. rapport. R5:Systemet skal indeholde en rapportgenerator. Rapporter som yy kan udvikles af: Alm. brugere?ja/nejKursuslængde:_____ Superbrugere?ja/nejKursuslængde:_____ Kundens IT afd.?ja/nejKursuslængde:_____ Fig 5.1 Reports

3 Fig 5.2 Platform requirements We have a platform R1:Product shall run on Pentíum PC’s with 128 MB. Many older PC’s still used, so tasks 2.1 to 2.5 must be supported on 80486 with 64 MB. R2:Our IT staff have expertice in Oracle. Product must use same database platform. R3:Product shall run on MS Windows release xx.yy. Supplier shall for 3 years port his product to new releases within ___ months from release date. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 We want a new platform anyway R4:Customer expects to switch to client-server running OS zz. Supplier shall specify server memory and server speed needed to obtain capacity and response time for Rxx. We want software and hardware (maybe) R5:Supplier shall deliver hardware + software. Supplier shall upgrade if capacity becomes inadequate for the load specified in xx. R6:Product shall run on Pentium PC’s with 128 MB. As an option, total delivery may include the PC’s and hardware support.

4 Fig 5.3A Who can integrate? Hotel system Account system Customer ??? Product supplier Main contractor Customer’s IT dept From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

5 Fig 5.3B Integration reqs, domain-level Sub-tasks: 1.Get guest invoices 2.Post on accounts Problem: Same posted twice or forgotten. 3.Send invoices... Variants: 1a.We have several hotels and want shared accounting. Example solution: Automatic transfer from hotel system to Wonder-Account xx.yy. Account numbers defined in a database table. Unbroken sequence of numbers. Data transmission. Task:5.1 Daily accounting Purpose:Balance with bank account... Send out invoices to company customers Frequency:Daily R1:The product shall support task 5.1. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

6 Fig 5.3C Integration reqs, product-level We have a commercial product R2:Customer uses WonderAccount xx.yy. Hotel system shall ensure transfer within next day. Shall transfer... once and only once. We want a new commercial product R3:Customer wants new account system. Supplier shall specify the systems he integrates with and the degree of transfer reliability. R4:Supplier shall specify detailed interface for chosen account system. Consortium model R5:Supplier shall deliver hotel system plus account system. Account system shall provide standard account facilities. We have a tailor-made system R6:Customer uses old mainframe system YY for accounting. Hotel system must ensure daily transfers, once and only once. Let the supplier study YY documentation? Document the interface? Let YY developer be main contractor? From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

7 Fig 5.4 Main contractor Hotel system Account system Telephone system Sub-contractor Joint design work The optimal split. Exists? Willing? Cost vs. market DB sys Embedded 3rd party product Main contractor Visible 3rd party product From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

8 System Nyt standard ydelsessystem KD: (Fig 1) Integrationskrav: Elektronisk patientjournal Målsætninger: Hurtig integration med nye produktionssystemer Hurtig tilføjelse af nye typer ydelser og pakker Undgå monopol Erstatnings lab-system Eksisterende system: LabSys-X Ydelse Nye skærmbilleder Nye typer ydelser og pakker Glu e

9 KD: (Fig 2) Integration. Hvilket krav er bedst? R1. EPJ systemet skal integreres med LabSys-X. Forklar hvordan. R2. EPJ systemet skal støtte opgave 2 (klinisk session) med ydelser fra LabSys-X. R3. EPJ systemet skal kunne rekvirere ydelser fra LabSys X og hente resultater fra LabSys X. R4. EPJ systemet skal have en API grænseflade til at modtage resultater og skal bruge LabSys-X API kald 17 og 19 til... Design-niveau: En god leverandør med en anden løsning må afvises. Sammenlign fem romaner? Hvordan sammenligner man hvor god støtten er? <> sammenligne skærmbilleder. Sikrer at funktionerne findes, men støtter de opgaverne godt?

10 Laboratoriesystem Kunden forventer integration med sit eksisterende system, LabSys-X, men kan overveje at skifte til et nyt laboratoriesystem. X-grænseflader findes i... Integrationsgrad:Eksempler / løsning: 1.Leverandøren tilbyder et alternativt system der opfylder kravene i... 2.Leverandøren tilbyder integration med LabSys-X som nedenfor. KD: (Fig 3) Integration med eksisterende system 3.Bruger starter X gennem EPJ sys og opgiver patient ID mv. til X 4.Skal ikke opgive patient ID mv.Patient ID mv. overføres automatisk 5.Bruger bestiller gennem EPJEPJ systemet bruger API grænse- skærme som for andre ydelser.fladen til LabSys X. 6.Tilstande og resultater af prøven ses i EPJ som for andre ydelser. 7.EPJ og X deler database. 8.EPJ og X synkroniserer deresKunne fx være hver time. database periodisk (replikering). 9.Data for en patient synkroniseres på brugerens ordre. Grader af integration

11 Nye produktionssystemer Kunden forventer at nye "produktionssystemer" kan integreres med EPJ sys. Interfaces - EPJ som server:Eksempler / løsning: 1.Det nye system kan hente ogKan gøres med messages, API, etc. opdatere EPJ data beskrevet i... 2.Det nye system kan bruge EPJ funktionalitet, inkl. advisering... Interfaces - EPJ som klient: 3.EPJ systemet kan hente og Kan gøres med messages, API, etc. opdatere data i det nye system. 4.EPJ systemet kan bestille ydelser og advare via det nye system. KD: (Fig 4) Integration med nye systemer Dokumentation og rettigheder: 5.EPJ grænsefladerne skal doku-Leverandøren bedes angive hvor menteres så et SW-hus kan forståmeget uddannelse et SW-hus dem og finde dem egnet til formålet.behøver 6.Tredjepart skal have ret til at bruge grænsefladerne. 7.Svartiderne for funktionerne skalAfhængigheder af datavolumen og være dokumenteret.platform bør angives.

12 Kunden forventer at hans egne medarbejdere kan udvide systemet... en slags Visual Basic til hospitaler. Krav:Eksempler / løsning: 1.Medarb. kan definere nye ydelser og tilhørendeProgramagtig erklæring skærmbilleder (se eksempler i... )af datatyper 2.Skærmb. kan registrere og vise ydelsesdata 3.Skærmb. kan vise beregnet data baseret påBeregnede udtryk vilkårligt data i... [databasen]eller programstumper 4.Skærmb. kan aktivere funktioner i EPJ systemet inklusive advisering, print... 5.Skærmb. kan sammensættes af “controls”, fx tekstfelter, tabeller, funktionsknapper, fane- blade, billeder, grafer. Farver kan dynamisk afspejle dataværdier og -tilstande. KD: (Fig 5) Nye skærmbilleder og ydelsestyper 6.Tredjepart kan tilføje nye typer “controls” til brug i skærmbillederne. 7.Der kan opbygges skærmbilleder for diverse enheder, fx PC, PDA, mobiltelefon