Övergripande kravplan Förenklad Utgivning

Kravplan

Versionshistorik

Utredningen Förenklad utgivning föranledde kravarbetet inom ramen för Förenklad Utgivning. Övergripande kraven utgick från lagkrav, kundbehov och Ineras affärsmål.

I linje med Ineras kravhanteringsprocess och för att säkerställa att samtliga s.k. ”högnivåkrav”/flöden/användningsfall (för definitioner se Ineras kravanvisning) hanteras på ett strukturerat och spårbart sätt, samlas de i ett specifikt namngivet Confluence-area kallat ”SITHS eID Portal”. Kravspecifikationen tilldelas ett versionsnummer för att möjliggöra historikhantering, ändringshantering och versionskontroll. Dessutom innehåller Confluence en generell versionshantering. Vid ny systemversion uppdateras kravspecifikationen med ett uppdaterat versionsnummer målversionsnummer.

Användningsfallen/högnivåkrav/flöden bryts systematiskt ned till utvecklingsbara krav för att säkerställa att utvecklarna och testare har en klar förståelse för vad som ska utvecklas och varför. Denna nedbrytning görs i form av olika ATK, acceptanskrav.  

För att garantera spårbarhet kopplas varje detaljerat krav till ett högnivåkrav i kravspecifikationen. Varje ATK identifieras med ett unikt krav-ID, vilket underlättar uppföljning och granskning.

Elicitering av högnivåkrav

Elicitering genomfördes under förstudien i nära samarbete med den externa referensgruppen, SITHS PA med kundrepresentanter från bland annat regionerna Stockholm, VGR, Skåne samt Göteborgs stad och Skånes kommuner. SITHS PA äger och förvaltar policyn för identiferingstjänsten SITHS och kraven måste utgå från verksamhetens behov och behöver förankras i policyn. Elicitering utgick också från DIGGs tillitsramverk för svensk e-legitimation , referensarkitekturen för Identitet och Åtkomst samt andra närliggande tjänster som HSA och Personuppgiftstjänsten, PU. Både referensarkitekturen, HSA samt PU påverkar SITHS-tjänsten och identifieringen av användare vid utfärdande av en e-legitimation.

Dokumentation

All kravdokumentation sker i Confluence, både vad gäller användningsfall eller detaljerade krav. Oavsett vilken kravkategori, det vill säga funktionella, kvalitativa/icke-funktionella krav eller s.k. begränsningar (Constraints).

Arbetsmetod

Kravarbete är ett teamarbete. Deltagare och ansvar:

Under kravarbetet får kraven olika statusar enligt följande

Vi har infört en kravsprint som löper över två veckor, men som nu ändras till en veckolång sprint efter önskemål från Test och Utveckling. Kravöverlämning kommer att ske i samband med respektive sprintplanering för varje utvecklingsteam. Respektive teamlead ska inför kravöverlämningen specificera vilka krav som ska överlämnas. Om denna tidplan mot förmodan inte kan hållas, ska en ny tidplan tas fram baserat på en ny prioritering. TPL beslutar om den nya tidplanen, som sedan ska stämmas av med HPL

Viktigt att poängtera, och i enlighet med kravanvisningen och Ineras SAFe, är att kravarbetet är en iterativ process. Arbetet pågår kontinuerligt, med en ökande precision och detaljeringsgrad över tid. Detta innebär att processen fortlöper genom hela projektet, men med varierande faser och intensitet.

När kraven har fått status ”Funktionellt godkänt” skapar respektive Team Epic eller Jira i respektive Teams Jira projekt. TPL, informeras när nya Epics eller Jiror skapas i respektive projekt.

Samtliga Epics, Jiror och tasks måste alltid taggas med ”Förenklad_Utgivning”.   

 Validering av kraven sker i olika steg.

Övergripande validering har redan skett med hjälp av den externa referensgruppen och produktägarna för både Paket 1 och Paket 2 under förstudien. Valideringen syftar till att säkerställa att kraven är i linje med verksamhetsbehoven.

Efter varje kravsprint sker kravöverlämning av kravgruppen med lösningsarkitekt i spetsen till respektive utvecklingsteam. Respektive Teamlead ansvarar för att ta emot kraven och bjuder in rätt resurser från sitt team. Facilitator skickar agendan till utvecklingsteamet inför genomgången. Under överlämningsmötet bestäms om kraven får statusen funktionellt godkänt eller inte.

