Beskrivning

Skrivkraven har utgjort en betydande utmaning i många decennier nu, och en av huvudorsakerna till detta är språket som används för att uttrycka dem. Det är viktigt att skriva krav på ett sätt som är både heltäckande och lätt att förstå, särskilt när läsarna är företagare, slutanvändare eller intressenter. Det betyder att man använder ett "naturligt" språk som är fritt från teknisk jargong och komplex terminologi. Men naturligt språk är till sin natur oprecist och kan lätt misstolkas eller missförstås, vilket leder till ytterligare komplikationer.

Tyvärr motstår många analytiker någon form av struktur i sina kravskrivande och föredrar istället att förlita sig på beskrivande stycken och meningar som kan innebära ytterligare krav. Även om detta tillvägagångssätt kan vara mer tilltalande för sina läsare, leder det ofta till förvirring och missförstånd när kraven överlämnas till utvecklare eller systemanalytiker. Det kan i sin tur resultera i långa diskussioner och förseningar samtidigt som man försöker klargöra vad kraven egentligen innebär.

Under intervjun med Visure Solutions, Jordan Kyriakidis, den uppskattade medgrundaren och VD:n för QRA Corp, delade med sig av sina insikter om olika aspekter av kravteknik. Under den här intervjun diskuterade vi några ganska intressanta ämnen, inklusive

• Väsentliga delar av stora krav
• Easy Atillvägagångssätt för RKRAV Syntax tillvägagångssätt
• AI vinner dragkraft i digitalisering av kravteknik
• Tips och tricks för att skriva bra krav
• Och mycket mer!

Vem är Jordan Kyriakidis?

Jordan Kyriakidis är en känd ledare inom området för design och verifiering av säkerhetskritiska system. Han är medgrundare och VD för QRA Corp, ett företag som tillhandahåller banbrytande lösningar för företag och regeringar för att identifiera och minska risker i komplexa projekt som involverar ny teknik i reglerade industrier. Med nästan två decennier av erfarenhet av att leda högpresterande team är Jordan en skicklig vetenskapsman med många internationella publikationer på sin kredit.

Jordan har en Ph.D. i kvantteori från University of Basel, Schweiz, och har bott och arbetat i olika länder över hela världen, inklusive Europa, USA och Kanada. Hans expertis inom kravteknik, tillsammans med hans passion för att avancera området, har gjort honom till en eftertraktad talare och tankeledare i branschen. Jordan är känd för sitt visionära tillvägagångssätt för att utnyttja AI och bästa praxis för skrivkrav i kritiska branscher, och han har varit avgörande för att digitalisera kravteknik.

Vad är kravspecifikation?

Kravspecifikation är processen att tydligt definiera och dokumentera de funktionella och icke-funktionella kraven för ett system, program eller produkt. Syftet med kravspecifikation är att fånga behov och förväntningar hos intressenter, inklusive kunder, slutanvändare och andra intressenter, på ett tydligt och kortfattat sätt. Denna dokumentation används som en ritning för design, utveckling, testning och implementering av systemet eller produkten. 

Kravspecifikationen innehåller vanligtvis en beskrivning av systemets eller produktens avsedda funktionalitet, prestanda, användbarhet, tillförlitlighet, säkerhet och andra viktiga egenskaper. Det kan också inkludera alla begränsningar, antaganden eller beroenden som kan påverka designen eller implementeringen av systemet eller produkten. Kravspecifikationen är en väsentlig komponent i mjukvaruutvecklingens livscykel och fungerar som en grund för effektiv kommunikation och samarbete mellan projektintressenter.

Vikten av att skriva stora krav

Att skriva stora krav är avgörande för framgången för alla programvaruutvecklingsprojekt. Här är några anledningar till varför:

