Lecture 01 RE Fundamentals

Requirements
Engineering
fundamentals
SWENG 580: advanced software
engineering
What is requirements engineering ?
What are requirements?
How are requirements specified?

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

2
SWENG 580: Advanced Software Engineering
What is requirements engineering?
Requirements engineering is the branch of software engineering
concerned with the real-world goals for, functions of, and constraints
on software systems. It is also concerned with the relationship of
these factors to precise specifications of software behavior, and to
their evolution over time and across software families. (Zave, 1997)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

3
real world goals
Motivation for development of the software system
Why are we building the system?
What system are we building?

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

4
precise specification
Provide the basis for
Analyzing the requirements
Validating that these requirements are what stakeholders want
Defining what the designers have to build
Verifying that the designers have built the right system

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

5
evolution over time and across software
families
Emphasizes the reality of
A changing world
The need to reuse partial specifications

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

6
Core RE activities
Planning and Eliciting requirements.
Who is the target for elicitation?
What techniques are used for elicitation?
Are requirements feasible?
How to identify and manage risk?
Modeling and Analyzing requirements.
How formal and abstract should be the model?
How expressive is the model? Does it support multiple different viewpoints?
What are the techniques for modeling enterprises, information structures, and
behavior?
How do you model quality requirements?
Communicating and Agreeing requirements.
How are requirements documented?
How do you negotiate and prioritize requirements?
How do you review and inspect requirements?
How do you validate requirements?
Realizing and Evolving requirements
How do you manage change?
How do you manage inconsistency?
What about traceability?.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

7
RE draws from diverse disciplines
Computer science
logic formalisms allow analysis of specifications
Systems engineering
characterizing systems
identifying system boundaries
And

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

8
Philosophy
Epistemology understanding beliefs of stakeholders
Phenomenology what is observable in the world
Ontology what can be agreed on as objectively true

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

9
Cognitive psychology
Provides an
understanding of the
difficulties people may
have in describing their
needs.
Domain experts utilize
subconscious knowledge
that they cannot
articulate leading to a
mismatch between their
response to questions
and their actual behavior.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

10
Anthropology
Observing human activities helps in understanding how computer
systems may help or hinder those activities.
Ethnomethodology has been used to develop observational techniques for analyzing
team-working (also termed ethnography)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

11
Sociology
Understanding the political and cultural changes caused by
technology.
Introduction of a computer system can change many things:
An organizations way of working
An organizations structure
Communication paths
Even the original needs that it was built to satisfy
Must ensure the process doesnt become politicized possibly by
involving those most affected by the system

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

12
Linguistics
RE is about communication.
Ambiguity and misunderstanding is easy when natural language is
used to express requirements.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

13
What is a requirement?
Can range from a high-level, abstract statement of a service or
constraint to a detailed, formal specification.
Why?
Requirements may be basis for a bid so must be open to interpretation.
Requirements may be part of the contract itself so must be defined in detail.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

14
Requirement abstraction
If a company wishes to let a contract for a large software
development project, it must define its needs in a sufficiently abstract
way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering,
perhaps, different ways of meeting the client organization's needs.
Once a contract has been awarded, the contractor must write a
system definition for the client in more detail so that the client
understands and can validate what the software will do. Both of
these documents may be called the requirements document for the
system. (Davis, 1993)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

15
Requirement separates the problem from the
solution
A separate
problem
description is
useful as it can
serve as a basis
for discussion
with stakeholders
to see if it
corresponds to
their needs,
evaluating design
choices and
generating test
cases
Figures Steve Easterbrook

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

16
But this is not a sequential process
Requirements engineering is iterative; a complete problem
specification does not have to exist before the solution
In fact, the problem statement is never fixed and change is inevitable
Perfecting a problem statement may not be cost effective either

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

17
Requirements classification
To cope with this duality we can classify requirements in terms of
their level of abstraction.
Sommerville (2005) suggests:
User requirements
System requirements
Software design specifications

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

18
User requirements
Abstract statements written in natural language with accompanying
informal diagrams.
Specify what services (user functionality) the system is expected to
provide and any constraints.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

19
System requirements
Detailed descriptions of the services and constraints.
Should be structured and precise.
Acts as contract between client and contractor.
Sometimes referred to as functional specification or technical annex.
Derived from analysis of the user requirements.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

20
Software design specifications
The analysis and design documentation used as basis for
implementation by developers.
Derived from analysis of the system specification

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

21
Example
User requirement
1. The software must allow a user to access, and subsequently bet on
individual sporting events
System Requirement
1.1 The user should be presented with the available sporting events
1.2 Facilities should be provided to allow the user to search the available
events based upon the sport, the date/time or by competitor.
1.3 The software should allow users to select one or more events from the
selection.
1.4 The selected events should be presented along with the current odds
for each event and outcome.
1.5 The software should allow the user to place a bet on any of those
events in the selection.
1.6 The software should record that bet, updating the users account.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

