Presentation is loading. Please wait.

Presentation is loading. Please wait.

Systems Analysis and Design – Week 4. SAD – Week 4 Finish off last weeks workshop Finish off last weeks workshop Homework review Homework review Recap.

Similar presentations


Presentation on theme: "Systems Analysis and Design – Week 4. SAD – Week 4 Finish off last weeks workshop Finish off last weeks workshop Homework review Homework review Recap."— Presentation transcript:

1 Systems Analysis and Design – Week 4

2 SAD – Week 4 Finish off last weeks workshop Finish off last weeks workshop Homework review Homework review Recap previous material Recap previous material An introduction to Use Cases An introduction to Use Cases Assignment 1 overview and timetable Assignment 1 overview and timetable

3 Week 3 – Interim Task How suitable is the Yorkies project for an Agile Approach? Produce a short bullet-pointed justification to the current managing director of why an Agile Approach should be used in this project. He is familiar with traditional approaches and would like you to emphasise the differences (15 minutes) How suitable is the Yorkies project for an Agile Approach? Produce a short bullet-pointed justification to the current managing director of why an Agile Approach should be used in this project. He is familiar with traditional approaches and would like you to emphasise the differences (15 minutes) You are appointed project manager, from an external software company, with a team of 5 developers - 3 of whom have some experience of developing web- enabled database software in the past. Assume you have all the software and hardware necessary for the development. What would you require Yorkies to provide in order to maximise your chances of project success? Justify to the managing director the resources required (15 minutes.) You are appointed project manager, from an external software company, with a team of 5 developers - 3 of whom have some experience of developing web- enabled database software in the past. Assume you have all the software and hardware necessary for the development. What would you require Yorkies to provide in order to maximise your chances of project success? Justify to the managing director the resources required (15 minutes.)

4 Week 3 – Interim Task From the Yorkies Case Study please identify: 1) A list of stakeholders you would interview. Place these in approximate order of interview appointment. Which might you decide to interview in groups? Where might you hold each interview? 2) The documents and computer files used by the system. For each document identify which stakeholder(s) you would want to discuss this with? Why is this stage important in analysing an existing system? 3) What other techniques might you use at Yorkies to learn about the workings of the existing system and/or decide how the new system should function?

5 Recap Make sure you are clear about the following: Computer systems/System boundaries/Interfaces Computer systems/System boundaries/Interfaces Planned and Agile Systems Development Methods (SDMs) Planned and Agile Systems Development Methods (SDMs) The different sorts of stakeholder and their concerns The different sorts of stakeholder and their concerns Functional and non-functional requirements Functional and non-functional requirements The importance of Requirements Analysis The importance of Requirements Analysis How to investigate requirements How to investigate requirements

6 Simple Use Cases

7 Use Cases Introduction Introduction Introduction Use Cases, Actors and Scenarios Use Cases, Actors and Scenarios Writing Use Cases Writing Use Cases Use Case Diagrams Use Case Diagrams

8 Use Cases Capture the functional requirements of the system Capture the functional requirements of the system Can be used for analysis, implementation, and testing Can be used for analysis, implementation, and testing Widely accepted as a good way to describe systems to users Widely accepted as a good way to describe systems to users Unified Modelling Language (UML) is a use case driven approach but use cases are not object orientated Unified Modelling Language (UML) is a use case driven approach but use cases are not object orientated In simple terms a use case is: In simple terms a use case is: The typical interaction between a user and a computer system The typical interaction between a user and a computer system A formalised textual description A formalised textual description Summarised by diagrams Summarised by diagrams

9 A use case tells a story of reaching a goal (or a set of stories of both getting and failing!) UC 4: “Place an order” 1. The clerk identifies the customer, each item and quantity. 2. The system accepts and queues the order.” Extensions: “1a. Low credit: Clerk takes prepayment” “2a. Low on stock: Customer accepts reduced...”

10 A Use Case Diagram ATM Manager Teller Customer actor communicate use case system boundary The diagram shows use cases and “actors” The diagram shows use cases and “actors” Helps gain overall picture of systems functionality/user requirements Helps gain overall picture of systems functionality/user requirements Show the system boundary Show the system boundary A key to the use cases A key to the use cases Noddy’s Bank arrange loan close account perform transaction open account

