CSCE 431:
Requirements
Some material from B. Meyer, M. Oriol, B. Schoeller, ETH Zurich
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Requirements Are Important
The hardest single part of building a software
system is deciding precisely what to build. No
other part of the conceptual work is as difficult as
establishing the detailed technical requirements,
including all the interfaces to people, to
machines, and to other software systems. No
other part of the work so cripples the resulting
system if done wrong. No other part is more
difficult to rectify later.
• Fred Brooks, No Silver Bullet – Essence and
Accident in Software Engineering, IEEE Computer,
vol. 20, no. 4, April 1987, pp. 10-19.
CSCE 431 Requirements
Software Risk
• Barry Boehm, Software Engineering Economics, Prentice Hall, 1981
CSCE 431 Requirements
Some Statistics on
Requirements
• 80% of interface faults and 20% of implementation
faults due to requirements (Perry & Stieg, 1993)
• 48% to 67% of safety-related faults in NASA SW
systems due to misunderstood HW interface
specifications, of which 2/3 are due to requirements
(Lutz, 1993)
• 85% of defects due to requirements, of which 49% are
incorrect assumptions 29% omitted requirements 13%
inconsistent requirements (Young, 2001).
• Requirements cause a lot of problems!
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Ethical View
• When customers present ideas that need
system solutions, developers have an ethical
and professional obligation to help customers
define their problem.
• You must build the best solution to the
customer’s problem, even if the customer
does not yet understand how to ask for it.
• Bernstein & Yuhas
• More on professional ethics in future lecture
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Definitions
• A requirement is a statement of desired
behavior for a system
• The requirements for a system are the
collection of all such individual requirements
• Requirements process has two activities:
• Requirements elicitation — definition of the system
in terms understood by the customer and/or user
• Agile process – user stories, customer on site
• Requirements analysis — definition of the system in
terms understood by the developer
CSCE 431 Requirements
Goals of Requirements Phase
• Understand the problem or problems that the eventual
software system, if any, should solve
• Prompt relevant questions about the problem and
system
• Provide basis for answering questions about specific
properties of the problem and system
• Decide what the system should do
• Decide what the system should not do
• Ascertain that the system will satisfy needs of its
stakeholders
• Provide basis for development of the system
• Provide basis for validation and verification (especially
testing) of the system
• B. Meyer, Object-Oriented Software Construction
CSCE 431 Requirements
Products of Requirements
• Requirements document
• Development plan
• Validation and verification plan (test plan)
CSCE 431 Requirements
How Much Effort?
• Should expect to allocate 15-30% of total
project effort on requirements
• Seems like a lot, but this phase is the source of
many project failures
• Remember that only 40-60% of requirements
are known during requirements elicitation
• Rest are emergent requirements
CSCE 431 Requirements
Stakeholders
• One of the first phases is to identify stakeholders
• Suggestions of groups to think about:
•
•
•
•
•
•
•
•
•
•
•
•
Clients
Customers
Clients’ and customer’s customers
Users
Domain experts
Legal experts
Purchasing agents
Software developers
Software project managers
Software documenters
Trainers
Consultants
CSCE 431 Requirements
Components of Requirements
• Domain properties
• Assumptions that are true in the domain
• Functional requirements
• Non-functional requirements
•
•
•
•
•
•
Reliability
Security
Accuracy of results
Time and space performance
Portability
Others?
CSCE 431 Requirements
Roles of Domain Properties
vs. Requirements
• Requirement R:
• “The database shall only be accessible to authorized
personnel”
• Domain Properties D:
• Authorized personnel have passwords
• Passwords are never shared with non-authorized personnel
• Specification S:
• Access to the database shall only be granted after the user
enters an authorized password
• S, D  R
• But what if domain assumptions are wrong?
• Steve Easterbrook, 2008
CSCE 431 Requirements
Domain Assumption?
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Quality Goals for
Requirements
• Correct
• Complete
• Consistent
• Unambiguous
• Traceable
• Modifiable
• Verifiable
• Prioritized
830-1998 — IEEE Recommended Practice for Software Requirements Specifications
CSCE 431 Requirements
Difficulties
• Natural language and its imprecision
• Formal techniques and their abstraction
• Users and their vagueness
• Customers and their demands (or
managers/marketing/sales)
• The rest of the world and its complexity
• And things change during the project
CSCE 431 Requirements
Bad Requirements, Example
NOT SO GOOD
The Background Task Manager shall provide status messages at regular
intervals of not less than 60 seconds.
BETTER
The Background Task Manager (BTM) shall display status messages in a
designated area of the user interface.
1. The messages shall be updated every 60 ± 10 seconds after
background task processing begins.
2. The messages shall remain visible continuously.
3. Whenever communication with the background task process is
possible, the BTM shall display the percent completed of the
background task.
CSCE 431 Requirements
Bad Requirements, Another
NOT SO GOOD
The XML Editor shall switch between displaying and hiding non-printing
characters instantaneously.
BETTER
The user shall be able to toggle between displaying and hiding all XML
tags in the document being edited with the activation of a specific
triggering mechanism. The display shall change in ≤ 0.1 seconds.
CSCE 431 Requirements
Bad Requirements, Another
NOT SO GOOD
The XML parser shall produce a markup error report that allows quick
resolution of errors when used by XML novices.
BETTER
1. After the XML Parser has completed parsed a file, it shall produce an
error report that contains the line number and text of any XML errors
found in the parsed file and a description of each error found.
2. If no parsing errors are found, the parser shall not produce an error
report.
CSCE 431 Requirements
Bad Requirements, One More
NOT SO GOOD
The editor shall not offer search and replace options that could have
disastrous results.
BETTER
1. The editor shall require the user to confirm global text changes,
deletions, and insertions that could result in data loss.
2. The application shall provide a multi-level undo capability limited only
by the system resources available to the application.
CSCE 431 Requirements
A Balancing Act
• One should not over-specify
• == committing too early to a specific implementation
• One should not under-specify
• == leaving some parts of the problem missing
CSCE 431 Requirements
A Simple Problem
NAUR’S PROBLEM STATEMENT
Given a text consisting of words separated by BLANK or by NL (new line)
characters, convert it to a line-by-line form in accordance with the
following rules:
1. Line breaks must be made only where the given text has BLANK or
NL;
2. Each line is filled as far as possible as long as
3. No line will contain more than MAXPOS characters.
• Peter Naur, Programming by Action Clusters, BIT, vol. 9, no. 3, pp. 250-258
CSCE 431 Requirements
“Improved” Specification
The program’s input is a stream of characters
whose end is signaled with a special end-oftext character, ET. There is exactly one ET
character in each input stream. Characters
are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words separated
by breaks, with possibly leading and trailing
breaks, and ending with ET.
J. B. Goodenough and S. Gerhart, Towards a Theory
of Test: Data Selection Criteria,
Current Trends in Programming Methodology, pp 44–
79, Prentice Hall, 1977
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Meyer’s Analysis
• The following discussion is based on Bertrand
Meyer’s analysis of the above specifications in
On Formalism in Specifications, IEEE
Software, pp. 6-26, Jan. 1985
• His definition of specification:
• Precise definition of the tasks to be performed by
the system
• Do not confuse with requirements, which are a
natural-language definition of the system
objectives
CSCE 431 Requirements
Seven Sins of the Specifier
1. Noise
• Irrelevant information, redundancy, remorse (restriction at use,
not definition, of an element)
2. Silence
• Feature exists, but not discussed
3. Over-specification
• Specification of a solution to the problem, not the problem
4.
5.
6.
7.
Contradiction
Ambiguity
Forward reference
Wishful thinking
• Feature definition, for which candidate solutions cannot be
realistically validated
CSCE 431 Requirements
Noise
The program’s input is a stream of characters
whose end is signaled with a special end-oftext character, ET. There is exactly one ET
character in each input stream. Characters
are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words
separated by breaks, with possibly
leading and trailing breaks, and ending
with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Remorse
The program’s input is a stream of characters
whose end is signaled with a special end-oftext character, ET. There is exactly one ET
character in each input stream. Characters
are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words separated
by breaks, with possibly leading and trailing
breaks, and ending with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Silence
• The “obvious” easily forgotten
• In the example:
• line never defined, except in the remorseful
sequence of characters “between successive NL
characters.”
• Are the NL characters part of the line?
• Are the first and the last lines “lines”?
• Behavior of NL relies on contextual knowledge of a
particular encoding (or an OS)
• Alarm should be set to TRUE in one case, but
nothing else is said about it
CSCE 431 Requirements
Contradictions
The program’s input is a stream of
characters whose end is signaled with a
special end-of-text character, ET. There is
exactly one ET character in each input
stream. Characters are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words
separated by breaks, with possibly leading
and trailing breaks, and ending with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Over-specification
The program’s input is a stream of characters
whose end is signaled with a special endof-text character, ET. There is exactly one
ET character in each input stream.
Characters are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words separated
by breaks, with possibly leading and trailing
breaks, and ending with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Ambiguity
The program’s input is a stream of characters
whose end is signaled with a special end-oftext character, ET. There is exactly one ET
character in each input stream. Characters
are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words separated
by breaks, with possibly leading and trailing
breaks, and ending with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS characters,
where MAXPOS is a positive integer) should
cause an error exit from the program (i.e., a
variable, Alarm, should have the value
TRUE). Up to the point of an error, the
program’s output should have the following
properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Forward References (implicit)
The program’s input is a stream of characters
whose end is signaled with a special end-oftext character, ET. There is exactly one ET
character in each input stream. Characters
are classified as:
• break characters—BL (blank) and NL (new
line);
• nonbreak characters—all others except
ET;
• the end-of-text indicator–ET.
A word is a nonempty sequence of nonbreak
characters. A break is a sequence of one or
more break characters. Thus, the input can
be viewed as a sequence of words separated
by breaks, with possibly leading and trailing
breaks, and ending with ET.
The program’s output should be the same
sequence of words as in the input, with the
exception that an oversize word (i.e., a word
containing more than MAXPOS
characters, where MAXPOS is a positive
integer) should cause an error exit from the
program (i.e., a variable, Alarm, should have
the value TRUE). Up to the point of an error,
the program’s output should have the
following properties:
1. A new line should start only between
words and at the beginning of the output
text, if any.
2. A break in the input is reduced to a single
break character in the output.
3. As many words as possible should be
placed on each line (i.e., between
successive NL characters).
4. No line may contain more than MAXPOS
characters (words and BLs).
CSCE 431 Requirements
Improved (w/o Quotes)
Given are a non-negative integer MAXPOS and a character
set including two “break characters” blank and
new_line. The program shall accept as input a finite
sequence of characters and produce as output a
sequence of characters satisfying the following conditions:
• It only differs from the input by having a single break character
wherever the input has one or more break characters.
• Any MAXPOS+1 consecutive characters include a new_line.
• The number of new_line characters is minimal.
• If (and only if) an input sequence contains a group of
MAXPOS+1 consecutive non-break characters, there exists no
such output. In this case, the program shall produce the output
associated with the initial part of the sequence up to and
including the MAXPOS-th character of the first such group, and
report the error.
Spec from Meyer
CSCE 431 Requirements
Verifiable Requirements
• Non-verifiable:
• The system shall work satisfactorily
• The interface shall be user-friendly
• The system shall respond in real time
• Verifiable:
• The output shall in all cases be produced ≤30s after the
corresponding input event. It shall be produced in ≤10s
for 80% of input events.
• Professional train drivers will reach level 1 of proficiency
(defined in requirements) in two days of training.
• Favor precise, falsifiable language over pleasant
generalities!
CSCE 431 Requirements
Complete Requirements
• Complete w.r.t. what?
• Definition from IEEE standard:
An SRS (Software Requirements Specification) is
complete if, and only if, it includes the following elements:
• All significant requirements, whether relating to functionality,
performance, design constraints, attributes, or external
interfaces. In particular any external requirements imposed by
a system specification should be acknowledged and treated.
• Definition of the responses of the software to all realizable
classes of input data in all realizable classes of situations.
Note that it is important to specify the responses to both valid
and invalid input values.
• Full labels and references to all figures, tables, and diagrams
in the SRS and definition of all terms and units of measure.
CSCE 431 Requirements
Complete Requirements
• Completeness cannot be completely defined
• Cross-checking mutators vs. accessors (so
that all effects defined) at least useful –
“sufficient complexity”
• E.g. consider each accessor for each possible use
of mutators
• “Think negatively” – how can I break it
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Why SE Standards?
• SE standards:
•
•
•
•
Define common practice
Guide new engineers
Make software engineering processes comparable
Enable certification
CSCE 431 Requirements
IEEE 830-1998
• IEEE Recommended Practice for Software
Requirements Specifications
• Approved 25 June 1998 (revision of earlier
standard)
• Descriptions of the content and the qualities of a
good software requirements specification (SRS).
• Goal: “The SRS should be correct, unambiguous,
complete, consistent, ranked for importance
and/or stability, verifiable, modifiable, traceable.”
CSCE 431 Requirements
IEEE Standard: Definitions
Contract
A legally binding document agreed upon by the customer and
supplier. This includes the technical and organizational
requirements, cost, and schedule for a product. A contract may
also contain informal but useful information such as the
commitments or expectations of the parties involved.
Customer
The person, or persons, who pay for the product and usually
(but not necessarily) decide the requirements. In the context of
this recommended practice the customer and the supplier may
be members of the same organization.
Supplier
The person, or persons, who produce a product for a customer.
In the context of this recommended practice, the customer and
the supplier may be members of the same organization.
User
The person, or persons, who operate or interact directly with
the product. The user(s) and the customer(s) are often not the
same person(s).
CSCE 431 Requirements
Issues Addressed
• Basic issues to be addressed by an SRS:
• Functionality
• What is the software supposed to do?
• External interfaces
• How does the software interact with people, the system’s hardware, other
hardware, and other software?
• Performance
• What is the speed, availability, response time, recovery time of various software
functions,…?
• Attributes
• What are the portability, correctness, maintainability, security,... considerations?
• Design constraints imposed on an implementation
• Are there any required standards in effect, implementation language, policies for
database integrity, resource limits, operating environment(s),…?
• The SRS writer(s) should avoid placing either design or project
requirements in the SRS
CSCE 431 Requirements
IEEE Standard: SRS’s
Recommended Structure
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms, and abbreviations Glossary
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and dependencies
3. Specific requirements
Appendices
Index
It makes sense to use the recommended structure
CSCE 431 Requirements
Example Section: Scope
• Identify software product to be produced by
name (e.g., Host DBMS, Report Generator,
etc.)
• Explain what the product will and will not do
• Describe application of the software: goals and
benefits
• Establish relation with higher-level system
requirements if any
CSCE 431 Requirements
Example Section: Product
Perspective
• Describe relation with other products if any
• Examples:
•
•
•
•
•
•
•
•
System interfaces
User interfaces
Hardware interfaces
Software interfaces
Communications interfaces
Memory
Operations
Site adaptation requirements
CSCE 431 Requirements
Example Section: Constraints
• Describe any properties that will limit the
developers’ options
• Examples:
•
•
•
•
•
•
•
•
•
•
Regulatory policies
Hardware limitations (e.g., signal timing requirements)
Interfaces to other applications
Parallel operation
Audit functions
Control functions
Higher-order language requirements
Reliability requirements
Criticality of the application
Safety and security considerations
CSCE 431 Requirements
Specific Requirements
(Section 3)
• This section brings requirements to a level of
detail usable by designers and testers
• Examples:
•
•
•
•
•
•
•
Details on external interfaces
Precise specification of each function
Responses to abnormal situations
Detailed performance requirements
Database requirements
Design constraints
Specific attributes such as reliability, availability,
security, portability
CSCE 431 Requirements
Possible Section 3 Structure
3. Specific requirements
3.1 External interfaces
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Functional requirements…
3.3 Performance requirements…
3.4 Design constraints…
3.5 Quality requirements…
3.6 Other requirements
CSCE 431 Requirements
Requirements and Agile
Methods
• Under XP (Extreme Programming)
• Requirements are taken into account as defined at the
particular time considered
• Requirements are largely embedded in test cases
• Benefits
• Test plan will be directly available
• Customer involvement
• Risks
• Change may be difficult (refactoring)
• Structure may not be right
• Tests only cover the foreseen cases
• Possibly useful advise
• Retain the best agile practices, in particular frequent
iterations, customer involvement, centrality of code and testing
• Disregard those that contradict proven SE principles
CSCE 431 Requirements
Recipes for Good
Requirements
• Managerial aspects:
• Involve all stakeholders
• Establish procedures for controlled change
• Establish mechanisms for traceability
• Treat requirements document as one of the
major assets of the project; focus on clarity,
precision, completeness
• Technical aspects:
• How to be precise? Formal methods?
CSCE 431 Requirements
Using Natural Language for
Requirements
• Keys are:
•
•
•
•
•
•
Structure
Precision (including precise definition of all terms)
Consistency
Minimizing forward and outward references
Clarity
Conciseness
CSCE 431 Requirements
Advice on Natural Language
• Apply the general rules of “good writing” (e.g. Strunk &
White)
• Use active form (Counter-example: “the message will be
transmitted. . . ”). This forces you to state who does what
• Use prescriptive language (“shall… ”)
• Separate domain properties and requirements
• For delicate or complex issues, use complementary
formalisms:
• Illustrations (with precise semantics)
• Formal descriptions, with explanations in English
• Even for natural language specs, a mathematical detour
may be useful
CSCE 431 Requirements
Advice on Natural Language
• When using numbers, identify the units
• When introducing a list, describe all the
elements
• Use illustrations to clarify
• Define all project terms in a glossary
• Consider placing individual requirements in a
separate paragraph, individually numbered
• Define generic verbs (“transmitted”, “sent”,
“downloaded”, “processed”. . . ) precisely
M. Mannion and B. Keepence, SMART Requirements, ACM SIGSOFT SENotes, vol. 20, no. 2, pp. 42-47, April 1995.
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
Techniques for Requirements
Elicitation
• Questionnaires: Asking the end user a list of
pre-selected questions
• Task Analysis: Observing end users in their
operational environment
• Scenarios: Describe the use of the system as a
series of interactions between a specific end
user and the system
• Use Cases: Abstractions that describe a class
of scenarios
CSCE 431 Requirements
Scenario
• A description of an event or series of actions and events
• In SE: a description of a use/uses of a system
• The description is written from an end user’s point of view
• A scenario can include text, video, pictures and story boards. It
usually also contains details about the work place, social
situations and resource constraints
• A narrative description of what people do and experience as they
try to make use of computer systems and applications [M. Carroll,
Scenario-Based Design, Wiley, 1995]
• A concrete, focused, informal description of a single feature of the
system used by a single actor
• Goal is to increase understanding of the system
Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns
CSCE 431 Requirements
Rationale for Scenarios
• For many, it is easier to relate to real-life
examples than to abstract descriptions of
possible behaviors
• People can understand and critique a scenario
of a planned interaction with a system
CSCE 431 Requirements
Finding Scenarios
• Do not expect the client to be verbose if the
system does not exist
• Client understands the application domain (problem
domain), not the solution domain
• Do not wait for information even if the system
exists
• “What is obvious does not need to be said”
• Dialog
• Developer helps the client to formulate the requirements
• Client helps the developer to understand the
requirements
• The requirements evolve while the scenarios are being
developed
Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns
CSCE 431 Requirements
Scenario Example
Bob, driving down Main Street in his patrol car, notices smoke
coming out of a warehouse. His partner, Alice, reports the
emergency from their car.
Alice enters the address of the building into her wearable
computer, a brief description of its location (i.e., NW corner),
and an emergency level. She confirms her input and waits for
an acknowledgment.
John, the dispatcher, is alerted to the emergency by a beep of
his workstation. He reviews the information submitted by Alice
and acknowledges the report. He allocates a fire unit and
sends the estimated arrival time (ETA) to Alice. Alice receives
the acknowledgment and the ETA.
• Observations
• Concrete
• Describes a single instance, not all possible situations
• Mentions participants
CSCE 431 Requirements
Heuristics
• Useful questions:
• What are the primary tasks that the system needs to
perform?
• What data will an actor create, store, change, remove or
add in the system?
• What external changes does the system need to know
about?
• What changes or events will an actor of the system need
to be informed about?
• Instead of only relying on questions and
questionnaires, perform task observation if the
system already exists (interface engineering or
reengineering)
• Speak with end users, not just to the client
• Expect resistance
Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns
CSCE 431 Requirements
Use Cases
• A use case defines a goal-oriented set of
interactions between external actors and the
system under consideration.
• Actors are parties outside the system that interact
with the system
• An actor may be a class of users, roles users can play,
or other systems.
• A use case is initiated by a user with a particular
goal in mind, and completes successfully when
that goal is satisfied.
• Includes possible variants of a sequence
interactions satisfying the goal or variants that lead
to failure
CSCE 431 Requirements
Use Cases
• The system treated as a “black box” (== the
interactions with system, including system responses,
are as perceived from outside the system)
• Use cases capture who (actor) does what (interaction)
with the system, for what purpose (goal), without
dealing with system internals
• A complete set of use cases specifies all the different
ways to use the system, and therefore defines all
behavior required of the system, bounding the scope of
the system.
• Use case steps are written in an easy-to-understand
structured narrative using the vocabulary of the domain
• With some help from graphical notations, such as UML use
case and sequence diagrams
CSCE 431 Requirements
Use Cases and Scenarios
• Use cases (often) defined based on scenarios
• Use cases vs. scenarios:
• Use case encapsulates a set of scenarios
• Each scenario is a single thread through a use case
CSCE 431 Requirements
Outline
• Motivation
• Ethics
• Overview of Requirements Task
• Recognizing Good Requirements
• Standards and Methods
• Requirements Elicitation
• About UML
CSCE 431 Requirements
What is UML?
• UML == Unified Modeling Language
• Nonproprietary standard for modeling software systems, OMG
• Convergence of notations used in object-oriented methods
• OMT (Object Modeling Technique, James Rumbaugh and colleagues)
• Booch (Grady Booch)
• OOSE (Ivar Jacobson)
• Current Version: UML 2.3 (May 2010)
• Information at the OMG portal http://www.uml.org
• Commercial tools:
• Rational (IBM), Together (Borland), Visual Architect (business processes,
BCD)
• Open Source tools:
• ArgoUML, BOUML, Dia,…
CSCE 431 Requirements
UML Diagrams
CSCE 431 Requirements
UML Diagrams
• Use case diagrams
• Describe the functional behavior of the system as seen by the
user
• Class diagrams
• Describe the static structure of the system: Objects, attributes,
associations
• Sequence diagrams
• Describe the dynamic behavior between objects of the system
• Statechart diagrams
• Describe the dynamic behavior of an individual object
• Activity diagrams
• Describe the dynamic behavior of a system, in particular the
workflow
CSCE 431 Requirements
UML Conventions
• All UML Diagrams are graphs of nodes and edges
• Nodes are entities and drawn as rectangles or ovals
• Rectangles denote classes or instances
• Ovals denote functions
• Names of Classes are not underlined
• SimpleTimer
• Employee
• Names of Instances are underlined
• aTimer:SimpleTimer
• JohnSmith:Employee
• An edge between two nodes denotes a relationship
between the corresponding entities
CSCE 431 Requirements
Use Case Diagrams
• Used during requirements elicitation and
analysis to represent behavior visible from
outside the system
• An actor represents a role (a specific kind of a
user of the system)
• A use case represents a class of functionality
provided by the system
• Use case model is the set of all use cases that
completely describe the system functionality
CSCE 431 Requirements
Actor
• A model for an external entity that interacts
with the system
• End user, administrator
• External system
• Physical environment (weather)
• Has a unique name and an optional description
• Examples:
• Student: a person that studies
• Teaching assistant: member of teaching staff who
supports the instructor
• Random number generator
CSCE 431 Requirements
Use Case
• Class of functionality
• Focus of description of a use case is the event
flow between actors and system
• Not just UML use case diagrams, narrative
should describe in detail:
•
•
•
•
•
•
Participating actors
Entry condition
Flow of events
Exit condition
Exceptions
Nonfunctional requirements
CSCE 431 Requirements
Use Case Model
Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns
CSCE 431 Requirements
Related Use Cases
• Extend Relationship
• To represent seldom invoked use cases or exceptional
functionality
• «extend» relationships model exceptional or seldom invoked
cases
• The exceptional event flows are factored out of the main event
flow for clarity
• The direction of an «extend» relationship is to the use case
being extended
• Use cases representing exceptional flows can extend more than
one use case.
• Include Relationship
• To represent functional behavior common to more than one
use case
• «include» behavior is factored out for reuse, not
because it is an exception
• The direction of an «include» relationship is to the use
case being used
CSCE 431 Requirements
Example: extend, include
Bruegge, Dutoit: Object-Oriented Software Engineering: Using UML, Java, and Patterns
CSCE 431 Requirements
Description Example
1. Name: DoHomework
2. Participating actor:
Student
3. Entry condition:
1. Student ready to
download exercise sheet
4. Exit condition:
1. Student delivered solution
5. Flow of events:
5.1. Student downloads
the exercise sheet
5.2. Student reads
through the assignments
5.3. Student processes the
assignments and types the
solution in his Computer.
5.4. Student prints out
the solution
5.5. Student delivers the
solution through the
submission system
6. Special requirements:
None
CSCE 431 Requirements
Advice
• A good use case must:
•
•
•
•
Describe a business task
Not be implementation-specific
Provide appropriate level of detail
Be short enough to be implemented by one
developer in one release
CSCE 431 Requirements
Value of Use Cases Debated
• According to Meyer:
Use cases are a minor tool for requirement elicitation
but not really a requirement technique. They cannot
define the requirements:
•
•
•
•
Not abstract enough
Too specific
Describe current processes
Do not support evolution
“Use cases are to requirements what tests are to
software specification and design”
• Cannot capture all requirements of a system
CSCE 431 Requirements
Summary of Requirements
• Goal: SRS that describe the problem, not solution
• Variety of sources and means for eliciting
requirements
• Use what makes most sense in the situation
• Variety of definition and specification techniques
• Use what makes most sense in the situation
• Requirements should be validated (that they meet
customer expectations)
• Specifications should be verified (that they satisfy
requirements)
CSCE 431 Requirements