22
Another classification
Functional requirements
Non-functional requirements
Domain requirements

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

23
Functional requirements
The services the system should provide.
How it will react to inputs.
Sometimes state what the system should not do.
Can be high-level and general (user requirements) or detailed,
expressing inputs, outputs, exceptions, etc. (system requirements)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

24
Non-functional requirements
Requirement imposed by the environment in which the system is to
exist.
This could mean timing constraints, quality properties, standard
adherence, programming languages to be used

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

25
Non-functional requirement types
Non-functional
requirements
Product
requirements
Organisational
requirements
External
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Usability
requirements
Delivery
requirements
Implementation
requirements
Standards
requirements
Legislative
requirements
Space
requirements
Performance
requirements
Privacy
requirements
Safety
requirements

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

26
Goals versus requirements
Some NFRs are difficult to define precisely making them difficult to
verify.
Should distinguish goals from NFRs

Goal a general intention of a stakeholder

The system should be easy to use by experienced operators

Verifiable NFR statement using some objective measure.

Experienced operators shall be able to use all the system functions
after 2 hours of training

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

27
Domain requirements
Derived from the application domain.
May be:
New functional requirements.
Constraints on existing functional requirements.
Specify how particular computations must be performed.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

28
Train protection system
The deceleration of the train shall be computed as:
D
train
= D
control
+ D
gradient

where D
gradient
is 9.81ms
2
* compensated gradient/alpha and where
the values of 9.81ms
2
/alpha are known for different types of train.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

29
Eh!
The example highlights an important issue with domain
requirements.
They are often expressed by domain experts using domain-specific
terminology.
They are used by software engineers unfamiliar with the intricacies
of the domain.
Additionally, domain experts often leave out information from a
requirement as they understand the area so well.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

30
User requirements
Describe functional and non-functional requirements as they pertain
to externally visible behavior in a form understandable by clients
and/or system users.
Use natural language, tables and simple intuitive diagrams.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

31
Problems with natural language
Lack of clarity
Precision is difficult without making the document difficult to read
Requirements confusion
Functional and non-functional requirements tend to be mixed-up
Requirements amalgamation
Several different requirements may be expressed together

Hence the need for linguistics knowledge!

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

32
Example: database requirement
The database shall support the generation and control of
configuration objects; that is, objects which are themselves
groupings of other objects in the database. The configuration control
facilities shall allow access to the objects in a version group by the
use of an incomplete name.

Fault: Includes both conceptual and detailed information
Describes the concept of configuration control facilities
Includes the detail that objects may be accessed using an incomplete name

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

33
Example: 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 centimeters 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 centimeters 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.

Fault: Grid requirement mixes three different kinds of requirement
Conceptual, functional requirement states that the editing system should provide a grid
and presents the rationale.
Non-functional requirement giving detailed information about grid units.
Non-functional UI requirement which defines how that grid is switched on and off by
user.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

34
Guidelines for writing requirements
Invent a standard format and use it for all requirements
Use language in a consistent way.
Use shall for mandatory requirements,
Use should for desirable requirements
Use text highlighting to identify key parts of the requirement
Avoid the use of technical language

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

35
Example: editor grid requirement
2.6 Grid facilities

2.6.1 The editor shall provide a grid facility where a matrix of
horizontal and vertical lines provide a background to the editor
window. This grid shall be a passive grid where the alignment
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.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

36
Example: editor node requirement
3.5.1 Adding nodes to a design
3.5.1.1 The editor shall provide a facility for users to add nodes of
a specified type to their design.
3.5.1.2 The sequence of actions to add a node should be as
follows:
1. The user should select the type of node to be added.
2. The user should move the cursor to the approximate node
position in the diagram and indicate that the node symbol
should be added at that point.
3. The user should then drag the node symbol to its final
position.

Rationale: The user is the best person to decide where to position a
node on the diagram. This approach gives the user direct control
over node type selection and positioning.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

37
System requirements
More detailed specifications of user requirements
Serve as a basis for designing the system
May be used as part of the system contract
System requirements may be expressed using system models (first
iteration of analysis models)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

38
More problems with NL specification
Ambiguity
The readers and writers of the requirement must interpret the same words in the same
way. NL is naturally ambiguous so this is very difficult
Over-flexibility
The same thing may be said in a number of different ways in the specification
Lack of modularization
NL structures are inadequate to structure system requirements

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

39
Alternatives to natural language

