Specifika underhållbarhetskrav

!Specifika underhållbarhetskrav
Ibland vet man redan vid utvecklingen av ett system att några specifika förändringar kan komma att behövas i framtiden. Kanske har man skäl att tro att systemet i framtiden behöver stödja flera valutor, eller att det kommer att behöva användas via Internet. Det är vanligt att kunna förutse sannolika framtida förändringar som man ändå inte vill ha med vid utvecklingen för att den ska bli billigare, snabbare eller helt enkelt för att man vill låta organisationen använda systemet en tid innan man bestämmer om förändringarna behövs. Krav som handlar om att beskriva tänkbara framtida förändringar, så att systemet redan från början kan vara förberett för att förändras kallas ''specifika underhållbarhetskrav''.

För att ett specifikt underhållbarhetskrav ska vara bra räcker det inte att det beskriver en tänkbar framtida förändring. Kravet måste även beskriva hur väl förberett systemet ska vara för förändringen. Det är till exempel stor skillnad på att en förändring är tekniskt möjlig och att förändringen ska kunna göras genom några enkla inställningar i en parameterfil. Några exempel på specifika underhållbarhetskrav:

*Alla texter i systemets användargränssnitt skall kunna bytas ut genom att ändra i en textfil.
*Införande av konceptet "bonuskund" som har en personlig rabattsats kopplad till sig skall kunna göras utan att systemets databasschema behöver ändras.
*Systemet skall kunna förändras för att stödja följande tänkbara framtida krav, utan några förändringar i telefonimodulen: rapporterna ska kunna visas på mobila enheter, lönetillägg ska kunna baseras på personlig försäljning.

Det är alltså viktigt att varje specifikt underhållbarhetskrav beskriver hur väl förberett systemet ska vara för en viss förändring. Lämpligen uttrycker man detta i termer av vilken påverkan på systemet förändringen skulle ha om den genomfördes. Det finns ett stort antal varianter av påverkan, exempelvis:

*Förändringen skall kunna utföras utan att systemets källkod behöver ändras eller utökas.
*Förändringen skall kunna utföras utan att systemets källkod behöver ändras. Ny källkod får dock läggas till (och anrop till den nya koden får läggas till i befintlig kod).
*Förändringen skall kunna utföras utan att några förändringar behöver göras i systemets kompilerade enheter. Nya kompilerade enheter får dock läggas till.
*Förändringen ska kunna utföras utan att systemets databasschema behöver ändras.
*Förändringen skall kunna utföras utan att systemets klientmoduler måste ändras.
*Ingen ändring alls, dvs. systemet ska redan ha funktionen inbyggd, men det ska gå att köra systemet utan att använda den. Det här betyder att det inte är fråga om något underhållbarhetskrav utan ett normalt funktionellt krav.

Vårt råd är att se till att få med relevanta specifika underhållbarhetskrav i kravspecifikationen och att låta dem bestå av både vad som ska ändras och på vilket sätt systemet får påverkas.