Requirements

Algemene informatie

Requirements gaan over het ontwikkelen van een Systeem of Software. Requirements zijn er om het duidelijker te maken wat er moet gebeuren. Op deze manier weet je dat iedereen het zelfde voor zich ziet en dat er geen fouten komen. Dus zo weet de klant dat de programmeur hem goed begrijpt. Ook is het makkelijker om te testen met concrete requirements, om te verifiëren dat de app doet wat het moet doen. Requirements moeten nooit onmogelijk zijn, dat zou nutteloos zijn.

Je hebt 3 soorten requirements:

• Functional Requirements
• Non Functional Requirements
• Randvoorwaarden

Dankzij requirements weet je of dat je uitwerking voldoet aan de Acceptatie Criteria. Requirements kunnen van de klant komen, maar ook vanuit de wet, de Stakeholder, Bedrijfs Procedures, factoren zoals markttrends, technologie en cultuur.

Functional Requirements

Een functionele requirement geeft aan hoe het systeem zich moet gedragen. Ze bestaan uit functie en gedrag. Een voorbeeld van een Functie kan zijn: “omzetbelasting berekenen” Een voorbeeld van Gedrag kan zijn: “Het systeem berekent de omzetbelasting door aankoopprijs te vermenigvuldigen met het belastingtarief.”

Hier zie je dat gedrag specefieker is en kan dus bepaalde gevallen handiger zijn. Functie is handiger als je nog niet precies weet hoe het Onder water moet werken, en je dus alleen de uitkomst kan specifieren. Je ziet functionele eisen vaak terug bij Rapportage Vereisten, Wettelijke vereisten, Data management etc.

• Maak je requirements helder en duidelijk, vermijd woorden zoals beter dan en gebruiksvriendelijk.
• Verder moet je aan je requirement ook een eigenaar hangen (Stakeholder), de persoon die er wat over mag zeggen.
• Geef goed de prioriteit aan.
• Meestal is aanvullende toelichting nodig.

Non-Functional Requirements

In tegendeel tot de Functionele Requirement, beschrijft de Non Functional Requirement niet wat het systeem moet doen, maar hoe het systeem moet werken. Bijvoorbeeld:

• Functionele eis: “De applicatie toont een lijst van alle aangesloten gebruikers.”
• Niet-functionele eis: “De applicatie moet binnen 2 seconden reageren bij het opvragen van de gebruikerslijst.”

non functionele eisen worden vaak gezien in de User Interface, Beveiliging, Onderheid etc.

Randvoorwaarde

Randvoorwaarden zijn zaken die vastliggen en die je vanuit het project niet kan veranderen, het zijn eigenlijk gewoon requirements, maar je hebt hier geen controle over. Als de wet iets zegt over bijvoorbeeld de AVG, dan moet je je daar aan houden. Verder kan het ook zijn dat een randvoorwaarde is: “We gebruiken C# als programmeertaal”

Het is handig om deze in je requirements mee te nemen zodat je de gevolgen ook meeneemt.

Requirements Workflow

Requirements Elicitation

Het achterhalen van requerements doe je bij de Stakeholder, dit kan door middel van Interviews, Brainstorming en Enquêtes. Maar requirements komen ook uit al bestaande software, of de wet.

Het kan voorkomen dat de Stakeholder er vanuit gaat dat iets logisch is, en het dus niet hoeft te vertellen, dit zijn valkuilen. Denk bijvoorbeeld aan een login functie, “Het is toch standaard dat je moet kunnen inloggen”.

Als je gaat prototypen met bijvoorbeeld Wireframes kan je dit soort problemen opsporen.

Requirements Analysis

Tijdens deze fase ga je op onderzoek uit. Kijk of dat ze consistent zijn, kijk of ze volledig zijn, juist en haalbaar. Kijk naar de prioriteiten.

Requirements Specification

Tijdens deze fase leg je alles vast. Inclusief meta-informatie. Er zijn meerdere manieren om dit te doen:

• In een formele en natuurlijke taal.
• Use case.
• User stories.

Requirements Validation

In deze fase ga je achterhalen en uitzoeken of jouw vastgestelde requirements wel kloppen met de visie van de klant of StakeHolder. Validatie kan je doen door middel van prototypes, test-cases en uitgebrijde reviews door/met StakeHolders. Requirements testen vereist zeer exacte requirements om inconsistenties op te sporen.

Requirements Management

Bij het ontwerpen zorg je altijd dat het herleidbaar is uit welke requirements iets komt, zodat het duidelijk is waarom bepaalde keuzes zijn gemaakt. Tijdens het ontwikkelen zie je dit bijvoorbeeld in git door de naam van je branch de nummer van de user story te geven. In een testplan wordt gerefereerd naar de eisen die te maken hebben met de specefieke test.

Acceptatie Criteria

Acceptatie criteria geven concreet aan welke specefieke voorwaarden en requirements moeten voldoen om aan de verwachting van de gebruiker of Product Owner te voldoen. Pas als je aan alle requirements hebt coldaan kan je zeggen dat het af is. Schrijf daarom je acceptatie criteria zo dat het altijd antwoord heeft op de vraag: “is de requirement vervult, is dit af?”

Acceptatie Criteria zijn:

• Meetbaar: de uitkomst waarde is aangegeven.
• Specefiek: voor de context waar de user story geldig is.
• Concreet: iedereen in je team snapt hem
• Testbaar: het moet duidelijk zijn dat het herhaalbaar is onder de gegeven omstandigheden.

Het is belangrijk dat je controleert met je gebruikers/doelgroep/product owner of het goede acceptatie criteria is.

Bijvoorbeeld

• Stel de gebruikersbehoefte is dat de vloer van de ruimte stofvrij moet zijn.
• Wat is dan ‘voldoende’ stofvrij?
• Een acceptatie criterium kan zijn dat als er minder dan 10 stofdeeltjes per m² wordt gevonden in 1 minuut stofzuigen, dan is het stofvrij genoeg.

Bijvoorbeeld

• Stel de requirement is dat de thermostaat gebruiksvriendelijk moet zijn. Wat betekent dat?
• Een acceptatie criterium kan zijn dat elke instelling van de thermostaat in maximaal 3 stappen moet kunnen worden ingesteld.