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. In de derde druk zijn nog eens vier hoofdstukken met IT onderwerpen toegevoegd. Hiermee is het aantal bladzijden ten opzichte van de tweede druk bijna verdubbeld. Het boek wordt hiermee steeds meer een boek voor automatiseerders. Het blijft echter ook toegankelijk voor niet automatiseerders. Zeker de eerste 17 hoofdstukken. Er is in de derde druk als uitbreiding opgenomen hoe requirements voor data, databases, business intelligence en processen uitgewerkt worden. Behalve uitgebreid in te gaan op ‘niet functionele’ requirements is voor het opstellen van functionele requirements opgenomen hoe je een datamodel opstelt, hoe je stermodellen maakt en hoe je een procesmodel opstelt.
• Productinformatie
  Binding : Paperback
  Distributievorm : Boek (print, druk)
  Formaat : 170mm x 240mm
  Aantal pagina's : 286
  Uitgeverij : Educom
  ISBN : 9789082888041
  Datum publicatie : 11-2021
  
• 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’. • Hoofdstuk 24 gaat in op data requirements. Voor het kunnen specificeren van functionele data requirements is een methode opgenomen voor het opstellen van een datamodel met uitwerkingen in de ISO notatie en de veel gebruikte IE notatie. Voor het vinden van de juiste BI data is beknopt opgenomen hoe deze data met de BEAM* aanpak gezocht kunnen worden. Daarnaast zijn ook uitgebreid ‘niet functionele’ data requirements aan de orde. • Hoofdstuk 25 gaat in op database requirements. Er is enige overlap met data requirements, maar verder staan database requirements op zichzelf. Er zijn naast functionele database requirements ook heel veel ‘niet functionele’ requirements voor databases aan de orde. Die gaan onder andere over database omgevingen, hoe ze gebruikt moeten kunnen worden, welke performance verwacht mag worden en uitwisselbaarheid met andere database omgevingen. • Hoofdstuk 26 gaat over requirements voor Business Intelligence en Business Intelligence omgevingen. Besproken wordt hoe de architectuur van Business Intelligence omgevingen zou kunnen zijn ingericht en welke requirements daaraan gesteld kunnen worden. Ook de requirements voor database structuren voor dit soort omgevingen komen aan de orde, zoals voor stermodellen en data vault. Ook komt aan de orde de wijze waarop de structuur moet worden opgezet om historie bij te houden. • Hoofdstuk 27 gaat in op requirements voor processen en workflows. Voor de functionele requirements is een uitgebreide uitleg opgenomen over hoe je procesmodellen moet opstellen. Aan de orde komen procesmodellen in de vorm van decomposities, IDEF0 procesmodellen en workflow diagrammen.
• Reviews (0 uit 0 reviews)
  Wil je meer weten over hoe reviews worden verzameld? Lees onze uitleg hier.