1. Chapter 4: Developing Requirements
Object-Oriented Software Engineering Practical Software Development using UML and Java
Chapter 4:
Developing Requirements

2. Chapter 4: Developing requirements
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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

3. 4.2 The Starting Point for Software Projects
green field project
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

4. 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

5. Chapter 4: Developing requirements
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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

6. Chapter 4: Developing requirements
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
A collection of requirements is a requirements document.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

7. Chapter 4: Developing requirements
4.5 Types of Requirements
Functional requirements
Describe what the system should do
Non-functional requirements
Constraints that must be adhered to during development
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

8. 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

9. Non-functional requirements
All must be verifiable
Three main types
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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

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

11. 4.6 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

12. Chapter 4: Developing requirements
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.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

13. 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
Use Case Diagrams
UWO Computer Science

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

15. Terminology Process Sale
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
Use Case Diagrams
UWO Computer Science

16. Terminology Gambler 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
Use Case Diagrams
UWO Computer Science

17. <<Actor>> Credit Card Authorization System
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
<<Actor>>
Credit Card Authorization System
Credit Card Authorization System
Use Case Diagrams
UWO Computer Science

18. 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
Use Case Diagrams
UWO Computer Science

19. 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.
Use Case Diagrams
UWO Computer Science

20. Video Use Case Diagram 1
Use Case Diagrams
UWO Computer Science

21. 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.
Use Case Diagrams
UWO Computer Science

22. 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!
Use Case Diagrams
UWO Computer Science

23. The “Guts” of Use Cases We can now supply the details of a use case
Define use cases (as done above)
Give a simple sentence to explain each use case
Give a detailed narration of what the use case does, in paragraph form
Describe the main course scenario (main success scenario, main flow)
Set pre and post conditions
Identify, then describe alternate scenarios with post and pre conditions
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
Use Case Diagrams
UWO Computer Science

24. 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!
Use Case Diagrams
UWO Computer Science

25. Main Course: Actor: Clerk System Actor: Credit Card Authorization
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.
Use Case Diagrams
UWO Computer Science

26. Alternate Course 1: No copies of movie available
Pre Condition: At least one copy of the movie to be rented is available. Post Condition: The video copy is rented to the customer
Alternate Course 1: 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
Other Design Considerations:
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: Clerk
System
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
Use Case Diagrams
UWO Computer Science

27. Question Write the detailed use case for the following:
Use Case: Add Customer
Description:
Narrative:
Main Course:
Pre Condition and Post Condition:
Alternate Scenario (think of 2)
Design Notes:
Use Case Diagrams
UWO Computer Science

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

29. Advantages Disadvantages
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
Use Case Diagrams
UWO Computer Science

30. Identifying Different Scenarios <<extend>>
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
Use Case Diagrams
UWO Computer Science

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

32. Chapter 4: Developing requirements
Use case diagrams
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

33. Chapter 4: Developing requirements
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.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

34. Chapter 4: Developing requirements
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.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

35. Chapter 4: Developing requirements
Inclusions
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.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

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

37. 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

38. 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

39. 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.
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

40. 4.13 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
Chapter 4: Developing requirements
© Lethbridge/Laganière 2005

41. Computer Science Department
Case Study
Design a Use Case Diagram for the following requirements:
Appendix C  Elections Management System
The Ootumlia Elections Commission is designing a system to manage elections. The system will manage elections for a variety of different elected bodies (e.g. school board, city councils, etc.). Each elected body can have various positions (also called seats, e.g. mayor, councilor, etc.). Elections are scheduled for a specific date, and usually several (or all) positions are voted on together; however, sometime there may be the need for a by-election (e.g. to elect a particular councilor because the incumbent, the previous person who held the position, has resigned).
The system will keep track of candidates for each seat. The system will also record who is the incumbent for a seat, since newspaper reporters are interested in reporting whether incumbents have won again or lost. The system records the name and address of each candidate and incumbent.
The system will also keep track of the list of eligible voters. Each voter can only vote for certain positions (e.g. a particular council seat that represents their area). Each voter is also assigned to vote at a specific poll – each poll has a number and is located in a polling station. The system records the name and address of each voter.
Finally, the system will keep track of the number of votes for each candidate at each poll. However, under no circumstances will it record which voter voted for which candidate, nor whether a voter voted at all.
Computer Science Department
UWO

42. Computer Science Department
Your Answer
Computer Science Department
UWO