1. Tydlig kommunikation: Välskrivna krav bidrar till att säkerställa att alla projektintressenter har en tydlig och gemensam förståelse för vad som förväntas av systemet eller produkten som utvecklas. Denna tydlighet säkerställer att alla är på samma sida, vilket minskar risken för missförstånd och missförstånd som kan leda till fel, omarbetningar och projektförseningar.
2. Fokus på användarnas behov: Stora krav fokuserar på slutanvändares och kunders behov, vilket säkerställer att systemet eller produkten som utvecklas uppfyller deras förväntningar och krav. Detta tillvägagångssätt ökar kundnöjdheten och minskar risken för projektmisslyckanden på grund av bristande överensstämmelse mellan produktens och användarnas behov.
3. Riskhantering: Krav kan identifiera potentiella risker och problem tidigt i utvecklingsprocessen, vilket gör det möjligt att införa proaktiva begränsningsstrategier. Genom att identifiera potentiella problem tidigt, kan team undvika kostsamma omarbetningar, förseningar och misslyckanden längre fram.
4. Effektivitet: Stora krav hjälper till att effektivisera utvecklingsprocessen genom att tillhandahålla en tydlig färdplan för utvecklare att följa. Denna färdplan säkerställer att utvecklare arbetar med de viktigaste funktionerna och kraven, och undviker slöseri med mindre viktiga uppgifter.
5. Kvalitetssäkring: Genom att ha väl definierade krav är det lättare att säkerställa att systemet eller produkten som utvecklas uppfyller de kvalitetskrav som krävs. Stora krav gör det lättare att testa, validera och verifiera systemet eller produkten som utvecklas, vilket säkerställer att den levereras i tid, inom budget och till förväntad kvalitetsnivå.

Egenskaper för stora krav

Stora krav är avgörande för att leverera framgångsrika programvaruutvecklingsprojekt som uppfyller kundernas förväntningar, levereras i tid och ligger inom budget. Här är några egenskaper hos stora krav:

1. Klart och koncist: Stora krav är lätta att förstå, med ett tydligt och kortfattat språk som undviker oklarheter eller förvirring.
2. Komplett: Stora krav bör fånga alla nödvändiga funktionella och icke-funktionella aspekter av systemet eller produkten som utvecklas, och lämnar inget utrymme för tolkningar eller missförstånd.
3. Exakt: Stora krav måste vara korrekta och verifierbara, utan avvikelser mellan vad som skrivs och vad systemet eller produkten förväntas göra.
4. Testbar: Stora krav ska vara testbara, det vill säga att det ska vara möjligt att skapa tester som kan verifiera att systemet eller produkten uppfyller kraven.
5. Prioriterat: Stora krav bör prioriteras för att säkerställa att de viktigaste egenskaperna och funktionaliteten utvecklas först.
6. Möjlig: Stora krav bör vara genomförbara, vilket innebär att de är tekniskt och praktiskt möjliga inom givna tids- och budgetbegränsningar.
7. Spårbar: Stora krav bör kunna spåras, vilket innebär att det finns en tydlig koppling mellan varje krav och dess källa, inklusive den intressent som begärde det.
8. Konsekvent: Stora krav bör vara förenliga med annan projektdokumentation, inklusive projektplanen, omfattningsbeskrivning och annan relevant dokumentation.
9. Entydig: Stora krav bör vara fria från oklarheter eller förvirring, vilket säkerställer att det finns en tydlig förståelse för vad som förväntas av systemet eller produkten som utvecklas.

Utmaningar när du skriver krav

Det finns olika utmaningar människor möter när de skriver krav.

Dåligt pappersarbete - I vissa organisationer är dokumentation av processer antingen obefintlig eller inte i nivå. I det här fallet blir kravinsamlingen en process i två steg: först omvända den befintliga processen och sedan identifiera områden som behöver förbättras och optimeras. För att bekräfta att kraven är konkretiserade och korrekta är det viktigt att identifiera nyckelintressenter och ämnesexperter och kontakta dem direkt. Att rita affärsprocesskartor och visualisera arbetsflöden är två utmärkta sätt att göra det. Detta hjälper till att eliminera felaktiga antaganden samtidigt som det ger en komplett bild. Att rita processkartor och visa processer är två användbara tillvägagångssätt för detta ändamål.

