1 / 18

2. Life-Cycle Perspective

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

Download Presentation

2. Life-Cycle Perspective

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 2. Life-Cycle Perspective Overview • 2.1 Motivation • 2.2 Waterfall Model • 2.3 Requirements in Context

  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. 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

  4. 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

  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

  6. 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

  7. 3. Software Requirements Defined • 3.1 Issues • 3.2 Functional Requirements • 3.3 Non-functional Requirements • 3.4 Significance

  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?

  9. For now, ignore how requirements are generated e.g., from customer needs Consider a very simple life cycle model Simplifying Assumptions

  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

  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

  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

  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

  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

  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

  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

  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?

  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

More Related