Requirements Analysis Lecture #3

1. Requirements AnalysisLecture #3 David Andrews dandrews@eecs.ukans.edu

2. What We Will Cover Today • Typical Design Flow • Top Down Design Approach • Understanding Requirements • Functional • Behavioral • Timing • Physical • Perform Requirements Analysis on Specific Example • Taking Verbal Description and Generating Requirements

3. Overview of Top Down Design • Requirements Assessment: What is it • Paper and pencil work/Negotiations with customer • Final requirements is your contract with customer, need to get it correct • Documentation: System Requirements Specification (SRS) • Top Level Design: Where are you going to put it • Functional Descriptions/Block Diagrams • Hardware Software partitioning • Automated Tools available (will discuss later) • Documentation: Hardware/Software Top Level Design Documents (STLDD/HTLDD)

4. Overview of Top Down Design • Detailed Design: How are you going to design it • Hardware Component selections, Fan Ins/Outs, simulations • Software Modules, Subroutines • Documentation: Hardware/Software Detailed Design Document (HDDD/SDDD) • Integration and Test: Frustration • Before Modules Brought Together, Unit Test • Bring Modules Together. This is where the rubber hits the road • Testing Based on Pre-Defined Hardware/Software Test Plan (HTP/STP)

5. Top Down Philosophy • Design Process is iterative, you make a stab at next lower level, then based on results, revisit upper level and adjust. Adjustments affect everyone, not just you • This seems like work, why not just “go for it” • Need to know what you are designing first before designing it. • Much easier to get a warm and fuzzy that the big picture is correct • Most projects are group oriented, you need to interface with others • 10:1 rule Each hour spent at the higher abstract level will save 10 hours at the next lower level. • Very expensive in Cost and Time to get to integration and test, and find that you make errors.

6. Requirements Analysis • Requirements Assessment: What is it • Timing: How fast does your system need to be ? MIPS/FLOPS, turnaround times, input/output times etc • Sizing: Most Systems are size limited. Anyone can develop a supercomputer/flight controller etc if you have enough space. • Interfaces: Are you hooked up to sensors inputting data ? How is the world going to communicate with your system ? • Other Special Requirements (Radiation Hardened, etc) These can affect cost, size, performance etc. • Customer may give you a laundry list that sometimes can be conflicting. You need to apply engineering expertise to give honest assessments. Customer may not really know all requirements, you again must help • Most Contract bids are based on Requirements Analysis. You must have a good understanding of all requirements in order to propose a feasible system solution • THIS IS YOUR CONTRACT, WHEN YOU IMPLEMENT ALL REQUIREMENTS YOU ARE DONE. IF THEY ARE NOT IMPLEMENTED, YOU ARE NOT

7. Top Level Design • Top Level Design: Where are you going to put it • System Block Diagram • System Address Map • Debug Support • Derived Requirements • Subsystem Interfaces • This is your Top Level Partitioning. Teams are assigned to implement modules defined here. • IMPORTANT: Interfaces are defined. This allows teams to work independently and simultaneously. • Derived requirements are targets for teams. They may not know or care about overall system. They just meet the derived requirements. • Don’t miss debug support. This may not be discussed in requirements analysis, but is key for further design and implementation

8. Detailed Design • Each Module in Top Level Design is further partitioned and designed. More derived requirements for each block in a module. • Interfaces within module are defined, chips selected, actual signals/interconnections are defined. • Functional Simulations are performed to guarantee the functionality of the Module. I.e., is the correct answer produced ? Are the algorithms correct ? • Simulations of Hardware performed in structured fashion (More Later) with automated tools. • Detailed Design is last chance to functionally knock out bugs before tedious implementation. • Automated Tools are Helping in the Detailed Design

9. Implementation • At this stage, the design should be proven correct. You want to implement the correct logic, etc. • Circuit design based on Logic Family • Board Layouts. • Physical constraints such as size, weight, power must be met. • This is the last step in the design process (before trying to make sense of what you designed). It took a long time to get here, but if done correctly, this is only a mechanical excersize.

