Functionele eisen vs. use cases

[Anoniem: 111026]

Voor een webapplicatie (betrekkelijk simpel CRM met relaties, adressen, contactpersonen, medewerkers) vraag ik mij af hoe ik de functionele eisen het best kan documenteren. Ik volg overigens geen 'grote methodiek' zoals DSDM of RUP. Toch wil ik een formeel document opstellen voordat ik verder ga met ontwerp.

Er zijn veel vragen waar ik niet uit kom:

1. Hoeveel detail neem je op?
   
   Zeg je bijvoorbeeld dat het overzicht van relaties de naam en het telefoonnummer toont, of zeg je alleen dat er een overzicht van relaties is?
2. Welke functionaliteit beschrijf je?
   
   Zeg je dat het overzicht sorteerbaar is en dat je het kunt filteren op type of zeg je toch nog steeds alleen dat er een overzicht is?
3. Hoe ga je om met CRUD functionaliteit?
   
   Zeg je dat je relaties kunt beheren, of zeg je dat ze kunt inzien, toevoegen, bewerken en verwijderen?
4. Wie gebruikt gewoon use cases als functionele eisen?
   Zo ja, hoe ga je dan om met details? Het sorteren van relaties lijkt me geen aparte use case. Maar waar benoem je dit dan?

Tips en ervaringen zijn zeer welkom. Ik heb moeite om te beginnen omdat ik telkens twijfel of ik wel de juiste aanpak heb.

[Meekoh]

volgens mij komen je functionele eisen gewoon in je functioneel ontwerp. Daar documenteer je ze zo gedetailleerd mogelijk! Want indien men later nog extra wensen hebt dan kan jij zeggen, maar ik heb dit gebouwd zoals het toen gevraagd is. Dus alles wat je daarna extra of anders wil hebben word gewoon een nieuwe build/release.

[Janoz]

Wat ik vaak doe is wat prototype screenshotjes maken. Dat helpt enorm in het begrip voor meer software leken. Probeer je in het FO trouwens zover mogelijk van daadwerkelijke implementatie details te houden. Dat is meer voor het TO.

Om op je lijstje terug te komen. Bij al die dingen de uitgebreide optie. Bedenk dat een FO een 'juridisch document' is. Aan het einde van het traject kan de functionaliteit gechecked worden tegen het FO. Vaak zie je dat halverwege het traject dingen niet duidelijk geformuleerd zijn en zal de klant ten alle tijden de meest ruime implementatie eisen. Daarnaast kan de klant vaak ineens extra fucntionaliteit gaan eisen. Als je het FO redelijk dicht hebt heb je iig iets waarmee je je grenzen aangegeven hebt en is ook duidelijk te zien wanneer iets meerwerk is (en waarvoor dus extra betaald zou moeten worden of als reden voor het niet halen van de deadline gebruikt kan worden)

[Cyphax]

Anoniem: 111026 schreef op vrijdag 29 september 2006 @ 13:04:
[list=1]
• Hoeveel detail neem je op?

Zeg je bijvoorbeeld dat het overzicht van relaties de naam en het telefoonnummer toont, of zeg je alleen dat er een overzicht van relaties is?

Als je het nergens anders afbakent zou ik dat soort details wel beschrijven.

• Welke functionaliteit beschrijf je?

Zeg je dat het overzicht sorteerbaar is en dat je het kunt filteren op type of zeg je toch nog steeds alleen dat er een overzicht is?

Zelfde als hierboven.

• Hoe ga je om met CRUD functionaliteit?

Zeg je dat je relaties kunt beheren, of zeg je dat ze kunt inzien, toevoegen, bewerken en verwijderen?

CRUD-matrix bouwen, is wel een goed idee. Maar dat is maar een overzicht van wat je in de use cases hebt kunnen beschrijven op zich.

• Wie gebruikt gewoon use cases als functionele eisen?
Zo ja, hoe ga je dan om met details? Het sorteren van relaties lijkt me geen aparte use case. Maar waar benoem je dit dan?

