Värdeströmmar, processer som levererar värde

Kravhantering, funktionella och icke funktionella krav.

Funktionella krav och icke funktionella krav? Funktionella beskriver systemets funktion, icke funktionella de andra, egenskaper som kvalitet prestanda, säkerhet. Så att T-forden ska vara snabbare än hästar, vad är det för krav?

Ulf Dellborg

Podd

I den digitala ekonomin överbryggar Enterprise Arkitektur (EA) klyftan mellan abstrakt strategi och konkret teknik. Funktionella krav binder i EA ihop affärsarkitektur med systemarkitektur. Dessa beskriver vad systemet ska göra. Trots deras centrala roll råder ofta begreppsförvirring kring vad funktionella krav faktiskt är, hur de skiljer sig från tekniska specifikationer eller affärsregler, och hur de bör förvaltas över tid i komplexa systemlandskap.

Varför behövs värdeströmmar

Den här artikeln analyser funktionella och icke funktionella krav, ur mitt perspektiv som arkitekt och pilot. Jag analyserar hur krav härleds ur affärsodell och processer, samt hur de används för att driva allt från upphandlingar till agil mjukvaruutveckling.

Jag vänder mig till dig, som precis som jag, vill förstå vad kravanalytikern menar med funktionella krav.

Vad är krav och funktionella krav?

Krav: Ett oeftergivligt önskemål som ofta ställs som villkor för att utföra el. godta något (SO)

Nyckelaktiviter i strategic canvas, toppnivån för värdeströmmarna

I grunden är ett krav ett villkor eller en förmåga som måste uppfyllas av ett system för att lösa ett problem eller uppnå ett mål för en intressent.

Ett funktionellt krav definierar beteendet hos ett system fokuserat på verksamhetslogiken. Icke-funktionella krav beskriver egenskaper.

Arkitektens uppgift är att säkerställa att systemets externa beteende stödjer affärsprocessen. Jag brukar nöja mig med det och att definier funktionell arkitektur.

Skillnad Funktionella och Icke-Funktionella Krav

Vad som är funktionella och icke funktionella krav är för mig inte entydig. De står ofta i konflikt med varandra och Gränsen mellan FR och NFR är flytande.

Säkerhetdkrav måste brytas ner i specifika funktionella krav för implementation. I regulatoriska kontexter transformeras icke-funktionella önskemål om motståndskraft till hårda, lagstadgade funktionella krav.

Jag tycker inte du behöver fokusera på vad som är vad. Bry dig om metoden att bygga rätt system.

Var hittar du funktionella krav?

Funktionella krav finns i affärsmodell och rocesser

Du hittar kraven i en trestegsraket som utgår från affärsmodellen skapas du en tydlig koppling från den strategiska nivån till detaljerad funktionalitet:

Värdeströmmen beskriver hur värde.
Affärsprocessen detaljerar arbetsflödet.
Applikationsprocessen visar systeminteraktionen.

Detta säkrar att varje investering bidrar till affärsmodell.

Läs mer

Lagkrav, Funktionellt tvång

Alla måste följa regelverk. GDPR innebar en förbättringa för skyddet av peronuppgifter. För bank och finans finns en regelverk som t ex AML, MIFID, IDD, Solvens och föraäkringsrörelselagen. Dislcosureförordning ochTaxonomiförordning är exempel regelverk, compliance ska oftast kunna visas.

Många ser regelverken som hinder och skapar en ineffektiv kravmaskin i jakten på paragrafer.

Funktionella kravs plats i arkitekturen

Kraven sätts mot den funktionella arkitektur

Funktionell arkitektur validerar att systemets beteende är komplett och håller ihop innan logisk och teknisk arkitektur fastställs.

Funktionella arkitekturen påklädd med kunktionella krav visar vad systemet ska göra för att uppfyllakrav från intressenter. Vyn beskriver systemets funktionella element och deras interaktioner.

Läs mer

Funktionella krav relaterat andre krav

En utmaning är den röda tråden från strategi till kod. BABOK beskriver denna kravhierarki.

