Krav -
Requirement

Från Wikipedia, den fria encyklopedin

Vid produktutveckling och processoptimering är ett krav ett enstaka dokumenterat fysiskt eller funktionellt behov som en viss design, produkt eller process syftar till att tillgodose. Det används vanligtvis i formell mening i ingenjörsdesign , inklusive till exempel inom systemteknik , programvaruteknik eller företagsteknik . Det är ett brett koncept som kan tala till vilken som helst nödvändig (eller ibland önskad) funktion, attribut, förmåga, egenskap eller kvalitet hos ett system för att det ska ha värde och nytta för en kund, organisation, intern användare eller annan intressent. Krav kan ha olika nivåer av specificitet; till exempel, ett krav specifikation eller krav "spec" (ofta oprecist kallad "de" spec / specs, men det finns faktiskt olika sorters specifikationer) avser ett explicit, höggradigt objektiv / klar (och ofta kvantitativt) krav (eller ibland, uppsättning krav) för att tillgodose ett material, design, produkt eller tjänst.

En uppsättning krav används som insatsvaror i designfasen för produktutveckling . Krav är också en viktig inmatning i verifieringsprocessen, eftersom test bör spåra tillbaka till specifika krav. Krav visar vilka element och funktioner som är nödvändiga för det specifika projektet. När iterativa metoder för mjukvaruutveckling eller smidiga metoder används, utvecklas systemkraven stegvis parallellt med design och implementering. Med vattenfallsmodellen utvecklas kraven innan design och implementering.

Termens ursprung

Begreppet krav har använts i mjukvaruteknik sedan åtminstone 1960-talet.

Enligt Guide to the Business Analysis Body of Knowledge® version 2 från IIBA ( BABOK ) är ett krav:

  1. Ett villkor eller förmåga som en intressent behöver för att lösa ett problem eller uppnå ett mål.
  2. Ett villkor eller förmåga som måste uppfyllas eller innehas av en lösning eller en lösningskomponent för att uppfylla ett kontrakt, standard, specifikation eller andra formellt införda dokument.
  3. En dokumenterad framställning av ett villkor eller förmåga som i (1) eller (2).

Denna definition är baserad på IEEE 610.12-1990: IEEE Standard Ordlista för Software Engineering Terminology.

Produkt kontra processkrav

Krav kan sägas relatera till två fält:

  • Produktkrav föreskriver egenskaper hos ett system eller en produkt.
  • Processkrav föreskriver aktiviteter som ska utföras av den utvecklande organisationen. Till exempel kan processkrav specificera de metoder som måste följas och begränsningar som organisationen måste följa.

Produkt- och processkrav är nära kopplade; ett produktkrav kan sägas specificera den automatisering som krävs för att stödja ett processkrav medan ett processkrav kan sägas specificera de aktiviteter som krävs för att stödja ett produktkrav. Till exempel kan ett maximalt krav på utvecklingskostnad (ett processkrav) införas för att uppnå ett maximalt försäljningspriskrav (ett produktkrav); ett krav på att produkten ska underhållas (ett produktkrav) hanteras ofta genom att ställa krav för att följa specifika utvecklingsstilar (t.ex. objektorienterad programmering ), stilguider eller en gransknings- / inspektionsprocess (processkrav).

Typer av krav

Krav klassificeras vanligtvis i typer som produceras i olika steg i en utvecklingsprocess, med taxonomin beroende på den övergripande modellen som används. Till exempel utformades följande schema av International Institute of Business Analysis i deras Business Analysis Body of Knowledge (se även FURPS och typer av krav ).