Ik heb dat een keer gedaan maar ik vind het niet bevredigend. Of je moet echt veel tijd in die dingen steken zodat je niets mist.

Tips en ervaringen zijn zeer welkom. Ik heb moeite om te beginnen omdat ik telkens twijfel of ik wel de juiste aanpak heb.

Maak het leesbaar (zoals met screenshots zoals Janoz suggereert) voor de opdrachtgever en zorg dat 'ie het volldige ontwerp accepteert. Met een handtekening eronder.

[Pwigle]

Hoeveel detail neem je op?
Zeg je bijvoorbeeld dat het overzicht van relaties de naam en het telefoonnummer toont, of zeg je alleen dat er een overzicht van relaties is?
Welke functionaliteit beschrijf je?
Zeg je dat het overzicht sorteerbaar is en dat je het kunt filteren op type of zeg je toch nog steeds alleen dat er een overzicht is?

Inderdaad zoals Moshe85 al zegt: Zoveel mogelijk details (wel in het redelijke blijven)
Denk even na over het doel dat je dit opstelt! Je wilt dat beide partijen (opdrachtgever/nemer) precies weten wat er uiteindelijk gaat komen. Je wilt achteraf geen discussie over wat een "overzicht van relaties" is.

Wie gebruikt gewoon use cases als functionele eisen? Zo ja, hoe ga je dan om met details? Het sorteren van relaties lijkt me geen aparte use case. Maar waar benoem je dit dan?

Eigenlijk moet elke functionele eis terugkomen in een use case. Maak van tevoren een excel overzichtje met alle functionale eisen en in welke use case (nummer) ze terugkomen. Dit is handig om te verantwoorden dat je aan alle functionele eisen voldaan heb.
Het sorteren van relaties kan wel degelijk een use case zijn maar je kan hem ook in een andere bestaande use case verwerken.

[Anoniem: 111026]

DaPoztMaster schreef op vrijdag 29 september 2006 @ 13:14:
[...]Eigenlijk moet elke functionele eis terugkomen in een use case. Maak van tevoren een excel overzichtje met alle functionale eisen en in welke use case (nummer) ze terugkomen. Dit is handig om te verantwoorden dat je aan alle functionele eisen voldaan heb.
Het sorteren van relaties kan wel degelijk een use case zijn maar je kan hem ook in een andere bestaande use case verwerken.

Één document met functionele eisen (als in: systeem biedt een overzicht van relaties) en één document met use cases (als in: gebruikers kiest om het overzicht van relaties te zien), dat lijkt me zo dubbel.

En het sorteren van relaties, dat is als use case nogal klein, toch? Dat is letterlijk één keer klikken. Verwerken in een andere use case berust volgens mij meer op toeval, en lijkt me foutgevoelig. Bijvoorbeeld in de use case Bewerk Relatie:

1. Gebruiker selecteert overzicht van Relaties
2. Gebruiker sorteert overzicht op bedrijfsnaam. <!
3. Gebruiker keist om een relatie te bewerken.
4. enz

Ligt het aan mij dat ik dit allemaal zo verwarrend vindt? Weet iemand voorbeelden online van functionele eisen of use cases (ik kom echt veel te veel use cases van pinautomaten tegen namelijk).

[Anoniem: 111026]

Dit is een reden waarom ik het zo verwarrend vind, uit Wikipedia:

quote: http://en.wikipedia.org/wiki/Use_case

In software engineering and system engineering, a use case is a technique for capturing functional requirements of systems...

Over Software requirements Specification (SRS)

quote: http://en.wikipedia.org/wiki/Requirements_analysis

In addition to use cases, the SRS contains functional requirements...

Over functionele requirements

quote: http://en.wikipedia.org/wiki/Functional_requirements

Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that show how the use cases are to be satisfied.

[Pwigle]

Één document met functionele eisen (als in: systeem biedt een overzicht van relaties) en één document met use cases (als in: gebruikers kiest om het overzicht van relaties te zien), dat lijkt me zo dubbel.