Motstridiga krav – När intressenter har olika prioriteringar för sina affärsmål leder det till krav som står i konflikt med varandra. I fall som dessa är det en affärsanalytikers ansvar att dokumentera alla krav i detalj, identifiera vilka förfrågningar som står emot varandra och ge intressenter möjlighet att bestämma vad som prioriteras.

Du kan inte fatta beslut utan att höra intressenternas synpunkter och som affärsanalytiker kanske du har några idéer om vad som bör prioriteras. Det är fortfarande viktigt att höra intressenternas perspektiv. Att skapa en omröstning kan vara en av metoderna för att få klarhet i vad som är viktigast för majoriteten av intressenterna.

Otillgänglighet för användarinmatning – Några orsaker kan bidra till att slutanvändarna inte är tillgängliga, och var och en kräver sin egen lösning. Till exempel är slutanvändare ibland så upptagna av sitt dagliga arbete att de inte är villiga att delta i kravinsamlingsaktiviteter.

I sådana fall är det bästa en affärsanalytiker kan göra att begränsa antalet och längden på engagemang. Inför mötet kommer att göra så mycket research som möjligt för att göra diskussionen mer organiserad och informativ. Det är nästan som att förvandla kravinsamling till kravvalideringssessioner. definiera fokusgrupper och identifiera de mest lämpliga slutanvändarna för varje grupp

Fokusera på gränssnitt istället för erfarenhet – Många intressenter och slutanvändare har en tydlig vision om hur den nya lösningen ska se ut, men de vet inte vad den ska åstadkomma. Alla systems användargränssnitt är avgörande, men det bör inte definiera eller störa funktionaliteten.

Affärsanalytiker bör alltid komma ihåg att hålla design- och funktionskrav åtskilda i sin dokumentation. Genom att använda mer allmänna verktyg som diagram, användarberättelser eller low-fi-prototyper snarare än designutkast, kan de behålla fokus på de funktionella aspekterna av kravinsamling.

Intressenternas input – När intressenter eller slutanvändare försöker tala om för designers hur systemet ska fungera istället för vad systemet ska göra, kan det leda till suboptimala konstruktioner. För att avvärja detta, validera varje potentiellt "falskt krav" genom att fråga "varför?" tills du kommer fram till det verkliga problemet som behöver lösas.

Kommunikationsproblem – Bland de frågor som kan leda till felkommunikation mellan en affärsanalytiker och andra parter är språkbarriärer, felaktiga antaganden, otillräckligt förklarat ordförråd och överanvändning av facktermer.

Den idealiska metoden för att undvika detta problem är att interagera ofta och utveckla tvåvägskonversationer. Dokumentera behoven som du har upptäckt och skicka in dem för expertgranskning och kritik till en mängd ämnesspecialister, skapa en ordlista med jargong och dubbelkolla lokaler.

Vanliga misstag när du skriver krav

Skrivkrav kan vara en utmanande uppgift, och det finns vanliga misstag som kan göras som kan påverka framgången för mjukvaruutvecklingsprojektet. Här är några vanliga misstag när du skriver krav:

1. Tvetydighet: Ett av de vanligaste misstagen vid skrivkrav är användningen av tvetydigt språk, vilket kan leda till missförstånd och fel. Detta kan undvikas genom att använda ett tydligt, kortfattat och entydigt språk.
2. Ofullständiga eller inkonsekventa krav: Krav som är ofullständiga eller inkonsekventa kan leda till förvirring och fel i mjukvaruutvecklingsprocessen. Detta kan undvikas genom att granska och validera kraven för att säkerställa att de är fullständiga och överensstämmer med annan projektdokumentation.
3. Brist på prioritering: Utan ordentlig prioritering kan krav utvecklas på ett slumpartat sätt, vilket leder till förseningar och en produkt som inte uppfyller kundernas förväntningar. Att prioritera krav kan säkerställa att de viktigaste egenskaperna och funktionaliteten utvecklas först.
4. Otydliga eller ej verifierbara krav: Otydliga eller okontrollerbara krav kan leda till missförstånd och svårigheter att validera att systemet eller produkten uppfyller kraven. Detta kan undvikas genom att se till att kraven är tydliga och verifierbara.
5. Guld plätering: Guldplätering sker när ytterligare funktioner eller funktionalitet läggs till systemet eller produkten som inte specificerades i kraven. Detta kan leda till förseningar, extra kostnader och en produkt som inte uppfyller kundernas behov.
6. Brist på engagemang av intressenter: Brist på intressentengagemang kan leda till krav som inte möter kundernas och andra intressenters behov. Att engagera intressenter under hela mjukvaruutvecklingsprocessen kan säkerställa att kraven är anpassade till deras behov och förväntningar.
7. Överberoende på teknik: Överberoende på teknik kan leda till krav som inte överensstämmer med kapaciteten hos systemet eller produkten som utvecklas. Detta kan undvikas genom att säkerställa att kraven är genomförbara och anpassade till den teknik som används.
8. Brist på testöverväganden: Testning är en viktig del av mjukvaruutveckling och bristande hänsyn till testning i kraven kan leda till en produkt som är svår att testa eller som inte uppfyller kvalitetskraven.