11 Actors To understand the system we have to know who the system is for (who will use it) – these are actors To understand the system we have to know who the system is for (who will use it) – these are actors An actor may be a a person (identified by role), an organization or another computer system An actor may be a a person (identified by role), an organization or another computer system Identify Identify who directly uses the system who directly uses the system who maintains the system who maintains the system external hardware used by system external hardware used by system other systems interacting with the system other systems interacting with the system Primary actors (direct users) and secondary actors Primary actors (direct users) and secondary actors

12 Actors (2) Can be one individual taking several roles Can be one individual taking several roles Fred as manager and teller Fred as manager and teller Several individuals taking one role Several individuals taking one role Fred, Mary, Bert are tellers Fred, Mary, Bert are tellers Actors can also be other computer systems / hardware devices Actors can also be other computer systems / hardware devices Might identify actors first then ask what do they need to do Might identify actors first then ask what do they need to do

13 UML definition of a use case “A use case is a coherent unit of functionality provided by a system or class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system.” Also “A description of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to an actor. Usually scenarios illustrate prototypical use case instances. An instance of a use case class.”

14 Scenarios (User Stories) Scenarios (User Stories) A scenario is a specific sequence of actions and interactions between actors and the system A scenario is a specific sequence of actions and interactions between actors and the system Also called a use case instance Also called a use case instance Or a user story Or a user story Each is one particular story of using the system (one path through a use case) for example. Each is one particular story of using the system (one path through a use case) for example. The scenario of successfully purchasing items with a credit card The scenario of successfully purchasing items with a credit card The scenario of failing to purchase items because of a credit card transaction denial The scenario of failing to purchase items because of a credit card transaction denial Can write specific stories – with realistic examples Can write specific stories – with realistic examples Users can write these Users can write these Can be used as a design prototype Can be used as a design prototype

15 Sample User Story for Record Vehicle Return At 4pm 4th June 2005 David Jones arrives in the depot with a 3 ton truck registration W123 XYZ. He presents his booking confirmation to the depot clerk Vijal Singh. At 4pm 4th June 2005 David Jones arrives in the depot with a 3 ton truck registration W123 XYZ. He presents his booking confirmation to the depot clerk Vijal Singh. The depot clerk checks enters the booking no on the system which confirms that the vehicle is expected back by 5pm that day driven by David Jones for FreshFish2U. The depot clerk notes the return vehicle mileage, diesel level on the confirmation form. He inspects the vehicle and notes no damage. These are entered into the system which reports that an additional mileage charge of £75 is required. This is verbally confirmed with the driver, as FreshFish2U are an account customer no payment is required then. Two copies of the vehicle receipt are printed containing details of the additional charge and the driver asked to sign. The depot clerk records the driver’s acceptance and retains one receipt; the other is given to the driver. The depot clerk checks enters the booking no on the system which confirms that the vehicle is expected back by 5pm that day driven by David Jones for FreshFish2U. The depot clerk notes the return vehicle mileage, diesel level on the confirmation form. He inspects the vehicle and notes no damage. These are entered into the system which reports that an additional mileage charge of £75 is required. This is verbally confirmed with the driver, as FreshFish2U are an account customer no payment is required then. Two copies of the vehicle receipt are printed containing details of the additional charge and the driver asked to sign. The depot clerk records the driver’s acceptance and retains one receipt; the other is given to the driver.

16 Identifying Use Cases Will probably be an iterative process Will probably be an iterative process Combination of several approaches Combination of several approaches working with users and other stakeholders working with users and other stakeholders interviews, workshops interviews, workshops asking what each actor wants from the system asking what each actor wants from the system validation and review validation and review does the use case return something of value to the actor? does the use case return something of value to the actor? Granularity questions Granularity questions e.g. “withdraw cash from ATM” or “withdraw cash from ATM using credit card” e.g. “withdraw cash from ATM” or “withdraw cash from ATM using credit card” Levels of use case Levels of use case Boundary or Scope of use case Boundary or Scope of use case

17 Writing use cases (1) Identify the commonest success scenario Identify the commonest success scenario This is easiest to read and understand This is easiest to read and understand Everything else is a modification of this Everything else is a modification of this Capture each actor’s intent and responsibility, from trigger to goal delivery Capture each actor’s intent and responsibility, from trigger to goal delivery Describe the information that passes between them Describe the information that passes between them Number each line. Number each line. Result: a readable description of system’s function

18 Writing Use Cases (2) Write failure conditions as extensions to the use case Usually every step of a use case can fail Usually every step of a use case can fail Note each failure condition separately, after the main success scenario. Note each failure condition separately, after the main success scenario. Result: a list of alternate scenarios.