Arkitektoniska krav
Arkitektoniska krav förklara vad som måste göras genom att identifiera den nödvändiga integrationen av system struktur och system beteende , det vill säga systemarkitektur av ett system.
I programvaruteknik kallas de arkitektoniskt betydelsefulla krav , vilket definieras som de krav som har en mätbar inverkan på ett mjukvarusystems arkitektur .
Företagskrav
Uttalanden på hög nivå om organisationens mål, mål eller behov. De beskriver vanligtvis möjligheter som en organisation vill förverkliga eller problem som de vill lösa. Anges ofta i ett affärsfall .
Användarkrav (intressent)
Medellång uttalanden om behoven hos en viss intressent eller grupp av intressenter. De beskriver vanligtvis hur någon vill interagera med den avsedda lösningen. Fungerar ofta som en mittpunkt mellan höga krav på företag och mer detaljerade lösningskrav.
Funktionella (lösning) krav
Vanligtvis detaljerade uttalanden om kapacitet, beteende och information som lösningen behöver. Exempel är formatering av text, beräkning av ett nummer, modulering av en signal. De kallas också ibland förmåga .
Krav på servicekvalitet (icke-funktionell)
Vanligtvis detaljerade uttalanden om förhållandena under vilka lösningen måste förbli effektiv, egenskaper som lösningen måste ha eller begränsningar inom vilka den måste fungera. Exempel inkluderar: tillförlitlighet, testbarhet, underhållsbarhet, tillgänglighet. De är också kända som egenskaper , begränsningar eller färdigheter .
Implementeringskrav (övergång)
Vanligtvis krävs detaljerade uttalanden om kapacitet eller beteende endast för att möjliggöra övergången från företagets nuvarande tillstånd till önskat framtida tillstånd, men det kommer därefter inte längre att krävas. Exempel är rekrytering, rollförändringar, utbildning, migrering av data från ett system till ett annat.
Tillsynskrav
Krav definierade av lagar (federala, statliga, kommunala eller regionala), kontrakt (villkor) eller policyer (företags-, avdelnings- eller projektnivå).

Kännetecken för goda krav

Kännetecknen för goda krav anges olika av olika författare, varvid varje författare i allmänhet betonar de egenskaper som är mest lämpliga för deras allmänna diskussion eller den specifika teknologidomän som behandlas. Följande egenskaper är dock allmänt erkända.

Karakteristisk Förklaring
Enhet (sammanhängande) Kravet tar upp en enda sak.
Komplett Kravet anges helt på ett ställe utan saknad information.
Konsekvent Kravet strider inte mot andra krav och överensstämmer helt med all auktoritativ extern dokumentation.
Icke-konjugerad ( Atomic ) Kravet är atomiskt , dvs det innehåller inte sammankopplingar. Exempel: "Postnummerfältet måste validera amerikanska och kanadensiska postnummer" bör skrivas som två separata krav: (1) "Postnummerfältet måste validera amerikanska postnummer" och (2) "Postnummerfältet måste validera kanadensiskt postnummer koder ".
Spårbar Kravet uppfyller hela eller delar av ett affärsbehov som anges av intressenter och auktoriserat dokumenterat.
Nuvarande Kravet har inte blivit föråldrat av tidens gång.
Entydig Kravet anges kortfattat utan att använda tekniskt jargong , akronymer (såvida det inte definieras någon annanstans i kravdokumentet) eller annat esoteriskt ord. Det uttrycker objektiva fakta, inte subjektiva åsikter. Det är föremål för en och en tolkning. Vaga ämnen, adjektiv, prepositioner, verb och subjektiva fraser undviks. Negativa uttalanden och sammansatta uttalanden undviks.
Ange betydelse Många krav representerar en intressentdefinierad egenskap vars frånvaro kommer att leda till en större eller till och med dödlig brist. Andra representerar funktioner som kan implementeras om tid och budget tillåter. Kravet måste ange en nivå av betydelse.
Verifierbar Genomförandet av kravet kan bestämmas genom grundläggande möjliga metoder: inspektion, demonstration, test (instrumenterad) eller analys (för att inkludera validerad modellering och simulering).

Det finns många fler attribut att tänka på som bidrar till kvaliteten på kraven. Om kraven är föremål för regler för dataintegritet (till exempel) är noggrannhet / korrekthet och giltighet / auktorisering också värdiga attribut. Spårbarhet bekräftar att kravuppsättningen tillgodoser behovet (inte mer - och inte mindre än vad som krävs).

Till ovanstående tillägger vissa externa observerbara, det vill säga kravet anger en egenskap hos produkten som kan observeras externt eller upplevs av användaren. Sådana förespråkare hävdar att krav som specificerar intern arkitektur, design, implementering eller testbeslut troligen är begränsningar och bör tydligt formuleras i avsnittet Begränsningar i kravdokumentet. Den kontrasterande uppfattningen är att detta perspektiv misslyckas på två punkter. För det första erkänner inte perspektivet att användarupplevelsen kan stödjas av krav som inte uppfattas av användaren. Exempelvis kan ett krav att presentera geokodad information för användaren stödjas av ett krav på ett gränssnitt med en extern tredjepartspartner. Gränssnittet är omärkligt för användaren, även om presentationen av information som erhållits via gränssnittet verkligen inte skulle göra det. För det andra begränsar en begränsning designalternativ, medan ett krav specificerar designegenskaper. För att fortsätta exemplet skiljer sig ett krav på att välja ett webbtjänstgränssnitt från en begränsning som begränsar designalternativ till metoder som är kompatibla med en enkel inloggningsarkitektur.