Skrivkrav med naturliga språkmetoder

Skrivkrav med naturliga språkmetoder innebär att använda vardagsspråket för att kommunicera kraven på ett sätt som är tydligt, kortfattat och lätt att förstå. Detta tillvägagångssätt används ofta inom mjukvaruutveckling och andra branscher där det finns ett behov av att fånga upp och dokumentera krav som är lätta att förstå för alla intressenter, oavsett deras tekniska expertis.

Naturligt språk är det språk som vi använder i vår dagliga kommunikation, som engelska, franska, spanska och så vidare. Skrivkrav med naturligt språk innebär att använda samma språk som intressenter använder i sin dagliga kommunikation, snarare än att använda teknisk jargong eller specialiserat språk som kan vara obekanta för icke-tekniska intressenter.

Jämfört med andra språk för skrivkrav har naturligt språk fördelen att det är lättare att förstå för icke-tekniska intressenter. Att använda naturligt språk kan bidra till att säkerställa att krav kommuniceras effektivt till alla intressenter, vilket leder till ett mer framgångsrikt projektresultat. Däremot är andra språk för skrivkrav, såsom formella specifikationsspråk, kanske mer exakta och entydiga, men de kan vara svårare för icke-tekniska intressenter att förstå.

För att skriva krav med naturliga språkmetoder är det viktigt att använda ett enkelt, vardagligt språk som är lätt att förstå. Kraven bör vara specifika, mätbara och verifierbara och bör undvika att använda vaga termer eller teknisk jargong. Att använda mallar, exempel och bilder kan också bidra till att göra kraven tydligare och mer koncisa.

EARS mall

EARS-mallen (Easy Approach to Requirements Syntax) är en kravinsamlings- och dokumentationsmall som ger ett strukturerat sätt att fånga och dokumentera krav. Det används ofta i industrier som flyg-, försvars- och mjukvaruutveckling, där det finns ett behov av att fånga och dokumentera komplexa och ofta tekniska krav. EARS-mallen kan användas för både funktionella och icke-funktionella krav.

EARS-mallen består av fyra huvudsektioner:

1. Miljö: Det här avsnittet beskriver det sammanhang i vilket systemet kommer att fungera, inklusive eventuella begränsningar eller beroenden som måste beaktas.
2. Skådespelare: Det här avsnittet beskriver de olika typer av användare eller system som kommer att interagera med systemet, inklusive deras roller och ansvar.
3. Krav: Detta avsnitt beskriver de specifika kraven för systemet, inklusive både funktionella och icke-funktionella krav. Varje krav definieras på ett tydligt och kortfattat sätt med hjälp av en standardiserad syntax.
4. Stimulans: Det här avsnittet beskriver de ingångar som kommer att trigga systemet att utföra vissa åtgärder eller svar, och de förväntade utsignalerna eller svaren.

