Cum să scrieți cazuri de utilizare eficiente

Publicat: 2015-08-21

Cum să scrieți cazuri de utilizare eficiente

Cazurile de utilizare sunt utilizate pe scară largă pentru a documenta logica de afaceri și procesele de sistem. Dar există o mulțime de opinii despre dacă sunt utile și cum ar trebui să fie structurate. În unele proiecte, dezvoltatorii nu se uită niciodată la cazurile de utilizare spunând că sunt verbose sau că într-adevăr nu înțeleg prea multe din ele. Ce poate face un analist de afaceri pentru ca cazurile de utilizare să fie cu adevărat eficiente?

Majoritatea dintre noi sunt conștienți că cazurile de utilizare descriu procesul de afaceri și sunt specificațiile pentru interacțiunile dintre sistem și actori pentru anumite obiective. Un document de caz de utilizare este diferit de un document de cerințe și nu este același cu un document de proiectare.

Să ne uităm la cele două exemple de cazuri de utilizare pentru cerință. Care dintre ele crezi că este una mai bună.

Exemplu – 1

Utilizați detaliile cazului Comentarii

Nume caz de utilizare – Comandați bilete

Numele este bun. Oferă în mod clar o indicație a cazului de utilizare

Scop – Clientul rezervă cu succes bilete pentru meciul de fotbal pe site

Descriere - Actorul vizitează site-ul web, vizualizează
program, selectează meciul
și locuri, cărți
bilet și face plata pentru meciul de fotbal

Scopul și descrierea sunt clar menționate.
Acest lucru îi va ajuta pe designeri
iar dezvoltatorii înțeleg ce este
scopul documentelor și codului lor de proiectare

Actori – Client, Reprezentant Serviciu Clienți
Condiții preliminare – Sistemul este în funcțiune.
Trigger – Actorul a accesat sistemul pentru a rezerva bilete.
Post-Condiție – Actorul poate rezerva bilete. Sistemul actualizează informațiile.

Toate celelalte detalii de caz de utilizare, cum ar fi Actori,
precondiții, condiții post și
declanșatorul sunt menționate care vor ajuta
proiectarea și dezvoltarea aplicației mai ușor.

Fluxul principal – Pași

  1. Actorul accesează site-ul web și selectează să rezerve bilete
  2. Sistemul afișează informațiile de rezervare
  3. Actorul confirmă detaliile meciului (Mai multe detalii în specificația UI)
  4. Actorul confirmă detaliile scaunului (Mai multe detalii în Specificațiile UI)
  5. Sistemul confirmă disponibilitatea
  6. Sistemul prezintă un formular pentru a obține informații despre utilizator
  7. Actorul oferă informații despre utilizator (Detalii într-un alt caz de utilizare)
  8. Sistemul prezintă un formular pentru informații de plată
  9. Actorul oferă informații de plată (Detalii într-un alt caz de utilizare)
  10. Sistemul confirmă detaliile și oferă un ID de rezervare
  11. Actorul salvează biletul
  12. Actorul iese din sistem.

Cazuri de utilizare incluse

- Plateste

– Generați ID rezervare

Cazuri de utilizare extinse

– Generați o notă de eșec de plată

– Tipărește biletul

Pașii din fluxul principal sunt clari dar
Detaliile UI sunt omise. Detalii UI în cazul de utilizare
în ceea ce privește alegerea locurilor și potrivirea
selecția poate face cazul de utilizare greoi.
Cazul de utilizare arată clar ce trebuie să facă actorul și ce va face sistemul
Procesul de plată este detaliat în a
caz de utilizare diferit, astfel încât sarcinile să poată fi
ușor de împărțit în diferite componente de proiectare.
Sunt denumite cazurile de utilizare incluse și extinse
astfel încât cineva să poată
consultați-le pentru mai multe detalii.

Flux alternativ

-anulează biletele

  1. Actorul anulează tranzacția
  2. Sistemul anulează tranzacția

Flux de excepție

- Biletele nu sunt disponibile pentru meciul selectat/ locurile selectate

1. Sistemul afișează un mesaj de eroare

Fluxurile alternative și de excepție sunt detaliate.

* Cazul de utilizare poate fi mai detaliat în ceea ce privește referințele și fluxurile alternative și de excepție. Acest exemplu este pentru a evidenția ceea ce ar trebui să fie cuprins într-un caz de utilizare bine scris.

Exemplu – 2

Utilizați detaliile cazului Comentarii

Nume caz de utilizare – Comandarea biletelor

Numele nu este din perspectiva utilizatorului și pare o definiție a procesului de afaceri.

Descriere – Actorul vizitează site-ul, vede programul, selectează meciul și locurile, rezervă biletul și efectuează plata pentru meciul de fotbal

Scopul cazului de utilizare lipsește. Designerii, analiștii de testare și dezvoltatorii nu vor înțelege de ce trebuie dezvoltată această funcționalitate.