Verifiering

Alla krav ska kunna verifieras. Den vanligaste metoden är genom test. Om detta inte är fallet bör en annan verifieringsmetod användas istället (t.ex. analys, demonstration, inspektion eller granskning av design).

Vissa krav är, genom sin struktur, inte verifierbara. Dessa inkluderar krav som säger att systemet aldrig eller alltid ska uppvisa en viss egenskap. Korrekt testning av dessa krav kräver en oändlig testcykel. Sådana krav måste skrivas om för att vara verifierbara. Som anges ovan måste alla krav vara verifierbara.

Icke-funktionella krav, som inte kan verifieras på mjukvarunivå, måste fortfarande sparas som en dokumentation av kundens avsikt. De kan dock spåras till processkrav som är bestämda för att vara ett praktiskt sätt att möta dem. Till exempel kan ett icke-funktionellt krav på att vara fritt från bakdörrar uppfyllas genom att ersätta det med ett processkrav för att använda parprogrammering . Andra icke-funktionella krav kommer att spåra till andra systemkomponenter och verifieras på den nivån. Till exempel verifieras systemets tillförlitlighet ofta genom analys på systemnivå. Avionics-programvara med sina komplicerade säkerhetskrav måste följa utvecklingsprocessen DO-178B .

Aktiviteter som leder till att systemet eller mjukvarukraven härleds. Kravsteknik kan involvera en genomförbarhetsstudie eller en konceptuell analysfas av projektet och framkallande av krav (insamling, förståelse, granskning och formulering av intressenternas behov ) och kravanalys , analys (kontroll av konsistens och fullständighet), specifikation (dokumentation av krav) och validering (se till att de angivna kraven är korrekta).

Krav är benägna att fråga om tvetydighet, ofullständighet och inkonsekvens. Tekniker som noggrann inspektion har visat sig hjälpa till att hantera dessa frågor. Oklarheter, ofullständighet och inkonsekvenser som kan lösas i kravfasen kostar vanligtvis storleksordningar mindre att korrigera än när samma problem finns i senare skeden av produktutvecklingen. Kravsanalys strävar efter att ta itu med dessa frågor.

Det finns en teknisk avvägning att överväga mellan krav som är för vaga och de som är så detaljerade att de

  1. ta lång tid att producera - ibland så att det är föråldrat när det är klart
  2. begränsa tillgängliga implementeringsalternativ
  3. är kostsamma att producera

Agila tillvägagångssätt utvecklades som ett sätt att övervinna dessa problem, genom att basera kraven på hög nivå och utarbeta detaljerna på en just-in-time eller sista ansvarsfullt ögonblick .

Dokumentationskrav

Krav skrivs vanligtvis som ett kommunikationsmedel mellan olika intressenter. Detta innebär att kraven ska vara lätta att förstå både för vanliga användare och för utvecklare. Ett vanligt sätt att dokumentera ett krav är att ange vad systemet måste göra. Exempel: 'Entreprenören måste leverera produkten senast xyz-dagen.' Andra metoder inkluderar användningsfall och användarberättelser .

Förändringar i krav

Krav förändras vanligtvis med tiden. När de väl har definierats och godkänts bör kraven falla under förändringskontroll . För många projekt ändras kraven innan systemet är klart. Detta beror delvis på komplexiteten i datorprogramvara och det faktum att användarna inte vet vad de vill innan de ser det. Denna egenskap hos krav har lett till studier och metoder för kravhantering .

Problem

Konkurrerande standarder

Det finns flera konkurrerande åsikter om vad kraven är och hur de ska hanteras och användas. Två ledande organ i branschen är IEEE och IIBA. Båda dessa grupper har olika men liknande definitioner av vad ett krav är.

Tvister angående nödvändigheten och effekterna av programvarukrav

