— 3 min read

Krav som man ofta missar

Read 143 times

Det är omöjligt att identifiera samtliga krav för ett system men däremot finns det vissa krav som behövs i många typer av system och som är lätta att missa. När krav upptäcks för sent leder det till höga kostnader. Listan nedan1 innehåller ett antal sådana krav och förhoppningen är att du kan få mer kompletta krav genom att studera listan och komplettera med dina egna erfarenheter. Listan gör inte anspråk på att vara komplett, den är tänkt att vara en grund för att ge dig ytterligare idéer.

Denna artikel publicerades ursprungligen av Konsultbolag1. Sedan 2020 har verksamheten gått ihop med inUse (part of AFRY). Vi har sedan dess kunnat erbjuda ett spännande urval av kurser inom de samspelande områdena kravhantering, test, design och effektkartläggning under inUse Academy.

Begrepp och processer

  • Begrepp (ordbok)
  • Generisk namnsättning
  • Koppling till verksamhetsprocesser
  • Kundens interna rutiner

Ickefunktionella krav

  • Volym
  • Svarstider
  • Prestanda
  • Kapacitetskrav
  • Förvaltningsbarhetskrav
  • Användbarhetskrav

Diverse osorterade

  • Dolda konsekvenser – följdfel för annan part
  • Förväntade krav, t ex utskrifter
  • Underhåll/förvaltning, t ex vilken dokumentation ska finnas, vem ska skriva den och hur ska den se ut
  • Användarupplevelse, t ex personas med olika förutsättningar
  • Varumärke – bevara och förstärka
  • Förväntade krav – outtalad befintlig funktionalitet
  • Felmeddelanden
  • Hjälptexter – hur de ska underhållas
  • Rapporter
  • Generalistens behov
  • Dokumentationskrav

Driftkrav

  • Övervakning
  • Installation

Lagkrav

  • Konsumentkreditlagen
  • Personuppgiftslagen

Funktionalitet för att stänga av systemet

Systemet behöver stängas av för både akuta och planerade avbrott. Hur ska det göras? Det bör helst finnas ett enkelt val för systemadministratören för att minimera felkällor förknippade med manuella rutiner. Vilken information ska visas för användarna när systemet är nere?

Behörigheter

Vem ska se vad? Vad händer när en användare försöker använda funktioner som denne inte har behörighet till? Ska funktioner som man inte är behörig till vara synliga eller ska de döljas helt och hållet? Vem ska administrera behörigheter och hur ska det göras?

Felmeddelanden

Specificera var meddelanden visas, exempelvis i en meddelanderuta eller i programmets statusrad. Felmeddelanden specificeras sällan i kraven, men om uppgiften att formulera felmeddelanden överlåts till utvecklarna blir resultatet inte alltid helt lyckat eftersom utvecklare ofta är bättre på att skriva programkod än på att skriva pedagogiska felmeddelanden på svenska. Ställ gärna krav på att det ska gå att exportera alla meddelanden som kan visas i systemet till exempelvis en Excel-fil. Om detta krav inte ställs, är det normalt mycket svårt att få ut texter ur systemet.

Larm när fel inträffar

När fel inträffar i systemet kan felet ska loggas och ett e-postmeddelande skickas till driftpersonal, systemansvarig eller motsvarande. En fördel med att systemet skickar larm är att felen blir mer synliga vilket gör att den ansvarige vidtar åtgärder.

Loggning vid fel

Det är mycket enklare att göra felsökning om systemet loggar varje fel till någon form av logg. Speciellt gäller detta i produktionsmiljön där det inte går att använda utvecklingsverktygen för felsökning. Loggningen kan ske till en textfil eller till det som i Windows heter händelseloggen (Event Log på engelska). Motsvarigheter till händelseloggen finns även i andra operativsystem. När ett fel inträffar kan man logga information om vilket program som kraschat på vilken rad, programmeringsspråkets felkod (exception) och även vilket indata funktionen som kraschade hade. Det är även praktiskt att kunna aktivera loggning av mer än bara fel, gärna alla anrop till alla funktioner eftersom fel kan bero på att anropen sker i en felaktig ordning.

Hantering vid överbelastning

Vad händer om systemet överbelastas? Ska transaktioner ångras? Ska felmeddelande visas? Ska systemet stängas av automatiskt?

Påverkar ändringen datavolymer?

Kommer systemet att få fler användare som gör andra saker på andra tider än tidigare? Detta kan leda till nya prestandaproblem.

Lista alla ställen i systemet som ändringen berör

Ta fram en spårbarhetsmatris som visar vilka testfall eller testområden som påverkas som visar vilka testfall som påverkas.

Påverkar ändringen teknik?

Vid behov av att beställa ny hårdvara, exempelvis en server, kom ihåg att göra det.

Finns det något som systemet inte får eller inte bör göra?

I ett banksystem får inte pengar dras från ett konto utan att nå mottagaren.

Finns det något undantag från normal hantering?

Om användaren söker i kundregistret på alla kunder som heter Andersson och det finns en miljon kunder i databasen kanske systemet bara ska visa de första hundra träffarna. Ta för vana att ställa frågan ”gäller detta alltid?”. Många regler har undantag som är lätta att glömma.

Vilka ändringar är troliga efter driftsättning?

I webbaserade system är det troligt att man efter driftsättningen hittar en massa småfel i texterna som man vill rätta till. Då är det bra om arkitekturen stödjer detta så att man inte måste kompilera om hela systemet för att ändra texter. Att kompilera om ett system kan ställa krav på omfattande regressionstester och därför vill man inte behöva kompilera om systemet för så små ändringar.

Krav på dokumentation

Många system förväntas finnas kvar i produktion under flera år. Dokumentation krävs för att det ska vara möjligt att förvalta systemet på ett kostnadseffektivt sätt. Ställ tidigt frågan ”vilken sorts dokumentation förväntar ni er?”.

Läs allt om kurserna på inUse Academy här!