6 stappen voor het schrijven van een SRS-Document dat werkt + sjabloon
Softwarespecificatiedocumenten worden soms gezien als artefacten die alleen zinvol zijn voor ontwikkelaars. Een SRS-document kan echter verder gaan en een gids worden voor marketingspecialisten, stakeholders, ontwerpteams en zelfs gebruikers.
dit artikel legt uit waarom softwaredocumentatie belangrijk is en hoe u uw SRS-document kunt schrijven om er een praktische handleiding van te maken voor alle teamspecialisten.
Wat is een SRS-Document en waarom is het belangrijk?
een SRS (software requirement specification) document is een artefact dat de vereisten, verwachtingen en normen voor een toekomstig product bevat. Het kan betrekking hebben op tekstdocumenten, spreadsheets, schema ‘ s, precedenten en andere elementen die de visie van het product te verduidelijken. Met andere woorden, een SRS document geeft een gedetailleerde beschrijving van hoe een product moet werken en hoe het product development team moet implementeren.
stel je het voor als het bouwen van een schip. Je hebt een visie op de mast of het zeil, en je kunt je zelfs voorstellen hoe het door de golven reist. Echter, je hebt strengere details nodig om het schip op het water te zetten.
hetzelfde geldt voor productontwikkeling. U kunt een duidelijk beeld hebben van een app die u wilt bouwen met alle functies, ontwerpelementen en knoppen. Echter, een verbale beschrijving van de functies is niet genoeg voor ontwikkelaars om het idee uit te voeren.
als het resultaat overeenkomt met de afbeelding in uw hoofd, moet u op papier uitleggen hoe een functie precies moet functioneren. Een SRS-document is een uitstekend instrument om dergelijke technische details te beschrijven.
.jpg)
Wie schrijft een SRS-Document?
het schrijven van een SRS-document betekent dat algemene beschrijvingen van functies, taken en doelstellingen worden overgebracht naar het gedetailleerde plan van hun technische implementatie.
SRS-documenten worden gewoonlijk geschreven door product-en projectmanagers of bedrijfsanalisten, die rechtstreeks met klanten communiceren of gebruikersonderzoek doen (die ook aan wireframes werkt en weet hoe het product zich moet gedragen) en de behoeften van toekomstige producten verzamelen.
ondertussen is dit document beschikbaar. Een goed SRS-document is niet alleen technisch, want het heeft ook betrekking op zakelijke doelen, statistieken, gebruikersproblemen, gebruikerspersona ‘ s, enz.
3 Redenen waarom een SRS-Document belangrijk is
de algemene waarde van een SRS-document is dus duidelijk. Hier zijn de redenen waarom software-eisen specificatie documenten zijn essentieel:
SRS is een communicatiepunt
als levend document dient een SRS-document als communicatieplatform tussen alle specialisten: ontwikkelaars, marketingspecialisten en medeoprichters.
door in een SRS-document formeel of informeel details uit te leggen, komen managers met cliënten overeen wat de verwachtingen van de resultaten zijn. Ondertussen, als de wijzigingen worden aangebracht in de eisen, een klant en/of een product eigenaar kan controleren en valideren in het document. En de ontwikkelaars zijn verantwoordelijk om aan deze verwachtingen te voldoen.
Final Description of Features
SRS documenteert de definitieve versies van software die voortkwamen uit de veronderstellingen die eerder met cliënten werden besproken. Tijdens vergaderingen en gesprekken, gebruikerstests en interviews kunnen de productversies heel vaak veranderen. Soms zelfs Product managers kunnen krijgen overweldigd door de bestaande product iteraties. SRS-bestand helpt om al deze vereisten te verenigen in één standaard en alle verwarring met betrekking tot de productvereisten te elimineren.
SRS is een Standaardgids voor productontwikkelaars
naast het beschrijven van de productvereisten, begeleidt het SRS-document het ontwikkelingsteam over de stappen die zij moeten volgen om een product te bouwen dat een klant wil.
afhankelijk van de organisatie van het project kunnen ontwikkelaars al dan niet betrokken worden bij het analytische gedeelte van het project. In beide gevallen moeten ze concluderen hoe het systeem moet functioneren, de vereisten definiëren en de parameters coderen om het aan te passen. Op dezelfde manier moeten professionals in de kwaliteitsborging alle technische aspecten begrijpen die aan het productconcept ten grondslag liggen. Daarom dient SRS-documentatie als standaard voor het plannen en uitvoeren van QA-tests.
ten slotte krijgen ontwerpers projectinzichten via srs-documenten om het ontwerp aan te passen aan de use case.
6 stappen om een goed SRS-Document te schrijven
functionele en niet-functionele eisen nemen een groot deel van elk SRS-document. Productmanagers nemen deze eisen niet zomaar uit het niets. Ze zijn het resultaat van nauwkeurige communicatie met klanten en diepgaand gebruikers-en technisch onderzoek. Hier zijn de belangrijkste stappen van het schrijven van uitstekende SRS documentatie:
Stap 1 Communicatie met een stakeholder
we verwijderen de eerste laag van onzekerheid door de stakeholders te vragen naar hun verwachtingen van het product. Tuurlijk, zo ‘ n interview geeft slechts een beetje begrip van de eisen. Dit is echter nog steeds een goed uitgangspunt voor onderzoek.
bij Uptech praten we eerst met de klant tijdens de pre-Sale en Kick-Off call wanneer we proberen uit te zoeken of we bij elkaar passen. We proberen de kleinste details over de cliënt te kristaliseren om zijn/haar idee te begrijpen.
eenvoudige communicatie geeft echter onvoldoende informatie over de doelgroep van het product en hun wensen en behoeften. Dus we gaan verder met de ontdekking fase om het duidelijk te maken.
Stap 2 Discovery Stage
de Discovery stage is cruciaal bij het schrijven van SRS-documentatie. In dit stadium hebben we de mogelijkheid om het probleem te onderzoeken dat het product moet oplossen, Interesses en behoeften. Ons doel hier is om problemen van gebruikers te identificeren en hypothesen te definiëren van mogelijke oplossingen om ze aan te pakken. Met een dergelijke aanpak kunnen we de app waardevol maken voor de gebruiker.
Use Cases vs User Stories
alle gebruikersgegevens worden een onderdeel van een SRS-document als Use Cases en User Stories. Het verschil tussen deze twee categorieën wordt in de Gemeenschap voor productontwikkeling uitvoerig besproken.
simpel gezegd, gebruikersverhalen zijn meer gericht op het resultaat en de voordelen die een gebruiker krijgt tijdens het gebruik van een functie. Terwijl use cases meer gedetailleerd beschrijven de functie zelf.
bijvoorbeeld, na meerdere gebruikersinterviews bij het Yaza project, concludeerden we dat de app een praatje moest hebben. Dus het verhaal van de gebruiker voor een dergelijke zaak zou klinken als: “als gebruiker, Ik wil chatten met een potentiële huiseigenaar.”
ondertussen, de use case voor dit verhaal zou beschrijven elke stap van een gebruiker voor het bereiken van dit doel – “als gebruiker, Ik moet een contact toe te voegen in mijn chatlijst en stuur hem/haar een bericht, zodat…”.
Stap 3 Bouw de structuur
zodra de ontdekking is voltooid, gaan we verder met het schrijven van SRS-documentatie. Ten eerste hebben we een korte structuur van het document nodig. De inhoud van een SRS-document kan aanzienlijk verschillen, maar de typische SRS-documentatiestructuur zou er zo uitzien:
1. Inleiding
de inleiding geeft een samenvatting van de inhoud van het document. Het wordt verondersteld om de volgende vragen te beantwoorden:
- korte beschrijving van de inhoud van het document;
- de beoogde lezers van dit document;
- het idee van de software die u aan het ontwikkelen bent;
- beoogde lezers.
1.1 Business Goals
Maak een lijst van doelen die u wilt bereiken op het project, zoals het maken van een MVP, het maken van een multiplatform mobiele app, of het starten van een website.
bovendien moet deze sectie de doelstellingen en successtatistieken van uw bedrijf weergeven. Hoewel sommigen dit deel van het document kunnen uitsluiten, is het van essentieel belang om deze zaken aan te geven, aangezien zij rechtstreeks van invloed zijn op onderzoek en ontwikkeling.
1.3 Beoogd gebruik
Hoe denkt u dat een individu uw product zal gebruiken? Wat zijn de functies die u biedt voor dit type gebruik? Beschrijf alle mogelijke manieren waarop een persoon uw product kan gebruiken in welke gebruikersrol hij / zij ook handelt.
1.4 Scope
dit deel beschrijft de omvang van het werk dat u moet uitvoeren om uw idee tot leven te brengen.
1.5 definities en acroniemen
deze geeft de definities weer van de termen die u in het document gebruikt om een volledig begrip voor de gebruikers te garanderen.
2. Algemene beschrijving
hier is het deel waar u het idee van de app uitlegt, waar het vandaan kwam en waarom het interessant kan zijn voor gebruikers.
2.1 gebruikers hebben
een stuk software dat voor iedereen is gebouwd, dient niemand. Maar als je precies weet wie je doelgroep is, waar ze werken, en hun pijn, heb je een hogere kans op het leveren van een app die op grote schaal wordt aangenomen door de gebruikers.
3. Systeemeigenschappen en-vereisten
nu is het tijd om de technische vereisten van uw toekomstige software te schetsen. Beschrijf de functies die uw product zal omvatten, samen met de normen die de kwaliteit van deze producten te definiëren.
3.1 functionele eisen
functionele eisen zijn systeemspecificaties, zonder welke de software niet goed zal functioneren. De definitie die u geeft aan uw softwarefuncties zal bepalen hoe ze verder zullen worden geïmplementeerd.
3.2 niet-functionele eisen
terwijl functionele eisen bepalen wat de functie van het systeem zal zijn, bepalen niet-functionele eisen hoe het systeem deze kenmerken zal implementeren, bijvoorbeeld de snelheid van voltooiing.
3.3 Tech Stack
een tech stack is een pool van technische oplossingen die gebruikt worden om software of een project te maken en uit te voeren. Het is van cruciaal belang om dit in het SRS-document aan te geven, aangezien het alle andere technische details definieert.
.jpg)
Stap 4 Maak een algemene beschrijving
voordat u in de details van uw product duikt, geeft u een algemeen overzicht van de belangrijkste functies van de app. Leg gewoon het doel van uw app, de functies, en hoe ze het probleem van de gebruiker op te lossen.
Stap 5. Definieer functionele en niet-functionele vereisten
de kern van uw SRS-document zal meestal bestaan uit de functionele en niet-functionele vereisten van het product. Met dergelijke specificaties voegt u meer details toe aan het algemene overzicht en begeleidt u het team door de technische specificaties van uw app.
het verschil tussen functionele en niet-functionele eisen is een ander knelpunt in de productontwikkelingsgemeenschap. We hebben onze expertise over dit onderwerp gedeeld in dit artikel.
Stap 6. Zorg ervoor dat de Client op dezelfde pagina
goedkeuring een langverwachte deel van de ontwikkeling is. De bewerkingen van de klant kunnen echter soms de hele hoeveelheid werk, die op een bepaald punt in het project is voltooid, teniet doen.
om de druk te vermijden, raden we aan akkoord te gaan met kleine delen van voltooide SRS-documentatie, in plaats van een heel pakket documenten tegelijk in te dienen. Dit helpt om bepaalde problemen snel op te lossen en is minder lastig.
Expert Tips over het schrijven van grote SRS documentatie
het kost tijd om de vaardigheid van het schrijven van uitstekende SRS documentatie aan te scherpen. We hebben een lijst van deskundige tips over het schrijven van SRS-documentatie uit onze ervaring getrokken. Dus hier zijn een paar inzichten die uw SRS documentatie effectief zal maken:
Maak het eenvoudig
dit is nauwelijks een geheim, maar eenvoudige dingen heersen over de wereld. Dit geldt zeker voor elk type documentatie waar u aan werkt. Uw SRS is een uniforme beschrijving van het toekomstige product voor uw hele team. Dit betekent dat de taal, structuur en formuleringen van uw SRS-document zo laconiek mogelijk moeten zijn.
omvatten bedrijfsdoelstellingen
hoewel een SRS-document voornamelijk gericht is op de technische kenmerken, met inbegrip van bedrijfsdoelstellingen, een goede praktijk is. Een SRS-document is een instructie voor het ontwikkelingsteam en de productsamenvatting voor niet-technische specialisten met betrekking tot het product. Bovendien, met inbegrip van zakelijke eisen, zoals statistieken en doeleinden, zal uw SRS een uniform instrument voor het hele team.
gebruikersgegevens toevoegen
de ontdekkingsfase onthult meestal de meest waardevolle informatie over een gebruiker. Het toevoegen van deze informatie aan het SRS-document maakt het een nuttig document voor het ontwerp-en ontwikkelingsteam.
Behandel uw SRS als een levend Document
het SRS-document mag niet statisch zijn, zelfs als u alle benodigde pakketten voor uw project hebt samengesteld. In Agile ecosystemen, projecten gaan rond het verwerven van nieuwe functies bij elke passerende iteratie. Al deze wijzigingen en wijzigingen dienen in het SRS-document te worden vermeld en met de klant te worden overeengekomen.
conclusie
het schrijven van SRS-documenten vergt diepgaand onderzoek, analyse en inspanning. Een uitgebreid SRS-document dat bedrijfskenmerken, technische details en gebruikersgegevens omvat, zal echter vruchten afwerpen met een verbluffend product dat zowel aan de verwachtingen van klanten als van gebruikers voldoet.
Uptech heeft vijf jaar ervaring met het bouwen van producten voor bloeiende startups. We weten hoe we de behoeften van de gebruiker kunnen onderzoeken en van SRS document een effectief instrument voor projectmanagement kunnen maken in plaats van een stapel met stof bedekte papieren.
F. A. Q.
Wat is SRS?
een SRS is een document met een gedetailleerde beschrijving van de technische specificaties en vereisten van een app of software. Een SRS instrueert ontwikkelaars ook over hoe het idee van het product te implementeren om aan de verwachtingen van de klant te voldoen.
Wat is het doel van een SRS-document?
het doel van een SRS-document is een technische beschrijving van de kenmerken van een product te geven, technische en niet-technische vereisten te verstrekken en het ontwikkelingsteam te begeleiden bij de implementatie.
Wie schrijft SRS documenten?
afhankelijk van de samenstelling van het team worden SRS-documenten meestal geschreven door:
- Product Manager;
- Project Manager;
- Business Analyst;
- Technical Engineer.