Requirements

Ton de Rooij • Boek • paperback

• Samenvatting
  Aan alles wat je gebruikt stel je eisen (Engels: requirements). Een horloge moet de juiste tijd geven, onder water gebruikt kunnen worden, het bandje mag niet te snel slijten, enzovoort. Dit geldt niet alleen voor dingen die we hebben. Het geldt ook voor software die we gebruiken. Software voor bijvoorbeeld het maken en verwerken van facturen moet kunnen omgaan met lastige veranderingen in te berekenen BTW percentages. Deze software moet niet alleen facturen maken die voldoen aan de wettelijke eisen, een bijbehorende acceptgiro kunnen opstellen, afdrukken, enzovoort, maar moet bij het maken van een creditfactuur (een factuur om een eerdere factuur terug te boeken) het BTW percentage gebruiken dat bij de oorspronkelijke factuur werd berekend, ook als het BTW percentage inmiddels is veranderd. Stel je niet de juiste eisen (requirements), dan krijg je iets anders dan je verwachtte. Bijvoorbeeld een horloge dat niet goed af te lezen is, software voor het maken van facturen die op creditfacturen het nieuwe BTW percentage gebruikt in plaats van het percentage van de oorspronkelijke factuur.
  
  Aan alles wat je gebruikt stel je eisen (Engels: requirements). Stel je niet de juiste eisen, dan krijg je niet wat je verwacht: software die niet de fiscale regels over het berekenen van BTW goed toepast of een horloge dat niet goed af te lezen is. Het boek is primair gericht op informatiesystemen, maar door de voorbeelden ook over andere systemen te laten gaan zijn is hetgeen besproken wordt beter te begrijpen en kan het boek ook voor andere systemen gebruikt worden. De lezer leert via het boek requirements (eisen) voor een (informatie-)systeem te formuleren. Verder leert de lezer onderscheid te maken tussen functionele requirements, niet functionele requirements, en restricties. Requirements moeten getest kunnen worden wanneer het systeem eenmaal ontwikkeld is. Het boek laat zien hoe requirements aangevuld kunnen worden om dit testen mogelijk te maken. Voor een systeem ontstaat soms een enorme berg aan requirements. Het boek geeft aanwijzingen hoe de requirements ingedeeld kunnen worden om overzicht te houden over deze berg aan requirements. Ook geeft het boek aan hoe onderscheid gemaakt wordt tussen requirements en doelstellingen (van de organisatie die het systeem wil hebben) waaraan het systeem moet bijdragen. Er wordt ingegaan op het verschil tussen requirements en oplossingen voor requirements. Requirements management komt aan de orde, het toepassen van requirements, en hoe de kunstfactor een systeem net iets aantrekkelijker kan maken dan andere op basis van dezelfde requirements gemaakte systemen. Tot slot wordt een oefening gegeven, samen met een uitgebreide uitwerking, waarmee de stof van het boek geoefend kan worden. In de tweede druk zijn zes hoofdstukken toegevoegd. Hierin wordt verwezen naar de IREB aanpak, ingegaan op hoe architectuur requirements beïnvloedt, TOGAF een methode om architectuur op te zetten toegelicht, NORA als een voorbeeld van een referentiearchitectuur gegeven, ingegaan op ‘user stories’ en ‘use cases’ als alternatieven voor tekst voor het specificeren van functionele requirements voor informatiesystemen.
• Productinformatie
  Binding : Paperback
  Distributievorm : Boek (print, druk)
  Formaat : 168mm x 240mm
  Aantal pagina's : 164
  Uitgeverij : Educom
  ISBN : 9789082888027
  Datum publicatie : 08-2019
  
