Activiteit 1.6 Bepalen niet-functionele eisen

Presentatie over: "Activiteit 1.6 Bepalen niet-functionele eisen"— Transcript van de presentatie:

1 Activiteit 1.6 Bepalen niet-functionele eisen
FURPS+ model Functionality Usability Reliability Performance Supportability

2 FURPS+-model + Implementation Interfacing Operations Packaging Legal …

3 Requirements Engeneering
Requirement = een eis; beschrijft “wat” het systeem moet kunnen Het proces dat zich bezighoudt met het bepalen en specifiëren van de services die gebruikers van een systeem verlangen en van de beperkingen waaronder het systeem werkt en zal worden ontwikkeld.

4 Functionele eisen vs niet-functionele eisen
Functionele eisen zijn de services die van een systeem verlangd worden. Niet-functionele eisen zijn de beperkingen die aan de verlangde services gesteld worden.

5 Functionele eisen (voorbeelden)
De gebruiker moet gegevens kunnen opvragen uit alle databases of uit een subset van de databases. Het systeem zal verschilende viewers ter beschikking stellen zodat de gebruiker alle verschillende documenten in het documentenarchief kan lezen. Elk order krijgt een uniek identificatienummer dat de gebruiker kan copiëren naar de vaste opslagruimte van een account.

6 Niet-functionele eisen (voorbeelden)
Het systeem zal geen persoonlijke informatie van de klant aan de operator tonen, behalve diens naam en referentienummer. Alle delivrables zullen worden gedocumenteerd volgens de XYZ-Co-SP-STAN-95 standaard.

7 Activiteit 1.7 - Afsluiten definitiestudie
analysedossier (+ haalbaarheidsonderzoek) goedkeuren prioriteiten bepalen Must have Should have Could have Want to have but … kiezen ontwerpopties make buy help ask for support MoSCoW stuurgroep combinatie

8 MoSCoW-model Ook veel gebruikt in moderne ontwikkelmodellen.
Snelle en voortdurende aanpassingen aan software vereisen dat continu prioriteiten bepaald worden. De klant/gebruiker speelt een cruciale rol. Rational Unified Proces, eXtreme Programming, Iterative Application Development, Dynamic Systems Development Method, …

9 Keuze ontwerpopties MAKE BUY HELP ASK FOR HELP COMBINATIE

10 Make or buy overwegingen
? Interne ontwikkelexpertise en capaciteit + Communicatie met eindgebruiker + Wijzigingen via directe communicatie ? Projectmoeheid ? Documentatie ± Betrokkenheid / kritische ingesteldheid

11 Make or buy overwegingen
BUY (maatwerk) ? Input van eigen organisatie ± Kosten ? Afhankelijkheid ? Communicatie (beslissingen) + Klant is koning

12 Make or buy overwegingen
BUY (standaardpakket) + Kosten - Flexibiliteit + Concurrentie MAKE & BUY Duurzaamheid (hardware, software, OS) Aanpassing/flexibiliteit

13 Pakketevaluatie RFI: request for information Pakketevaluatiecriteria
vragenlijst naar longlist functionele aspecten niet-functionele aspecten (prijs, ondersteuning, referenties) Pakketevaluatiecriteria weighted ranking methode RFP: request for proposal naar shortlist

14 RFI voorbeeld

15 RFI onderwerpen Longlist algemene functionaliteit
faciliteiten voor de applicatie toepassingsarchitectuur gegevensintegriteit data dictionary toegang tot gegevens gebruikersinterface performantie, betrouwbaarheid, beschikb. systeeminterface

16 Weighted ranking method

17 WRM verfijning % i.p.v. Ja/Nee wegingsfactor per categorie
en per item binnen categorie

18 Request for proposal Shortlist Overzicht van het bedrijf
Doelstelling van het project en hoofdobjectieven Contextdiagram E/R diagram Huidige technische infrastructuur Mainframe CPU en periferie hardware LAN en WAN hardware &communicatie architectuur Toekomstige technische architectuur Business statistieken