Course Summary: Review of Software Engineering Requirements and Architecture

1. Course Summary: Review of Software Engineering Requirements and Architecture Gruia-Catalin Roman and Christopher Gill CSE 436 Spring 2007 Department of Computer Science and Engineering

2. The cost of correcting an error grows very rapidly as the project moves along its life-cycle This observation argues for early error detection and provides the motivation for technical reviews The highest cost errors are those involving the systems requirements formulation Costs

3. Response • There is no silver bullet for the very difficult task of requirements definition and management • The state of the art, however, is very much ahead of the state of the practice • What you learn in this course, you can apply with impact • A standardized framework can be the conduit for bridging the gap • increased awareness • common terminology • assimilation of very basic practices

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

5. 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 Waterfall Model of System Lifecycle

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 Requirements in Context

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

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

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

10. 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 • … combinations of these kinds of domains/ranges

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

12. 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(Τ)

13. Elicitation • Discover and catalogue application needs • Identify constraints • Identify and prioritize objectives • Reconcile conflicting views • Define standard terminology • Separate concerns • Organize the information • Pave the way to conceptualization • Make technical specifications feasible

14. Principal Product of Elicitation • Requirements Definition Document (RDD) • is still at a relatively high level • does not provide yet a baseline for the development (needs to be refined and extended during specification) • does provide the basis for specification • is the starting point for a number of specialized preliminary studies • The document must be accessible to a broad range of readers • customers, users, managers, designers

15. 1. Introduction - the mind set 2. Definition of terms - the basis for accurate communication 3. Objectives - the central issue 4. Overall system organization - the context 5. External Interfaces - the environment refined 6. Capabilities - the outline for a solution 7. Constraints - the bounds placed on the solution space 8. Additional documentation - attached or included by reference Sample RDD Table of Contents

16. Point of origin elicitation and/or allocation activity Purpose provide a baseline for all software development activities Focus software/environment interactions technical reformulation of constraints Nature highly technical Usage design testing technical studies Software Requirements Specification (SRS)

17. Sample SRS Table of Contents 1. Introduction (ANSI/IEEE STD-830-1984) 2. General description 3. Specific requirements 3.1 Functional requirements - input/processing/output 3.2 External interface requirements - interface specification 4. Performance requirements (non-functional) 5. Design constraints 6. Attributes 7. Other requirements

18. Objectives, capabilities, and constraints in the RDD are traceable to the SRS having to trace the less-technical RDD to design can become counterproductive one objective may affect everything Using the RDD only to construct the SRS is feasible for some projects objectives and rationale should not be lost Traceability

19. Traceability • Traceability is a property of the software development process • refers to the ability to relate elements of a specification to those design components that ensure their satisfiability • relations that are precise and narrow in scope simplify analysis • relations that are diffused often entail complex analysis • Specifications may be • functional or non-functional • part of the system requirements or the byproduct of design • Traceability is a useful tool, but not a substitute for verification • Most traceability chains run through the software architecture • requirements to design • design to code

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

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

22. 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 Requirements Validation

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

24. Requirement Specification & Testing: Domain Specific Scripting Languages aircraft.digital_inputs[FLAPS] = 2; threat_environment->addThreat(new ThreatAircraft(MIG_29, aircraft.altitude, position_offset(aircraft.latitude,aircraft.longitude,aircraft.bearing,3*MILES_TO_FEET))); Readable, approachable language • aircraft.extend_flaps • create_threat “MIG29”, :distance => 3.miles In contrast to… (Thanks to John Aughey for this slide)

25. External actions associated with transitions Documentation implications 3. Specific Requirements 3.1 Initial state Initialization 3.2 State A 3.2.1 Event X Next State S’ Action A State Machine Models

26. Object-Oriented Variations • Events may be external or internal (conditions) • Actions may be external or internal (operations)

27. Data Flow Models • Dataflow diagram notation • functions—deterministic input/output transformations triggered by the presence of all needed inputs • flows—unbounded queues • stores—global system data • terminators—interface models • minispecs—semantics of the lowest level functions

28. User Manual For Applications Involving Human Interfaces • Effective specifications often require the integration of multiple related models • Human/computer interactions are too complex for commonly used requirements techniques • The User Manual can be used as a substitute for (and/or can grow out of) large sections of the SRS

