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


Requirements specification


Activity of unearthing a customer’s needs
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 environmental requirements on the software
to guide the implementers


Platforms, implementation language(s), …
Defines constraints on the software


Defines the “what”
Does not define the “how”
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





Identifies fundamental assumptions
Potential basis for future contracts
Better get it right


Consumer (what they get)
Software producer (what they build)
Upon delivery, some software is actually rejected
by customers
Changes are cheap

Better make them now rather than later
Users of a Requirements Document
System customers
Specify the requirements and
read them to check that they
meet their needs. They
specify changes to the
requirements
Managers
Use the requirements
document to plan a bid for
the system and to plan the
system development process
System engineers
Use the requirements to
understand what system is to
be developed
System test
engineers
Use the requirements to
develop validation tests for
the system
System
maintenance
engineers
Use the requirements to help
understand the system and
the relationships between its
parts
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
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



Identifies all things that the system affects



How will the situation change as a result of
introducing the software?
“World Model”
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


Software



Operating systems, types of machines, memory size,
hard disk space
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
Structure












Introduction
Executive summary
Application context
Functional requirements
Environmental requirements
Software qualities
Other requirements
Time schedule
Potential risks
Future changes
Glossary
Reference documents
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


Finite state machines




Production plants
Formulas


Telephone systems
Coin-operated machines
Petri nets


Office automation
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 Requirements
Requirements Review
Execute System Tests
Develop Acceptance Tests
Acceptance Test Review
Design
Design Review
Execute Integration Tests
Develop Integration Tests
Integration Tests Review
Code
Code Review
Execute Unit Tests
Develop Unit Tests
Unit Tests Review
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