För att använda EARS-mallen bör kravanalytikern eller teamet först identifiera miljön där systemet kommer att fungera, inklusive eventuella begränsningar eller beroenden. Därefter bör de identifiera de olika aktörerna eller användarna som kommer att interagera med systemet och deras roller och ansvar. Sedan bör de identifiera de specifika kraven för systemet, med hjälp av den standardiserade syntaxen som definieras i mallen. Slutligen bör de identifiera de stimuli som kommer att trigga systemet att utföra vissa åtgärder eller svar, och de förväntade utsignalerna eller svaren.

EARS-mallen är utformad för att ge ett tydligt och kortfattat sätt att dokumentera krav, vilket gör det lättare att förstå och verifiera kraven. Det används ofta i branscher där det finns behov av exakta och korrekta krav, såsom flyg-, försvars- och mjukvaruutveckling. Genom att använda EARS-mallen kan kravanalytiker säkerställa att alla relevanta krav fångas upp och dokumenteras på ett konsekvent och strukturerat sätt.

INCOSE riktlinjer – mall

INCOSE, eller International Council on Systems Engineering, är en internationell icke-vinstdrivande medlemsorganisation som tillhandahåller standarder och riktlinjer för att hjälpa organisationer att skapa bättre systemtekniska processer. INCOSE System Requirements Standard (SRS) innehåller en uppsättning regler och standarder som är utformade för att hjälpa organisationer att utvärdera kravförklaringar innan de implementeras. SRS har antagits av ett antal stora företag såväl som statliga myndigheter runt om i världen och kan användas i många olika branscher för olika tillämpningar. Det är viktigt för intressenter som mjukvaruutvecklare, affärsanalytiker, projektledare, testare, personal på IT-avdelningen och andra teammedlemmar att ha en god förståelse för dessa krav innan man börjar arbeta med något systemkravsuttalande eller projekt.

Att skriva bra krav innebär i slutändan en noggrann avvägning mellan att vara detaljerad och kortfattad, samt att se till att kravet är testbart och genomförbart. INCOSE SRS erbjuder principer och riktlinjer så att team kan skriva kvalitetskrav och hjälpa till att säkerställa att deras projekt blir framgångsrika. Detta kommer att hjälpa till att undvika kostsamma fel under utveckling eller efter driftsättning, och hjälper därmed organisationer att skapa bättre system på kortare tid.

Vad är INCOSE-reglerna?

Kravutlåtanden utvärderas genom reglerna för INCOSE. Dessa standarder hjälper organisationer att bedöma genomförbarheten och kvaliteten på krav innan de implementeras. Utvärderingsprocessen inkluderar fyra huvudkriterier:

• Klar - De skriftliga kraven ska vara tydliga, lättlästa och begripliga. Ange tydligt informationen med hjälp av bekräftande meningar som ska utbytas mellan aktörerna. Varje krav måste beskriva tydliga framgångskriterier. Försök att använda enkla ordförråd och undvik förkortningar. Till exempel, "Användaren ska kunna se revisionsloggrapporten".
• Atomic - Varje krav bör behandlas som ett diskret testfall. Konjunktioner som och, eller, och så vidare bör inte användas eftersom de kan leda till att kraven går miste. Detta är särskilt viktigt eftersom termer som dessa kan få mjukvaruutvecklare och testare att förbise kraven. Att dela upp komplicerade behov i mindre delar tills var och en kan testas separat är ett sätt att förhindra att detta händer.
• Entydigt – Otydliga, ofullständiga eller motsägelsefulla krav kan leda till fel och omarbetningar. För att förhindra att detta händer bör kraven ses över av varje intressent innan de slutförs. Detta kommer att hjälpa till att tidigt identifiera eventuella luckor som sedan kan åtgärdas.
• Verifierbar – Alla i utvecklingsteamet bör ha tillgång till dokumentet så att de kan referera det så ofta som krävs. Eftersom kraven måste vara tydliga vill teammedlemmarna inte ha mer information. De ska alla vara tillgängliga i SRS-dokumentet.
• Nödvändigt – Varje krav ska dokumentera något som användarna verkligen behöver eller något som krävs för att uppfylla ett standard- eller integrationsbehov på grund av att det finns ett externt gränssnitt. Det är också viktigt för varje krav att ha en auktoriserad källa.
• Designoberoende – Varje krav måste definiera vad som är nödvändigt, inte hur det ska implementeras. Kraven måste definiera egenskaperna hos systemet som ska observeras externt, inte de interna detaljerna.
• genomförbart – Varje krav måste vara tekniskt genomförbart och bör implementeras med hänsyn till budget, deadline och andra restriktioner som påverkar projektet. Kraven bör återspegla det faktiska tillståndet, inklusive kostnad, tidslinje och teknik. De bör inte vara beroende av framtida tekniska framsteg.
• Komplett – Kravdokumentet bör innehålla tillräckligt med information för att ditt utvecklingsteam och testare ska kunna slutföra produkten och säkerställa att den uppfyller användarens krav utan buggar.
• Korrekt - Kraven som anges i dokumenten bör vara mycket exakta för att undvika någon form av förvirring. De får inte ha några kryphål, tvetydigheter, subjektivitet, superlativ eller jämförelser. För att kunna skriva korrekta krav måste vi därför skaffa korrekt information och korrekt dokumentera den information som samlas in.

