[ §3 : 1 ]

2. Life-Cycle Perspective

Overview

2.1 Motivation 2.2 Waterfall Model 2.3 Requirements in Context

[ §3 : 2 ]

2.1 Motivation

Premise of modern software engineering design/planning must consider product’s entire life this is a central and essential assumption

In contrast, a more narrow perspective e.g., development only is likely to lead to failures lacks dependability assurances risks later expenses much > development costs

[ §3 : 3 ]

2.1 Motivation, Continued

Other life-cycle concerns also fundamental maintainability, extensibility, portability, etc. must be considered throughout life-cycle as well

Life-cycle starts with requirements definition … upon which everything that follows depends

[ §3 : 4 ]

2.2 Waterfall Model as Overview

Understanding requirements

presupposes a good grasp of the development process as a whole

Waterfall model remains one of the best

abstractions for the entire development process

Requirements definition

System design

Software design

Implementation and unit testing

Integration and testing

Operation and maintenance

[ §3 : 5 ]

Multiple Development Perspectives Waterfall model

product focused Spiral (Boehm)

driven by risk analysis and mitigation planning, risk assessment, engineering, customer evaluation

Evolutionary e.g. XP (Beck) increment driven rapid prototyping, regression testing, evolution

Transformational specification driven formal methods

[ §3 : 6 ]

2.3 Requirements in Context Requirements may vary

in level of abstraction, contents from one context to another

System requirements result from an analysis or discovery

process Software requirements

result from a design process involving requirements allocation

Sometimes there is no distinction between them

Requirements definition

System design

Software design

system requirements

software requirements

constraints

problem needs

[ §3 : 7 ]

3. Software Requirements Defined

3.1 Issues 3.2 Functional Requirements 3.3 Non-functional Requirements 3.4 Significance

[ §3 : 8 ]

3.1 Issues What are requirements? Why are they significant? When are they generated? How are they generated? How are they documented? How are they managed? When are they discarded? Can requirements be implicit?

[ §3 : 9 ]

Simplifying Assumptions

For now, ignore how requirements are generated

e.g., from customer needs Consider a very simple

life cycle model

Requirements definition

Program design

Coding and testing

software requirements

application

[ §3 : 10 ]

Terminology A requirement is a technical objective which is imposed upon

the software, i.e., anything that might affect the kind of software that is produced

A requirement may be imposed by the customer the developer the operating environment

The source, rationale, and nature of the requirement must be documented

Requirements fall into two broad categories functional non-functional

[ §3 : 11 ]

3.2 Functional Requirements Functional requirements are concerned with what the software

must do capabilities, services, or operations

Functional requirements are not concerned with how the software does things, i.e., they must be free of design considerations

Functional requirements are incomplete unless they capture all relevant aspects of the software’s environment

they define the interactions between the software and the environment

the environment may consist of users, other systems, support hardware, operating system, etc.

the system/environment boundary must be defined

[ §3 : 12 ]

Important Messages

Requirements are difficult to identify Requirements are difficult to write Requirements change over time Discrepancies between needs and

capabilities may render the software useless Life-cycle considerations must be

documented since they have design implications

[ §3 : 13 ]

Communication Issues Missing or vague requirements are a recipe for disaster Anything that is not made explicit may not be implemented or

considered Anything that is ambiguous is likely to get implemented in the

least desirable way Standard trade practices may be omitted (in principle!) Cultural settings do affect the way in which requirements are

written and read Multiple views may be required to formulate a reasonably

complete set of requirements

[ §3 : 14 ]

Implicit Requirements

An interface specification can become a requirement definition only if it is the only processing obligation its semantics are well defined

A product cannot be its own requirements definition because the rationale for the design decisions is lost there is no verification criterion

[ §3 : 15 ]

Non-Functional Requirements Non-functional requirements place restrictions on the

range of acceptable solutions Non-functional requirements cover a broad range of

issues interface constraints performance constraints operating constraints life-cycle constraints economic constraints political constraints manufacturing

[ §3 : 16 ]

Important Messages

Constraints are the main source of design difficulties

No formal foundation on which to base the treatment of most non-functional requirements is available today

Non-functional requirements are at least as dynamic as the functional ones

[ §3 : 17 ]

Case Study: Sensor Display Consider a small system that displays the status of

several sensors (e.g., pressure, temperature, rate of change, etc.) on a limited-size screen

What are some of its functional requirements? What are some of its non-functional requirements?

display System

[ §3 : 18 ]

3.4 Significance Requirements are the foundation for the software development

process Requirements impact the life cycle throughout its phases

customer/developer interactions contractual agreements feasibility studies quality assurance project planning risk analysis testing user documentation