Aantekeningen E-Government (BI-3): Requirements engineering

Dit artikel is onderdeel van mijn openbare aantekeningen die ik heb gemaakt tijdens mijn studie Business IT & Management aan De Haagse Hogeschool.

Arendsen e.a.: Een requirement is een behoefte, doelstelling, eis, wens of beperking aan systeem van belanghebbende om bij te dragen aan bereiken van een doel. De kwwaliteit van de requirements bepaalt in hoge mate:

  • het succes van ICT projecten – 50~70% van fouten in project komt door slechte requirements (Forrester, Standish Group, Wiegers, Carnegie Mellon Uni en Firesmith);
  • de beheerslasten – verhouding van de kosten: project 20% vs beheer 80%.

1. Requirements

Voordelen juiste requirements proces:

  • overeenstemming tussen opdrachtgever en -nemer over wat het systeem moet doen;
  • basis voor de architectuur en ontwerp;
  • basis voor schattingen en planningen;
  • beperken ontwikkelkosten en herstelwerk;
  • referentiekader voor reviews, inspecties en tests;
  • vergemakkelijken de ingebruikname;
  • na project onderkennen van verbeteringen.

Eigenschappen van een requirement:

  • behoefte van belanghebbende;
  • doelstelling van belanghebbende;
  • voorwaarde aan een product;
  • eigenschap van een product.

Typen requirements:

  • business/proces doelen – scope en richting van overige doelen (waarom) → visie & scope document;
  • gebruikers functies – doelen en taken voor uitvoer (wat) → use case specificatie;
  • systeem – eis of beperking (hoe) → systeem requirements specificatie.

Functionele requirements = mogelijkheden die het moet bieden aan belanghebbenden:

  • gedrag;
  • gegevens;
  • foutafhandeling;
  • dynamiek;
  • presentatie;
  • interfaces.

Niet functionele requirements = eigenschap van het systeem:

  • functionaliteit;
  • betrouwbaarheid;
  • bruikbaarheid;
  • efficiëntie;
  • onderhoudbaarheid;
  • portabiliteit.

2. Requirementsontwikkeling

Requirementsontwikkeling = eisen en wensen van systeem systematisch in kaart brengen;

Juist en volledig vastleggen van requirements door:

  1. elicitatie – ontlokken van requirements bij belanghebbenden, expliciet maken dmv:
    1. documenten;
    2. bestaand systeem;
    3. interview
    4. workshop;
    5. observatie
    6. brainstorm;
    7. taakanalyse;
    8. scenario’s;
    9. prototypen.
  2. analyse – vaststellen van de essentie van een requirement:
    1. welk hoger doel dient de requirement;
    2. is de requirement essentieel.
  3. specificatie – vaardigheid om requirements op een overdraagbare manier vast te leggen;
  4. validatie – controleren van specificaties op juistheid, volledigheid en consitentie:
    1. op correcte manier opgeschreven, dmv:
      • review/inspectie;
      • diagrammen/modellen;
      • acceptatietests;
      • handleidingen.
    2. verwoorden requirements behoeften van stakeholders, dmv:
      • walkthrough in groep;
      • use case senario’s;
      • prototype;
      • simulatie.

3. Requirements management

Een requirements juist en volledig verwerken in het systeem door:

  1. intake en identificatie;
  2. traceerbaarheid, door:
    1. bron onderkennen;
    2. herleidbaar naar tussenproduct;
    3. versiebeheer per requirement
  3. wijzigingsbeheer;
  4. verificatie, door:
    1. managementreview;
    2. inhoudelijke review;
    3. inspectie;
    4. walkthrough;
    5. audit.