Framtida trender: Skrivkrav med AI

Tekniken med artificiell intelligens (AI) har potential att revolutionera hur krav skrivs och hanteras i produktutvecklingen. Under de senaste åren har det skett betydande framsteg inom naturlig språkbehandling (NLP) och maskininlärning (ML) som har gjort det möjligt att automatisera vissa aspekter av kravteknik.

En potentiell framtidstrend är användningen av AI-drivna chatbots, som ChatGPT och Jasper, för att hjälpa till med att skriva krav. Dessa chatbots använder NLP-algoritmer för att analysera input från intressenter och generera högkvalitativa krav baserat på denna input. Genom att utnyttja dessa verktyg kan organisationer effektivisera kravkonstruktionsprocessen, minska den tid och ansträngning som krävs för att utveckla krav, vilket leder till snabbare produktutvecklingscykler och effektivare användning av resurser.

En annan potentiell trend är användningen av AI för att automatiskt identifiera och extrahera krav från olika källor till ostrukturerad data, såsom kundfeedback, inlägg på sociala medier och produktrecensioner. Genom att använda NLP-algoritmer för att automatiskt identifiera och extrahera relevanta krav från dessa källor kan organisationer få en djupare förståelse för kundernas behov och preferenser, vilket leder till mer framgångsrika produktutvecklingsresultat.

AI-teknik kan också bidra till att förbättra kvaliteten och konsekvensen i kraven genom att identifiera potentiella konflikter, oklarheter eller redundanser i kraven. Detta kan bidra till att minska risken för fel och missförstånd, vilket leder till bättre produktkvalitet och färre kostsamma omarbetningscykler.

Viktiga tips för skrivkrav

1. Skriv i lager – Att skriva krav i lager innebär att bryta ner komplexa krav i mindre, mer hanterbara bitar. Detta hjälper till att göra kraven mer förståeliga, heltäckande och lättare att implementera.
2. En i taget - Varje krav bör behandlas som ett diskret testfall. Konjunktioner som och, eller, och så vidare bör inte användas eftersom de kan leda till att kraven går miste. Detta är särskilt viktigt eftersom termer som dessa kan få mjukvaruutvecklare och testare att förbise kraven. Att dela upp komplicerade behov i mindre delar tills var och en kan testas separat är ett sätt att förhindra att detta händer.
3. Prata "vad" inte "hur" - Fokus bör ligga på vad systemet kommer att göra, inte hur det gör det. Undvik dessutom att gräva för djupt i designämnen som fältnamn, programmeringsspråksobjekt och programvaruobjekt. Om du kommer på att du diskuterar dessa ämnen i kravspecifikationsdokumentet, ta ett steg tillbaka – det betyder förmodligen att du blir för specifik.
4. Verifierbar – En annan sak att tänka på när man organiserar krav är att de alltid ska vara testbara. Det innebär att det måste vara möjligt att verifiera att systemet uppfyller det aktuella kravet. Detta länkar också till vår nästa punkt – spårbarhet. Om ett krav är fullt av vaga termer blir det svårare att analysera och verifiera om systemet faktiskt uppfyller dessa standarder prestationsmässigt. Sträva därför så mycket som möjligt efter tydlighet och precision i ditt språk så att kravinsamlingen inte är en tvetydig process.
5. Spårbarhet – Spårbarhet i projektledning avser att säkerställa att krav är kopplade till andra komponenter i projektet. Detta gör att projektledare, utvecklare och intressenter kan hålla reda på ett kravs hela livscykel från början till slut i alla riktningar såväl som med andra delar av systemet. Om du hanterar spårbarhet på rätt sätt kan du undvika kod som inte motsvarar något krav ('stray'-kod), och se till att varje testfall täcker minst ett krav. Du kan göra krav spårbara genom att märka dem med en unik identifierare och tillhandahålla information om deras källa i ett centralt arkiv tillgängligt för alla teammedlemmar.
6. De 3 Ws – Krav bör fokusera på att möta användarens behov och inte på lösningen. Därför är det viktigt att förstå användarens krav och smärtpunkter innan kraven utvecklas.
   1. Vad? - Vad gör vi?
   2. WHO? – Vem kommer att gynnas?
   3. Varför? – Varför gör vi det?
