CSC480
Software Engineering
Lecture 6
September 8, 2004
Topics
User & system requirements
 Functional & non-functional requirements
 Ways to express requirements

Requirement Analysis

Requirements generally express what an
application is meant to do (i.e., explore the
problem domain)
 Generally,
they don’t try to express how to accomplish
these functions (i.e., explore the solution domain)
What Is a Requirement?

The following statement (Y) sounds like one
 The
system should allow the user to access his
account balance

And what is not? See the following statement (N)
 Customers’
account balances will be stored in a table
called “balance” in an Access database
Types of Requirement

Targeted audience
– targeted primarily for customers, in
a non-techie format
 D-requirements – targeted primarily for developers,
with detailed descriptions
 C-requirements

Levels of description
Requirements Readers
User requirements
Client managers
System end-users
Client engineers
Contractor managers
System architects
System requirements
System end-users
Client engineers
System architects
Software developers
Software design
specification
Client engineers (perhaps)
System architects
Software developers
Types of Requirement

Levels of description
 As


 As


the basis for a bid for a contract
A high-level abstract statement of a service or of a system
constraint
Open for interpretation
the contract itself
A detailed mathematical functional specification
must be defined in detail
Definitions and Specifications
Requirements definition
1. The software must provide a means of repr esenting and
1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Why Req’ts Must Be Written?


Developers tend to believe that the source code
express all the requirements
But without requirements, the team cannot
 Know
what goals it is trying to accomplish
 Inspect and test its work properly
 Track its productivity
 Gather data for estimations in future projects
 Satisfy its customer
Each Requirement Must Be









expressed properly, (clarity)
made easily accessible, (accessibility)
numbered, (traceability)
accompanied by tests that verify it, (testability)
provided for in the design, (traceability)
accounted for by code, (traceability)
tested in isolation, (testability)
tested in concert with other requirements, and (testability)
validated by testing after the application has been built.
(testability)
IEEE 830-1993 SRS Table of Contents
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications
interfaces
2.1.6. Memory constraints
2.1.7. Operations
2.1.8. Site adaptation
requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and
dependencies
2.6. Apportioning of
requirements
3. Specific requirements
-- see chapter four -4. Supporting information
-- see chapter four --
Functional v.s. Non-Functional

Functional requirements
 Specify

services must be provided
Non-functional requirements
 Performance – speed, throughput
 Reliability
and availability
 Error handling
 Interfaces (with user or other applications)
 Constraints – tool & language, standards, platform, etc

Inverse requirements – what the app doesn’t do
Non-functional
requirement types
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Desired Attributes for SRD





Completeness
Consistency
Nonambiguity
Each requirement should be testable
Each requirement should be numbered and the
number should be used in tracing the fulfillment
in design through testing
Problems w/ Natural Language

Lack of clarity


Requirements confusion


Precision is difficult without making the document
difficult to read
Functional and non-functional requirements tend to
be mixed-up
Requirements amalgamation

Several different requirements may be expressed
together
Editor Grid Requirement
2.6 Grid facilities To assist in the positioning of entities on
a diagram, the user may turn on a grid in either centimetres
or inches, via an option on the control panel. Initially, the
grid is off. The grid may be turned on and off at any time
during an editing session and can be toggled between inches
and centimetres at any time. A grid option will be provided
on the reduce-to-fit view but the number of grid lines shown
will be reduced to avoid filling the smaller diagram with grid
lines.
Requirement problems

Grid requirement mixes three different kinds of
requirement



Conceptual functional requirement (the need for a
grid)
Non-functional requirement (grid units)
Non-functional UI requirement (grid switching)
Structured presentation
2.6 Grid f acilities
2.6.1
The editor shall provide a grid facility wh ere a
matrix of horizontal and ver tical lines provide a
background to the editor windo w. T his grid shall be
a p assive grid where the alignme nt of entities is the
user's responsibility.
Rationale: A grid helps the user to create a tidy
diagram with well-spaced entities. Although an active
grid, where entities 'snap-to' grid lines can be useful,
the positioning is imprecise. The user is the best person
to decide where entities should be positioned.
Specification: ECL IPSE/WS/Tools/DE/FS Section 5.6
Using Diagrams – informal

Story-boarding
 Informal

diagrams with icons and links
Mock-up screens
 Use
simple GUI screens/pages to illustrate navigation
among them
Using Diagrams – formal

Use case diagrams
 Actors-system

Data flow diagrams (DFD)
 Data

interactions
traffic among processing units
State-transition diagrams
 The
logics of transitioning from one state to another
Initialize Use Case for Encounter
actors
Encounter
Use case
Initialize
player
Travel to
adjacent
area
Encounter
foreign
character
designer
Set rules
Use case details
Initialize
1. System displays player’s
main character in the
dressing room.
2. System displays a window
for setting his character's
qualities.
3. Player allocates the
qualities of his main
character.
4. Player chooses an exit
from the dressing room.
5. System moves player’s
main character into the area
on the other side of the exit.
Engage Foreign Character Use Case
Encounter
Use case
Initialize
player
Travel to
adjacent
area
Engage
foreign
character
designer
Set rules
Use case details
Engage Foreign Character
1. System displays the
foreign character in the
same area as the player’s.
2. System exchanges
quality values between the
two characters.
3. System displays the
results of the engagement.
4. System displays player’s
character in a random
area.
Data Flow Diagram: Explanation of Symbols
Processing
element
Get
deposit
Direction
of data flow
Check
deposit
Account #
& deposit
Data type
Data Flow Diagram: Explanation of Symbols
Processing
element
Input
Get
deposit
Direction
of data flow
Check
deposit
User
Account #
& deposit
Output
Data type
Printer
…...
balance
query
account
Data store
database
account
data
Create
account
summary
Partial Encounter State-Transition Diagram
Preparing
Setting up
Complete
setup
Waiting
Player
clicks
qualities
menu
Foreign
character
enters
area
Engaging
Using Conditions in State-Transition Diagrams
state
event
Waiting
Player
moves to
adjacent
area
condition
[foreign
character
present]
[foreign
character
absent]
Engaging
condition
state