Implementation i system & systemkrav

Krav mot system och delsystem är en viktig aspekt av kravhanteringsprocessen inom systemutveckling och projektledning. Dessa krav definierar vad som förväntas av både det övergripande systemet och dess underliggande delsystem för att säkerställa att systemet fungerar som det ska. Här är några viktiga aspekter att överväga när det gäller krav mot system och delsystem:

Krav mot system:

1. Funktionella krav: Beskriver vad en funktion ska klara i det övergripande systemet.
2. Systemets begränsningar: Det är viktigt att klart definiera systemet ska göra och vad systemet inte ska göra, samt gränsytor mot andra system. 
3. Kvalitetskrav: Specificera kraven för kvalitet och precision som systemet måste uppfylla. Det kan inkludera krav på datakvalitet, noggrannhet eller konsistens.
4. Prestandakrav: Ange prestandakrav som systemet måste uppfylla, inklusive svarstider, belastningshantering och skalbarhet.

Krav mot delsystem:

1. Samband med systemkrav: Delsubsystemens krav bör vara kopplade till systemkraven och tydligt visa hur varje delsystem bidrar till att uppfylla systemets övergripande mål.
2. Funktionella krav: Precis som för systemkrav, definiera vad varje delsystem ska utföra och vilka specifika funktioner det måste ha. Detta innebär att delsystemen måste bidra till att uppfylla systemets övergripande funktionella krav.
3. Gränssnittskrav: Om delsystemen interagerar med varandra eller med andra externa system, specificera kraven för gränssnittet, inklusive dataformat och kommunikationsprotokoll.
4. Datahanteringskrav: Om delsystemen hanterar data, definiera krav för hur data ska lagras, bearbetas och överföras inom och mellan delsystemen.hm det finns beroenden mellan olika delsystem, klargör dessa och hur de påverkar systemets funktionalitet.

En noggrann och strukturerad definition av krav för både system och delsystem är avgörande för att säkerställa att alla delar av projektet är på rätt spår och att systemet som helhet uppfyller sina mål och användares behov. Detta hjälper också till att minimera risken för missförstånd och fel under utvecklingsprocessen.

Validering och Verifiering.

Validering är sättet att visa att du byggt rätt system, verifiering ar att visa att du byggt systemet rätt. Om du ska bevisa att du har ett säkert system måste du visa att du uppfyller kraven på säkerhet. 

Initiering till de krav som skall ställas på säkerhet görs genom en riskanalys, e

Mål för säkerheten sätts upp

Det första steget i implementeringen är transformationen från en funktionell arkitektur (vad verksamheten gör) till en logisk arkitektur (hur systemet struktureras mjukvarumässigt för att stödja detta). Detta steg är teknikneutralt; det definierar komponenter och gränssnitt utan att peka ut specifika produkter eller servrar.

1.1 Transformationsteori: Från Process till Komponent Den funktionella arkitekturen består ofta av verksamhetsprocesser och tjänster. I ArchiMate motsvarar detta Business Layer. För att skapa en logisk arkitektur måste dessa element mappas mot Application Layer. Mapping: En Business Function (Verksamhetsfunktion) realiseras av en Application Service (Applikationstjänst). Strukturering: Dessa tjänster grupperas logiskt i Application Components (Applikationskomponenter). En komponent i detta skede är en abstrakt "svart låda" som kapslar in funktionalitet och data. 1.2 Informationsarkitektur och Dataflöden Parallellt med funktionaliteten måste informationsflödet definieras. Funktionella krav på information (t.ex. "Systemet ska hantera användardata") omvandlas till Data Objects (Dataobjekt) i ArchiMate. Den logiska arkitekturen definierar relationerna (Access relationships) mellan Applikationskomponenter och Dataobjekt (Läs, Skriv, Uppdatera). 1.3 AI-stödd Modellering i Steg 1 I denna fas kan AI användas för Requirement-to-Model Transformation. Genom att mata in textbaserade funktionella krav i en AI-modell tränad på ArchiMate-syntax, kan systemet generera förslag på logiska komponenter och deras relationer. Detta säkerställer att inga funktionella krav "tappas bort" i övergången till logik.