29. Identify the screens/windows Define permitted transitions among them as a graph Identify the events that trigger moves from one screen/window to another Identify interactions common among screens/windows specific to the user interface paradigm in use User Interface Navigation

30. Actors model the environment and the users initiate activity by providing stimuli can be primary or secondary Use cases are complete courses of action initiated by actors (basic or alternative) can be extended by (interrupt analogy) or use other use cases (call analogy) Use Case Models

31. Architecture Design Phase Technical goals • Identify the principal components that make up the system and their (internal and external) interfaces • Ensure compliance with respect to expectations captured in the requirements specification • Understand, assess, and control risks • Ensure predictability of the development process through accurate planning

32. Software Architecture as Artifact • The architecture of a system is an abstract description of its structure and behavior • The level of abstraction is chosen such that all critical design decisions are apparent and meaningful analysis is feasible • A complete software architecture is usually specified by a combination of • design diagrams • component specifications

33. Hierarchy and Partition Water tank example HeatController Controller Water Tank Tank Timer Heater Intake Outtake

34. Composition static layered controller client/server pipes and filters peer to peer proxy / object-based dynamic object-oriented software bus service provision Communication explicit message passing event propagation Coordination implicit blackboard shared tuple space database/futures Emerging styles new software domains mobile computing sensor networks Many Architectural Styles

35. Design Diagrams • An abstraction of the system structure • A map of the system organization at a particular level of abstraction • Names of the principal system components and relations among them • Hints at the operational behavior of the system (constrains what the system can do) • May provide implementation directives

36. Component Specifications • Component specifications supply the details needed to provide a complete system description at this particular level of abstraction • interface syntax • interface semantics • The structural and behavioral properties captured by the component specifications must be consistent with the design diagram

37. Function-oriented modularity Synonyms: action, process, transformation Basic idea: organize the system structure around the kinds of activities it mustperform Rationale: a system is the functionality it supplies to the user Object-oriented modularity Synonyms: data record, class Basic idea: organize the system structure around the kinds of data it mustmaintain Rationale: functionality changes more often than the data required to support it Alternative Decomposition Approaches

38. procedure object task active object package An Example of Component Notation • Passive • procedure • object • Active • task • active object • Organizational • package • External • devices and interfaces

39. The notation is the same for classes and objects and so are the semantics Synchronized objects specify mutual exclusion among all methods Notation and semantics may be adjusted for different settings Synchronized methods limit mutual exclusion to identified methods Object Level Synchronization @ class class method 1method 2method 3 @ method 1@ method 2 method 3

40. Sample component types procedure object process (threaded object) Interface depends on component type and language—but it is real Behavior reflects the component type but must be abstract Heater Methods turn on, turn off failed, heating State active (T/F) failed (T/F) Component HeatController Heater h = 1..4 turn off failed inactive turn on active

41. Sample connector types procedure invocation message queue Connectors are complex specialized components Heat Controller vs. Heater Possible alternatives method invocation message passing event notification Connector HeatController HeatController HeatController raise heater on send get Heater Heater Heater h = 1..4 h = 1..4 h = 1..4

42. Sample Connectors message queue auto watering manual watering incident logging field condition intruder sensor loss water ph timer sprayer sensor field bus

43. Actuators are events of a predefined nature that initiate activity timer interrupt mouse down Implementation is language specific often complex distributed across the code Conceptually are simple to understand easy to analyze Heat Controller Some methods are time triggered Actuator heater duty cycle is at the level of 100 milliseconds HeatController Heater h = 1..4

44. Modular Design elevator control alignment manager door manager travel manager alignment sensor door assembly main motor floor sensor

45. Responsive Design Continuous alignment while at a floor elevator control alignment manager door manager travel manager alignment sensor door assembly main motor floor sensor

46. Safe Design Doors are closed while moving or not at a floor elevator control doors closedstationarylevel at floor travel manager door manager mandatory check door floor edge up edge down floor departure request alignment sensor door assembly floor sensor main motor

47. Concluding Remarks • Development of software based systems is complex • multiple perspectives • different notations • significant and sophisticated analysis • Requirements elicitation and specification should focus on communication among people • Requirements must be traceable through the architecture to the code itself (and vice versa) • The design process should focus mainly on fundamentals and on the creative activities