2 life cycle perspective l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
2. Life-Cycle Perspective PowerPoint Presentation
Download Presentation
2. Life-Cycle Perspective

Loading in 2 Seconds...

play fullscreen
1 / 18

2. Life-Cycle Perspective - PowerPoint PPT Presentation


  • 270 Views
  • Uploaded on

2. Life-Cycle Perspective Overview 2.1 Motivation 2.2 Waterfall Model 2.3 Requirements in Context 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '2. Life-Cycle Perspective' - JasminFlorian


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
2 life cycle perspective
2. Life-Cycle Perspective

Overview

  • 2.1 Motivation
  • 2.2 Waterfall Model
  • 2.3 Requirements in Context
2 1 motivation
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
2 1 motivation continued
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
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

2.2 Waterfall Model as Overview
multiple development perspectives
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
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

2.3 Requirements in Context
3 software requirements defined
3. Software Requirements Defined
  • 3.1 Issues
  • 3.2 Functional Requirements
  • 3.3 Non-functional Requirements
  • 3.4 Significance
3 1 issues
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?
simplifying assumptions
For now, ignore how requirements are generated

e.g., from customer needs

Consider a very simple life cycle model

Simplifying Assumptions
terminology
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 2 functional requirements
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
important messages
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
communication issues
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
implicit requirements
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
non functional requirements
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
important messages16
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
case study sensor display
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?
3 4 significance
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