Chapter 4: Developing Requirements Timing: 50 minutes

Question: Scenario 1:You get an offer in 2 years by Boeing as a Software Developer. Scenario 2: You get an offer in 2 years by Google as a Software Developer. Both: pay the same amount of money are in the same city are equal distance from your house Which job do you take and why? © Lethbridge/Laganière 2005 Chapter 4: Developing requirements2

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements3 4.1 Domain Analysis The process by which a software engineer learns about the domain to better understand the problem: The domain is the general field of business or technology in which the clients will use the software A domain expert is a person who has a deep knowledge of the domain Benefits of performing domain analysis: Faster development Better system Anticipation of extensions

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements4 4.2 The Starting Point for Software Projects green field project Be careful with cases B and D, why? Customer may not have done a good job (e.g. proposing a system that is too large or does not address a clear problem)

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements5 4.3 Defining the Problem and the Scope A problem can be expressed as: A difficulty the users or customers are facing, Or as an opportunity that will result in some benefit such as improved productivity or sales. The solution to the problem normally will entail developing software A good problem statement is short and succinct

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements6 Defining the Scope Narrow the scope by defining a more precise problem List all the things you might imagine the system doing —Exclude some of these things if too broad —Determine high-level goals if too narrow Example: A university registration system

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements7 4.4 What is a Requirement Requirement: A statement about the proposed system that all stakeholders agree must be made true in order for the customer’s problem to be adequately solved. Short and concise piece of information Says something about the system All the stakeholders have agreed that it is valid It helps solve the customer’s problem Describes either: An aspect of the what the proposed system must do A constraint on the system A collection of requirements is a requirements document.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements8 4.5 Types of Requirements Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development Question: A Functional Requirement for cs2212 project might be: First Name must be 1-20 characters. Can you figure out what might be a Non-Functional Requirement that I have given you for your cs2212 project?

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements9 Functional requirements What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements10 Non-functional requirements All must be verifiable Three main types (Quality  Q) 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability —Response time —Throughput —Resource usage —Reliability —Availability —Recovery from failure —Allowances for maintainability and enhancement —Allowances for reusability

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements11 Non-functional requirements 2. Categories constraining the environment and technology of the system. (Platform  PL) —Platform —Technology to be used 3. Categories constraining the project plan and development methods (Process  PR) —Development process (methodology) to be used —Cost and delivery date -Often put in contract or project plan instead

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements12 Question Classify the following requirement statements into F for functional, Q for quality, PL for platform, PR for process and X for should not be a requirement: a)If the alarm system is ringing, then the elevator doors will proceed to the ground floor, open doors and suspend further operations b)The student information system will provide output from all commands within one second c)The system will use an array to hold the invoices d)The java.util.Date class should be used to handle dates e)The system must run under Linux and Windows f)The system must be done by September 2008 g)The system should be able to be expanded in the second release to handle new file formats for graphics h)All phone extensions must start with an 8 a)F b)Q c)X d)X e)PL f)PR g)Q h)F

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements Use-Cases describing how the user will use the system A use case is a typical sequence of actions that a user performs in order to complete a given task The objective of use case analysis is to model the system … from the point of view of how users interact with this system … when trying to achieve their objectives. A use case model consists of —a set of use cases —an optional description or diagram indicating how they are related

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements14 Use cases In general, a use case should cover the full sequence of steps from the beginning of a task until the end. A use case should describe the user’s interaction with the system... —not the computations the system performs. A use case should be written so as to be as independent as possible from any particular user interface design. A use case should only include actions in which the actor interacts with the computer.

UWO Computer Science Use Case Diagrams15 UML Use Case Diagram What Are Your Users Goals? Use case diagrams are a simple UML notation to illustrate the goals of your users Use cases Are created in the early stages of the project Are an effective means of communicating with your end users Allow you to model what happens in an existing system or what the user can do in a new system Can be used as the basis for picking test cases during the testing of the system. A use case represents a sequence of actions (or goal) to be performed by the system and the users/actors who interacts with that use case

