Software Requirements

Engineering

Lecture: 07
 Overview of Lecture 6
Content of Lecture
• Understanding User Needs: Skill 2
• Chapter 11 The Requirements Workshop

• Chapter 12 Brainstorming and Idea Reduction

• Chapter 13 Storyboarding
 Sequence [Todays Agenda]
Content of Lecture
• Defining the System: Skill 3
• Ch14 - Use Cases
• Ch15 - Organizing Requirements
• Ch16 - Vision Document
• Ch17 - Product Management
Team Skill 3 -
Defining the System
(Chapters 14-17 of the requirements text)

4
 Recap
 In Team Skill 1, we
developed the skills that
focus the team on analyzing
the problem.
 In Team Skill 2, we
described a set of techniques
the team can use to
understand user needs and
features proposed for the
system.
 In Team Skill 3, we'll
continue to focus on the 5

features we identified earlier.

Use Cases

6
Key Points
 Use cases carry the majority of the
requirements for the system.
 The development team, with user
involvement, writes the use cases.
 Use cases are built on a common, standard
format.
 Use cases later drive test case development

7
Benefits of Use Cases
 Easier to write and read
 Force developers to think from the user perspective
 Use cases engage the users in the requirements process
 Use cases provide a sequence of actions
 Help to understand what the system needs to do and how it
might go about doing it
 Use cases carry over directly into the testing process

Use cases simply tell a better requirements story

8
So, Use these
What is a Use Case?
 Definition: A use case describes sequences of
actions a system performs that yield an
observable result of value to a particular
actor: -
 Sequences of actions
 System Performs
 Observable result of value
 Particular Actor
9
Actors
 Definition: An actor is someone or something
that interacts with the system
 Type of Actors: -
 Users
 Other systems or applications
 A device

10
Flow of events
 The heart of the use case is the event flow, usually a textual
description of the interactions between the actor and the system

 The flow of events can consist of both:

 the basic flow, which is the main path through the use case,
and
 alternate flows, which are executed only under certain
circumstances

11
Use Case Model - Development Steps
1. Identify and describe the actors
2. Identify the use cases and write breif
description
3. Identify actor/use case relationships
4. Outline use cases
5. Refine use cases

12
1. Identify and Describe the Actors
 Who uses the system?
 Who gets/provides information from/to
system?
 Who supports and maintains the system?
 What other systems interact with this system?
 Where in the company is the system used?

In this process you may find new actors, most likely, non human actors …
13
2. Identify the Use Cases and Write a Brief
Description
 Find what are the intentions of each actor with
respect to the system? Ask For: -
 What will the actor use the system for?
 Will the actor create, store, change, remove, or
read data in the system?
 Will the actor need to inform the system about
external events or changes?
 Will the actor need to be informed about certain
occurrences in the system?
14
2. Identify the Use Cases and Write a Brief
Description
 Give a descriptive name:
 Start with an action verb
 Describes goal or intent
 Give a one-sentence description

15
Figure 14-2. Use cases for the
Homeowner/Programmer actor

16
3. Identify Actor/Use Case Relationships
 Draw a diagram showing relationships
between actors and use cases

Eat food

Buy food
Parent Child

17
4. Outline Use Cases
 Describe sequence of events in
basic flow (sunny day scenario)
 Typically, you will outline the basic
flow first.
 There is only one basic flow
 Describe sequences of events in
alternate flows (rainy day
scenarios)
 what ifs, e.g., What if the server is 18

down?
 4. Outline Use Cases - Questions
 Basic flow:
 What event starts the use
case?
 How does the use case end?
 How does the use case
repeat some behavior?
 Alternate flow:
 Are there optional situations in
the use case?
 What odd cases might happen?
 What may go wrong?
 What may not happen?
19
5. Refine Use Cases
 At some point later in the project lifecycle you will
refine the use cases to the next and last level of
detail.
 At that time, there are a number of additional
factors to be considered, such as: -
 Describe All alternate flows, including exception
conditions
 Describe pre-conditions / post-conditions
 Pre-conditions describe the things that must be true before a use
case starts.
 Post-conditions describe the persistent states the use case leaves20
behind
Use Case Anatomy

21
See Appendix C for fully elaborated use-case specification template
Microwave Example

Cook Food

User

22
Cook Food Use Case – Slide 1 of 4
A. Name: Cook Food
B. Brief description: User places food in microwave
and cooks it for desired period of time at desired
power level.
C. Actors: User

23
Cook Food Use Case – Slide 2 of 4
D. Basic flow:
1. User opens door and places food in unit
2. User enters time for cooking
3. User pushes start button
4. Unit cooks food
5. Unit beeps

24
Cook Food Use Case – Slide 3 of 4
E. Alternate flows
1. User cancels time before starting
2. User cancels cooking before finished
3. User selects reduced power level before pushing start
button

25
Cook Food Use Case – Slide 4 of 4
F. Pre-conditions
 Unit is plugged in
 Unit is in ready state
G. Post-conditions
 Food is cooked or user cancelled operation
H. Special requirements
 Timer should display remaining time to finish while
cooking
 Default power setting should be "high"
26
Organizing Requirements

27
Key Points
 Requirements must be captured and recorded
in a document, database or model.
 Different types of projects require different
requirements organization techniques.
 Complex systems require that requirements
sets be developed for each subsystem.

28
Organization Techniques
 Requirements can rarely be defined in a single
document or in a single use-case model.
 There may be no. of reasons: -
 The system may be very complex
 The system being constructed may be a subsystem
of a larger system and may satisfy only a subset of
all the requirements identified
 Marketing and business goals needs to be
separated from the detailed product requirements

29
Different Ways of Organizing (1/3)
 One set defines the features of the system in
general terms, and
 another defines requirements in more specific
terms.
 Often, the former is called the Vision document
(discussed extensively in Chapter 16),
 whereas the latter set may consist of the system
use-case model and associated supplementary
requirements (discussed in Chapter 22).
30
Different Ways of Organizing (2/3)
 One "parent" requirements set defines
requirements for the overall "system,"
including hardware, software, people, and
procedures, and
 another defines requirements for just the
software subsystem

31
Different Ways of Organizing (3/3)
 One set defines the full set of requirements for
a family of products, and
 E.g microsoft
 another defines requirements for just one
specific application and for one specific
release

32