#productlabel
een software requirement specification (SRS document) beschrijft hoe een software systeem moet worden ontwikkeld. Simpel gezegd, een SRS biedt alle betrokkenen een roadmap voor dat project.
Het biedt hoogwaardige definities voor de functionele en niet-functionele specificaties van de software, en kan ook use cases bevatten die illustreren hoe een gebruiker met het systeem zou interageren na voltooiing.,
Opmerking: Laat ons u helpen bij het schrijven van een Software Requirements Specification. Vraag een oproep aan met onze CTO door dit formulier in te vullen.
inhoudsopgave
Waarom is een SRS-Document belangrijk?
stel dat u een chat-app wilt maken met een specifiek uiterlijk en functionaliteit en wilt dat deze specifiek is afgestemd op ondernemingen. Je hebt het gevoel dat je de extra functies die commerciële chat-apps gebruiken om een beroep op het publiek en focus op functies die bedrijven nodig hebben kunt knippen. Maar je bent geen Ontwikkelaar.,
dus u moet de ontwikkeling van de app uitbesteden. Maar je moet er ook voor zorgen dat degene die je inhuurt om je idee om te zetten in werkelijkheid precies weet wat je probeert te bereiken. Zonder alle details om de app te voltooien, kunnen tijd en kosten snel uit de hand lopen. Ontwikkelaars kunnen een verkeerde afslag nemen en moeten de code refactor als het eindproduct niet overeenkomt met de foto die je in je hoofd had.
een SRS-document dwingt u om het idee op papier te zetten om al deze details te behandelen. Je moet dit idee vertalen naar een taal die ontwikkelaars begrijpen., Een SRS document beschrijft wat een client wil en wat ontwikkelaars zullen bieden. Het is de schriftelijke overeenkomst over elk detail van de app.
het hebben van een duidelijke set van vereisten zorgt ervoor dat een ontwikkelingsteam software maakt die aan de behoeften van de clients voldoet. Een SRS zal helpen bij het schatten van de kosten van het werk en het dekken van de projectomvang. Het geeft programmeurs ook een idee van de tech stack die ze nodig hebben en helpt hen hun werk te plannen, maar dat is niet alles:
- ontwerpers krijgen projectinzichten via srs-documenten, zodat ze het ontwerp kunnen matchen met de use case.,
- Testers krijgen de richtlijnen voor het maken van testcases die voldoen aan de behoeften van het bedrijf.
- eindgebruikers gebruiken de SRS om de software te begrijpen.
- Het biedt beleggers een overzicht van de kenmerken van het systeem, zodat zij beleggingsbeslissingen kunnen nemen.
een SRS is belangrijk omdat het een enkele bron van informatie en verwachtingen is, die misverstanden tussen projectmanagers, ontwikkelaars, ontwerpers en testers voorkomt.
wat bevat een SRS?,
een SRS moet voldoende informatie hebben voor ontwikkelaars om de beschreven software te voltooien. Het geeft niet alleen de beschrijving van de software in ontwikkeling, maar ook het doel dat het zal dienen: wat de software wordt verondersteld te doen en hoe het moet presteren.,van de software of wat het verondersteld wordt te doen
Het Verschil Tussen Functionele en Niet-functionele Vereisten
de Functionele eisen zijn de doelen van het nieuwe systeem aan het ontwerpen bent., Ze beschrijven het systeem en hoe het zal functioneren om te helpen met de taken van een gebruiker. Ze bepalen hoe het systeem zal reageren op input van de gebruiker en hebben details over berekeningen, gegevensinvoer en bedrijfsprocessen. U kunt functionele eisen overwegen een gedetailleerde beschrijving van de functies van de toepassing en de behoeften van de gebruiker. Zonder te voldoen aan de functionele eisen, zal het systeem niet werken.
hoewel functionele vereisten specificeren wat een systeem doet, beschrijven niet-functionele vereisten hoe het systeem het zal doen. Niet-functionele vereisten hebben geen invloed op de functionaliteit van de toepassing., Zelfs zonder te voldoen aan niet-functionele eisen, zal het systeem de gewenste taken uitvoeren.
niet-functionele eisen zijn ook belangrijk omdat ze de Algemene kenmerken definiëren die de gebruikerservaring beïnvloeden. In plaats van zich te richten op gebruikersvereisten, richten ze zich op gebruikersverwachtingen en behandelen onderwerpen als prestaties, veiligheid, betrouwbaarheid, beschikbaarheid en bruikbaarheid.,
Hoe schrijf je een software Requirement Specification Document
het is het beste om het proces dat je gebruikt om een SRS document te schrijven te organiseren door te beginnen met een skelet en algemene informatie over de software die je aan het ontwikkelen bent, en af te ronden door details toe te voegen om je concept uit te werken. Hier zijn zes stappen betrokken bij het maken van een SRS document:
Get Software Requirements Specification Document
we hielpen meer dan 200 bedrijven hun software producten te bouwen. Huur onze business analist met 6 jaar ervaring in om een SRS voor u te schrijven.,
Request SRS
Maak een Outline
De eerste stap in het proces is het maken van een outline voor uw SRS. U kunt dit zelf maken of een bestaand SRS-sjabloon gebruiken als uitgangspunt. Hier is een basisvoorbeeld van een SRS-outline:
Download het ebook
- Inleiding
- Doel
- Doelgroep
- het Beoogde Gebruik
- Omvang
- Definities
- Algemene Beschrijving
- de Behoeften van de Gebruiker
- Aannames en Afhankelijkheden
- Kenmerken van het systeem en de Vereisten
- Functionele Eisen
- Externe Interface Requirements
- Systeem Eigenschappen
- Niet-functionele Requirements
Definieer het Doel
als je Eenmaal hebt een schets, moet u het uit vlees., Begin met het definiëren van het doel van het product in de introductie van uw SRS. Hier beschrijf je het beoogde publiek en hoe ze het product zullen gebruiken. Hier is hoe je het doel moet structureren:
- Definieer de scope van het product
- Beschrijf de waarde die het zal leveren
- toon wie de software zal gebruiken
- Detail hoe het zal helpen met de taak van de beoogde gebruikers
Geef een overzicht
na het definiëren van het doel van het product, vat samen hoe het zal werken., Hier vindt u een algemene beschrijving van de functies van de software en hoe ze passen bij de behoeften van de gebruiker te geven.
u zult ook de veronderstellingen beschrijven die u maakt over de functionaliteit van het product en alles waarvan het afhankelijk is in het huidige tech-ecosysteem.
Beschrijf functionele en niet-functionele vereisten
Nu u de Algemene informatie hebt geschreven, is het tijd om specifieker te worden. Het invullen van uw overzicht voordat u werkt aan functionele en niet-functionele eisen geeft u een referentie om ervoor te zorgen dat u voldoet aan de basisbehoeften van de gebruiker, terwijl u de details in te vullen.,
deze gedetailleerde beschrijving van de eisen van het systeem is het meest essentiële onderdeel van een SRS-document. Beschrijf de functionele eisen in voldoende detail, zodat ontwikkelaars aan het werk kunnen gaan en de niet-functionele eisen zoals beveiligingsspecificaties en prestaties.
Hier kunt u use cases toevoegen om levendig te beschrijven hoe een gebruiker met uw systeem zal communiceren. Het is waar de doelstellingen van uw project zijn gedetailleerd en zal meten hoe het project vordert tijdens de ontwikkeling.,
voeg aanvullende Details toe
de laatste stap in het maken van het concept van uw SRS-document is het toevoegen van details die ontwikkelaars kunnen helpen de taak af te maken in de vorm van bijlagen, woordenlijsten van termen en referenties.
krijg goedkeuring
zodra u voldoende details aan de SRS hebt toegevoegd om te beschrijven wat het systeem verondersteld wordt te doen, is het tijd dat de stakeholders het document goedkeuren.
u zult hoogstwaarschijnlijk een presentatie moeten geven aan de mensen die betrokken zijn bij het ontwikkelingsproces., Zij kunnen om wijzigingen vragen en u zult het SRS-document moeten bijwerken op basis van feedback van stakeholders voordat u het definitief goedkeurt.
Dit is een goed teken. Het betekent dat zowel ontwikkelaars als stakeholders het document preciezer maken, zodat het project minder van de rails gaat.
hoe Software Use Cases te schrijven in een SRS
Een use case beschrijft hoe een gebruiker zal interageren met het systeem. Het zal het product beschrijven vanuit het oogpunt van de eindgebruiker in een eenvoudig verhaal formaat. Het uitschrijven van use cases dwingt je om na te denken over wat gebruikers zullen doen met de software en hoe het zal reageren., Het is de real-life visualisatie van de functionele eisen.
Hier zijn stappen die u kunt volgen om een use case te schrijven:
- Beschrijf de eindgebruikers van uw product.
- Focus op een van deze gebruikers.
- splits de interacties van deze gebruiker in use cases. Elke interactie is een use case.
- Beschrijf de volgorde van gebeurtenissen voor elke use case.
- Schrijf een gedetailleerde beschrijving van de acties van de gebruiker en hoe het systeem moet reageren.
- breid elke use case uit met alternatieve gebruikersacties en systeemreacties.
- herhaal 1-6 voor elk type eindgebruiker.,
Wat zijn de kenmerken van een grote SRS?
Er zijn specifieke kenmerken die elke SRS zou moeten hebben. Door deze lijst te bekijken en te vergelijken met uw SRS, kunt u ervoor zorgen dat het een nuttig document is voor alle stakeholders.
expliciet
een SRS-document moet gemakkelijk te begrijpen zijn. Niets mag vaag zijn, dus er zijn geen misverstanden tussen belanghebbenden.,
meetbaar
de vereisten in uw SRS-document moeten meetbaar zijn, zodat het eindproduct kan worden gevalideerd en geverifieerd aan de hand van de specificaties.
Complete
een SRS-document moet voldoende informatie bevatten zodat uw ontwikkelteam het product kan voltooien en voor testers om te valideren dat het product aan de behoeften van de gebruiker voldoet zonder bugs.
levensvatbaar
de vereisten moeten passen bij de realiteit van de huidige omgeving, met inbegrip van het budget, het tijdschema en de technologie. Ze moeten niet afhankelijk zijn van komende technologische doorbraken.,
flexibel
omdat er dingen kunnen veranderen in de werkomgeving, moet uw SRS-document flexibel genoeg zijn om updates mogelijk te maken. Voeg geen overbodige informatie toe aan meerdere secties die bij elke wijziging moeten worden bijgewerkt.
controleerbaar
Iedereen in het ontwikkelteam moet toegang hebben tot het document, zodat ze er zo vaak als nodig naar kunnen verwijzen. De eisen moeten nauwkeurig zijn, zodat teamleden niet om meer informatie hoeven te vragen. Ze moeten allemaal beschikbaar zijn in het SRS-document.,
Consistent
de vereisten moeten bij elkaar passen. Een gedeelte van uw vereisten document mag niet in strijd zijn met een ander. Het document moet consequent worden opgemaakt en overal dezelfde terminologie gebruiken.
geen Implementatiebeperkingen
een SRS-document zou gedetailleerd genoeg moeten zijn om de taak te voltooien, maar zou niet al te specifiek moeten zijn, omdat dat de ontwikkeling zou kunnen beperken. Veel van de ontwikkeling is afhankelijk van diensten van derden die ontwikkelaars hebben geen controle over.,
nauwkeurige
doelen in een vereisten document moeten nauwkeurig zijn om verwarring te voorkomen. Vermijd het volgende:
- mazen in de wet: “de toepassing moet worden geladen in 3 seconden als het kan worden gedaan.”
- ambiguïteit: “het MVP-product moet zo snel mogelijk worden vrijgegeven.”
- subjectiviteit: “de gebruikersinterface moet gebruiksvriendelijk zijn.”
- superlatieven: “dit zou de beste toepassing in zijn klasse moeten zijn.”
- Comparative: “deze toepassing zou beter moeten zijn dan Slack.,”
A Software Requirement Specification (SRS) Example
Hier is een bijgesneden voorbeeld van een SRS-document voor een enterprise chat-app genaamd eChat:
Inleiding
dit document beschrijft het projectplan voor de ontwikkeling van “eChat.”
Het is bedoeld voor ontwikkelaars, ontwerpers en testers die werken aan “eChat” en projectinvesteerders., Dit plan zal een samenvatting bevatten van:
- hoe het systeem zal functioneren
- de reikwijdte van het project vanuit ontwikkelingsoogpunt
- de technologie die wordt gebruikt om het project te ontwikkelen, en
- de metrics die worden gebruikt om de voortgang van het project te bepalen
- algemene beschrijving
bedrijven hebben hulpmiddelen voor communicatie op afstand nodig, vooral nu meer mensen thuis werken. Het probleem is dat de meeste bedrijven uiteindelijk met behulp van meerdere applicaties om dit te bereiken: een voor tekst chat, een voor video chat, en een voor conferenties en vergaderingen., “eChat” lost dit probleem op door deze functies in één applicatie te combineren.
Download het whitepaper
klanten
de klanten zullen enterprise bedrijven zijn. Het zal niet gericht zijn op het grote publiek.
functionaliteit
- gebruikers moeten zich kunnen aanmelden bij LDAP-accounts van ondernemingen.,
- gebruikers moeten in staat zijn ad hoc chatgroepen aan te maken met sets van gebruikers en privéberichten naar individuele gebruikers te sturen.
- gebruikers zouden tekstchats moeten kunnen hebben die ze in threads kunnen breken.
- de toepassing moet in staat zijn om groepsvideochat van maximaal 100 gebruikers tegelijk aan te kunnen.
Platform
De applicatie zal worden ontwikkeld in React Native om de creatie van een webgebaseerde applicatie, een iOS mobiele app en een Android mobiele app mogelijk te maken.
Deze toepassingen zullen verbinding maken met een REST API gebouwd met .,NET Core om gegevens op te slaan en op te halen uit een MySQL-database.
authenticatie gebeurt via bestaande LDAP-installaties.
Ontwikkelingsverantwoordelijkheden
De ontwikkelaars van het “eChat” – team zijn verantwoordelijk voor het schrijven van alle code voor de toepassing, het ontwikkelen van de database en het beheren van releases.,
gebruikersklasse en kenmerken
Er zal een klasse gebruikers zijn genaamd admin die toegang heeft tot alle functionaliteit van de app, waaronder:
- kanalen creëren waar meerdere gebruikers kunnen interageren
- deze kanalen openbaar maken voor het hele bedrijf of privé voor een groep mensen
- deze kanalen verwijderen
- archiveren deze kanalen
standaardgebruikers hebben toegang tot alle functionaliteit van de app behalve die hierboven vermeld.,
Systeemeigenschappen
functionele vereisten
- gebruikers moeten in staat zijn ad-hoc chatgroepen te maken die gebruikersgroepen bevatten en privéberichten naar andere gebruikers te verzenden.
- gebruikers zouden tekstchats moeten kunnen hebben die ze in threads kunnen breken.
- Chats moeten voor onbepaalde tijd gearchiveerd kunnen worden, zodat gebruikers kunnen verwijzen naar eerdere chats.
- gebruikers moeten bestanden kunnen uploaden naar chats ter referentie.
- vereisten voor externe Interface
gebruikersinterfaces
- Front-end software: React Native
- Back-end software: .,s-besturingssystemen door hun standaard web browser
- iPhone
- Android –
- Niet-Functionele Requirements
Prestatie-Eisen
- De toepassing moet laden en bruikbaar zijn binnen 3 seconden
- De applicatie een update van de interface op de interactie binnen 2 seconden
- De database moet worden genormaliseerd om te voorkomen dat de redundante gegevens en het verbeteren van de prestaties
- De database moet worden verdeeld om stroomuitval te voorkomen
Veiligheid Vereisten
- Databases moeten gebruiken sharding overbodig verlies van gegevens te voorkomen.,
- back-ups van de databases moeten elk uur worden gemaakt en gedurende een week worden bewaard.
beveiligingseisen
- alle sleutels die worden gebruikt voor de REST-API moeten veilig worden opgeslagen.
- alleen de REST API zou verbinding moeten kunnen maken met de databases.
- Databases moeten achter een firewall staan.
Software Quality attributen
- beschikbaarheid: omdat deze toepassing cruciaal is voor zakelijke communicatie, hebben we een doel van vier negens(99,99%) beschikbaarheid.,
- juistheid: de toepassing mag nooit toestaan dat iemand berichten of discussies leest die niet voor die persoon bedoeld zijn.
- onderhoudbaarheid: de toepassing moet continue integratie gebruiken, zodat functies en bugfixes snel kunnen worden geïmplementeerd zonder downtime.
- Usability: de interface moet eenvoudig te leren zijn zonder een handleiding en gebruikers in staat stellen hun doelen te bereiken zonder fouten.
samenvatting
een SRS-document is een noodzakelijk onderdeel van het voltooien van een softwareontwikkelingsproject., Het is de roadmap die richting geeft aan iedereen die betrokken is bij het project, zodat het eindproduct voldoet aan de behoeften van de gebruiker.
zonder een compleet SRS-document op zijn plaats voordat u een project start, zal het moeilijk zijn om te zien wanneer een project is voltooid en zou de ontwikkeling kunnen leiden tot het creëren van onbedoelde functies. Een SRS-document geeft u de mogelijkheid om een project nauwkeurig in te schatten en taken efficiënt toe te wijzen.
het maken van een SRS-document kan een tijdrovend, nauwgezet proces zijn., Gelukkig heeft het team van Relevant meer dan 200 bedrijven geholpen bij het maken van SRS-documenten en het lanceren van nieuwe producten. We zijn klaar om te helpen met uw volgende software project, gewoon drop ons een lijn.