UWO Computer Science Use Case Diagrams16 Simple Example Suppose a gambler is playing a dice game where if he/she roll 2 dice and the values of the dice add up to 7 he/she wins, otherwise he/she loses. Sample Use Case Diagram: Roll A Die Gambler

UWO Computer Science Use Case Diagrams17 Terminology Use Case: a goal to be accomplished, a sequence of activities that achieve that goal Normally a verb followed by a noun, for example: Process Sale Add Customer E.g. Bad Use Case: Log In (the goal is not really to log in!) E.g. Good Use Case: Authentic User Notation: Process Sale

UWO Computer Science Use Case Diagrams18 Terminology Actor: people/systems that interact with use cases Human Actors: Clients, Customers, Employees —Pick clear names such as Hotel Desk Clerk, Librarian, Head Librarian. —Don’t pick names based just on job titles: for example if the clerk, the secretary and the receptionist all do the same operations on the telephone answering system you are writing, pick one name for all 3, not 3 different actor names,e.g. phone operator —Notation: Gambler

UWO Computer Science Use Case Diagrams19 –Non-Human Actors: External systems that communicate with the system being designed e.g. Credit Card Authorization, Web Server Ignore internal components, only model external other systems as actors, not internal parts of your system. For example, your internal database should NOT be an actor. Notation: Or > Credit Card Authorization System

UWO Computer Science Use Case Diagrams20 Suggestions for Designing Use Cases Choose a good name e.g. Add Appointment rather than Make Time Show a complete and completable behaviour e.g. Add Appointment rather than Add Appointment Location e.g. Add Appointment rather than Adding Appointment Show inverse use cases if applicable e.g. Add Appointment AND Delete Appointment Limit a use case to ONE behaviour e.g. Add Appointment, Update Appointment AND Delete Appointment rather than Manage Appointments Write the use case from the actors point of view e.g. Sell Stock rather than Delete Stock

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements21 Use case diagrams

UWO Computer Science Use Case Diagrams22 Use Case Example Design the use case diagram for the following situation: Suppose we are re-designing a system for BustBlocker Video Stores. Currently, a customer picks a video off a shelf and brings it to the clerk. The clerk logs in once in the morning and during the rest of the day must check out the video to a customer or check in videos that are returned by customers. The clerk or the store manager must also be able to add new copies of movies and delete copies of movies. When a customer pays for a video, the clerk will use the check credit card system to check the user’s credit card. The clerk and the store manager must be able to add and delete and update customer information. Customers want to have a printed list of the movies they have rented within a given time frame, the clerk must print this list.

UWO Computer Science Use Case Diagrams23 Video Use Case Diagram 1

UWO Computer Science Use Case Diagrams24 Video Use Case Diagram 2 How would your diagram change if you were going to allow customers to do self check out and self check in of movies and print their own list.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements25 Inclusions (Called Uses In MS Visio) Allow one to express commonality between several different use cases. Are included in other use cases —Even very different use cases can share sequence of actions. —Enable you to avoid repeating details in multiple use cases. Represent the performing of a lower-level task with a lower-level goal.

UWO Computer Science Use Case Diagrams26 Use Cases that can be reused > Try to factor out common behaviour from 2 or more use cases, a subscenario of a use case Example: Event Organizer Guest Book RoomBook Hall Guarantee Reservation >

UWO Computer Science Use Case Diagrams27 Advantages Helps to avoid documenting the same information in more than 1 detailed use case Helps identify common functionality for later coding decisions Disadvantages Might cause UML designers to start looking to early for common functionality rather than just identifying the use cases. Not as easy to read for non-UML users so it may make diagrams more confusing for users

UWO Computer Science Use Case Diagrams28 Identifying Different Scenarios > If a use case has a complex or unusual scenario, you might want to make it a separate use case If there is some point where the behaviour diverges, you might want to make this a separate use case

