Requirements Analysis Lecture #3 David Andrews

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

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)

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)

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.

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

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

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

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.

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

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

Requirements Lets Take a Closer Look at Requirements

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)

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

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

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

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

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…)

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

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