Affärskrav definierar varför med fokus på värdeskapande och strategi.
Intressentkrav beskriver behoven hos specifika användargrupper eller roller för att stödja affärskravet.
Funktionella krav beskriver vad systemet ska göra.
Teknisk desgn som beskriver hur systemet byggs för att möjliggöra funktionen. r.

Kraven i Agila och Skalade Miljöer

Traditionell EA och kravhantering associeras ofta med tunga "Vattenfalls"-projekt och dokumentation. Men hur fungerar funktionella krav i en modern, agil kontext?

Från Kravspecifikation till Backlog: SAFe och Agil Arkitektur

I agila ramverk som SAFe (Scaled Agile Framework) ersätts den kravspecifikationen av en hierarkisk och backlog. Denna struktur bryter ner krav i nivåer.

På den högsta nivån, portföljnivån, hanteras Epics. Dessa är omfattande initiativ, ofta tvärfunktionella, som motsvarar en förändring i en affärsförmåga (Capability). Ett exempel på detta skulle kunna vara "Inför AI-driven kundtjänst".
Dessa Epics bryts sedan ner till nästa nivå, "Large Solution", där de tar formen av Capabilities eller Features. Detta är specifika systemtjänster som levererar direkt värde till verksamheten, såsom en "Chatbot som kan hantera returer".
Slutligen, på teamnivån, definieras de atomära funktionella kraven som User Stories. Dessa fokuserar strikt på användarvärde och formuleras ofta utifrån användarens perspektiv, till exempel: "Som kund vill jag kunna ladda upp en bild på min trasiga vara för att starta ett returärende."

Enterprise Arkitektens roll i SAFe skiljer sig från traditionella metoder då de sällan skriver detaljerade User Stories; detta ansvar faller oftast på produktägaren. Istället fokuserar arkitekten på att definiera och förvalta Enabler Epics. Detta är arkitektoniska och tekniska krav som utgör förutsättningen för att affärsfunktionerna ska kunna realiseras. Om teamet exempelvis ska bygga den nämnda chatboten (ett funktionellt krav), är det arkitektens uppgift att identifiera och definiera det underliggande behovet, såsom "Etablera en molnbaserad ML-plattform och API-gateway" (ett tekniskt/arkitektoniskt krav). Genom detta arbete skapar arkitekten en så kallad "Architectural Runway" – en robust teknisk landningsbana som möjliggör att funktionella krav kan implementeras snabbt och säkert utan att systemet drabbas av instabilitet eller eskalerande teknisk skuld.

DevOps och Kontinuerlig Validering

I en DevOps-miljö förändras synen på funktionella krav från "Dokumentation" till "Exekverbar kod". Metoder som Behavior Driven Development (BDD) används för att formulera krav som tester. Gherkin Syntax:

Feature: Returhantering
Scenario: Kund returnerar trasig vara
Given att kunden är inloggad
When kunden laddar upp en bild
Then ska systemet skapa ett ärende med status "Granskning".

Här är testkoden själva kravspecifikationen. Detta säkerställer att kravet aldrig blir inaktuellt ("Documentation Drift"), eftersom systemet inte går att bygga (Build Failure) om inte kravet (testet) är uppfyllt. För Enterprise Arkitekten innebär detta att spårbarhet flyttas från Excel-ark till versionshanteringssystem (Git) och CI/CD-pipelines.

Microservices och Domänstyrd Design (DDD)

Microservices-arkitektur har också förändrat kravhanteringen. Istället för en stor lista med krav för hela systemet, bryts kraven ner per Bounded Context (enligt Domain-Driven Design).

Funktionella krav för domänen"Fakturering" hanteras isolerat från domänen "Lager". EA:s roll blir att definiera gränssnitten mellan dessa domäner. Kraven handlar då om interaktionen mellan tjänster: "Faktura-tjänsten ska prenumerera på händelsen OrderCreated från Order-tjänsten.".

Vad Används funktionella krav till

Vi har definierat vad krav är och var de kommer ifrån. Men vad är deras praktiska nytta i det dagliga arbetet för en organisation?

Gap-Analys och Arkitekturell Utvärdering