UWO Computer Science Use Case Diagrams29 Example Note: the arrow goes from the more exceptional case to the normal case Customer Rent Video Rental Refused > Overdue videos still on loan

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements30 Extensions Used to make optional interactions explicit or to handle exceptional cases. By creating separate use case extensions, the description of the basic use case remains simple. A use case extension must list all the steps from the beginning of the use case to the end. —Including the handling of the unusual situation.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements31 Generalizations Much like superclasses in a class diagram. A generalized use case represents several similar use cases. One or more specializations provides details of the similar use cases.

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements32 Example of generalization, extension and inclusion

> vs. > > use when one use case one cannot live without the other use case. The use case must include another use case. The one use case can NOT be completed without the other use case. —For example when you create an order you always must verify name. NOTE: used to be called > > use when one use case can live without the other in some instances. The use case will extend to another use case to do some stuff occasionally but not always. —For example, you can create an order but if the order is for a new customer you may have to do additional check which you do not have to do for existing customers. In that case you can have an extend use case. © Lethbridge/Laganière 2005 Chapter 4: Developing requirements33

Another Example © Lethbridge/Laganière 2005 Chapter 4: Developing requirements34 Bold Text Select Text Print Word Document Print Preview Word Document > QUESTION: Often, in the project, you will be required to DELETE something and LIST all the somethings. How does the > apply in this scenario (for example  deleting a file and listing all the files)?

UWO Computer Science Use Case Diagrams35 Other Things to Remember At this early point in requirements analysis, DO NOT attempt to design screens for your use cases, just identify them. i.e. don’t worry about how the use cases work, just worry about what the use cases are. Match the actors name to how he/she interacts with the system, not to his/her job title Use cases should be easy for your users to understand, again remember they tell what the user must accomplish NOT how to accomplish it!

UWO Computer Science Department36 Case Study Design a Use Case Diagram for the following requirements: A camping reservation system for multiple campgrounds. Each campground has a manager and rangers. Managers and rangers can enter information such as campsite info, and which sites are useable and which sites are undergoing repair/regrowth. Campers can use the system to select and reserve camping locations.  Identify the actors  Identify the use cases  Look for any include use cases  Look for any extend use cases  Which use case might you want to expand to a DETAILED USE CASE?

UWO Computer Science Department37 Your Answer Add Site List Sites > Search sites Book site Cancel booking Modify Site Delete Site > Modify booking Ranger Camper > Check Availability

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements38 The modeling processes: Choosing use cases on which to focus Often one use case (or a very small number) can be identified as central to the system —The entire system can be built around this particular use case There are other reasons for focusing on particular use cases: —Some use cases will represent a high risk because for some reason their implementation is problematic —Some use cases will have high political or commercial value Create a detailed use case for the central use cases

UWO Computer Science Use Case Diagrams39 The “Guts” of Use Cases –We can now supply the details of a use case 1.Define use cases (as done above) 2.Give a simple sentence to explain each use case 3.Give a detailed narration of what the use case does, in paragraph form 4.Describe the main course scenario (main success scenario, main flow) 5.Set pre and post conditions 6.Identify, then describe alternate scenarios with post and pre conditions 7.List any additional requirements that must be met –The users should be allowed to review the narrative to see if it clearly reflects the goal the user is trying to accomplish

UWO Computer Science Use Case Diagrams40 Example 1. Use Case Name: Check out video 2. Description: This use case allows the actor, clerk, to rent out a video to a particular customer 3. Narrative: This use case starts with the clerk entering in the video id number of the video to be rented. The system displays the video title and how many copies are available. If no copies are available, the action is cancelled. If there is at least one copy available, the system prompts for customer’s id number. If the name displayed matches the customer name the system prompts for the payment information. The clerk enters in the customers credit card number which is authorized by the credit card authorization system, if the card is not valid, the customer is asked if he/she wishes to pay with cash, if he/she says no, the action is cancelled. Otherwise the system displays the return date for the video and gives a confirmation message that the video was rented. Review this narrative with your users before continuing!