10. Integration and Test • Where the Rubber hits the road..... • This step is usually underwhelmed in planning stage, and is overwhelming in actual work. • Integration and Test can take as long or longer than the other design steps. • Philosophy: Minimize the unknowns. Common approach of junior engineers is to “go for it”. Better to take tiny bites than choke on a big piece. • Test Modules First, subsystems second, then two subsystems, then multiple tested subsystems etc. You must go back and retest other components when anything that affects it changes. • The results of this is when you get paid........

11. Summary • Design Methods • Top Down • Bottom Up • Random • Top Down Design Steps • System Requirements Specification What • Document SRS • Top Level Design Where • Document STLDD/HTLDD • Detailed Design How • Document (Schematics, Code) • Integration and Test Selloff • Document STP/HTP

12. Requirements Lets Take a Closer Look at Requirements

13. Types of Requirements Functional Requirements • “Depressing button X shall illuminate light Y within 200 msec.” Non-functional Requirements • “Mean time between unsafe operating situations for each train car shall be greater than 250,000 years” (BART specification) • “Mean time to repair a single component failure shall be less than 30 minutes after arrival of mechanic bringing standard tool set.” (typical jet aircraft) • “Vehicle shall exceed 25 mpg” • “Elevator system shall deliver at least 1000 passenger*floors per minute at up-peak” Constraints • Specifies a required technical or other approach – “CORBA technology shall be used” Specifies regulatory or other constraints on solution space/design process – “System shall conform to requirements of DO-178b” (FAA software process)

14. Detailed Behavioral Requirements 1. List subsystems • In a fine-grain distributed system, this is sensors+actuators+objects – “Other objects” are usually compute-nodes such as dispatcher • Actors included to provide environmental model and interface 2. Create a database of behavioral requirements for each subsystem • Replication • Instantiation – Initial conditions – When are dynamic objects are created? • I/O interface (list of sensor/actuator interfaces) • State (private variables useful for describing behavioral memory) • Constraints – Non-functional requirements; safety interlocks • Behaviors – Functional requirements

15. Some Characteristics of a Good Requirement Understandable and unambiguous • Understandable to system designers who have to implement it • Understandable to marketing/sales/customers who know the needs • Understandable to outside vendors (non-domain experts) who have to build it • Concise (few words) and simple Implementation-neutral • Doesn’t say how to do it, just what the desired outcome/action/side-effect is Testable • If you can’t test it, how do you know the system meets the requirement? – Constraints can be difficult – how to you prove something is impossible? Traceable • Must be possible to trace that requirement is satisfied by final system – Sometimes done by tracing to features/system component functions – More often done in practice by tracing to system tests

16. Modeling The System Build models to check requirements • Making model executable forces designer to confront details • Models help look for bottlenecks and explore design alternatives We’re going to discuss common examples of different models • “Plumbing diagram” for capacity analysis • Statistical/queuing models • Functional models • Analytic models • Hybrids Time can be treated as: Discrete Event / Continuous / Cycle / Hybrid

17. Capacity Models (with network example) “Plumbing Diagram” / spreadsheet: • Messages are delivered from source to destination • Example: Maximum bandwidth 1000 msgs/sec (might also be in bytes/sec) – But nodes may be limited by CPU power to lower bandwidths

18. Statistical Models Statistical: • Maximum bandwidth • Time delay at 50% of maximum bandwidth • Ignore noise, failures Detailed statistical: • Delivery time (including retries) • Loss probability (with limited retries) • Maximum bandwidth possible • Service degradation vs. used bandwidth Queueing theory • (Math beyond the scope of this course…)

19. Functional & Implementation Models Functional • CAN network is a priority queue • Feed messages to network and see what happens Implementation • Verilog for CAN chip implementation… But, some things usually don’t matter • Implementation below level of abstraction – e.g., if motor is controlled with voltage, current, pulse-width modulation – e.g., type of sensor/actuator as long as it implements the correct function

20. Simulation Models Coupled analytic models (e.g., spreadsheets) • 12 messages, 113 bits each, sent at 20 Hz • 5 messages, 118 bits each, sent at 2 Hz ... Continuous Time models • Usually used in physical domain (e.g., computational fluid dynamics) Cycle-based models • e.g., Verilog • Ends up being how time-triggered simulations run • Simulation speed proportional to length of time simulated Discrete Event simulations • Events are queued for action at specified times (e.g., wait 100 msec then do X) • Simulation “clock” fast-forwarded to next queued event at zero cost • Simulation speed proportional to number of events