Soorten requirements bij een SaaS selectie

Er zijn verschillende soorten requirements die we verdelen in een aantal categorieën. Deze categorieën hebben we later nodig om requirements op een goede manier vast et kunnen stellen.

De requirements categorieën:

• Business requirements
  De wens van de organisatie is de start van het project. Definieer deze wens(en) dus duidelijk en ondubbelzinnig.
• User requirements
  Welke wensen heeft de gebruikersorganisatie, dus de mensen die er echt mee moeten werken, t.a.v. het systeem.  Deze wensen zullen een stuk gedetailleerder zijn dan de business wensen. Wat moet het systeem precies doen en wat moeten de gebruikers er mee kunnen.
• Software requirements
  De software requirements gaan dieper in op de user requirements en worden tevens opgedeeld in functionele en niet functionele eisen.
• Technische randvoorwaarden
  Aan welke eisen moet het systeem voldoen. Moet het kunnen draaien op een bepaald platform, gebruik maken van een specifieke externe database of communiceren via bepaalde protocollen? Deze requirements omvatten de technische kaders van dit project.
  Zorg er dus voor dat we bij het vastleggen van de requirements onderscheid maken tussen deze categorieën.

Business requirements

Bij het vaststellen van de business requirements gaan we opzoek naar de doelstellingen die de opdrachtgever, de business heeft gedefinieerd.
De business requirements zijn richtinggevend. Ze beantwoorden de vraag welk doel de aan te schaffen software moet invullen.
Voorbeelden hiervan zijn:

• Alle medewerkers willen toegang hebben tot actuele relatiegegevens (hogere efficiëntie).
• Management wil dat klanten zelf bestellingen via de webshop kunnen doen (minder doorlooptijd, tevreden klanten).
• Management wil bovendien dat inkomende post niet meer kwijt raakt (minder risico, hogere omzet).

User requirements

De user requirements zeggen iets over wat de gebruiker met het systeem moet kunnen doen. Namelijk de activiteiten en processen die de gebruikers met de business software moeten uitvoeren. Veel user requirements kunnen we echter putten uit procesbeschrijvingen en werkinstructies. Uit de verschillende soorten requirements wordt deze als eerste gekozen om een grove software selectie te kunnen maken.
Voorbeelden van user requirements zijn:

• Kan relatiegegevens ophalen uit relatiesysteem en overnemen in een document.
• Het poststuk moeten we kunnen lokaliseren met behulp van statussen.
• Het systeem moet een management informatie genereren.
• Het systeem moet een ontvangstbevestiging mailen aan de klant die een bestelling heeft gedaan.
  Het is van belang dat iedere user requirement te herleiden is naar een business requirement. Is dat niet zo, dan is het geen requirement.

Software requirements

De software requirements gaan in op details. Ze beschrijven ondubbelzinnig wat het systeem moet kunnen doen. Deze requirements zijn bij software ontwikkeling echter veel gedetailleerder dan in de context van SaaS. Bij de selectie van een standaard software oplossing kunnen we namelijk volstaan met meer globale beschrijvingen van de software requirements. We hoeven dus niet in te gaan op attribuut beschrijvingen en datastructuren. Deze zijn immers al in de software aanwezig en hoeven niet geprogrammeerd te worden.
Bij het vastleggen van de software requirements is het echter wel van belang onderscheid te maken tussen functionele en niet functionele requirements.

Functionele requirements

Van alle soorten requirements zijn de functionele requirements de meest aansprekende voor de eindgebruikers. Ze beschrijven namelijk de concrete functies die een systeem moet kunnen uitvoeren. Zonder deze functies zal het systeem niet onze doelstelling kunnen vervullen en wordt het dus uitgesloten voor selectie.
Voorbeeld van functionele requirements:

• Het systeem moet na iedere bestelling een ontvangstbevestiging versturen met informatie over de bezorgtermijn.
• Dagelijks moet het systeem een overzicht met openstaande bestellingen genereren.
• Het systeem moet, ook dagelijks, een overzicht met voorraadinformatie genereren.

Niet functionele requirements

Niet functionele requirements beschrijven de kwaliteitseisen die we aan het hele systeem stellen. Ze zijn minder gedetailleerd dan functionele eisen.
Ze beschrijven niet WAT het systeem moet doen, maar HOE het systeem moet werken. Hier komen onder andere zaken als performance, onderhoud, veiligheid en betrouwbaarheid aan de orde. Maar het kunnen ook eisen zijn die voortvloeien uit wet/regelgeving.
Voorbeeld van niet functionele eisen:

• De gebruiker wil een gebruikersvriendelijk systeem.
• De gebruiker wil dat de schermen binnen 3 seconden worden geladen.
• Het systeem moet alle binnenkomend bestanden controleren op virussen.
• De applicatie moet voldoen aan de AVG.

Soorten requirements en randvoorwaarden

De randvoorwaarden behoren ook tot de soorten requirements. In de randvoorwaarden beschrijven we de technische kaders voor de aan te schaffen software. Het al dan niet kiezen voor een SaaS oplossing ligt vaak in de randvoorwaarden omsloten. Hier beschrijven we minimaal de volgende aspecten:

• Welke drivers/api´s  gebruikt het systeem.
• Zijn er eisen t.a.v. de gebruikte browser.
• Wat zijn de eisen ten aanzien van uitwisselingsprotocollen.

Aanvullend bij private cloud:

• Op welk operating system moet de software kunnen draaien.
• Op welke database moet de software kunnen draaien.

Discussieer mee op LinkedIn.