Introduction to Software Engineering

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

74 εμφανίσεις

Introduction to Software Engineering

Lecture 5

André
van der
Hoek

Today’s Lecture


Requirements engineering



Requirements specification



Recurring, Fundamental Principles


Rigor and formality


Separation of concerns


Modularity


Abstraction


Anticipation of change


Generality


Incrementality


These principles apply to all aspects of software engineering

ICS 52 Life
Cycle

Requirements

phase

Verify

Design

phase

Verify

Implementation

phase

Test

Testing

phase

Verify

Requirements Phase


Terminology


Requirements analysis/engineering


Activity

of unearthing a customer’s needs


Requirements specification


Document

describing a customer’s needs


Note: requirements address what a customer
needs
, not what a customer wants


A customer often does not know what they
want,
let alone what they need


Time
-
lag between initial desire and future need


Long and arduous,
often educational
, process



Requirements Analysis


System engineering versus software
engineering


What role does software play within the full
solution?


Trend: software is everywhere


Contract
model versus participatory design


Contract: carefully specify requirements, then
contract out the development


Participatory: customers, users, and software
development staff work together throughout the
life cycle

Techniques for Requirements Analysis


Interview customer


Create use cases/scenarios


Prototype solutions


Observe customer


Identify important objects/roles/functions


Perform research


Construct glossaries


Question yourself

Use the principles

Requirements Specification


Serves as the fundamental reference point between
customer and software producer


Defines capabilities to be provided without saying
how they should be provided


Defines the “what”


Does not define the “how”


Defines environmental requirements on the software
to guide the implementers


Platforms, implementation language(s), …


Defines constraints on the software


Performance, usability, …


Defines software qualities

Why Spend a Lot of Time?


A requirements specification is
the

source for
all future steps in the software life cycle


Lays the basis for a mutual understanding


Consumer (what they get)


Software producer (what they build)


Identifies fundamental assumptions


Potential basis for future contracts


Better get it right


Upon delivery, some software is actually rejected
by customers


Changes are cheap


Better make them now rather than later


U
s
e

t
h
e

r
e
q
u
i
r
e
m
e
n
t
s

t
o
d
e
v
e
l
o
p

v
a
l
i
d
a
t
i
o
n

t
e
s
t
s

f
o
r
t
h
e

s
y
s
t
e
m
U
s
e

t
h
e

r
e
q
u
i
r
e
m
e
n
t
s
d
o
c
u
m
e
n
t

t
o

p
l
a
n

a

b
i
d

f
o
r
t
h
e

s
y
s
t
e
m

a
n
d

t
o

p
l
a
n

t
h
e
s
y
s
t
e
m

d
e
v
e
l
o
p
m
e
n
t

p
r
o
c
e
s
s
U
s
e

t
h
e

r
e
q
u
i
r
e
m
e
n
t
s

t
o
u
n
d
e
r
s
t
a
n
d

w
h
a
t

s
y
s
t
e
m

i
s

t
o
b
e

d
e
v
e
l
o
p
e
d
S
y
s
t
e
m

t
e
s
t
e
n
g
i
n
e
e
r
s
M
a
n
a
g
e
r
s
S
y
s
t
e
m

e
n
g
i
n
e
e
r
s
S
p
e
c
i
f
y

t
h
e

r
e
q
u
i
r
e
m
e
n
t
s

a
n
d
r
e
a
d

t
h
e
m

t
o

c
h
e
c
k

t
h
a
t

t
h
e
y
m
e
e
t

t
h
e
i
r

n
e
e
d
s
.

T
h
e
y
s
p
e
c
i
f
y

c
h
a
n
g
e
s

t
o

t
h
e
r
e
q
u
i
r
e
m
e
n
t
s
S
y
s
t
e
m

c
u
s
t
o
m
e
r
s
U
s
e

t
h
e

r
e
q
u
i
r
e
m
e
n
t
s

t
o

h
e
l
p
u
n
d
e
r
s
t
a
n
d

t
h
e

s
y
s
t
e
m

a
n
d
t
h
e

r
e
l
a
t
i
o
n
s
h
i
p
s

b
e
t
w
e
e
n

i
t
s
p
a
r
t
s
S
y
s
t
e
m
m
a
i
n
t
e
n
a
n
c
e
e
n
g
i
n
e
e
r
s
Users of a Requirements Document

Non
-
Functional Requirement Types

