[ §4 : 1 ] 4. Requirements Processes II Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Software Requirements Specification

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

[ §4 : 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 : 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 Τ and f(Τ)

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

[ §4 : 6 ] Technical Contents 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

[ §4 : 7 ] Specification after Elicitation

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

[ §4 : 9 ] Centralized Controller 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

[ §4 : 10 ] Specification after Allocation

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

[ §4 : 12 ] Distributed Controller Additional internal interfaces have been identified The specification rules out a centralized implementation Architecture is constrained accordingly Elevator controller

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

[ §4 : 14 ] Verification Example: Elevator Door Control Logic 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.

[ §4 : 15 ] 4.5 Requirements Validation 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 : 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