Sådan skal kravene formuleres

Niveau: Kravene skal være på det rigtige niveau, dvs. ikke så detaljerede at leverandøren skal lave en masse fra grunden i stedet for at kunne genbruge eksisterende teknologi og ikke så generelle at man ikke kan se om de er opfyldt og ikke kan sammenligne løsningernes styrker.
Forretningsmæssige mål: Man skal kunne se de forretningsmæssige mål (som ikke er krav til leverandøren, men til det samlede projekt), og se hvordan målene tilgodeses gennem krav.
Funktionelle krav: Funktionelle krav skal dækkes dvs. de arbejdsopgaver der skal støttes og det data der skal opbevares og kommunikeres.
Verificerbarhed: Kravene skal kunne verificeres.
Redundans: "Don't repeat yourself". Et krav må kun optræde een gang.
Konkret: Krav skal være konkrete.
Kollission: Funktionelle (kliniske) og non-funktionelle (tekniske) krav må ikke kollidere.
Ansvarsfordeling: Krav skal være krav og ikke dikteringer (tænk i ansvarsfordeling mellem leverandør og kunde).

Disse aspekter skal dækkes af krav

Indhold: Kravene skal dække hele den ønskede løsning.
Kvalitet: Kravene skal sikre løsningens kvalitet, herunder (inspireret af MCCall's kvalitetsfaktorer):

• Korrekthed (Correctness): Systemets opførsel skal være korrekt og deterministisk.
  
• Pålidelighed (Reliability): Systemet skal være driftsstabilt og pålideligt.
  
• Effektivitet (Efficiency): Der bør defineres Service Level Agreements (SLA) for svartidskrav.
  
• Integritet (Integrity): Systemets dataintegritet skal til alle tider være sikker og intakt.
  
• Anvendelighed (Usability): Også kendt som "brugervenlighed", noget der bedst verificeres ved faktiske brugeres konkrete anvendelse.
  
• Vedligeholdbarhed (Maintainability): Daglig drift og operations skal være uproblematisk.
  
• Fleksibilitet (Flexibility): Det skal være let at ændre og konfigurere systemet til nye behov.
  
• Testbarhed (Testability): Systemet skal kunne testes (functional, unit, whitebox, blackbox, load, stress, endurance, ...).