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

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

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

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

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.

A customer-order workflow in UML

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

A customer-order workflow with actors

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

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

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

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

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

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

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

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

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

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 ...... .......

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.

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.

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