Kravsteknik - Requirements engineering

Kravsteknik ( RE ) er processen med at definere, dokumentere og vedligeholde krav i den tekniske designproces . Det er en almindelig rolle i systemteknik og softwareteknik .

Den første anvendelse af udtrykket kravsteknik var sandsynligvis i 1964 i konferenceavisen "Vedligeholdelse, vedligeholdelsesevne og systemkravsteknik", men det kom først i slutningen af ​​1990'erne med offentliggørelsen af ​​en IEEE Computer Society- vejledning i marts 1997 og etablering af en konferenceserie om kravsteknik, der har udviklet sig til International Requirements Engineering Conference .

I vandfaldsmodellen præsenteres kravsteknik som den første fase af udviklingsprocessen. Senere udviklingsmetoder, herunder Rational Unified Process (RUP) for software, antager, at kravsteknik fortsætter gennem et systems levetid.

Kravsstyring, som er en underfunktion af systemteknikpraksis, er også indekseret i International Council on Systems Engineering (INCOSE) manualer.

Aktiviteter

Aktiviteterne involveret i kravsteknik varierer meget afhængigt af typen af ​​system, der udvikles, og organisationens specifikke praksis (r) involveret. Disse kan omfatte:

  1. Krav oprettelse eller krav fremkaldelse - Udviklere og interessenter mødes; sidstnævnte bliver spurgt om deres behov og ønsker angående softwareproduktet.
  2. Kravsanalyse og forhandling - Krav identificeres (inklusive nye, hvis udviklingen er iterativ), og konflikter med interessenter løses. Både skriftlige og grafiske værktøjer (sidstnævnte bruges ofte i designfasen, men nogle finder dem også nyttige på dette stadium) bruges med succes som hjælpemidler. Eksempler på skriftlige analyseværktøjer: brugssager og brugerhistorier . Eksempler på grafiske værktøjer: UML og LML .
  3. Systemmodellering - Nogle tekniske felter (eller specifikke situationer) kræver, at produktet designes og modelleres fuldstændigt, før dets konstruktion eller fabrikation starter. Derfor skal designfasen udføres på forhånd. For eksempel skal tegninger til en bygning udarbejdes, inden en kontrakt kan godkendes og underskrives. Mange felter udleder muligvis modeller af systemet med Lifecycle Modelling Language , mens andre måske bruger UML . Bemærk: I mange områder, såsom software engineering, klassificeres de fleste modelleringsaktiviteter som designaktiviteter og ikke som kravstekniske aktiviteter.
  4. Kravspecifikation - Krav dokumenteres i en formel artefakt kaldet en Requirements Specification (RS), som først bliver officiel efter validering. En RS kan om nødvendigt indeholde både skriftlige og grafiske (modeller) oplysninger. Eksempel: Specifikation af softwarekrav (SRS).
  5. Validering af krav - Kontroller, at de dokumenterede krav og modeller er konsistente og opfylder interessentens behov. Kun hvis det endelige kladde består godkendelsesprocessen, bliver RS ​​officiel.
  6. Kravsadministration - Håndtering af alle aktiviteter relateret til kravene siden starten, overvågning som systemet er udviklet og endda indtil efter det er taget i brug (f.eks. Ændringer, udvidelser osv.)

Disse præsenteres undertiden som kronologiske stadier, selvom der i praksis er betydelig sammenflettning af disse aktiviteter.

Kravsteknik har vist sig at bidrage tydeligt til succes i softwareprojekter.

Problemer

En begrænset undersøgelse i Tyskland præsenterede mulige problemer i implementeringen af ​​kravsteknik og spurgte respondenterne, om de var enige om, at de var faktiske problemer. Resultaterne blev ikke præsenteret som værende generaliserbare, men antydede, at de vigtigste opfattede problemer var ufuldstændige krav, bevægelige mål og tidsboksning, hvor mindre problemer var kommunikationsfejl, manglende sporbarhed, terminologiske problemer og uklare ansvarsområder.

Kritik

Problemstrukturering, et centralt aspekt af kravsteknik, er blevet spekuleret for at reducere designydelsen. Nogle undersøgelser tyder på, at det er muligt, hvis der er mangler i kravsteknikprocessen, der resulterer i en situation, hvor krav ikke eksisterer, softwarekrav kan oprettes uanset som en illusion, der forkert præsenterer designbeslutninger som krav

Se også

Referencer

eksterne links