2. Life-Cycle Perspective

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