SISp 2.2 Soorten requirements

In de SISp methode verdelen we de requirements in een aantal categorieën.  Deze categorieën hebben we nodig om later een goede keuze te kunnen maken.

De categorieën:

* Business requirements,
De wens van de organisatie is de start van het project. Definieer deze wens(en) duidelijk en ondubbelzinnig.

* User requirements,
Welke wensen heeft de gebruikersorganisatie, 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 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 database  of communiceren via bepaalde protocollen? Software requirements omvatten de technische kaders van dit project.
Zorg ervoor dat je bij het vastleggen van de requirements onderscheid maakt 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 het aan te schaffen pakket 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 dat inkomende post niet meer kwijt raakt (minder risico, hogere omzet)

User requirements

De user requirements zeggen iets over wat de gebruiker met het system moet kunnen doen. De activiteiten en processen die de gebruikers met het pakket moeten uitvoeren. Veel user requirements kunnen worden geput uit procesbeschrijvingen en werkinstructies.
Voorbeelden van user requirements zijn;
* Kan relatiegegevens ophalen uit relatiesysteem en overnemen in een document
* Het poststuk moet gelokaliseerd kunnen worden 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 nog veel gedetailleerder, in de context van de SISp methode, dus bij de selectie van een standaardpakket kan worden volstaan met globalere beschrijvingen van de software requirements. We hoeven niet in te gaan attribuut beschrijvingen en datastructuren. Deze zijn immers al in het pakket aanwezig en hoeven niet geprogrammeerd te worden.
Bij het vastleggen van de software requirements is het van belang onderscheid te maken tussen functionele en niet functionele requirements.

Functionele requirements

Functionele requirements beschrijven de concrete functies die een systeem moet kunnen uitvoeren. Zonder deze functies zal het systeem niet onze doelstelling kunnen vervullen en wordt het uitgesloten voor selectie.
Voorbeeld van functionele requirements:
* Het systeem moet na iedere bestelling een ontvangstbevestiging versturen met informatie over de bezorgtermijn.
* Het systeem moet een overzicht met openstaande bestellingen genereren.
* Het systeem moet een overzicht met voorraadinformatie genereren.

Niet  functionele requirements

Niet functionele requirements beschrijven de kwaliteitseisen die aan het hele systeem worden gesteld. 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.

Randvoorwaarden

In de randvoorwaarden worden de technische kaders beschreven voor het aan te schaffen pakket. Hier worden minimaal de volgende aspecten beschreven:
* Op welk operating system moet de software kunnen draaien.
* Welke drivers/api´s  gebruikt het systeem
* Zijn er eisen t.a.v. de gebruikte browser
* Op welke database moet de software kunnen draaien
* Wat zijn de eisen ten aanzien van uitwisselingsprotocollen

Boeken over dit onderwerp

Exam Ref 70-346 Managing Office 365 Identities and Requirements

Auteur: Orin Thomas
Prepare for Microsoft Exam 70-346-and demonstrate your real-world mastery of the skills needed to provision, manage, monitor, and troubleshoot Microsoft Office 365 identities and cloud services.
Europrijs: 38,95
Bestellen

The IT4IT™ Reference Architecture, Version 2.1

Auteur: Andrew Josey
This Pocket Guide provides a concise introduction to the IT4IT™ Reference
Architecture, Version 2.1, an Open Group Standard. The IT4IT standard provides a
vendor-neutral, technology-agnostic, and industry-agnostic reference architecture for
managing the business of IT, enabling insight for continuous improvement.
This Pocket Guide is based on the IT4IT Reference Architecture Version 2.1. What’s
more, it’s authoritative with material derived from the official IT4IT documentation
and contributions from members of the IT4IT Forum.
The audience for this Pocket Guide is:
* Individuals who require a basic understanding of the IT Value Chain and IT4IT
Reference Architecture
* IT Professionals who are responsible for delivering services in a way that is
flexible, traceable, and cost-effective
* IT Professionals / Practitioners who are focused on instrumenting the IT
management landscape
* IT leaders who are concerned about their operating model
* Enterprise Architects who are responsible for IT business transformation
Topics covered include:
* An introduction to the IT4IT Reference Architecture, the structure of the IT4IT
standard, and the positioning of the IT4IT standard in the standards landscape
* The IT Value Chain and IT4IT Reference Architecture concepts, including Value
Streams
* The Strategy to Portfolio (S2P) Value Stream
* The Requirement to Deploy (R2D) Value Stream
* The Request to Fulfill (R2F) Value Stream
* The Detect to Correct (D2C) Value Stream
* A summary of the differences between the IT4IT Reference Architecture and
ITIL
Europrijs: 16,91
Bestellen

Meer boeken over informatie analyse vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten: Geen
Sidebar