P
e
r
f
o
r
m
a
n
c
e
r
e
q
u
i
r
e
m
e
n
t
s
S
p
a
c
e
r
e
q
u
i
r
e
m
e
n
t
s
U
s
a
b
i
l
i
t
y
r
e
q
u
i
r
e
m
e
n
t
s
E
f
f
i
c
i
e
n
c
y
r
e
q
u
i
r
e
m
e
n
t
s
R
e
l
i
a
b
i
l
i
t
y
r
e
q
u
i
r
e
m
e
n
t
s
P
o
r
t
a
b
i
l
i
t
y
r
e
q
u
i
r
e
m
e
n
t
s
I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
r
e
q
u
i
r
e
m
e
n
t
s
E
t
h
i
c
a
l
r
e
q
u
i
r
e
m
e
n
t
s
L
e
g
i
s
l
a
t
i
v
e
r
e
q
u
i
r
e
m
e
n
t
s
I
m
p
l
e
m
e
n
t
a
t
i
o
n
r
e
q
u
i
r
e
m
e
n
t
s
S
t
a
n
d
a
r
d
s
r
e
q
u
i
r
e
m
e
n
t
s
D
e
l
i
v
e
r
y
r
e
q
u
i
r
e
m
e
n
t
s
S
a
f
e
t
y
r
e
q
u
i
r
e
m
e
n
t
s
P
r
i
v
a
c
y
r
e
q
u
i
r
e
m
e
n
t
s
P
r
o
d
u
c
t
r
e
q
u
i
r
e
m
e
n
t
s
O
r
g
a
n
i
z
a
t
i
o
n
a
l
r
e
q
u
i
r
e
m
e
n
t
s
E
x
t
e
r
n
a
l
r
e
q
u
i
r
e
m
e
n
t
s
N
o
n
-
f
u
n
c
t
i
o
n
a
l
r
e
q
u
i
r
e
m
e
n
t
s
Structure


Introduction


Executive summary


Application context


Functional requirements


Environmental requirements


Software qualities


Other requirements


Time schedule


Potential risks


Future changes


Glossary


Reference documents

Introduction


What is this document about?


Who was it created for?


Who created it?


Outline

Executive Summary


Short, succinct, concise, to
-
the
-
point,
description


Usually no more than one page


Identifies main goals


Identifies key features


Identifies key risks/obstacles

Application Context


Describes the situation in which the software
will be used


How will the situation change as a result of
introducing the software?


“World Model”


Identifies all things that the system affects


Objects, processes, other software, hardware, and
people


Provides an abstraction for each of those,
characterizing the properties and behaviors that
are relevant to the
software system


Identifies fundamental assumptions

Functional Requirements


Identifies all concepts, functions, features,
and information that the system provides to
its users


Provides an abstraction for each of those,
characterizing the properties and functions
that are relevant to the
user


What is the system supposed to do?


What information does the system need?


What is supposed to happen when something
goes wrong?

An approximate user interface is part of functional requirements

Environmental Requirements


Platforms


Hardware


Operating systems, types of machines, memory size,
hard disk space


Software


CORBA, Jini, DCOM, 4GL, …


Programming language(s)


Standards


Software Qualities


Correctness


Reliability


Efficiency


Integrity


Usability


Maintainability




Testability


Flexibility


Portability


Reusability


Interoperability


Other Requirements


What about cost?


What about documentation?


What about manuals?


What about tutorials?


What about on
-
the
-
job training?


What about requirements that do not fit in
any of the previous categories?


Time Schedule


By when should all of this be done?


Initial delivery date


Acceptance period


Final delivery date


What are some important milestones to be
reached?


Architectural design completed


Module design completed


Implementation completed


Testing completed


Potential Risks


Any project faces risks


Boehm’s top ten risks (see lecture
3)


It is important to identify those risks
up
-
front

so
the customer
and you (!)

are aware of them


One of the requirements could be to explicitly address
the risks


Future Changes


Any project faces changes over time


It is important to identify those changes
up
-
front

so the customer
and you (!)

are aware of them


These changes could simply pertain to potential
future enhancements to the product


One of the requirements could be to build the product
such that it can accommodate future changes


Note: structure the requirements document in
such a way that it easily absorbs changes


Define concepts once


Partition separate concerns





Glossary


Precise definitions of terms used throughout
the requirements document

Reference Documents


Pointers to existing processes and tools used
within an organization


Pointers to other, existing software that
provides
similar functionality


Pointers to literature

Observations


Document is structured to address the
fundamental principles


Rigor


Separation of concerns


Modularity


Abstraction


Anticipation of change


Generality


Incrementality


Not every project requires every section of
the document


Specification Methods


Natural language


Data flow diagrams


Office automation


Finite state machines


Telephone systems


Coin
-
operated machines


Petri nets


Production plants


Formulas


Matrix inversion package


Objects (in object
-
oriented methods)


Use cases (in UML)

Verification


Is the requirements specification
complete?


Is each of the requirements
understandable?


Is each of the requirements
unambiguous?


Are any of the requirements
in conflict?


Can each of the requirements be
verified?


Are are all terms and concepts
defined?


Is the requirements specification
unbiased?

Acceptance Test Plan


Accompanies a requirements specification


Specifies, in an operational way, consistency
between the requirements specification and
the system that will be delivered


Binds a customer to accept the delivered
system if it passes all the tests


Covers all aspects of the requirements
specification

V
-
Model of Development and Testing

Develop Acceptance Tests

Acceptance Test Review

Requirements Review

Develop Requirements

Execute System Tests

Develop Integration Tests

Integration Tests Review

Design Review

Design

Execute Integration Tests

Develop Unit Tests

Unit Tests Review

Code Review

Code

Execute Unit Tests

Example


French fries
and mayonnaise
place

Your Tasks

1.
Read and study slides of this lecture


2.
Read
Chapter
9 of van
Vliet


3.
Note: discussion starts Friday