[ §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

[ §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

[ §3 : 7 ] 3. Software Requirements Defined 3.1Issues 3.2Functional Requirements 3.3Non-functional Requirements 3.4Significance

[ §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

[ §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?

[ §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