Actori – Client, Reprezentant Serviciu Clienți
Trigger – Actorul a accesat sistemul pentru a rezerva bilete.
Post-Condiție – Actorul poate rezerva bilete. Sistemul actualizează informațiile.

Lipsesc condițiile prealabile.

Etapele principale ale fluxului

  1. Clientul accesează site-ul web și selectează opțiunea „Rezervare bilete” „pentru a rezerva bilete
  2. Sistemul afișează lista de potriviri într-un meniu vertical.
  3. Reprezentantul Serviciului Clienți selectează din meniul derulant
  4. Sistemul afișează detaliile scaunului într-o hartă a scaunelor
  5. Actorul alege locurile. Dacă locurile nu sunt disponibile și este afișat un mesaj de eroare.
  6. Actorul oferă detalii de plată
  7. Actorul rezervă biletul, altfel anulează biletul.
  8. Sistemul generează un ID de rezervare folosind prenumele clientului și un număr de 4 cifre generat aleatoriu

Cazuri de utilizare incluse
- Plateste

În pașii cazului de utilizare, există câteva referințe la elemente reale ale interfeței de utilizare care pot deruta cititorul. Fluxurile alternative sunt scrise în fluxul principal, ceea ce face dificilă înțelegerea întregului proces.
Actorul este menționat prin multe nume – „Client, Actor și Reprezentant Serviciu Clienți, ceea ce este confuz”.
Generarea codului de rezervare este explicată aici, deși nu este de interes pentru actorii legati de comandarea biletelor.
Nu există fluxuri alternative, fluxuri de excepție și nicio mențiune a tuturor cazurilor de utilizare aferente.

Acest caz de utilizare nu are claritate și detalii și nu va ajuta echipa să dezvolte corect funcționalitatea.

Ce ar trebui să fie într-un caz de utilizare Ce nu ar trebui să fie într-un caz de utilizare
  1. Nume
  2. Descriere/Obiectiv
  3. Condiții prealabile
  4. Trigger
  5. Flux de bază și fluxuri alternative
  6. Scenarii de excepție
  7. Condiții post
  8. Cerințe speciale, dacă există
  9. Link către detaliile UI și alte modele/diagrame conexe
  1. Detalii de implementare
  2. Prelucrare internă
  3. Cerințe nefuncționale
  4. Detaliile interfeței cu utilizatorul trebuie făcute simultan cu cazurile de utilizare, dar într-un document separat

.

Câteva sfaturi de urmat pentru a scrie cazuri de utilizare utile:

  1. Scrieți pașii cazului de utilizare din perspectiva actorului.
  2. Cazurile de utilizare nu trebuie să aibă detalii de design și arhitectură. Ar trebui să se concentreze asupra procesului de afaceri.
  3. Este mai bine dacă pașii din cazul de utilizare sunt scrieți într-un mod ordonat în timp
  4. În funcție de cerințe și complexitate, decideți dacă operațiunile CRUD (Creare, Read, Update and Delete) trebuie păstrate în cazuri de utilizare separate sau pot fi combinate într-unul singur.
  5. Este important să oferiți referințe la și de la fluxuri alternative, fluxuri de excepție, cazuri de utilizare incluse și cazuri de utilizare extinse, astfel încât designul afacerii să fie complet.
  6. Alegeți un șablon (definit de proiect, definit de companie sau oricare detaliat) și urmați structura pentru toate cazurile de utilizare.
  7. Este important să existe diagrame de cazuri de utilizare.
  8. În Agile, avem povești de utilizatori pentru a capta cerințele. Poveștile utilizatorilor pot fi detaliate folosind cazuri de utilizare lean într-un mod iterativ.
  9. Validările ar trebui să fie detaliate.

După ce ați scris un caz de utilizare, puneți aceste întrebări și este un caz de utilizare eficient dacă răspunsul este „Da” la toate întrebările -

  1. Va ști utilizatorul când va fi executat fluxul de afaceri prezent în cazul de utilizare?
  2. Este clar cine va efectua ce pas al cazului de utilizare?
  3. Este descrierea logicii de afaceri astfel încât să existe suficiente informații pentru analiză, proiectare, dezvoltare și testare?
  4. Există referințe adecvate de la fluxul principal la fluxurile alternative și de excepție?
  5. Există o diagramă de caz de utilizare prezentă?

Cazurile de utilizare sunt o modalitate eficientă de a capta cerințele și de a documenta formal procesele de afaceri dacă acestea sunt bine scrise. Întreaga echipă ar trebui să fie instruită să folosească cazurile de utilizare pentru a-și îndeplini sarcinile. Cazurile de utilizare și diagramele de cazuri de utilizare sunt o modalitate excelentă de a discuta despre procesele de afaceri cu clienții. Este mai bine să aveți un șablon standard de caz de utilizare cu instrucțiuni privind scrierea cazurilor de utilizare. Cazurile de utilizare scrise astfel vor fi apreciate de toți membrii echipei de proiect și părțile interesate.