UWO Computer Science Use Case Diagrams41 4.Main Course: Actor: ClerkSystemActor: Credit Card Authorization System 1. The clerk enters the video id number of the movie to be rented. 3. The clerk enters the customer id number 5. The clerk enters the customers credit card number 8.The clerk confirms the checking out of the movie 2. The system displays the name of the movie and the number of copies available 4. The system displays the customers name. 6. The system sends the card number to the credit card authorization system and waits for confirmation 9. The system displays that the video was rented and displays the return date 7. Reports card is accepted.

UWO Computer Science Use Case Diagrams42 5.Pre Condition: At least one copy of the movie to be rented is available. Post Condition: The video copy is rented to the customer 6.Alternate Course 1: There are no copies of movie available Pre Condition: At Step 1 of main course, the actor enters a movie where all the copies have been rented Post Condition: Video is not rented to the customer 7.Other Design Considerations: 1.If 2 or more clerks try to rent the same copy at the same time, the system should allow only one of them to rent it Actor: ClerkSystem 1.The clerk enters the video id number of the movie to be rented. 3. The clerk cancels the check out operation 2. The system displays the name of the movie and that there are ZERO copies available

Another Example of a Detailed Use Case © Lethbridge/Laganière 2005 Chapter 4: Developing requirements43 Example from use-cases-for-agile-scrum-projects/ use-cases-for-agile-scrum-projects/

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements44 The benefits of basing software development on use cases They can help to define the scope of the system They are often used to plan the development process They are used to both develop and validate the requirements They can form the basis for the definition of testcases They can be used to structure user manuals

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements45 Problems with Use Cases Try to describe a use case for adjusting the wake-up time of an alarm clock. If you were writing this use case, what is the problem that would likely occur? HINT: almost everyone has an alarm clock, what does this imply about how YOU would design it? You would probably describe the way your own clock does it, rather than thinking of a more efficient and/or innovative way to do it!

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements46 Use cases must not be seen as a panacea The use cases themselves must be validated —Using the requirements validation methods. There are some aspects of software that are not covered by use case analysis. Innovative solutions may not be considered.

User Stories There are problems with drawing a Use Case Diagram based on the initial requirements that were given you. Can you guess what some of the problems are? The initial requirements might be wrong OR incomplete OR change during the project. I.e. the user changes his/her mind or thinks up new features. Called: Scope Creep So….. How can we keep our requirements “Agile”? Chapter 4: Developing requirements47

User Stories Who should write the features? The business side or the developer side? Any thoughts? © Lethbridge/Laganière 2005 Chapter 4: Developing requirements48 Business SideDevelopment Side Pros knows exactly what is needed can roughly gage how long it will take to write the code Cons doesn’t really understand (or care) how long it takes to develop a feature isn’t sure the developer really understood what was wanted/needed starts thinking about HOW to do it rather than what needs to be done and starts using technical jargon doesn’t get at chance to listen to figure out what is really needed

User Stories Business Person might write the feature:  Manage appointment Developer might write the feature:  Use date/time field for storing appointment start time What is the solution then? WHO should write the feature list? BOTH the business people and the developers MUST be involved with writing of requirements! © Lethbridge/Laganière 2005 Chapter 4: Developing requirements49

User Stories User Story: describes functionality valuable to a user/customer. (should be able to fit on a recipe card) Format should be: As a, I want so that. Examples: As a customer I want to see the most popular blu-ray discs sold so that I can order one or many of them As a customer I want to sort the most sold blu-rays by price so that I can see the expensive ones first. Good site with tips on User Stories: © Lethbridge/Laganière 2005 Chapter 4: Developing requirements50

User Stories Decide if these stories are good user stories or bad ones: A.As a user I can add a new appointment B.As a user I can set the time of a new appointment C.The system will run on Unix and Linux D.As a scheduler, I want to add an appointment to a calendar so that I can keep track of my schedule E.While building the scheduling system we will use a Gantt chart to monitor the programmers progress F.The GUI needs to be built © Lethbridge/Laganière 2005 Chapter 4: Developing requirements51

