Anskaffelse og kravspecifikation

Præsentationer af emnet: "Anskaffelse og kravspecifikation"— Præsentationens transcript:

1 Anskaffelse og kravspecifikation
SR5_Special Interfaces and integration

2 SR5: Special interfaces and integration
Kilder SR: Soren Lauesen: Software requirements - Styles and techniques. Addison-Wesley, 2002. UID: Soren Lauesen: User interface design - A software engineering perspective. Addison-Wesley, Fra kapitel 5. SL-07: Søren Lauesen: Vejledning til kravskabelon SL-07. Samfundslitteratur, 2007. Ekstra: Nye slides som ikke har noget sidestykke i bøgerne. Mange slides er vist i dansk oversættelse. © 2002, 2005, Pearson Education retains the copyright to the slides from the books, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

3 3. SR5.1 Reports Vores gamle system har 500 rapporter,
men vi ved ikke hvor meget de bruges Eksterne rapporter R1: Systemet skal trykke lønsedler med formatet vist i bilag xx. Klart formål Eksisterende rapporter - uklart formål Nye rapporter 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/nej Kursuslængde: _____ Superbrugere? ja/nej Kursuslængde: _____ Kundens IT afd.? ja/nej Kursuslængde: _____

4 4. SR5.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 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. 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. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

5 5. SR5.3A Who can integrate? Customer’s Customer IT dept ??? Hotel
Product supplier Main contractor Hotel system Account system Or a consortium From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

6 6. Integrationskrav: Elektronisk patientjournal
Kontekstdiagram F1. SKS Koder EPJ-system Klinik Rekvisition Svar F2. LabsysX Dobbelt linie: Leverandøren integrerer F10. Nye eksterne systemer Patient- administration

7 7. (SL-07 F) Hæmmende detaljering (fra H:S)
Krav 512: Systemet skal være modulopdelt med SOA grænseflader Integrationsplatform Medicinmodul Notatmodul Bookingmodul Data må ikke lagres lokalt Grænseflade 3: Opret ordination Hent ordination XML En ny SOA service mellem to leverandører: Ca. 2 * DKK Leverandør: Det bliver dyrt. Vores system skal laves helt om. Hvorfor dette krav? Kunden vil være leverandøruafhængig - undgå monopol. Bedre løsning: Krav 512: Periodisk overførsel plus overførsel pr. patient på brugers ordre. Krav 513: Tredjepart skal have ret til at udtrække alt data. Krav 514: Tredjepart skal kunne integrere med andre systemer. Krav 515: Data og grænseflader skal dokumenteres så tredjepart kan forstå dem og finde dem egnet til formålet.

8 E: Eksternt system E: Eksternt system
8. Integrationsløsninger - S skal bruge data fra E Lokalt E-data Eksternt E-data Initiativ S: System E: Eksternt system data Data-aktualitet (hvor friskt er det lokale data?) 1. S overfører periodisk fra E, fx hver nat. 2. S overfører på brugers kommando. 3. S henter altid data i E (S har kun en temporær kopi). S: Klient - initiativ E: Server 4. E overfører periodisk. 5. E overfører data når det er til rådighed. 6. E meddeler S når nyt data er til rådighed. S: Server E: Klient System E: Eksternt system Opgaver: Mail og mail-server? Sagsbehandlers brug af CPR? Den rejsende handelsmand? Medicinfortegnelse, mv. (SKS koder)

9 9. Integrationskrav (behov) - S skal bruge data fra E
Bruger er ligelad med client-server Lokalt E-data Eksternt E-data System E: Eksternt system Data-aktualitet (hvor friskt er det lokale data?) 1. Lokalt E-data højst et døgn gamle. 2. Bruger vil ofte vide om der er nyt E-data. 3. Bruger vil evt. have nyeste E-data. 3? Bruger har altid behov for nyeste E-data ? 4. Off-line: Bruger skal kunne udføre tasks C1-C5 uden adgang til E. Løsning Overførsel hver nat. Eller ... S til E: data med tid > sidst? Overfør på brugers ordre. Henter altid hos E. Overførsel ved connect og disconnect. Svartider (evt. L1) 5. Bruger skal have adgang til lokalt E-data med samme svartid som for andet lokalt data. 6. Bruger kan hurtigt se om der er nyt E-data. 7. Nyt E-data skal kunne overføres og vises inden bruger taber tålmodigheden (kunden forventer 20 sekunder).

10 OK, men svært at vurdere samtidig med brugerfladen
10. Andre integrationskrav Task-støtte 1. Systemet skal integrere med E så tasks C1-C5 støttes effektivt. Hvilket data 2. Systemet skal bruge E-data om varepriser og lager. Andre funktioner 3. Systemet skal kunne advisere E om . . . 4. Systemet skal modtage advisering fra E om . . . OK, men svært at vurdere samtidig med brugerfladen Data-overførsel til E 5. E skal have nyt S-data inden et døgn. 6. E skal kunne få at vide om der er nyere S-data. 7. E skal kunne bede om nyeste S-data. System E: Eksternt system Lokalt E-data Eksternt E-data