Notation Description
Structured
natural
language
This approach depends on defining standard forms or
templates to express the requirements specification.
Design
description
languages
This approach uses a language like a programming language
but with more abstract features to specify the requirements by
defining an operational model of the system.
Graphical
notations
A graphical language, supplemented by text annotations is
used to define the functional requirements for the system. An
early example of such a graphical language was SADT
(Schoman and Ross, 1977). More recently, use-case
descriptions (Jacobsen, Christerson et al., 1993) have been
used.
Mathematical
specifications
These are notations based on mathematical concepts such as
finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer and
contractor about system functionality. However, most
customers dont understand formal specifications and are
reluctant to accept it as a system contract.

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

40
Structured language specification
A limited form of natural language may be used to express
requirements
This removes some of the problems resulting from ambiguity and
flexibility and imposes a degree of uniformity on a specification
Often best supported using a forms-based approach

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

41
Form-based specification
Include the following information:
1. Definition of the function or entity
2. Description of inputs and where they come from
3. Description of outputs and where they go to
4. Indication of other entities required
5. Pre- and post-conditions (if appropriate)
6. The side effects (if any)

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

42
Example: form-based node specification
Function Add node
Description Adds a node to an existing design. The user selects the
type of node, and its position. When added to the
design, the node becomes the current selection. The
user chooses the node position by moving the cursor to
the area where the node is added.
Inputs Node type, Node position, Design identifier
Outputs Design identifier
Destination The design database. The design is committed to the
database on completion of the operation.
Requires Design graph rooted at input design identifier
Pre-condition The design is open and displayed on the user's screen
Post-condition The design is unchanged apart from the addition of a
node of the specified type at the given position
Side-effects None

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

43
PDL-based requirements definition
Requirements may be defined operationally using a language like a
programming language but with more flexibility of expression
Most appropriate in two situations
Where an operation is specified as a sequence of actions and the order is important
When hardware and software interfaces have to be specified
Disadvantages are
The PDL may not be sufficiently expressive to define domain concepts
The specification will be taken as a design rather than a specification
Notation is only understandable to people with programming language knowledge

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

44
Part of ATM specification

class ATM {
// declarations here
public static void main (String args[]) throws InvalidCard {
try {
thisCard.read () ; // may throw InvalidCard exception
pin = KeyPad.readPin () ; attempts = 1 ;
while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;
}
if (!thisCard.pin.equals (pin))
throw new InvalidCard ("Bad PIN");
thisBalance = thisCard.getBalance () ;
do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;
switch (service) {
case Services.withdrawalWithReceipt:
receiptRequired = true ;

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

45
Interface specification
Most systems must operate with other systems and the operating
interfaces must be specified as part of the requirements
Three types of interface may have to be defined
Procedural interfaces
Data structures that are exchanged
Data representations
Formal notations are an effective technique for interface
specification

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

46
PDL interface specification
interface PrintServer {

// defines: an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue,
cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

47
The requirements document
The requirements document is the official statement of what is
required of the system developers
Should include both a definition and a specification of requirements
It is NOT a design document. As far as possible, it should be a set of
WHAT the system should do rather than HOW it should do it

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

48
Users of requirements document
Specify the requirements and read them to
check that they meet their needs. They
specify changes to the requirements
Use the requirements document to plan a
bid for the system and to plan the system
development process
Use the requirements to understand what
system is to be developed
Use the requirements to develop validation
tests for the system
Use the requirements to help understand
the system and the relationship between its
parts
Customers
Managers
Developers
Test engineers
Maintenance engineers

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

49
Requirements for a requirements document
Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the system i.e. predict
changes
Characterize responses to unexpected events

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

50
Key points
Requirements set out what the system should do and define
constraints on its operation and implementation
Functional requirements set out services the system should provide
Non-functional requirements constrain the system being developed
or the development process
User requirements are high-level statements of what the system
should do
User requirements should be written in natural language, tables and
diagrams
System requirements are intended to communicate the functions
that the system should provide
System requirements may be written in structured natural language,
a PDL or in a formal language
A software requirements document is an agreed statement of the
system requirements

E
n
g
i
n
e
e
r
i
n
g

D
i
v
i
s
i
o
n
,

T
h
e

P
e
n
n
s
y
l
v
a
n
i
a

S
t
a
t
e

U
n
i
v
e
r
s
i
t
y

51
References
A. Davis, Software Requirements: Objects, Functions and States,
Second Edition, Upper Saddle River, NJ: Prentice-Hall, 1993.
B. Nuseibeh and S. Easterbrook,Requirements Engineering: A
Roadmap, Proceedings of the International Conference on Software
Engineering, Limerick, Ireland, June 2000, pp. 35 46.
I. Sommerville, Software Engineering, 7
th
ed., Boston, MA: Addison-
Wesley, 2005.
P. Zave, Classification of Research Efforts in Requirements
Engineering, ACM Computing Surveys, 29(4), pp 315 321.

Lecture 01 RE Fundamentals

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 01 RE Fundamentals

Uploaded by

Copyright:

Available Formats

Requirements

You might also like