Usecase per requirement?

[sytrusze]

Hoi allemaal,

ik ben bezig met het opstellen van usecases voor een opdracht. Ik heb 15 functionele en 2 niet-functionele requirements.

Is het nu de bedoeling dat ik ook 15 usecases opzet of kan een usecase meerdere requirements bevatten?

Ik heb bijvoorbeeld een functionele requirement:
Req. #4.1: De gebruiker moet de mogelijkheid hebben om de tekst en de bijbehorende feedback op 1 pagina te zien en te plaatsen. (dit is momenteel gescheiden op 2 aparte pagina's, fyi).

Als ik voor deze requirement een usecase zou schrijven, dan is de flow of events wel heel kort...
- Gebruiker gaat naar de homepagina.
- Gebruiker ziet dat tekst en commentaar op 1 pagina staan.

Ik heb ook een andere requirement:
Req. #4.2: De gebruiker moet de feedback kunnen koppelen aan een specifiek gedeelte van de tekst

Als ik van deze requirement een Usecase maak, dan een van de flows zijn:
- Gebruiker selecteert stuk tekst
- Gebruiker krijgt een input veld in beeld
- Gebruiker voert feedback in
dan kan hiervan de output zijn: tekst en feedback zijn de zien op 1 pagina, wat dus meteen req #4.1 omvat.

Kan dit? Of moet er echt PER requirement een usecase zijn?

---------------------
Edit:

Meteen nog een vraag. Ik heb een requirement: De feedback is alleen zichtbaar op de pagina's waarop feedback gevraagd word.

Het is dus de bedoeling dat de moderator per pagina kan aangeven of feedback geven mogelijk is of niet. Is "de moderator kan per pagina aangeven of feedback geven mogelijk is of niet." dan meteen ook mijn usecase die hoort bij deze requirement?

Hartelijk dank alvast!

[ Voor 15% gewijzigd door sytrusze op 01-06-2019 05:49 . Reden: Toevoeging ]

[Rmg]

Normaal gesproken kan een use case naar meerdere requirements mappen. Maar dat hangt soms ook een beetje van welk ontwikkelings methode. Use cases doe je net anders in RUP, agile of waterval.

Sowieso moet je je afvragen waarom je use cases schrijft.

Je 2e vraag lijken beide requirements. Het ene gaat over wat een gebruiker ziet het andere over wat een moderator moet kunnen.

[ Voor 33% gewijzigd door Rmg op 01-06-2019 19:41 ]

[johnkeates]

Ik denk dat je bij dit soort vragen vooral in gedachten moet houden waarom het spul zo bedacht is; requirements, use cases maar ook zaken als activity diagrams enz. zijn bedoeld om een niet-ambigue documentatie voor een software ontwerp te zijn. Dat houdt in dat als jij zeker weet dat het duidelijk(er) is op manier A vs. manier B, je dus al kan beslissen of dat wel of niet moet.

Ik zou zelf RQ 4.1 al splitsen en context koppelen aan RQ 4.2:

RQ 4.1.1: Als gebruiker wil ik de feedback gekoppeld aan de test op een pagina kunnen zien
RQ 4.1.2: Als gebruiker wil ik op de pagina van RQ 4.1.1 feedback kunnen wijzigen
RQ 4.1.3: Als gebruiker wil ik op feedback aan specifieke delen van tekst kunnen koppelen tijdens een wijziging als beschrijven in RQ 4.1.2

Als iemand over 5 jaar dan wil weten waarom je op pagina X de tekst, feedback en koppelingen kan CRUD'en, dan kan je dat terugvinden in RQ 4.1 en de sub-RQ's daar in.

Aan de andere kant, stel dat het een schoolopdracht is voor een vak dat puur over het schrijven van een SRS gaat, of slechts de FO delen, dan zal je eerder gewoon moeten volgen wat in de opdrachtomschrijving staat. Staat daar in: maak een FO aan de hand van X PO-interviews met de AUP-SDLM methode, dan zal AUP er vast wel een mening over hebben hoe gedetailleerd en hoe zelfstandig een requirement is.

Stel dat et eerder een opdracht is waarbij je je skills m.b.t. requirements engineering moet aantonen, dan zou ik eerder zelf de vrijheid nemen om de requirements zo te documenteren dat ze niet voor meerdere interpretaties vatbaar zijn.

[ Voor 25% gewijzigd door johnkeates op 01-06-2019 19:44 ]

[sytrusze]

Hartelijk bedankt beide voor jullie antwoord, hier kom ik wel mee uit de voeten.

@johnkeates Het gaat inderdaad om een afstudeeropdracht, waarbij ik mijn skills moet aantonen.

Nog een andere vraag: De feedback moet opgeslagen/opgehaald kunnen worden in/uit de database.
- Lang verhaal, maar de manier waarop het werkt is: er wordt een cronjob uitgevoerd om x aantal minuten die de feedback ophaalt en opslaat in de database.
Hoe maak ik hier een use case van? Gezien er geen menselijke actoren zijn...kan je hier uberhaupt een usecase van maken?

Bedankt nogmaals!

[johnkeates]

Nee, dat is een RQ or NFRQ, dat is een implementatie detail; iets wat je misschien in je TO zet. Aan de andere kant: dit is niet iets wat ik zou doen; zodra je met een cronjob dingen aan elkaar moet hacken begint het een beetje te kriebelen, maar het kan natuurlijk zo zijn dat de brondata niet op een andere manier te krijgen is en er geen triggers/hooks voor handen zijn...

[sytrusze]

Hoi @johnkeates ,

sorry, ik had je antwoord destijds wel gelezen maar helemaal vergeten te reageren...bij deze, bedankt!