mjukvaruutveckling kan vara en spännande process av kreativ problemlösning, design och teknik. Men under de glänsande apparna och polerade webbsidorna ligger den mindre sexiga men oh-så viktiga byggnadsställningen som möjliggör bra programresultat: dokumentation.

dokumentation säkerställer att team och enskilda intressenter är på samma sida om en produkt eller programvaras mål, omfattning, begränsningar och funktionella krav.

tyvärr kan processen att skapa och dokumentera dessa krav vara tråkig, förvirrande och rörig.

programkrav dokument kan snabbt bli långa, otympliga, text tunga dokument, vilket gör dem särskilt sårbara för fel, inkonsekvenser och misstolkningar. På grund av detta kan skrivning och användning av dessa dokument vara tidskrävande och leda till kostsamma (och undvikbara) designfel.

Så vad ska produktchefer, mjukvaruteam och företagsledare göra?

även om det inte finns någon One-size-fits-all-regel för mjukvaruutvecklingsmetoder, finns det sätt att minska fel, spara tid och driva effektiva resultat.

nedan går vi igenom målen och fördelarna med dokument för programvarukrav och några bästa metoder som hjälper dig att spika processen från början till slut.

vad är programkrav dokument?

ett dokument för programvarukrav (även kallat specifikationer för programvarukrav) är ett dokument eller en uppsättning dokumentation som beskriver funktionerna och det avsedda beteendet hos ett program.

med andra ord beskriver software requirements document (SRD) företagets eller organisationens förståelse av slutanvändarens (vanligtvis klientens) behov och beroenden samt eventuella begränsningar på systemet.

vad ingår i en SRD?

medan SRD fungerar som en ritning för att hantera omfattningen av ett projekt, definierar det i slutändan bara funktionella och icke-funktionella krav för ett system. Dokumentet beskriver inte design-eller tekniklösningar. Dessa beslut fattas senare av utvecklarna.

en välskriven SRD bör:

• bryta problemet i hanterbara delar.
• fungera som referens för testning och validering.
• informera designspecifikationerna (dvs. SRD måste innehålla tillräcklig information om programvarans krav för att göra en effektiv design).
• ge feedback till klienten (slutanvändaren).

SRD visar för klienten att din organisation förstår problemet de vill lösas och hur man hanterar dessa problem genom mjukvarulösningar. Eftersom kunder ofta är direkta intressenter är det särskilt viktigt att utarbeta dokumentationen tydligt i lekmanens termer (undvika teknisk jargong).

återigen, hur du skriver din SRD beror på vilken metod och metod ditt team eller organisation prenumererar på. IEEE standards organization rekommenderar dock att typiska SRDs bör omfatta följande ämnen:

• gränssnitt
• funktionella funktioner
• prestandanivåer
• datastrukturer/element
• tillförlitlighet
• säkerhet/integritet
• kvalitet
• begränsningar och begränsningar

om vart och ett av dessa ämnen tydligt behandlas och beskrivs i din dokumentation, du får en mer fullständig bild av den information som behövs för att utveckla din ansökan.

så här spikar du ditt programkrav dokument

oavsett tillvägagångssätt du tar till dokumentation, följ dessa bästa metoder för att skapa en effektiv och effektiv SRD.

håll det organiserat

namnet på spelet är organisation. Innan du börjar faktiskt dokumentera, se till att börja med en organisationsstrategi för alla dokument, inklusive var dina dokument lagras, hur du säkerställer konsekvens och hur bidragsgivare och medarbetare enkelt kan hålla dokument uppdaterade. För att vara effektiv bör ett programkrav dokument organiseras och tydlig. Många organisationer förlitar sig på husmallar för att upprätthålla konsekvens mellan projekt. Mallar är ett bra sätt att spara tid (fyll bara i de förorganiserade avsnitten) och håll dig konsekvent i din dokumentationsprocess.

dokumentmallar förstärker emellertid ofta problemet med långvariga, text-tunga krav. För att undvika att fastna i sidor med text, överväga att komplettera din dokumentationsprocess med visuella data.

se till att kraven är fullständiga