Respektive Teamlead beslutar om kraven är funktionellt godkända. Om kraven inte får status funktionellt godkänt går de tillbaka till kravgruppen för bearbetning. Produktägarna deltar i samtliga överlämningsmöten. I ett senare skede kommer testare att verifiera kraven genom att undersöka om systemet fungerar ur ett funktionellt perspektiv.

Övergripande tidplan för återstående kravarbete gällande Paket 1 – Förenklad utgivning

• April – Maj: Loggning, onboarding UX, Onboarding CGI, onboarding digital id-kontroll leverantör.

  • Deadline 20250630.

• Juni: Reporter + Ev. Input från digital id-kontroll-leverantör som påverkar kravbilden + Utestående frågor och utredning

  • Deadline 20250831

• Augusti: Fakturaunderlag + utstående frågor och utredning

  • Deadline 20251015

• September-Januari: iterativ process baserat på resultatet av utveckling och test. Ändringshantering, fokus på lösning samt löpande utestående frågor

Ändringshantering

Alla ändringar som påverkar projektets leveranser, tidsramar eller resurser ska dokumenteras på ett konsekvent och transparent sätt. Detta inkluderar:

• Beslut från styrgruppen: Alla ändringar som ändrar projektets måldimensioner (tid, kostnad och kvalitet/omfattning) ska beslutas av styrgruppen och dokumenteras i styrgruppens beslutslogg. HPL dokumenterar och informerar styrgruppen om dessa eventuella förändringar, styrgruppen beslutar om dessa förändringar skal genomföras eller inte. Dessa beslut ska vara väl motiverade och innehålla en tydlig beskrivning av ändringens påverkan.

• Operativa avvikelser och justeringar: Ändringar som ligger inom projektets befogenheter och mandat hanteras direkt av projektledningen och dokumenteras löpande efter behov i Conflence, Jira eller Teams. Detta kan innefatta till exempel justeringar av krav, arbetsmetoder, val av teknik, mindre resursförändringar eller finjusteringar av tidsplanen. Större operativa avvikelser och justeringar som inte kräver styrgruppsbeslut tas upp på beredningsmöten och dokumenteras i beredningsgruppens protokoll.

• Justeringar i krav som påverkar verksamheten, Ineras kunder, ska stämmas av först med den externa referensgruppen, SITHS PA. Om dessa justeringar påverkar projektets mål och tidplan behöver hanteras och prioriterats. Dessa krav ska tas upp med HPL för prioritering i samverkan med projektägaren i beredningsforum.

 Inera SAFe och diverse möten

I SAFe finns en mängd olika möten på teamnivå samt program- och portföljnivå. Här beskrivs de relevanta möten som i stor utsträckning involverar projektet och hela teamet. Utöver kravarbetsmöten och dialog med SITHS PA det är här kommunikationen sker mellan de olika teamen.

Dagligt Scrum-möte: Deltagare är respektive utvecklingsteam, tjänstespecialist och produktägare. TPL deltar i mån av tid.

Sprintplanering: Deltagare är respektive utvecklingsteam, tjänstespecialister, produktägare, TPL. Lösningsarkitekt deltar vid behov.

Sprintgenomgång: Ett möte som hålls i slutet av varje sprint där teamet demonstrerar det färdiga arbetet för att få feedback. Vid behov ska produktbackloggen uppdateras. Respektive TeamLead informerar TPL, om en demo kan hållas i slutet av respektive sprint, beroende på om det finns färdigt arbete eller inte. Om ett arbete är pågående, men ej helt färdigt arbete, kan teamet eventuellt visa upp detta och förklara vad som återstår att göra. Teknisk PL har en tät dialog med Respektive TeamLead för att stämma av läget i varje sprint och besluta om det ska genomföras en demo eller inte. HPL bjuds in som frivillig deltagare när det hålls en demo.
Sprintgenomgång är inte bara en demonstration, utan också ett tillfälle för samarbete och feedback. Deltagare är kravgruppen, produktägare och TPL. HPL deltar i mån av tid.

Inkrementplanering (PI): En del av Ineras SAFe. Samtliga team, kravgruppen, HPL och TPL deltar.