Het lijkt me juist overzichtelijk. Hoe weet jij na het maken van al je usecases wel zeker dat je alle functionele eisen verwerkt hebt? Leuke afstudeervraag lijkt me dat
Een overzicht/document van je functionele eisen maken is niet veel werk aangezien een eis meestal maar 1 regel is. Usecases daarentegen zijn niet erg overzichtelijk maar bieden wel meer details over het te ontwerpen systeem.
Kijk niet teveel naar wikipedia, daar raak je soms teveel van in de war.

[Anoniem: 19286]

Anoniem: 111026 schreef op vrijdag 29 september 2006 @ 13:58:
Over functionele requirements
http://en.wikipedia.org/wiki/Functional_requirements
Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that show how the use cases are to be satisfied.
[...]

Dit is volgens mij gewoon een fout op wikipedia. Requirements vertellen namelijk wat het systeem moet doen en niet hoe het systeem dat moet doen, dat is juist het ontwerp. Met requirements probeer je de scope vast te leggen van het systeem. Overigens is use cases een veelgebruikte manier om dit te doen, maar er zijn meer mogelijkheden,

[MBV]

Zou imho beter 'external workings' kunnen zijn: systeem als black-box, en kijken welke output bij welke input hoort. Technical details zijn daarbij wel nodig, wanneer je een formule als technisch beschouwt. Uiteraard horen er geen implementatiedetails in

[dingstje]

Anoniem: 19286 schreef op vrijdag 29 september 2006 @ 21:57:
[...]


Dit is volgens mij gewoon een fout op wikipedia. Requirements vertellen namelijk wat het systeem moet doen en niet hoe het systeem dat moet doen, dat is juist het ontwerp. Met requirements probeer je de scope vast te leggen van het systeem. Overigens is use cases een veelgebruikte manier om dit te doen, maar er zijn meer mogelijkheden,

Dus een voorbeeld zou dan kunnen zijn:

Functional requirement: de gebruiker moet relaties kunnen sorteren op elke kolom.

Mogelijke use case:

• De gebruiker opent het overzicht van de relaties
• De gebruiker klikt op de kolom 'Naam', de relaties worden alfabetisch gesorteerd op naam
• De gebruiker klikt nogmaals op de kolom 'Naam', de relaties worden omgekeerd alfabetisch gesorteerd op naam

Andere mogelijke use case:

• De gebruiker opent het overzicht van de relaties
• De gebruiker klikt in de select box met label 'Sorteren Op' op 'Naam' en bij Sorteervolgorde op 'Oplopend'
• De gebruiker klikt in de select box met label 'Sorteren Op' op 'Naam' en bij Sorteervolgorde op 'Aflopend'

[Anoniem: 19286]

De meningen verschillen daar nog wel eens over, wat nou een 'goede' use case is en wat een 'slechte'. Imho mag een use case geen implementatie-specifieke termen bevatten, zoals select-box, etc. Dit vertelt juist hoe het systeem gaat werken en met requirements wil je puur beschrijven wat het moet doen. In jou geval zou ik zoiets als het volgende doen:

Use Case: Genereer relatie-overzicht
Actor: Gebruiker (Dit is in principe wel erg algemeen, beter is bijv medewerker, etc)
Basic Course Of Events:
1. Gebruiker navigeert naar relatie-overzicht
2. Systeem toont relatie-overzicht op alfabetische volgorde

Dit is eigenlijk je basis use-case, en deze kan je dan eventueel nog uitbreiden (extends) met een andere use, zoals Sorteer relatie-overzicht, waar je dan in beschrijft op welke manieren een gebruiker de gegevens kan sorteren.

Een erg goed boek over use cases is:
Use Cases - Requirements in Context
Daryl Kulak & Eamonn Guiney
Het boek geeft duidelijke voorbeelden hoe het wel moet, maar ook hoe het niet moet en veel gemaakte fouten. Kortom, een aanrader als je serieus met use cases aan de gang wil.