softwareontwikkeling kan een spannend proces zijn van creatieve probleemoplossing, ontwerp en engineering. Maar onder de glanzende apps en gepolijste webpagina ‘ s ligt de minder sexy maar oh-zo-belangrijke steiger die goede software resultaten mogelijk maakt: documentatie.

documentatie zorgt ervoor dat teams en individuele stakeholders op dezelfde pagina staan met betrekking tot de doelstellingen, reikwijdte, beperkingen en functionele vereisten van een product of softwareapplicatie.

helaas kan het proces van het maken en documenteren van deze vereisten vervelend, verwarrend en rommelig zijn.

softwarevereisten documenten kunnen snel lange, logge, tekstzware documenten worden, waardoor ze bijzonder kwetsbaar zijn voor fouten, inconsistenties en verkeerde interpretaties. Hierdoor kan het schrijven en gebruiken van deze documenten tijdrovend zijn en leiden tot dure (en vermijdbare) ontwerpfouten.

dus wat moeten productmanagers, softwareteams en bedrijfsleiders doen?

hoewel er geen one-size-fits-all-regel is voor softwareontwikkelingsbenaderingen, zijn er manieren om fouten te verminderen, tijd te besparen en effectieve resultaten te genereren.

hieronder gaan we door de doelstellingen en voordelen van software requirements documents en een paar best practices die u zullen helpen het proces van begin tot eind te volgen.

Wat zijn software requirements documents?

een software requirements document (ook wel software requirements specifications genoemd) is een document of documentatieset dat de eigenschappen en het beoogde gedrag van een toepassing beschrijft.

met andere woorden, het software requirements document (SRD) beschrijft het begrip van het bedrijf of de organisatie van de behoeften en afhankelijkheden van de eindgebruiker (meestal de client) en van eventuele beperkingen op het systeem.

Wat is opgenomen in een SRD?

terwijl het SRD fungeert als blauwdruk voor het beheer van de reikwijdte van een project, definieert het uiteindelijk alleen functionele en niet-functionele eisen voor een systeem. Het document schetst geen ontwerp-of technologische oplossingen. Deze beslissingen worden later door de ontwikkelaars genomen.

een goed geschreven SRD moet:

• het probleem in beheersbare delen opsplitsen.
• dienen als referentie voor het testen en valideren.
• Informeer de ontwerpspecificaties (d.w.z. dat het SRD voldoende informatie over de eisen van de software moet bevatten om een effectief ontwerp te maken).
• geef feedback aan de client (eindgebruiker).

het SRD laat de client zien dat uw organisatie begrijpt welk probleem zij willen oplossen en hoe deze problemen met behulp van softwareoplossingen kunnen worden opgelost. Omdat klanten vaak directe stakeholders zijn, is het vooral belangrijk om de documentatie duidelijk in lekentaal op te stellen (technisch jargon vermijden).

nogmaals, hoe u uw SRD schrijft zal afhangen van de aanpak en methodologie waarop uw team of organisatie zich abonneert. Echter, de IEEE-standaarden organisatie adviseert typische SRDs moet betrekking hebben op de volgende onderwerpen:

• Interfaces
• functies
• Prestaties
• Data-Structuren/Elementen
• Veiligheid
• Betrouwbaarheid
• Beveiliging/Privacy
• Kwaliteit
• Beperkingen

Als elk van deze onderwerpen wordt duidelijk besproken en uitgelegd in de documentatie, heb je een meer compleet beeld van de informatie die nodig is om uw applicatie te ontwikkelen.

hoe uw software requirements document na te leven

welke aanpak u ook kiest voor documentatie, volg deze best practices om een effectief en efficiënt SRD te creëren.

houd het georganiseerd

de naam van het spel is Organisatie. Voordat u daadwerkelijk begint met documenteren, moet u beginnen met een organisatiestrategie voor alle documenten, inclusief waar uw documenten worden opgeslagen, hoe u consistentie kunt garanderen en hoe medewerkers en medewerkers documenten eenvoudig up-to-date kunnen houden. Om effectief te zijn, een software requirements document moet worden georganiseerd en duidelijk. Veel organisaties vertrouwen op huis sjablonen om consistentie tussen projecten te behouden. Sjablonen zijn een geweldige manier om tijd te besparen (vul gewoon de vooraf georganiseerde secties in) en blijf consistent in uw documentatieproces.

documentsjablonen versterken echter vaak het probleem van langdradige, tekstintensieve vereisten. Om te voorkomen dat u verzandt in pagina ‘ s met tekst, kunt u overwegen uw documentatieproces aan te vullen met visuele gegevens.

zorg ervoor dat de vereisten volledig zijn

om een eis “volledig” te laten zijn, moet het alle nodige informatie bevatten om de eis uit te voeren. Dit betekent dat wanneer de ontwerpers en ontwikkelaars gaan uit te bouwen van de functie, ze zijn niet links maken van veronderstellingen of gissingen over de eis.