User Stories Notice that “as the user I can add a new appointment” is a bit vague. Need to have a conversation with the business people to see is need to make a complete appointment. The user story is a reminder to have the conversation, we can discuss the details with the user when they become important (“just in time” requirements analysis) © Lethbridge/Laganière 2005 Chapter 4: Developing requirements52

User Stories Usually ONE user story should fit on a recipe card. If it takes up more space, then it should be broken down. Put the test cases on the back of the card. © Lethbridge/Laganière 2005 Chapter 4: Developing requirements53

User Stories – more detailed example © Lethbridge/Laganière 2005 Chapter 4: Developing requirements54

User Stories – Top 3 mistakes Too formal / too much detail. Product owners with good intentions often try to write extremely detailed user stories. If a team sees a story at iteration planning that looks like an IEEE requirements document, they'll often assume that all the details are there and they'll skip the detailed conversation. Technical tasks masquerading as stories. A lot of the power of Agile comes from having a working increment of software at the end of each iteration. If your stories are really just technical tasks, you often don't end up with working software at the end of each iteration, and you lose flexibility in prioritization.increment Skipping the conversation. Stories are intentionally vague before iteration planning. If you skip the acceptance criteria conversation, you'll risk moving in the wrong direction, missing edge cases or overlooking customer needs.risk From this site: © Lethbridge/Laganière 2005 Chapter 4: Developing requirements55

User Stories: Estimation Who decides how long it takes to complete a user story? Developer or Business Person? DEVELOPER! Each story is assigned an estimate in story points Describes the amount of work, NOT a length of time! © Lethbridge/Laganière 2005 Chapter 4: Developing requirements56 How long would it take you to shovel the big pile of this snow on the left? How long would it take you to show the little pile compared to the big pile on the right?

User Stories Computer Scientists are excellent at telling which feature would take the longest and which would take the shortest amount of time, but they are very bad at estimating the EXACT amount of time in hours or days. Thus we give User Stories points, an estimate of the amount of work BUT not the amount of time. e.g. An admin must be able to add a new customer might be 1 story point but An admin must be able to search for a customer might be 2 story points. Note: only features get points, not bug fixes or chore © Lethbridge/Laganière 2005 Chapter 4: Developing requirements57

User Stories: Iteration: a group of features that are FULLY implemented, usable code for some subset of the application. An iteration might be 1 week or 2 weeks, it depends. Velocity: Developers estimate in story points how long it will take to complete an iteration. Business people sort stories by priority, highest go into first group, next highest go into second group, etc. Each group is an iteration © Lethbridge/Laganière 2005 Chapter 4: Developing requirements58

User Stories Developers might have a higher priority for something because it is required to implement another feature BUT the customer/business person must have final say. Try to avoid having one story depend on another story if possible. Good User Stories INVEST  © Lethbridge/Laganière 2005 Chapter 4: Developing requirements59 I ndependent N egotiable V aluable E stimable S mall T estable

User Stories – Pivotal Tracker Goal is to have a fully usable application at the end of each iteration. Create a public project on Your task is to: 1. Enter stories for every feature in the application 2. Add acceptance tests to the Description field of each story (so that they know when the story is complete -- this would normally go on the back of a story card) 3. Assign each story to a group member 4. Estimate the length of each story in "story points” © Lethbridge/Laganière 2005 Chapter 4: Developing requirements60

User Stories Watch this: Then this: © Lethbridge/Laganière 2005 Chapter 4: Developing requirements61

© Lethbridge/Laganière 2005 Chapter 4: Developing requirements Difficulties and Risks in Domain and Requirements Analysis Lack of understanding of the domain or the real problem —Do domain analysis and prototyping Requirements change rapidly —Perform incremental development, build flexibility into the design, do regular reviews Attempting to do too much —Document the problem boundaries at an early stage, carefully estimate the time It may be hard to reconcile conflicting sets of requirements —Brainstorming, JAD sessions, competing prototypes It is hard to state requirements precisely —Break requirements down into simple sentences and review them carefully, look for potential ambiguity, make early prototypes