Gap-analys är processen att jämföra nuläget (Baseline Architecture) med målbilden (Target Architecture). Funktionella krav är måttstocken i denna analys. Metoden kallas ibland CΔV (Current Gap Vision).44 Scenario: Företaget ska införa en ny affärsmodell för prenumerationer. Definiera Krav (Vision): "Systemet måste stödja återkommande kortbetalningar (Recurring Billing)." Utvärdera Nuläge (Current): Nuvarande ERP stöder endast engångsfakturor. Identifiera Gap (Delta): Gapet är avsaknaden av logik för att spara tokeniserade kortuppgifter och schemalägga dragningar. Lösningsarkitektur: Detta gap definierar omfattningen för projektet. Antingen köper vi en "Subscription Management"-modul (Buy) eller bygger det själva (Build). Utan detaljerade funktionella krav blir Gap-analysen en gissningslek. Med precisa krav kan arkitekten kvantifiera gapet och därmed kostnaden för förändringen.

Upphandling och RFP-processen

Vid upphandling av stora Enterprise-system (ERP, CRM, HR-system) är Request for Proposal (RFP) det viktigaste verktyget. Funktionella krav utgör kärnan i utvärderingen. En standardiserad utvärderingsmatris används ofta där leverantörer måste svara på varje funktionellt krav.

Enterprise Arkitekter använder denna data för att bedöma "Fit-to-Standard". Om en leverantör har för många "M" (Modification), innebär det att systemet måste skräddarsys med kod. Detta ökar drastiskt Total Cost of Ownership (TCO) och försvårar framtida uppgraderingar. EA rekommenderar ofta att verksamheten ändrar sina processer (och därmed sina funktionella krav) för att matcha standardlösningen ("Y"), snarare än tvärtom.

Spårbarhet och Konsekvensanalys

En Requirements Traceability Matrix (RTM) är ett levande dokument (eller databas) som mappar krav genom hela livscykeln: Affärskrav -> Funktionellt Krav -> Designkomponent -> Källkod -> Testfall Användning vid Förändring (Change Management): Om en intressent vill ändra ett krav ("Vi ska inte längre stödja betalning med check"), kan arkitekten använda RTM för att se exakt vilka systemkomponenter som påverkas, vilka tester som blir inaktuella, och vilka affärsprocesser som måste ritas om. Detta minimerar risken för oförutsedda sidoeffekter i komplexa systemlandskap.

Validering och Testning (V-Modellen)

Slutligen är funktionella krav basen för User Acceptance Testing (UAT). Ett funktionellt krav måste vara:

Atomärt: Det beskriver en sak.
Otvetydigt: Det kan bara tolkas på ett sätt.
Verifierbart: Det går att skriva ett test som ger svaret Sant eller Falskt.

Om kravet är "Systemet ska vara användarvänligt", är det inte ett funktionellt krav (det är ett NFR) och går inte att testa binärt. Om kravet är "Systemet ska kräva max 3 klick för att slutföra en order", är det funktionellt och testbart. I V-modellen verifierar Systemtestet att de funktionella kraven är uppfyllda, medan Acceptanstestet verifierar att Affärskraven är uppfyllda.

Ramverk i EA som Kontext.

The Open Group Architecture Framework (TOGAF) är industristandard för EA. En av dess mest distinkta egenskaper är placeringen av kravhantering. I TOGAF:s Architecture Development Method (ADM) är fasen Requirements Management inte en sekventiell fas som sker i början och sedan avslutas (som i Vattenfallsmodellen). Istället placeras den i centrum av ADM-hjulet och interagerar kontinuerligt med alla andra faser (A till H).

Kravens Evolution genom ADM