bijvoorbeeld, stel dat je een webpagina aan het ontwikkelen bent. Een van de beschreven eisen is wat er moet gebeuren in geval van een fout. Een onvolledige eis zou kunnen zeggen zoiets als ” In geval van een fout, het systeem moet soepel af te sluiten.”

in dit geval is “smooth” niet gedefinieerd en wordt het aan interpretatie overgelaten. Deze dubbelzinnigheid kan leiden tot een verkeerde interpretatie van de gewenste resultaten (en meer werk om terug te gaan en het op te lossen).

om dit te voorkomen, Schrijf een volledige eis die definieert hoe een succesvolle functie eruit ziet:

“In geval van een fout, moet het systeem een foutpagina tonen met het volgende bericht:

Uh-oh! Het lijkt erop dat er iets mis is gegaan. Probeer het binnen enkele minuten opnieuw. Als het probleem blijft bestaan, neem dan contact op met ons ondersteuningsteam op [email protected] ”

door een volledige eis te definiëren, is er minder dubbelzinnigheid en een duidelijk resultaat voor het ontwikkelingsteam om aan te werken.

Make requirements testable

Dit is een vrij alomtegenwoordige standaard, maar te vaak slagen organisaties er niet in eisen te schrijven die volledig aan deze regel voldoen.

vereisten moeten verifieerbaar zijn. Anders is er geen objectieve manier om te weten of de eis naar tevredenheid is uitgevoerd.

voor elke eis die u schrijft, moet u ervoor zorgen dat deze gevalideerd is op een of meer van de volgende manieren:

• inspectie
• demonstratie
• Walk-through
• testen

vereisten op hoog niveau worden vaak geïnspecteerd of getest door de gebruiker, zodat ze meestal gebaseerd zijn op meer algemene specificaties. Maar lagere eisen die software testen ondergaan zullen waarschijnlijk meer gedetailleerde specificaties nodig.

implementation-neutral functional requirements

zoals we eerder hebben opgemerkt, is een SRD geen ontwerpdocument. Het is niet en mag niet bepalen hoe de functionele eisen moeten worden uitgevoerd vanuit een ontwerp standpunt.

daarom moeten alle functionele eisen implementatieneutraal zijn. Met andere woorden, de eisen moeten aangeven wat het systeem moet doen, maar niet hoe het moet doen.

Er zijn verschillende voordelen aan implementatie-neutrale vereisten, waaronder:

• een efficiënter ontwerpproces
• aanpasbare vereisten die niet afhankelijk zijn van een specifiek implementatieontwerp
• minder conflict tussen vereisten als gevolg van tegengestelde implementatiedetails

eventuele implementatiebeperkingen moeten worden voorbehouden aan de niet-functionele vereisten van het systeem.

evalueer documentatie met stakeholders

wanneer alle softwarevereisten zijn gedocumenteerd, laat alle relevante stakeholders de definitieve documentatie evalueren voordat de ontwikkeling begint.

Stakeholders moeten ontwerpers en ontwikkelaars, testers die de vereisten zullen valideren, ingenieurs, vertegenwoordigers van de eindgebruiker en de klant omvatten.

door alle stakeholders de documentatie te laten beoordelen en goedkeuren voordat u met de ontwikkeling begint, verbetert u de tevredenheid van de teams en vergroot u de kans dat de vereisten aan hun behoeften voldoen.

help softwareontwikkelaars en hun teams op dezelfde pagina te blijven met flowcharts die uw softwarevereisten efficiënt en elegant in kaart brengen. Zoek naar een diagramming oplossing die u kan helpen:

• Organiseer uw vereisten in een stroomdiagram om uw componenten apart te houden, uw afhankelijkheden duidelijk te houden, en de stakeholders duidelijk.
• gebruik swimlanes om visueel te beschrijven welke teams verantwoordelijk zijn voor elke vereiste.
• wijzig snel vereisten of andere gegevens naarmate de projectbehoeften evolueren.
• Link data (inclusief aanvullende documenten) om uw lopende project te ondersteunen en te informeren.
• deel de documentatie (en eventuele wijzigingen) onmiddellijk met relevante belanghebbenden.

documentatie hoeft geen karwei te zijn. Met Lucidchart kunt u eenvoudig processen, gebruikersverhalen en softwarevereisten op één locatie documenteren. Door het visueel definiëren van uw eisen specificaties, zult u en uw team in staat zijn om informatie snel te vinden en te handelen, terwijl het verminderen van de mogelijkheden voor fouten, inconsistenties en verkeerde interpretaties.

begin met documenteren

verkrijg vandaag inzicht in uw bestaande technische systemen met Lucidchart.

leer hoe