usecasespecification.template
TRANSCRIPT
Use Case Specification
SUBJECT \* MERGEFORMAT Use Case Specification < Supermarket Manager> Authors: Pop Sebastian
Document Number:
Version: Publish Date:
Record of Processing
No.VersionDateStatusWhoDescription
1
2
3
4
5
6
7
Record of Approval
No.VersionDateWhoDescription
1
2
3
4
5
6
7
Recipients of Document
No.VersionDate of DistributionRecipients
1
2
3
4
5
6
7
Table of Contents
21
1.1Brief Description21.2Primary Actor21.3Stakeholders and Interests21.4References22Flow of Events22.1Basic Flow22.2Alternative Flows22.2.1< First Alternative Flow >22.2.2< Second Alternative Flow >23Special Requirements23.1< First Special Requirement >24Preconditions24.1< Precondition One >25Postconditions25.1< Postcondition One >26Extension Points26.1
27Technology and Data Variation List28Open Questions2
Use Case Specification
1
1.1 Brief Description
Use case: logIn
Level: user-goal level
Primary actor: Angajat
Main success scenario: Angajatul porneste aplicatia si ii este cerut pentru a se autentifica un user si o parola . Angajatul introduce userul si parola corect , sistemul permitandu-i realizarea altor cazuri de utilizare.Acest caz conditioneaza realizarea tuturor celorlalte cazuri de utilizare.
Extensions: Angajatul incearca sa se autentifice utilizand un user sau o parola gresita.Sistemul ii va bloca accesul la aplicatie dandu- un mesaj de eroare.
Use case: logOut
Level: user goal-level
Primary actor: Angajat
Main success scenario: Angajatul paraseste aplicatia prin apasarea butonului de logOut sau prin inchiderea aplicatiei.
Use case: iniating a sell
Level: user goal-level
Primary actor: Angajat
Main success scenario: Angajatul initiaza vanzarea produselor catre client,dupa ce s-a logat in sistem.Vanzarea va fi initiata prin apasarea butonului Initiating.
Extensions:Angajatul nu poate initia vanzarea intrucat nu este logat in sistem
Use case: adding products to sell
Level: user goal-level
Primary actor: Angajat
Main success scenario: Dupa ce vanzarea a fost initiata,casierului ii se permite sa adauge produsele cerute de catre client
Extensions:Nu toate produsele cerute de clienti vor fi gasite in baza de date.Sistemul ii va returna un mesaj de eroareArticol inexistent.
Use case: computing the total price
Level: user goal-level
Primary actor: Angajat
Main success scenario: Daca toate produsele au fost scanate de catre casier,se va genera totalul prin apasarea butonuluiAfisare pret total
Extensions:Totalul va fi realizat in functie de dorinta clientului.Daca unul sau mai multe produse nu au fost gasite in baza de date,alegerea va apartine clientului.Daca asteapta ca administratorul sa furnizeze un cod al produsului sau renunta la produse,totalul fiind facut fara acele produse.
Use case: decreasing the products stock
Level: user goal-level
Primary actor: Angajat
Main success scenario: Dupa ce un produs din stoc a fost vandut,angajatul poate sa modifice stocul respectiv,eliminand produsele vandute.Angajatul va putea face acest lucru,apasand pe butonul Decreasing stock.
Use case: finaliznig the sell
Level: user goal-level
Primary actor: Angajat
Main success scenario: O parte din produse sau toate produsele au fost scanate cu succes.
Use case: issuing an invoice
Level: user goal-level
Primary actor: Angajat
Main success scenario: Odata vanzarea finalizata,se emite un bond de casa care este inamant clientului.
Use case: CRUD on user accounts
Level: user goal-level
Primary actor: Administrator
Main success scenario:Administratorul poate creea cu succes un cont,sa citeasca un cont,sa modifice un cont,sa stearga un cont.
Use case: CRUD on products
Level: user goal-level
Primary actor: Administrator
Main success scenario:Administratorul poate creea cu succes un nou stoc de produse,sa vizualizeze un stoc,sa modifice un cont,sa stearga un cont.
Use case: best selling products
Level: user goal-level
Primary actor: Administrator
Main success scenario:Administratorul intocmeste rapoarte in diferite formate(XML,TXT),despre cele mai vandute produse
Use case: products out of stock
Level: user goal-level
Primary actor: Administrator
Main success scenario:Administratorul intocmeste rapoarte in diferite formate(XML,TXT),despre produsele care nu mai exista in stoc.
Use case: promotion
Level: user goal-level
Primary actor: Administrator
Main success scenario:La fiecare al zecelea client,se poate activa ocazional o promite,constand dintr-o reducere de 50% din suma produselor cumparate.Sistemul va identifica fiecare al 10-lea client si va trimite un mesaj catre casier care va activa promotia.
Use case: send email report
Level: user goal-level
Primary actor: Administrator
Main success scenario:Administratorul va trebui sa trimita rapoarte in deiferite formate(XML,TXT),cu privire la cele mai vandute produse si rapoarte depsre activitatea angajatilor.
1.2 Primary Actor
In acest caz de utilizare avem doi actori: Angajat si Administrator1.3 Stakeholders and Interests
[The list of the stake holders and key interestes in this use-case.]
1.4 References
[Here you put references to other documents or sources of information valid for this Use-Case Specification. One example of such a document/source of information could be a Business Rules document.]
2 Flow of Events
2.1 Basic Flow
2.2 Alternative Flows
2.2.1 < First Alternative Flow >
[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of Events section. Think of the Alternative Flow subsections like alternative behavior( each alternative flow represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.]
Alternative Flow Starts
[Express what starts the alternate flow, what happens, and include a reference to where in the basic flow this alternative flow branches out]
2.2.1.1 < An Alternative Subflow >
[Alternative flows may, in turn, be divided into subsections if it improves clarity.]
Alternative Flow Ends
[Express what happens when the alternative flow ends, and if applicable indicating where in the basic flow the sequence will continue]
2.2.2 < Second Alternative Flow >
[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative flow separate to improve clarity. Using alternative flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
3 Special Requirements
[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use cases event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirements(such as operating systems and environments, compatibility requirements, and design constraints(should be captured in this section.]
3.1 < First Special Requirement >
4 Preconditions
4.1 Userii au aplicatia pe un dispozitiv
4.2 Baza de data sa fie populata5 Postconditions5.1 < Postcondition One >
6 Extension Points
[Extension points of the use case.]
6.1
[Definition of the location of the extension point in the flow of events.]
7 Technology and Data Variation List
< Put here the variations that will cause eventual bifurcations in the scenario>
8 Open Questions
[If there is any open questions regarding the Use-Case described in this document, enter those questions here. Use the following guide for typing in your open questions.]
PAGE