Fase 2 opstellen van requirements

In dit hoofdstuk zullen de activiteiten worden belicht die tijdens deze fase requirements engineering zijn uitgevoerd. Binnen deze fase zijn de requirements geeliciteerd, geanalyseerd en geprioriteerd. De keuze om requirements engineering te gebruiken is voor het vastleggen (specificeren) van de requirements uit het proces en dat de behoefte van de stakeholders op een correcte en complete manier te vertalen.

Opstellen van requirements

Voor het bepalen van de requirements is de theorie “Succes met requirements” toegepast. Hieruit kwam naar voren dat requirement met verschillende technieken kunnen worden achterhaald. Zo is het eliciteren aan de hand van interviews achterhaald. Tijdens het verwerken van de interview zijn enkele (mogelijke) requirements gelijktijdig bijgehouden. Verder is na het analyse fase van de knelpunten verder gegaan met het deze fase.

De requirements zijn eerst opgedeeld in business, gebruikers- en systeemrequirements.

Naar aanleiding van de analyse van de huidige situatie is duidelijk geworden wat de reden is dat het DIS voor de stakeholder niet efficiënt is.

Daarom is er gekozen om de requirements niet alleen te richten op een bepaald systeem, maar op

kennismanagementproces als geheel. De business, gebruikers- en systeemrequirements zijn gecombineerd met de twee onderdelen van kennismanagementproces. Door een combinatie te maken is het mogelijk om de requirements vanuit twee invalshoeken te bekijken.

Door onderscheid te maken in de requirements is er een verband te vinden tussen de soorten requirements. Hieronder is te zien hoe de requirements ingedeeld zijn.

- Businessrequirements: bijdrage aan heet kennismanagementproces. De businessrequirements heet met namen te maken met het doel van het kennismanagementproces ofwel de ‘ organisatie’.

Voorbeeld van een businessrequirement; Met een documentair informatiesysteem dat voorziet in de informatiebehoefte van de stakeholders zullen de stakeholders tijd besparen in de dagelijkse werkzaamheden.

- Gebruikersrequirements: wordt opgesteld om in business requirments te voldoen De kennismgement onderdelen waaronder het valt zijn ‘technologie’ en ‘organisatie’.

Voorbeeld van een gebruikersrequirement; De stakeholders (de medewerkers) moeten op de hoogte gebracht worden over het laatste nieuws.

- Systeemrequirements: eisen aan het systeem, die de business daaraan centraal stelt. De systeemrequirements heeft vooral te maken met het onderdeel ‘technologie’.

Voorbeeld van een systeemrequirement; Het documentinformatiesysteem beschikt over een Zoekmachine( zoeken naar en in documenten)

Analyseren van requirments

Na de elicitatie zijn de requirements uit de lijst geanalyseerd op de onjuistheden. Voor het analyseren is gebruik gemaakt van een checklist. De checklist is opgesteld met behulp van het boek ‘Succes met de requirements. Met behulp van het boek heb ik verschillende vragen geformuleerd die aansluiten bij de requirementslijst en heb deze voorgelegd bij de bedrijfsmentor of hij het hier mee eens was.

De volgende vragen uit de theorie zijn gebruikt voor de analyse:

- Gaat het hier om een samengesteld requirement dat opgesplitst moet worden in afzonderlijke, elementaire requirements?

- Zijn de requirements op een correcte manier opgeschreven?

- Zijn de requirements implementatiedetail vrij opgesteld? (Arendsen, 2011)

Aan de hand van de vragen zijn de requirement gecontroleerd. Hierdoor heb ik overzicht weten te behouden bij het tijdens het analyseren.

Verder is voorkomen dat er meerdere requirements in een grote requirement geplaatst worden. Hiermee is ook voorkomen dat belangrijke aspecten van de requirement ‘vergeten’ worden.

Met de vraag; Zijn de requirements op een correcte manier opgeschreven? is gecontroleerd of de requirements onder de juiste categorie geplaatst zijn en of deze wel geformuleerd zijn als business-, gebruiker- en systeemrequirements.

Er is een vraag opgesteld om te controleren of de requirements implementatiedetail vrij zijn opgesteld. Voor het marktonderzoek naar verschillende systemen is het belangrijk dat de requirements vrij zijn van

implementatiedetails anders wordt er al geneigd richting een bepaald systeem. Bij het nalopen van de requiqrments bleek dat niet alle requirements elementair waren. De niet elementaire zijn vervolgens opgesplitst zoals min voorbeeld hieronder.

G4A De interne medewerkers willen

zoekopdrachten op alle metadata kunnen in- en uitstellen waar ze wekelijks, dagelijks, maandelijks specifieke informatie ontvangen.

D S

G4B De interne medewerkers kunnen

D

Prioteren van Requirements

Na het analyseren van de requirements zijn deze geprioriteerd. Voor het prioriteren van de requirements is gebruik gemaakt van de MoSCoW methode. Met behulp van de methode is het mogelijk om aan te geven welke requirements in de oplossingen dienen terug te komen.

De requirements zijn op basis van gesprekken met stakeholders geprioriteerd. De lijst is bij de stakeholder medewerkers kennismanagement, de manager van K&T en enkele stakeholders voorgelegd. Uit deze gesprekken hebben de stakeholders hun feedback gegeven.

Conclusie

Uiteindelijk ben erachter gekomen wat de wensen zijn voor het vinden van een geschikte oplossing tijdens het marktonderzoek. Dit proces heb ik er langer over gedaan dan afhankelijk voor was ingepland. Dit mede doordat er rekening gehouden moest worden met planning van diverse stakeholders. Ver waren de

(business) doelen van het proces niet helder waren. De planning is hierdoor aangepast om uiteindelijk niet in problemen te komen aan het aan van het traject.

Verder was het document niet altijd even helder voor de stakeholders waardoor ik vaak enkele aanpassingen moest verrichten. Zo was de lijst aan het begin niet nog helemaal compleet en was per requirements uit de lijst voor de betreffende stakeholders onoverzichtelijk.