7. 1 krav för 1 uppgift – Varje krav bör ange en enda åtgärd och mål. Se upp för överdriven användning av "och" och "eller". Till exempel, "Om den sista fredagen i månaden och betalningen förfaller den 31:a, och om den 31:a är den sista fredagen i månaden, kommer att skicka in betalningen den dagen efter 6:XNUMX Eastern Time att resultera i en sen betalning ”. Jag utmanar dig att förstå det!
8. Prioritera krav – Prioritera krav utifrån deras betydelse och inverkan på projektets framgång. Detta bidrar till att säkerställa att de viktigaste kraven levereras först och att intressenternas behov tillgodoses.
9. Ingen flyktklausul – Till exempel, "Systemet ska fastställa antalet inloggningsförsök, utom när användaren tydligt har skrivit in ett felaktigt användarnamn".

Enligt Jordan, vad skiljer framgångsrika projekt från misslyckade?

Enligt Jordan Kyriakidis är det som skiljer framgångsrika projekt från misslyckade förmågan att effektivt hantera krav. Framgångsrika projekt har en klar förståelse för kraven och kan hantera dem genom hela utvecklingsprocessen, från initial planering till slutleverans. Å andra sidan lider misslyckade projekt ofta av dålig kravhantering, vilket kan leda till felkommunikation, förseningar och i slutändan misslyckande med att uppfylla projektmålen. Därför är det avgörande för företag att investera i robusta kravtekniska metoder och verktyg för att säkerställa framgången för sina projekt.

Var kan man hitta mer om Jordan Kyriakidis?

För att lära dig mer om Jordan Kyriakidis och QRA Corp, kolla in deras LinkedIn-sida på https://www.linkedin.com/company/qra-corp/. Dessutom kan du hitta Jordan Kyriakidis på LinkedIn på https://www.linkedin.com/in/jordankyriakidis/. QRA Corp har också flera whitepapers och fallstudier tillgängliga på deras webbplats som ger insikter om dess teknologi och dess tillämpning i olika branscher.

Avslutande tankar

Sammanfattningsvis har Jordan Kyriakidis och Visure Solutions delat en insiktsfull konversation om skrivkrav. Vi har utforskat vikten av att skriva stora krav och berört utmaningarna med att skriva krav tillsammans med vanliga misstag. Vi tittade på olika metoder som naturliga språkmetoder, EARS-mallen och INCOSE-riktlinjer. AI-teknik har också öppnat många möjligheter för skrivkrav vilket gör det lättare för människor som börjar lära sig att skriva dem bättre. Slutligen har vi också inkluderat viktiga tips som hjälper dig på vägen när du ger dig ut på den här resan. Från att lära sig om INCOSE-regler till framtida trender i skrivkrav – här finns något för alla! Ta bort dessa viktiga tips och använd dem i praktiken nu! Kolla in hela intervjun nu!