Dit is een door mij gemaakte samenvatting van het boek:
Handboek Requirements - Brug tussen Business en ICT //
De volgende hoofdstukken worden in de samenvatting behandeld: H1, H2, H5, H6 t/m H9 en H11 t/m H17 en H19 t/m H21
Requirements zijn er enerzijds om de business optimaal te kunnen ondersteunen en anderzijds om het software-
ontwikkelteam het project te kunnen laten realiseren. Het gaat dan voornamelijk om het afstemmen van de
requirements. De requirements vormen een brug tussen de business en de ICT
Schommelkarikatuur: afstemmen van requirements.
De vijf belanghebbenden van een systeem + waarom zij de betreffende requirements nodig hebben:
1) Opdrachtgever: softwareontwikkeltraject niet zonder reden gestart bepaalde bedrijfsdoelen
halen/problemen op te lossen.
2) Opdrachtnemer: Hij weet hierdoor wat er ontwikkeld moet worden en kan inschattingen gaan maken betreft de
kosten, de planning en het personeel. Hoe beter de requirements, hoe nauwkeuriger de inschatting.
3) Ontwikkelaars: Hierdoor weten de ontwikkelaars waar het systeem aan moet voldoen.
4) Testers: Hierdoor weten de testers waaraan de te testen software moet voldoen. De gegeven requirements zijn
tevens de norm voor het testen van de software.
5) Gebruikers: Zij weten wat het systeem na het ontwikkelen wel en niet kan. Dit zal de manier van werken
beïnvloeden (prettig of niet prettig).
Als het niet lukt om de requirements te achterhalen, maakt het ook niet meer uit hoe goed je de overige
activiteiten uitvoert.
Requirements globaal gezien: opdrachtverstrekking, projectplan.
Requirements gedetailleerd gezien: detailplanning, ontwerp, bouw, test. Deze ontwikkelactiviteiten
nemen de requirements als vertrekpunt.
De relatieve herstelkosten van een doorwerkfout, betreft de requirements, worden steeds hoger naarmate er meer
activiteiten zijn uitgevoerd met de verkeerde requirements.
3
, Van het totale budget, dat wordt gebruikt voor het ontwikkelen van een systeem/software applicatie, gaat 25%
tot 40% op aan het herstellen van fouten in de requirements.
Drie grote fouten die projecten doen falen/niet succesvol maken:
Gebrek aan gebruikersinbreng, onvolledige requirements/specificaties, veranderende
requirements/specificaties.
Kritieke succesfactoren
Kwalitatief goede requirementsspecificaties; volledig, consistent, eenduidig en valide.
Managen van wijzigingen in de requirements; voorkomt een scope creep (omvang van de te ontwikkelen
software neemt niet toe).
Voldoende gebruikersinbreng; om een intensieve samenwerking tussen de gebruikers en het
ontwikkelteam, betreft de requirements, scherp te krijgen/te houden.
Het belang en de moeilijkheidsgraad van requirements worden vaak onderschat. Dit is een verklaring voor het feit
dat er zoveel softwareprojecten met problemen kampen.
4
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller JeroenHHS. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $3.21. You're not tied to anything after your purchase.
