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. [ §1 : 2 ] Costs 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

3. [ §1 : 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. [ §1 : 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. [ §1 : 5 ] Waterfall Model of System Lifecycle 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

6. [ §1 : 6 ] 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

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

13. [ §1 : 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. [ §1 : 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 : 15 ] Sample RDD Table of Contents 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

16. [ §1 : 16 ] Software Requirements Specification (SRS) 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

17. [ §1 : 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. [ §1 : 18 ] Traceability 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

19. [ §1 : 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. [ §1 : 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. [ §1 : 21 ] 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.

22. [ §1 : 22 ] 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

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

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

26. [ §1 : 26 ] Object-Oriented Variations Events may be external or internal (conditions) Actions may be external or internal (operations)

27. [ §1 : 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. [ §1 : 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. [ §1 : 29 ] User Interface Navigation 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

30. [ §1 : 30 ] Use Case Models 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)

31. [ §1 : 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. [ §1 : 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. [ §1 : 33 ] Controller Timer IntakeOuttake Heater Tank Heat Controller Water Tank Hierarchy and Partition Water tank example

34. [ §1 : 34 ] Many Architectural Styles 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

35. [ §1 : 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. [ §1 : 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. [ §1 : 37 ] Alternative Decomposition Approaches Function-oriented modularity Synonyms: action, process, transformation Basic idea: organize the system structure around the kinds of activities it must perform 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 must maintain Rationale: functionality changes more often than the data required to support it

38. [ §1 : 38 ] An Example of Component Notation Passive procedure object Active task active object Organizational package External devices and interfaces procedure object task active object package

39. [ §1 : 39 ] @ class method 1 method 2 method 3 class @ method 1 @ method 2 method 3 Object Level Synchronization 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

40. [ §1 : 40 ] Component 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) Heater Heat Controller h = 1..4 activeinactive failed turn on turn off

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

42. [ §1 : 42 ] Sample Connectors water incident logging field condition auto wateringmanual watering ph sprayer timer sensor field bus sensor loss intruder messag e queue

43. [ §1 : 43 ] Actuator 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 Heater Heat Controller h = 1..4 heater duty cycle is at the level of 100 milliseconds

44. [ §1 : 44 ] Modular Design alignment manager travel manager door manager alignment sensor main motor door assembly floor sensor elevator control

45. [ §1 : 45 ] Responsive Design Continuous alignment while at a floor door manager alignment manager travel manager alignment sensor main motor door assembly floor sensor elevator control

46. [ §1 : 46 ] Safe Design Doors are closed while moving or not at a floor door manager travel manager alignment sensor main motordoor assemblyfloor sensor elevator control edge upedge downfloordoor floor departure request mandatory check doors closed stationary level at floor

47. [ §1 : 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