• Inhoudsopgave
  • Hoofdstuk 1 beschrijft wat requirements zijn, wat een systeem is, en waarom we de term ‘requirement’ gebruiken in plaats van ‘eis’ of ‘behoefte’. • Hoofdstuk 2 gaat in op waarom we een set aan requirements opstellen. Er wordt een groot aantal voorbeelden gegeven van wat er mis gaat als je voorafgaand aan het maken van een systeem niet eerst requirements opstelt. Er wordt verder aangegeven waarom requirements niet alleen worden opgesteld voor het ontwikkelen voor nieuwe informatiesystemen, maar ook voor het aanschaffen van standaard software. • Hoofdstuk 3 laat zien dat het opschrijven van requirements geen mega science is. Ook laat hoofdstuk 3 zien dat requirements niet altijd als tekst beschreven moeten worden. Een tekening, een foto of een schema zijn vaak niet alleen veel duidelijker en compacter, maar soms onontbeerlijk. Met tekst kunnen we bepaalde requirements niet zinvol beschrijven. • Hoofdstuk 4 behandelt kort het gehele proces van het specificeren van requirements. Alle onderwerpen komen aan bod. Ieder van de hoofdstukken 5 tot en met 15 gaat uitgebreid in op één van de onderwerpen uit hoofdstuk 4. • Hoofdstuk 5 gaat over het beschrijven van de context en het op te lossen probleem alvorens in detail de requirements te specificeren. • Hoofstuk 6 laat zien hoe je kunt beginnen met een overall requirement dat je vervolgens opsplitst in deelrequirements. • Hoofdstuk 7 gaat in op het verschil tussen doelstelling en requirement. Een systeem moet wel bijdragen aan doelstellingen, maar een doelstelling zelf is geen requirement. Dat neemt niet weg dat het goed is de doelstellingen waaraan een systeem een bijdrage moet leveren op te schrijven. • Hoofdstuk 8 gaat in op het verschil tussen oplossing en requirement. Voor het voldoen aan requirements zijn vaak diverse oplossingen mogelijk. Reden om hiertussen een onderscheid te maken. • Hoofdstuk 9 helpt de lezer te herkennen of een requirement een ‘functioneel’ requirement dan wel een ‘niet functioneel’ requirement is. Verder komen ‘restricties’ aan de orde, beperkingen die voor het systeem als geheel gelden. • Hoofdstuk 10 gaat in op ‘testaanvullingen’ voor requirements. Hiermee wordt aangegeven hoe je kunt zien dat aan het requirement wordt voldaan. Deze aanvullingen hebben testers nodig bij het testen van het systeem. • Hoofdstuk 11 beschrijft hoe je overzicht houdt over de soms enorme berg aan requirements. Zo wordt getoond hoe requirements ingedeeld kunnen worden. Bijvoorbeeld naar onderdelen van een systeem, of in geval van informatiesystemen, naar onderdelen van het bedrijfsproces dat met het systeem ondersteund gaat worden. • Hoofdstuk 12 laat ziet wat requirementsmanagement is, waarom het zo belangrijk is, en hoe het aangepakt kan worden. • Hoofdstuk 13 gaat in op het SMART maken van requirements. Dit acroniem is bekend bij alle automatiseerders. Aangegeven wordt hoe het van belang is bij het opstellen en beheren van requirements. • Hoofdstuk 14 gaat in op het toepassen van requirements. Onder andere hoe het hebben van een complete set van requirements een enorme hulp kan zijn bij de aanschaf van standaardsoftware. • Hoofdstuk 15 gaat in op de ‘kunstfactor’. Systemen die iets bijzonders hebben zijn over het algemeen succesvol. Dit hoofdstuk gaat er op in hoe je de ‘kunstfactor’ bewust bij de requirements kunt inbouwen. • Hoofdstuk 16 geeft de lezer de mogelijkheid om de theorie van hoofdstuk 1 tot en met 15 toe te passen. Het hoofdstuk beschrijft een casus en geeft een aantal opgaven. • Hoofdstuk 17 geeft een uitwerking van de opgaven van hoofdstuk 16. Deze uitwerking kan de lezer ook gebruiken als voorbeeld van hoe requirements uitgewerkt worden. • Hoofdstuk 18 gaat in op de IREB standaard voor requirementsmanagement. Uitgelegd wordt wat IREB is en moet worden toegepast. • Hoofdstuk 19 beschrijft welke invloed van architectuur uitgaat op het specificeren van requirements. Daarmee wordt ook het belang aangetoond van het hebben van een uitgewerkte architectuur. • Hoofdstuk 20 geeft een voorbeeld van een methode om de architectuur uit te werken, namelijk TOGAF. • Hoofdstuk 21 geeft een voorbeeld van een zeer uitgebreide referentie-architectuur die een organisatie kan gebruiken indien er geen uitgewerkte architectuur voor handen is. Het gaat om NORA. • Hoofdstuk 22 gaat in op een manier om functionele requirements voor informatiesystem in kaart te brengen, namelijk het gebruik van ‘user stories’. • Hoofdstuk 23 gaat in op een manier om functionele requirements in kaart te brengen die uitgebreider is dan ‘user stories’, namelijk het werken met ‘use cases’.
• Reviews (0 uit 0 reviews)
  Wil je meer weten over hoe reviews worden verzameld? Lees onze uitleg hier.