Många projekt har lyckats med liten eller ingen överenskommelse om kraven. Vissa bevis tyder dessutom på att specificera krav kan minska kreativitet och designprestanda. Krav hindrar kreativitet och design eftersom designers blir alltför upptagna av tillhandahållen information. Mer allmänt tyder en del forskning på att programvarukrav är en illusion som skapas genom att felaktig framställa designbeslut som krav i situationer där inga verkliga krav är uppenbara.

Under tiden ifrågasätter de flesta smidiga metoder för mjukvaruutveckling behovet av att noggrant beskriva programvarukraven på förhand, vilket de anser vara ett rörligt mål. Istället beskriver extrem programmering till exempel krav informellt med användarberättelser (korta sammanfattningar som passar på ett indexkort som förklarar en aspekt av vad systemet ska göra), och anser att det är utvecklarens skyldighet att direkt be kunden om förtydligande. Agila metoder försöker fånga krav i en serie automatiserade godkännandestester .

Krav kryper

Omfattningskrypning kan uppstå från krav som rör sig över tiden. I kravhantering är ändring av krav tillåtet, men om inte tillräckligt spårade eller föregående steg (affärsmål än användarkrav) stryps inte av ytterligare tillsyn eller hanteras som en kostnad och potentiellt programfel, då är kravförändringar enkla och sannolikt att hända. Det är lätt att kravförändringar sker snabbare än utvecklare kan producera arbete och ansträngningar att gå bakåt som ett resultat.

Flera krav taxonomier

Det finns flera taxonomier för krav beroende på vilket ramverk man arbetar under. (Till exempel de angivna standarderna för IEEE, vice IIBA eller US DoD). Olika språk och processer på olika platser eller tillfälligt tal kan orsaka förvirring och avvikelse från önskad process.

Bearbeta korruptioner

En process som drivs av människor är föremål för mänskliga brister i styrelseformer, där bekvämlighet eller önskningar eller politik kan leda till undantag eller fullständig undergravning av processen och avvikelser från lärobokens sätt att processen ska fortsätta. Exempel inkluderar:

  • Process utan stränghet får ingen respekt - Om undantag eller förändringar är vanliga, till exempel att organisationen som driver den har liten oberoende eller makt eller inte är tillförlitlig och transparent i register, kan det leda till att den totala processen ignoreras.
  • Nya spelare som vill göra en övergång - till exempel, den naturliga tendensen hos nya människor att vilja ändra sin föregångares arbete för att visa sin makt eller påståenden om värde, till exempel en ny VD som vill ändra den tidigare VD: s planering, inklusive affärsmål, av något (till exempel en mjukvarulösning) som redan är under utveckling, eller ett nyskapat kontor motsätter sig den aktuella utvecklingen av ett projekt eftersom de inte fanns när användarkraven skapades, så de börjar försöka backspåra och omstarta projektet.
  • Att färga utanför raderna - t.ex. att användare som vill ha mer kontroll matar inte bara in saker som uppfyller kravhanteringsdefinitionen "användarkrav" eller prioritetsnivå, utan infogar designdetaljer eller favoriserade leverantörskarakteristika som användarkrav eller allt som deras kontor säger som det högsta möjlig prioritet.
  • Visar sig sent - t. Ex. Gör lite eller ingen ansträngning för att framkalla krav före utveckling. Detta kan bero på att de tänker att de kommer att få samma fördel oavsett individuellt deltagande, eller att det inte är någon mening om de bara kan införa krav i testfasen och nästa snurr, eller att man alltid vill ha rätt genom att vänta på efterarbete kritik.

Inom US Department of Defense-processen finns några historiska exempel på kravfrågor

  • M-2 Bradley-frågeställningarna om tillfälliga kravrörelser som beskrivs i Pentagon Wars ;
  • F-16-tillväxten från Fighter-maffian från lättviktsfighterkoncept , tillskrivet F-15-programmet som försökte sabotera konkurrens eller enskilda kontor som inlett lokala önskemål som försvagar konceptet att vara lätt och låg kostnad.
  • entusiasm ca. 1998 för "Net-Ready" ledde till sitt mandat som Key Performance Parameter från Net-Ready-kontoret, utanför kontoret som definierade kravprocessen och inte överensstämmer med det kontors tidigare definierade processen, deras definition av vad en KPP var, eller att vissa ansträngningar kanske inte är lämpligt eller kan definiera vad som utgjorde 'Net-Ready'.

Se även

Referenser