Phase A (Architecture Vision): Här identifieras de övergripande, strategiska funktionella kraven. "Vi behöver en förmåga att sälja direkt till konsument." Dessa är ofta kopplade till affärsmål och vision.
Phase B (Business Architecture): Här detaljeras kraven baserat på affärsprocesser. "För att sälja direkt till konsument måste processen för Order-to-Cash stödja kortbetalning." Här skapas ofta en "Requirements Catalog" där funktionella krav listas och kopplas till affärstjänster.
Phase C (Information Systems Architecture): Detta är den mest intensiva fasen för funktionella krav. Här delas kraven upp i: Data Architecture: Krav på datastrukturer och informationsflöden (t.ex. "Kundobjektet måste innehålla leveransadress"). Application Architecture: Krav på applikationsfunktioner (t.ex. "CRM-systemet måste exponera ett API för adressuppslag").
Phase D (Technology Architecture): Här valideras att de funktionella kraven är tekniskt genomförbara med vald infrastruktur.
Phase E (Opportunities and Solutions): Gap-analys utförs. Vilka funktionella krav kan lösas med nuvarande system (Reuse) och vilka kräver nyanskaffning (Buy/Build).

TOGAF betonar att funktionella krav är dynamiska. När man rör sig genom faserna upptäcks nya krav, och gamla krav förfinas eller förkastas. Den centrala kravhanteringsprocessen säkerställer att dessa förändringar kommuniceras till alla intressenter, så att inte

Zachman-ramverket: Den Ontologiska Placeringen av Funktion

Zachman-ramverket är inte en metodik (process) utan en ontologi (klassificeringsschema). Det består av en matris med 6 kolumner (Interrogatives: What, How, Where, Who, When, Why) och 6 rader (Perspectives: Planner, Owner, Designer, Builder, Integrator, User).

I Zachman-ramverket är funktionella krav primärt lokaliserade i kolumnen "HUR" (Process/Function). Analysen av denna kolumn genom raderna visar hur ett krav materialiseras:

Rad 1 (Planner - Scope): Här definieras funktionen som en lista av affärsprocesser eller marknadsaktiviteter. (Ex: "Fakturering").
Rad 2 (Owner - Enterprise Model): Här beskrivs Affärskraven. Funktionen modelleras som en affärsprocessmodell (t.ex. BPMN). Detta visar logiken i verksamheten oberoende av system.
Rad 3 (Designer - System Model): Detta är den kritiska nivån för Funktionella Krav i IT-mening. Här transformeras affärsprocessen till applikationslogik. "Fakturering" blir "Generera PDF-faktura och maila till kund".
Rad 4 (Builder - Technology Model): Här definieras den tekniska implementationen (pseudokod, kontrollstrukturer).

Insikt: Zachman-ramverket tvingar arkitekter att verifiera "vertikal spårbarhet" (Alignment). Ett funktionellt krav på Rad 3 (System) måste ha en förälder på Rad 2 (Affär). Om ett systemkrav saknar koppling uppåt, är det sannolikt onödig funktionalitet ("Gold Plating") som inte tillför affärsvärde. Omvänt, om en affärsprocess på Rad 2 saknar motsvarande systemfunktionalitet på Rad 3, har vi ett "Gap" där verksamheten saknar IT-stöd.

ArchiMate: Det Visuella Språket för Funktionsmodellering

ArchiMate, som också förvaltas av The Open Group, erbjuder ett grafiskt språk för att modellera dessa samband. I ArchiMate 3.x finns explicita element för att hantera krav och deras relationer till arkitekturen.

Viktiga element och relationer: Requirement (Motivation Layer): Representerar själva kravet. Business Function (Business Layer): Representerar en grupp av affärsbeteenden (t.ex. "Lagerhantering"). Application Function (Application Layer): Representerar automatiserat beteende i ett system. Application Service (Application Layer): Representerar funktionen exponerad mot omvärlden (t.ex. ett API).

Modelleringsmönster: Ett vanligt mönster i ArchiMate för att visa uppfyllnad av funktionella krav är: Stakeholder har en Driver (Drivkraft: "Kostnadseffektivitet"). Driver leder till ett Goal (Mål: "Automatisera manuell orderläggning"). Goal realiseras av ett Requirement (Krav: "Systemet ska stödja EDI-order"). Application Service (EDI Gateway) realiserar Requirement.

Detta visuella samband gör det möjligt att utföra konsekvensanalys. Om vi tar bort "EDI Gateway", ser vi direkt i modellen att "Requirement" blir "Unrealized", vilket i sin tur hotar "Goal" och påverkar "Stakeholder". Detta gör funktionella krav till en integrerad del av arkitekturmodellen, inte bara en textlista i ett Word-dokument.