1. Requirements Functional requirements  Use-cases
Actors and use cases
Use-case diagram
Brief notation
Prioritization
Fully dressed notation

2. Requirement specification
A requirement specification can be made up of the following parts:
The functionality of the IT system expressed as use-cases
The data that the IT system have to register
Non-functional requirements
Requirements regarding usability, reliability, performance, supportability
Features not expressed as use-cases – like a report generation
We now concentrate on bullet 1. – use-cases

3. Requirement process
Step 1: Identification of tasks and workflows, identifying use cases through the development of event tables (AS IS and TO BE) and evaluation through prototyping
Step 2: Development of use case diagram
Step 3: Description of the use cases
Step 4: Developing a domain model showing classes (concepts), attributes, and associations between them
Step 5: Development of system sequence diagrams and operation contracts

4. What is a use case?
A use-case describes a working procedure for a specific actor/user of an IT system.
A use-case is used to show the interaction between actor and IT system
Functional requirements as use-cases outline, in what way the IT system are going to support the user

5. Workflows
The company's task and the order they are processed in are the workflow
Some workflows are more critical than others, and it’s the critical that are in focus
In a company selling product to customers, it is interesting to know when the orders are ready for delivery and when the customer had paid.

6. A customer-order workflow in UML

7. Description of workflow
Description of customer-order workflow (scenario)
Our shop assistant register the wanted goods and customer information on an order note. The order note is handed to the stock. An invoice is send to the customer. When our stock employee recieves the order note, he finds the goods, packs them and makes them ready for shipping. Every morning the carrier comes and collects the packages, deliver them to the customers who sign a reciept. A few days later the bookkeeping recieves payment. The bookkeeping notes that the payment period have been met.
Register order Shop assistant
Pack order Stock employee
Deliver order Carrier
Recieve payment
Accountant

8. A customer-order workflow with actors

9. Find use cases Two approaches: We have chosen to use an event table
Actor and tasks
Events and use cases
We have chosen to use an event table
Have all use cases been found?
All those relating to the management of the business such as a customer relationship - both "happy days" and cancellations
All those who are a condition for the business to run
Could be that inventories are recorded and updated
Handling of security, etc.
Does the use-case provides an observable value?
Coffee break test!
Management test

10. Event table TO BE, Customer – order business
Actor
Use case
Steps in use case
Customer places an order by phone
Shop assistant
Register order
Register that wanted products bought Register customer information Save the order Send out order form and invoice
Warehouse receives the order
Employee Stock
Pack order
Choose the order from list of order Register that a product is packed Write down stock Register that the entire order is packed
Order prepared
Carrier
Deliver order
Print the waybill with the order to be delivered Register an order has been delivered
Customer pays
Accountant
Register payment
Display the Notification that the amount is paid Register the order is completed
Time for payment exceeded
System
Send out reminder
Compare payment deadline with the current date Automatically sends a reminder if payment is late

11. Good or Bad Use-cases? Criteria:
Completed; goal fulfilled; coffee break
Small create, read, update and delete tasks are gathered in one description (CRUD)
Check: Are all tasks included?
Are all actor tasks described?
Are critical tasks included?
Can all data be created, read, updated and deleted (CRUD)?
Good or bad?
Administration of books
Register the title of a book
Loan of book
Update reservation
Delete reservation

12. What is an actor?
An actor is something with behaviour that interacts with the IT system:
Person identified as a user role, e.g. cashier, salesman, stock employee
Another computer system
A device e.g. a temperature sensor
Primary actor: Has user goals fulfilled through use-case

13. Use case diagram
Use cases from the event table is displayed in a UML use case diagram
Use case diagram is a graphic model of the system's functionality and communication with the stakeholders
includes:
Use cases
Actors
Associations between use cases and the actor(s) who interact with the use case
delimitation

14. Use case diagram for customer - order
Small use cases can be assembled in CreateReadUpdateDelete (CRUD) use-cases
Lets make the diagram in UMLet

15. Description formats for use cases
Overall textual descriptions in a short summarized form (customer-facing)
Brief: textual description of a happy days scenario
Casual: variations of happy days scenario
Detailed descriptions of the "expanded" form - fully dressed
The steps in the use case and variations thereof are described in detail
A graphical representation of the interaction of the use case in a system sequence diagram - SSD (in a later session)
All use cases described in brief and / or causal. Only the critical described fully dressed with associated solid state and contracts

16. Use case description, Brief
Template for brief description:
Use case: Name of the use case
Description: An overall but complete description of who initiates the use case, the expected system actions and responses of this that adds value to an actor
Input to the system actions retrieved from the event table: Steps in use case

17. Example: Brief use case description
Brief description Use case: Register Order
A customer approaches to place an order. Shop assistant uses the system to create a new order, add items to the order, track customer information, store the order and print the order form and invoice. Along the way, the system displays details about the goods, subtotal and total.
Event
Use case
Steps in use case
Actor
Customer places an order
Register order
Add desired items Register customer Save the order Print the order form and invoice
Shop assistant

18. Use-case description Casual
In addition to the brief form there can be added alternative scenarios in the Causal format
Examples of alternative scenarios for the use-case: Register Order:
If the goods are sold the system indicates when new products are expected home, so the customer can be informed
If the customer wishes to pay immediately

19. Prioritazation af use-cases
According UP designing, implementation and testing is done in small chunks through a number of iterations (steps)
The highest priority and most complex use-case is analysed, designed and coded in the first iterations (so one must assume that the rest also can be made) The steps in development of use-cases are:
Use cases identified and they appear in a UML use-case diagram
Then, they are described in brief or casual form.
On this basis, use cases are prioritized (based on architecture-related importance, risks and business value), and then the most important are analysed for the design of prototypes and "fully dressed" descriptions.

20. Use-case description: ”Fully dressed”
Detail storyline in use-case in a number of steps (flow of events) consisting of:
Actor action<-> System response
Add actor, pre- and post-conditions
Use essential and black box style
Brief- and/or casual descriptions and mock ups are used as the basis for the fully dressed descriptions.

21. Example: Use case: Register Order
Mock UP’s:
1. Start register goods
Flow of events in fully dressed description
Use-case starts with a customer inquiry over the telephone to order goods
Shop assistant begins a new order the system creates a new order
Shop assistant Specifies the ID of the desired products
The system returns the item description, price, sub total and running total
Shop assistant adds the desired number of items
The system adds the items
Steps 4-7 are repeated until all items are added
Shop assistant specify delivery information
The system validates the data and record customer
Shop assistant completes order
The System saves the order
Shop assistant request for an order form and invoice
The system prints a confirmation
UI design details (buttons and fields) should not be included in the description! It is up to the designer to determine
2. Response good nr 1231