Introduction to Requirements
Specification
1
Outline

Requirement Engineering

Software Lifecycle and Software Processes
2
3
Three Level Requirements



Stakeholder Needs
Features of the System
Software Requirements
4
Stakeholder Needs
(extracted from the slides of Peter Hauker, Rational)
5
Stakeholders in SE

Customers


Users



Those who pay for the software
Those who use the software
Software developers
Development Managers
Problem: The customer often doesn’t have good
grasp of what he wants.
6
Features of the System
7
Software Requirements
8
Importance of Requirements

The set of requirements constitute a
contract between the client and the
software developer
 It should be written such that all
stakeholders can understand what the
system will do.
 It allows developer to map problem
domain concepts to solution domain
concepts
9
Importance of Requirements
10
How Do We … ?

… know what the system is supposed to
do?



By proper
requirements development
… keep track of the current status of
requirements?
… determine the impact of a
requirements change?

By proper
requirements management
11
We are focusing on these stages of RE
Elicitation
Analysis
Negotiation
Validation,
Verification
Introduction
Representation,
Specification
Requirements
Management
12
12
Requirements Engineering:
General View
13
Requirements Development
Process
14
Requirements Development
Process




Elicitation: work with the customer on gathering
requirements
Analysis: process this information to understand it,
classify in various categories, and relate the
customer needs to possible software requirements
Specification: Structure the customer input and
derived requirements as written documents and
diagrams
Validation: you’ll ask your customer to confirm
that what you’ve written is accurate and complete
and to correct errors.
15
What is Requirements Management?
16
Requirements Types
17
Functional Requirements


Describe the functionality or services
that the system is expected to
provide
Address the input-output behavior of
a system
18
Examples of Functional
Requirements
3.1.1{FR1}
Software shall automatically detect the
presence of the network.
3.1.2{FR2}
Software shall automatically detect the
presence of other computers running the
application that are connected to the
network.
19
Non-Functional Requirements
20
Design Constraints
21
Requirements Gathering:
Dice Game

Requirements gathering is the Starting
Point (WHAT, i.e., problem oriented)
Dice Game:
• A player rolls two dice.
 If the total is seven, the player
wins; otherwise he loses.
22
Modeling:
Bridge between Requirements and Solution

Modeling a system involves:




identifying the things that are important
to your particular view
Their properties
consider how specific instances of these
things must fit together.
Modeling a system is affected by
how you expect to use the
system
23
How Do You Expect to Use the
Dice Game ?

“Happy end” scenario
Dice Game:
• Roll two dice.
System:
•CONGRATULATIONS!
You won the game.
24
How Do You Expect to Use the
Dice Game ?

Not so “happy end” scenario
Dice Game:
• Roll two dice.
System:
• Looser, try again …
25
Modeling: Dice Game

Modeling Features:
Dice Game:
• A player rolls two
dice.
 If the total is seven,
the player wins;
otherwise he loses.
Play with one user
and two dice
26
Modeling: Dice Game
Modeling Structure
Rolls
1
Player
2
name
Die
FaceValue
2
1
Plays
1
DiceGame
total
1
Includes
27
Modeling: Dice Game
Modeling Behavior
: DiceGame
Die1: Die
Die2:Die
Play()
roll()
GetFaceValue()
roll()
GetFaceValue()
Result()
Total()
28
Role of Visual Modeling
29
Modeling Requirements:
Requirements Specifications

Definition: “Specifications represent a model of
how inputs are related to system reactions and
outputs”



Specification is an ABSTRACTION of the
Requirements
Needed for: complex, large, or critical problems.
Specifications will increase the technical level of
details given in the requirements
30
Modeling of The Problem: Problems?

Abstraction might capture only part of the
real world truth (i.e., incomplete)




A book may have more than one writers
Somebody else is paid to write the book …
Domain Knowledge is required
Complexity of the Problem is an issue
31
Errors in Requirements
might be also dangerous …
32
References
Collaboration (2006). Requirements Analysis.
http://en.wikipedia.org/wiki/Requirements_engineering
Karl E. Wiegers (2000). When Telepathy Won’t Do: Requirements Engineering
Key Practices.
http://www.processimpact.com/articles/telepathy.html
HCi Consulting (2001-2). Software requirements analysis, and why it doesn't work.
http://www.jiludwig.com/HCI_Journal_article.html
Michael G. Christel, Kyo C. Kang (1992). Issues in Requirements Elicitation.
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf
Mildred Shaw (1997). Soft System Methodology.
http://sern.ucalgary.ca/courses/seng/613/F97/grp2/ssm.htm
References
33
33
References
Pictures:
http://japanesecentral.com/Siryoo/pictureclips/clothes/suit.jpg
http://www.bchu.org/whyweight/Success_Strategy/Content.htm
http://www.customnames.com/NewVinylList.html
http://pacovilla.com/vweb/gallery/slideshow.php?set_albumName=PacosToyBox
http://www.tacojohns.com/HTML/Graphics/Food/Burritos/Medium/ComboBurrito.gif
http://www.cia.gov/cia/information/artifacts/model.htm
All references on recipe cards
References
34
34