Requirements Functional requirements  Use-cases

1. RequirementsFunctional 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-orderworkflow in UML

7. Description of workflow Description of customer-orderworkflow (scenario) Our shop assistant register the wantedgoods and customer information on an order note. The order note is handed to the stock. An invoice is send to the customer.Whenourstockemployeerecieves the order note, hefinds the goods, packsthem and makesthemready for shipping.Every morning the carriercomes and collects the packages, deliver them to the customerswho sign a reciept.A fewdayslater the bookkeepingrecievespayment. The bookkeeping notes that the paymentperiod have beenmet. Register order Shop assistant Pack orderStockemployee Deliver order Carrier Recievepayment Accountant

8. A customer-orderworkflow with actors

9. Find use cases • Two approaches: • 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

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.

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. Prioritazationaf 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. Mock UP’s: 1. Start register goods Example: Use case: Register Order 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 orderthe 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