[ §3 : 1 ] 2. Life-Cycle Perspective Overview 2.1 Motivation 2.2 Waterfall Model 2.3 Requirements...
-
Upload
arthur-riley -
Category
Documents
-
view
213 -
download
1
Transcript of [ §3 : 1 ] 2. Life-Cycle Perspective Overview 2.1 Motivation 2.2 Waterfall Model 2.3 Requirements...
[ §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