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 CycleRequirements

phaseVerify

DesignphaseVerify

ImplementationphaseTest

TestingphaseVerify

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

Use the requirements todevelop validation tests forthe system

Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process

Use the requirements tounderstand what system is tobe developed

System testengineers

Managers

System engineers

Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements

System customers

Use the requirements to helpunderstand the system andthe relationships between itsparts

Systemmaintenance

engineers

Users of a Requirements Document

Non-Functional Requirement Types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

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

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

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 TestsAcceptance Test Review

Requirements ReviewDevelop Requirements Execute System Tests

Develop Integration TestsIntegration Tests Review

Design ReviewDesign Execute Integration Tests

Develop Unit TestsUnit Tests Review

Code ReviewCode 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