11 11. Integration: Ansvar og rettigheder
Lokalt E-data Eksternt E-data leverandør-ansvar System E: Eksternt system Integrationsansvar 1. Leverandøren skal integrere med E. 1a. Leverandøren skal integrere med E. E-leverandøren kan være konsulent. 1b. Kunden (eller tredjepart autoriseret af kunden) skal integrere med E og System-leverandøren skal støtte ham. Ret til at bruge data og grænseflader (fælles for alle integrationer) 2. Kunden (eller tredjepart autoriseret af kunden) skal kunne integrere systemet med andre systemer. 3. Det skal være let at tilføje nye grænseflader (services). 4. Kunden skal have mulighed for at udtrække alt data fra systemet, fx for at konvertere dem til et andet system. 5. Systemets tekniske grænseflader skal dokumenteres så kunden kan forstå dem og bruge dem til formålet.

12 12. Integration: Sikkerhed og baggrund
Adgangsret (evt. H1, fælles for alle integrationer) 1. Må kun hente E-data til brugers PC i henhold til sikkerhedsreglerne. Sikring mod tab af data (evt. H3, fælles for alle integrationer) 2. Systemet skal beskytte mod tab eller dublering af data ved overførslen, fx hvis et af systemerne har været off-line eller er brudt sammen. 3. Systemet skal beskytte mod udelelighedsproblemer, fx at bruger A . . . 4. Systemet skal logge alle fejl ved overførslerne. Baggrund (ikke krav, men forudsætninger for kravene) Eksternt system: Axapta, version . . . Tasks: Integration med E bruges i C1-C5. Dokumentation: Grænsefladen til E er dokumenteret i Eller: Detaljerne afklares under proof-of-concept. Ændringsfrekvens: E-data opstår løbende gennem dagen. Eller: E-data opdateres ca. hvert kvartal. Datavolumen: Der tilføjes eller ændres ca. 400 E-records pr. dag. I alt er der ca. 100,000 records hver på ca. 100 tegn.

13 13. Eksempel: SL-07 F1. Simpel integration
Eksternt system: SKS-tabellerne omfatter koder for diagnoser, ydelser, afdelinger, mv. Tasks: Koderne bruges ved de fleste arbejdsopgaver. Dokumentation: Tabellerne er bl.a. tilgængelige som zip-tekstfiler med fast feltbredde fra Sundhedsstyrelsens web-site. De er dokumenteret på samme web-site. Ændringsfrekvens: Afdelingskoderne opdateres månedligt, de øvrige koder kvartalsvis. Datavolumen: SKS-tabellerne udgør op til records à ca. 100 tegn. Integrationsansvar: Eksempler på løsning: Kode: 1. Leverandøren integrerer systemet med SKS-koderne. Krav om data-aktualitet: Eksempler på løsning: Kode: 2. Lokale koder bør højst være en uge gamle. Systemet overfører koder hver ___ dag. 2p. Det sker at de nye SKS-koder giver problemer, fx at de er i konflikt med tidligere lokale koder. 3. I særlige tilfælde kan der være behov for større data-aktualitet. Driftsafdelingen kan starte en dataoverførsel.

14 14. Eksempel: SL-07 F2. Eksisterende system
Eksternt system: LabsysX. Tasks: Laboratorie-resultater bestilles og bruges i de kliniske sessioner (C10). Dokumentation: De tekniske grænseflader til LabsysX er beskrevet i . . . Ændringsfrekvens: Der leveres ca. 400 resultater pr. dag, fordelt mellem 8:00 og 16:30. Datavolumen: Hvert resultat består af ca tegn. Integrationsansvar: Eksempler på løsning: Kode: 1. Leverandøren integrerer systemet med LabsysX. MediData kan være konsulent. Krav om data-aktualitet: Eksempler på løsning: Kode: 2. Lokale data bør højst være tre timer gamle. Systemet overfører data periodisk. Eller: Data overføres på LabsysX's initiativ. 3. Bruger vil ofte have nyeste resultater for en bestemt patient. Systemet henter resultaterne på brugers ordre. Krav om svartider: Se L1.

15 15. (Integration med eksisterende system, fortsat)
Støtte til arbejdsopgaverne: Eksempler på løsning: Kode: 4. Integrationen skal støtte C10 på en effektiv måde, fx så bestillinger og adviseringer håndteres på samme måde som for andre ydelser, uden genindtastning af patientdata. Andre funktioner: Eksempler på løsning: Kode: 5. Bruger kan bestille LabsysX-tests gennem systemet. Systemet bruger API-grænsefladerne til LabsysX 6. Systemet kan advisere bruger om nye eller udeblevne LabsysX-resultater. 7. Systemet kan advisere LabsysX om udeblevne resultater. Data-overførsel til LabsysX: Ingen relevante. Eksempler på løsning:

16 16. Refleksion - hvorfor var integrationskrav svære?
Uklart hvad problemet var (hvad er et integrationsbehov?). Litteraturen handler kun om løsninger. "Best paper award" i Kyoto RE'2004 for krav der graduerer løsninger. Flere og flere integrationer kræves i praksis. Gennembrud Start med løsninger og spørg "hvorfor". Se på stor samling eksisterende integrationskrav. Katalog over "behovstyper". Kravområder der er i spil for en integration Data-aktualitet Tasks der støttes Data der overføres Andre funktionelle krav (advisering, mv.) Sikkerhed (adgangsret og datatab/dublering) Brugervenlighed (task efficiency) Dokumentation (til tredjeparts integration) Datakonvertering (til nyt system) Svartider (for lokalt data og eksternt) Vedligehold (til nye integrationer) Eneste nye område