för att ett krav ska vara” komplett ” bör det innehålla all nödvändig information för att genomföra kravet. Detta innebär att när designers och utvecklare går att bygga ut funktionen, de är inte kvar att göra antaganden eller gissningar om kravet.

låt oss till exempel säga att du utvecklar en webbsida. Ett av kraven som beskrivs är vad som ska hända vid ett fel. Ett ofullständigt krav kan säga något som ” vid fel bör systemet gå smidigt ut.”

i detta fall definieras” smidigt ” inte och lämnas upp till tolkning. Denna tvetydighet kan leda till felaktig tolkning av de önskade resultaten (och mer arbete för att gå tillbaka och fixa det).

för att undvika detta, skriv ett komplett krav som definierar hur en framgångsrik funktion ser ut:

”vid fel måste systemet visa en felsida med följande meddelande:

Uh-oh! Det verkar som om något gick fel. Försök igen om några minuter. Om problemet kvarstår, kontakta vårt supportteam på [email protected]. ”

genom att definiera ett fullständigt krav är det mindre tvetydighet och ett tydligt resultat för utvecklingsteamet att arbeta med.

gör krav testbara

detta är en ganska allestädes närvarande standard, men alltför ofta misslyckas organisationer att skriva krav som helt uppfyller denna regel.

krav måste verifieras. Annars finns det inget objektivt sätt att veta om kravet genomfördes på ett tillfredsställande sätt.

för varje krav du skriver, se till att det valideras på ett eller flera av följande sätt:

• inspektion
• Demonstration
• genomgång
• testning

krav på hög nivå genomgår ofta inspektion eller användartestning, så de förlitar sig vanligtvis på mer allmänna specifikationer. Men lägre krav som genomgår mjukvarutestning kommer sannolikt att behöva mer detaljerade specifikationer.

tillämpa implementeringsneutrala funktionskrav

som vi noterade tidigare är en SRD inte ett designdokument. Det definierar inte och bör inte definiera hur funktionskraven måste genomföras ur designsynpunkt.

därför bör alla funktionella krav vara implementeringsneutrala. Med andra ord bör kraven ange vad systemet ska göra, men inte hur det ska göra det.

det finns flera fördelar med implementeringsneutrala krav, inklusive:

• en effektivare designprocess
• modifierbara krav som inte är beroende av en specifik implementeringsdesign
• mindre konflikt mellan krav som härrör från motsatta implementeringsdetaljer

eventuella begränsningar för implementeringen bör reserveras för systemets icke-funktionella krav.

utvärdera dokumentation med intressenter

När alla programvarukrav har dokumenterats, låt alla relevanta intressenter utvärdera den slutliga dokumentationen innan utvecklingen börjar.

intressenter bör inkludera designers och utvecklare, testare som kommer att validera kraven, ingenjörer, slutanvändarrepresentanter och klienten.

genom att låta alla intressenter granska och godkänna dokumentationen innan du börjar utveckla, förbättrar du tillfredsställelsen mellan teamen och ökar sannolikheten för att kraven kommer att uppfylla deras behov.

hjälp mjukvaruutvecklare och deras team att hålla sig på samma sida med flödesscheman som effektivt och elegant kartlägger dina programvarukrav. Leta efter en diagramlösning som kan hjälpa dig:

• organisera dina krav i ett flödesschema för att hålla dina komponenter distinkta, dina beroenden tydliga och intressenterna uppenbara.
• använd swimlanes för att visuellt beskriva vilka lag som är ansvariga för varje kravuppsättning.
• snabbt ändra krav eller andra data som projektet behöver utvecklas.
• länkdata (inklusive ytterligare dokument) för att stödja och informera ditt pågående projekt.
• dela dokumentationen (och eventuella ändringar) omedelbart med relevanta intressenter.

dokumentation behöver inte vara en syssla. Med Lucidchart kan du enkelt dokumentera processer, användarberättelser och programkrav på en plats. Genom att visuellt definiera dina kravspecifikationer kan du och ditt team snabbt hitta och agera på information samtidigt som du minskar möjligheterna till fel, inkonsekvenser och misstolkningar.

börja dokumentera

få synlighet i dina befintliga tekniska system med Lucidchart idag.

lär dig hur