När den logiska strukturen är fastställd, inleds fasen för teknisk realisering. Här tas beslut om infrastruktur, plattformar och icke-funktionella krav (NFR) såsom prestanda, säkerhet och tillgänglighet. Målet är att visa var och hur de logiska komponenterna ska exekveras.

2.1 Mappning mot Infrastruktur I ArchiMate innebär detta steg att man kopplar element från Application Layer till Technology Layer och Physical Layer. Noder och Enheter: Logiska applikationskomponenter "placeras" på Nodes (t.ex. Applikationsserver, Molnkluster) eller Devices (t.ex. Mobil enhet, IoT-sensor). Systemmjukvara: Här definieras beroenden till databashanterare, operativsystem och virtualiseringsplattformar (System Software). 2.2 Designmönster och Icke-Funktionella Krav Den tekniska arkitekturen måste hantera systemets kvalitetsattribut. Tillgänglighet: Modelleras genom redundanta noder och replikeringsprocesser (Technology Process). Interoperabilitet: Definierar tekniska gränssnitt (Technology Interfaces) och protokoll (t.ex. REST, SOAP, MQTT) som möjliggör kommunikation mellan noder. 2.3 AI för Arkitekturell Optimering I steg 2 kan AI användas för Design Pattern Recommendation. Genom att analysera den logiska arkitekturen och de icke-funktionella kraven kan AI-agenter föreslå lämpliga infrastrukturella mönster (t.ex. Microservices, Serverless, Edge Computing) och identifiera potentiella flaskhalsar eller säkerhetsrisker i den föreslagna topologin.

Det tredje steget handlar om att paketera arkitekturen för anskaffning och implementering. Här formaliseras beslutet om "Köp vs. Bygg" (Buy vs. Build) och dokumentationen färdigställs för att kunna utgöra underlag vid upphandling av hyllvara (COTS - Commercial Off-The-Shelf) kombinerat med anpassning.

3.1 Systemarkitekturdokumentet (SAD) Ett System Architecture Document (SAD) är en samlad beskrivning som kommunicerar arkitekturen till olika intressenter. Enligt standard (t.ex. ISO/IEC/IEEE 42010) bör SAD innehålla olika Vyer (Views) som adresserar specifika intressenters frågor. Generering: SAD kan idag genereras halvautomatiskt från ArchiMate-modellen. Verktyg kan extrahera diagram och beskrivningar för att skapa ett dokument som alltid är synkroniserat med modellen. 3.2 Strategin: Hyllvara (COTS) vs. Anpassning I ArchiMate-modellen hanteras denna distinktion ofta i Implementation & Migration Layer. Gapanalys: Man modellerar ett Nuläge (Baseline) och ett Målläge (Target). Gapet däremellan är vad som ska anskaffas eller utvecklas. Modellering av COTS: En COTS-produkt modelleras som en Application Component som realiserar en uppsättning logiska funktioner. Modellering av Anpassning: Anpassningar och integrationer (t.ex. "limmet" mellan system) modelleras ofta som separata komponenter eller specifika Application Processes som måste utvecklas internt eller av en integratör. 3.3 Kravspecifikation för Upphandling För att upphandla rätt lösning måste den logiska arkitekturen översättas till kravtext. Funktionella skall-krav: Härleds direkt från Application Functions och Services i steg 1. AI-driven Kravgenerering: Genom att använda Generativ AI kan man mata in delar av ArchiMate-modellen och be systemet generera utkast till kravspecifikationer (RFP - Request for Proposal). AI kan även användas "baklänges" för att analysera inkomna anbud och matcha leverantörernas beskrivningar mot den egna arkitekturmodellen för att upptäcka avvikelser.