19 Writing Use Cases (3) For each failure condition, follow the failure till it ends or rejoins For each failure condition, follow the failure till it ends or rejoins Recoverable extensions rejoin main course. Recoverable extensions rejoin main course. Non-recoverable extensions fail terminate the use case Non-recoverable extensions fail terminate the use case Each scenario goes from trigger to completion. Each scenario goes from trigger to completion. Result: Complete use case Result: Complete use case

20 Review: Scenarios run from trigger event to goal completion or abandonment. Use Case – Place an order ScenarioScenarioScenario Item in Stock YesYesNo Customer passes credit check YesNo Complete order Abandon Order

21 Write the recoverable and failure scenarios as “extensions” to the ideal one UC 4: Place an order” 1. Clerk identifies the customer, each item and quantity. Checks stock levels and customer credit 2. System accepts and queues the order.” Extensions: “1a. Low credit: Customer is ‘Preferred’...” “1b. Low credit & not Preferred customer:...” “2a. Low on stock: Customer accepts reduced...”

22 Summary use cases, tasks, and subfunctions link together Sailboat image: User goals are at sea level. advertiseorderinvoice set up promotion reference promotion monitor promotion place order create invoice send invoice identify promotionidentify customer register user identify product project goal Strategic Goals User Goals Subfunctions “ white” “blue” “indigo”

23 Advantages of Use Cases Capture requirements from a users’ perspectives Capture requirements from a users’ perspectives Gets early user involvement Gets early user involvement Simplifies user validation Simplifies user validation Helps manage delivery Helps manage delivery Prioritise use cases to define iterations for delivery Prioritise use cases to define iterations for delivery Estimate % requirements captured and delivered Estimate % requirements captured and delivered Progresses the development Progresses the development Can identify objects (classes) from scenarios Can identify objects (classes) from scenarios Can become the basis of user manuals Can become the basis of user manuals Can become the basis for test plans and test cases Can become the basis for test plans and test cases Improve quality Improve quality Provide good traceability of requirements Provide good traceability of requirements Identifies exceptions earlier Identifies exceptions earlier

24 Use cases make functional requirements readable and reviewable 1) Use cases hold functional requirements in an easy-to-read, easy-to-track, text format. 2) A use case collects how a goal succeeds or fails. A scenario shows one specific condition in a use case 3) Use cases show only functional requirements but can make a framework for non-functional requirements & project details. 4) Use cases provide one tool for systems design but do not address all design needs

25 Assignment 1 – Requirements and Use Cases Form groups of 2 or 3 Form groups of 2 or 3 Let me know your group members and email addresses today Let me know your group members and email addresses today I will give you a group name I will give you a group name Look at assignment/example documents now (handout) Look at assignment/example documents now (handout) Work on this in your group between this week and next week (together or online) If you have any problems in understanding the assignment please email me Work on this in your group between this week and next week (together or online) If you have any problems in understanding the assignment please email me There is other material on Use Cases and the Powerpoint slides on Requirements & Use Cases for the course so far on Blackboard and the RACC Student network. Feel free to use material from other sources if you wish but don’t forget to give credit © for this. There is other material on Use Cases and the Powerpoint slides on Requirements & Use Cases for the course so far on Blackboard and the RACC Student network. Feel free to use material from other sources if you wish but don’t forget to give credit © for this.

26 Assignment 1 -Schedule Aim to get deliverables 1-3 (on requirements) to me by the end of next weeks session. Aim to get deliverables 1-3 (on requirements) to me by the end of next weeks session. There will be a supervised Tutorial/Workshop next week Tuesday (Wk 5) to make sure each team has some time together to complete the work. PCs and Internet access (for research) available in the room. I will provide assistance as required to any group that needs help in finishing the deliverables. There will be a supervised Tutorial/Workshop next week Tuesday (Wk 5) to make sure each team has some time together to complete the work. PCs and Internet access (for research) available in the room. I will provide assistance as required to any group that needs help in finishing the deliverables. There will be an Evaluation Workshop in week 5 Thursday where you will peer-review another group’s work – All deliverables need to be with me by midnight Tuesday 10 th July. There will be an Evaluation Workshop in week 5 Thursday where you will peer-review another group’s work – All deliverables need to be with me by midnight Tuesday 10 th July.


Download ppt "Systems Analysis and Design – Week 4. SAD – Week 4 Finish off last weeks workshop Finish off last weeks workshop Homework review Homework review Recap."

Similar presentations


Ads by Google