Samenvatting
Handboek Requirements samenvatting
- Instelling
- Hogeschool Van Amsterdam (HvA)
Samenvatting van 10 pagina's voor het vak Information systems & requirements aan de HvA
[Meer zien]Voorbeeld 2 van de 10 pagina's
Voorbeeld 2 van de 10 pagina's
In winkelwagengesponsord bericht van onze partner
Voorbeeld van de inhoud
Samenvatting Handboek RequirementsHoofdstuk 1 t/m 12
Positionering requirements
Hs. 1 Belang van requirements
Requirements als brug: requirements vertellen wat het te ontwikkelen system moet kunnen. Vanuit
de business, om hen optimaal te ondersteunen en vanuit het ontwikkelteam, om het te realiseren.
Het gaat bij requirements om het afstemmen van verwachtingen.
Belanghebbende van requirements:
- De opdrachtgever: het nieuwe systeem moet hem helpen om bepaalde bedrijfsdoelen te halen
of om een probleem op te lossen.
- De opdrachtnemer: requirements vertellen welk systeem gerealiseerd moet worden, hierna
kunnen betrouwbare inschattingen gemaakt worden.
- De ontwikkelaars: requirements vertellen waaraan de te bouwen software aan moet voldoen. De
basis van het systeemontwerp en de realisatie.
- De testers: waar moet de software aan voldoen. Testen of de norm is behaald.
- De gebruikers: wat kan het nieuwe systeem en wat niet. Gebruiksvriendelijkheid.
Ontwikkelactiviteiten zoals ontwerpen, bouwen en testen nemen de te implementeren requirements
als vertrekpunt. Een fout die tijdens het opstellen van de requirements wordt ontdekt en hersteld
kost vijf tot tien keer minder dan dezelfde fout die tijdens de realisatie wordt ontdekt en hersteld. De
problemen die software ontwikkelprojecten ondervinden met requirements blijken hoofdzakelijk
betrekking te hebben op de kwaliteit van de specificaties van de requirements op wijzigingen in de
requirements en op gebrek aan gebruikersinbreng.
De kritische succesfactoren voor softwareontwikkeling:
- Kwalitatief goede requirementsspecificaties, criteria:
Volledigheid, niets ontbreekt.
Consistentie, geen conflicterende requirements.
Eenduidigheid, een uitleg nodig.
Validiteit, bijdragen aan het beoogde bedrijfsdoel.
- Managen van wijzigingen in de requirements.
- Voldoende gebruikersinbreng.
Hs. 2 Requirements
Een requirement is:
1. Een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die
een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren.
2. Een eis aan het systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in
een behoefte te voorzien van een belanghebbende uit de business.
, Verdeling in functioneel en niet-functioneel. Een functionele requirement geeft het gewenste gedrag
van het systeem weer. Een niet-functionele requirement is een kwaliteitseis waaraan het systeem
moet voldoen, bijvoorbeeld hoe snel, hoe gemakkelijk, hoe veilig, hoe foutgevoelig het systeem moet
zijn.
Een systeemfunctie zet de invoer van het systeem om in de uitvoer. Het verschil tussen een
gewenste systeemfunctie en een functionele requirement is dat een functionele requirement een eis
stelt aan het gedrag van het systeem, terwijl een systeemfunctie dat gedrag zelf representeert.
Gevolg: een functioneel ontwerp is vervangen door een requirementspecificatie. Het is niet mogelijk
om eisen te ontwerpen.
Een use case is een requirement en representeert de geautomatiseerde ondersteuning die een
gebruiker nodig heeft bij het uitvoeren van een procestaak. Een use case levert een resultaat dat
zelfstandig waarde heeft voor de gebruiker en geeft aan hoe de gebruiker en het systeem
samenwerken om dat resultaat te behalen.
Onjuist gebruik van requirement:
- Eis is geen synoniem van requirement.
- Een technische beperking is geen requirement, maar stelt wel eisen aan de implementatie van de
requirement.
- Een ontwerpbeslissing is een beslissing over de manier waarop de requirements
geïmplementeerd worden.
- Een bedrijfsregel is een regel die een bepaald aspect van de business definieert of beperkt.
Hs. 3 Requirements engineering
Voordat een organisatie besluit om een software ontwikkeltraject te starten is er behoefte aan extra
geautomatiseerde ondersteuning, bijvoorbeeld omdat er aanpassingen in de interne
bedrijfsprocessen nodig zijn.
Relatie tussen requirements engineering en andere vakgebieden:
- Projectleiding: ontwikkeling
- Systeemontwerp: ontwerp
- Realisatie: implementatie
- Test: specificaties
Het doel van requirements engineering is het tot stand brengen en in stand houden van
overeenstemming tussen de opdrachtgever, de medewerkers en het software ontwikkelteam over
de requirements. Requirements development resulteert in een baseline met daarin de
overeengekomen requirements.
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper SamenvattingenTBK. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €4,69. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 53068 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen