4. Requirements Processes II

1. 4. Requirements Processes II Overview • 4.1 Fundamentals • 4.2 Elicitation • 4.3 Specification • 4.4 Verification • 4.5 Validation Software Requirements Specification

2. From Definition to Specification • Requirements first must be defined • Concrete, unambiguous, coherent statement of needs • Acts as initial contract among customers, developers, etc. • Allows customers, developers, etc. to plan ahead • Requirements must then be specified • Definitions are at too high a level to guide design • Requirements must be refined and classified • Separated into sub-requirements to pin down details • Functional and non-functional requirements distinguished • Requirements must be allocated to an architecture

3. What Constitutes “Functional”? • Type as input, value as output • E.g., towards constructors and initialization methods • Type as input and output • E.g., towards allowed polymorphism and type conversions • Value as input and output • E.g., towards functions and operators • Value as input, type as output • E.g., towards classifiers and type identifiers • … and combinations of these domains/ranges

4. What about Time? • Superficially, time seems (and often may be) non-functional • E.g., when running faster is “a good thing” but does not change outcome • However, some systems are inherently time-dependent • E.g., human interaction, mechanical control, etc. • Making system run too much faster or slower may be harmful • In such cases, time must be treated as a functional element • One technique is to transform time into events • A timer or other device has a specified setting (e.g., rate) : Τ • The device generates events at times governed by that setting : f(Τ) • Functional requirements can be written about Τ and f(Τ) • Per a model that represents the relationship between Τ andf(Τ)

5. 4.3 Specification • The Software Requirements Specification (SRS) is a description of the functionality and constraints that must be delivered by the software • precise • detailed • technical • The SRS becomes the baseline for the entire software development process • The boundary between the system and its environment must be known at this time • The SRS assumes that the system functions have been allocated over an architecture

6. The proper content of the SRS is determined by fundamental technical considerations having to do with how we view computing The specific form of an SRS reflects the specific computational model underlying the specification methodology being employed Technical Contents

7. Specification after Elicitation

8. Consider the development of an elevator control system for a 10-story residential building. Running Case Study: Elevator

9. All external interfaces have been identified The specification does not rule out a distributed implementation … … but provides a concrete high-level architecture to allow further specification and refinement Centralized Controller

10. Specification after Allocation

11. Elevator Case Study, Continued • The full technical specification cannot complete (and it may be expensive to start it) until all interfaces (internal and external) are well defined

12. Additional internal interfaces have been identified The specification rules out a centralized implementation Architecture is constrained accordingly Distributed Controller Elevator controller

13. 4.4 Verification • Requirements verification is an activity directed towards the discovery of specification errors • The ultimate goal is to ensure that the specification (when considered on its own) is • correct • consistent • complete • The verification must be carried out against a model (formal or informal) • Formal and semi-formal specifications can be checked out by tools

14. Consider a deterministic finite state representation of the elevator movement logic Some errors can be detected simply by the nature of the model invalid initial state missing transitions non-deterministic transitions possible live-lock, etc. Verification Example: Elevator Door Control Logic

15. Concerned with establishing that specified requirements represent the needs of the customer and/or user Needs are not reflected by any model or document Thus, validation cannot be performed in a mechanical way Good communication is the key to a successful validation well-defined terminology well-written and simple specifications formal reviews rapid prototypes simulations 4.5 Requirements Validation

16. Validation Example: Elevator Movement Policy • Consider an elevator movement policy which • takes the elevator up and down, from top to bottom, and services requests as it goes • The policy satisfies the customer stated requirements • every request is eventually serviced • there is a defined upper bound on the time it takes for a request to be serviced • Nevertheless • the time it takes to service a request during low demand periods may be unacceptable • unnecessary energy utilization emerges as a new issue • the need for a better policy (and ideas about it) may emerge