Slide 1

Copyright 1995-1999 SCRA 1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Copyright 1995-1999 SCRA All rights reserved. This information is copyrighted by the SCRA, through its Advanced Technology Institute (ATI), and may only be used for non-commercial educational purposes. Any other use of this information without the express written permission of the ATI is prohibited. Certain parts of this work belong to other copyright holders and are used with their permission. All information contained, may be duplicated for non-commercial educational use only provided this copyright notice and the copyright acknowledgements herein are included. No warranty of any kind is provided or implied, nor is any liability accepted regardless of use. The United States Government holds "Unlimited Rights" in all data contained herein under Contract F33615-94-C-1457. Such data may be liberally reproduced and disseminated by the Government, in whole or in part, without restriction except as follows: Certain parts of this work to other copyright holders and are used with their permission; This information contained herein may be duplicated only for non-commercial educational use. Any vehicle, in which part or all of this data is incorporated into, shall carry this notice. Requirements and Specification Modeling (RSM) RASSP Education & Facilitation Program Module 30 Version 3.00 Slide 2 Copyright 1995-1999 SCRA 2 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Rapid Prototyping Design Process SYSTEM DEF. FUNCTION DESIGN HW & SW PART. HW DESIGN SW DESIGN HW FAB SW CODE INTEG. & TEST VIRTUAL PROTOTYPE RASSP DESIGN LIBRARIES AND DATABASE Primarily software Primarily hardware HW & SW CODESIGN RSM Slide 3 Copyright 1995-1999 SCRA 3 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Goals l To Investigate the State-of-the-Art in Requirement and Specification Modeling Methodologies l To Show How RSM Is an Important Part of the Top-Down Design Methodology l To Describe a Unified Evaluation Framework for Specification Modeling Methodologies l To Describe an Existing RSM Methodology and Apply various evaluation criteria to It Slide 4 Copyright 1995-1999 SCRA 4 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM m Where RSM fits in the RASSP Roadmap m Goals of the Module m Requirements & Specifications Defined m Test Bench Development m Where RSM fits in the Product Life-Cycle m The System Definition Process Slide 5 Copyright 1995-1999 SCRA 5 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l Requirements Engineering and Requirements Analysis m Requirements Engineering Goals m Requirements Analysis m Requirements Validation l Specification Modeling Methodologies (SMM) m SMM Applied to Reactive Systems m Methodology Attributes Slide 6 Copyright 1995-1999 SCRA 6 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l Methodology Survey m Survey Content m Review of Evaluative Parameters m Ward and Mellor's Methodology (SDRTS or RTSA) m Jackson System Development (JSD) m Software Requirements Engineering Methodology (SREM) m Object Oriented Analysis (OOA) m Specification and Design Language (SDL) m Embedded Computer Systems (ECS) m Vienna Development Method (VDM) m Language of Temporal Ordering Specification (LOTOS) m Electronic Systems Design Methodology (MCSE) m Integrated Specification and Performance Modeling Environment (ISPME) Slide 7 Copyright 1995-1999 SCRA 7 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l CASE Tools m RDD-100 m DOORS m SLATE m Requirements and Traceability Management (RTM) m Statemate m ADEPT Slide 8 Copyright 1995-1999 SCRA 8 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline (Cont.) l RASSP Requirement Capture and Test Planning m Review of the problem and the approach to solution m Examples q FFT q SAR m Use of the virtual prototype l Summary Slide 9 Copyright 1995-1999 SCRA 9 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM m Goals m Requirement defined m Specification defined m Executable Requirements and Specifications m Test Bench Planning and Development m Where RSM fits in the Product Life-Cycle l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology (SMM) l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary RSM Outline Slide 10 Copyright 1995-1999 SCRA 1010 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Customer Expectations l Customers expect: m A system that accomplishes the desired overall functionality m An accurate implementation of each function m A system with products that will be operational and useful in its natural and induced environments m Conformance to constraints on funding, schedule, physical characteristics, technology, external interfaces etc., during design and manufacture and after delivery Slide 11 Copyright 1995-1999 SCRA1 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Defined A requirement is: l A statement identifying a capability, physical characteristic, or quality factor that bounds a product or process need for which a solution is to be pursued l A clear documentation of the customer's expression of need so as to be directly usable in the design process Slide 12 Copyright 1995-1999 SCRA 1212 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements : Usual Approach l Traditional: paper documents in a natural language m Subject to omissions, ambiguities, and errors m Interpretation needs to be manual: subjective errors m Natural language documents: reader and writer give different meanings to the same words m Extraction of requirements from original document to a requirements tracking tool adds to ambiguity and chances of errors m Need for manual mapping of written requirements into diverse design tools m No underlying formalisms to ensure consistency among the various elements comprising the requirements document Slide 13 Copyright 1995-1999 SCRA 1313 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Requirements l A requirement modeled in a simulatable language is known as an executable requirement l Overcomes the problems associated with traditional ways of documenting requirements l Written in a machine-executable language l Presents an external view of the system l Especially well-suited for hardware and hardware/software systems, e.g. embedded systems l A simulatable requirement evolves to a executable specification Slide 14 Copyright 1995-1999 SCRA 1414 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Specifications Defined l A specification is a complete but purely external description of a system to be designed. l A completed specification involves modeling the environment in which the system is expected to function, and describing relations between the environment and the system in terms of a functional description. l ( Requirements + Constraints + Behavior + Design criteria ) = Specifications Slide 15 Copyright 1995-1999 SCRA 1515 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Specification Document l The Specification Document is structured in the following manner: m Problem presentation m Characteristics and modeling of the environment m System I/O specifications m Functional specifications- system function description m Operational specifications- Operation sequence, accuracy m Technological specifications- implementation constraints m Additional information such as document source, and explanations Slide 16 Copyright 1995-1999 SCRA 1616 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Executable Specification l An executable specification m A simulatable description of a component or system object q Represents an arbitrarily high level of abstraction e.g. DSP system, architecture, or HW/SW component level q Reflects function and timing q Incorporates a description of the object's interface q Provides the proper data transformations m May also describe electrical or physical aspects including q Power, cost, size, fit, and weight m Includes defined test requirements which leads to a test bench l Denotational items (e.g. power) are m Considered factual (derived) items to be checked m Not executed Slide 17 Copyright 1995-1999 SCRA 1717 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Role of the Executable Requirement/Specification l Executable Specification features: m A description of a system or component to reflect function, timing, and other aspects of the intended design m Operational features of the intended design m Abstract while retaining necessary detail l Executable Specification contents : m Fiscal and non-functional constraints m Behavioral description m Test bench l Executable Specification Applications: m At each level of design abstraction in a top-down design methodology m Decomposition of constraints into subsystems m Checking of systems and subsystems against testbenches m Deriving requirements for lower levels Slide 18 Copyright 1995-1999 SCRA 1818 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Need for Test Bench l Test bench simulates the environment of a model l Tests model functionality and timing l Compares model output with expected output l Provides a framework for the development of executable requirements Slide 19 Copyright 1995-1999 SCRA 1919 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Test Planning l A test bench is an executable VHDL model which instantiates the Model Under Test (MUT) l The MUT output is compared against the expected response as generated by the test bench. l Uses automatic test generation techniques l Test planning is necessary for model validation Slide 20 Copyright 1995-1999 SCRA 2020 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Goals in Test Planning l Goals can be evaluation or search goals l Evaluation goals: m Evaluate correctness of the MUT for all values within a range of the adjustable requirement space. Choose a set of samples from the evaluation space m Form a test case by a sample value-constrained requirements pair m Trade-off between testing time and degree of confidence of the test group l Search goals: m Search for extremes that may be attained by the adjustable requirements taken into consideration m Adjustable requirement needs to exhibit monotonic behavior in the search range Slide 21 Copyright 1995-1999 SCRA 2121 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP A Typical Testbench Or Noise Slide 22 Copyright 1995-1999 SCRA2 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Within the Product Life-Cycle Develop Specification Fabricate/ Compile HW/SW Verification Set Requirements Test Use Design Implement/Code Validate Verify Technologies of interest data (SW &HW) (simulatable) Product Test (HW/SW) (System) RSMRSM upgrade System Test (HW SW) Verify / Test Acquisition data to multiple vendors Slide 23 Copyright 1995-1999 SCRA 2323 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Detailed view of the RSM DETERMINE SYSTEM REQUIREMENTS AND CONSTRAINTS DEVELOP FORMAL (EXECUTABLE) REQUIREMENTS ENVIRONMENT SPECIFICATION SYSTEM SPECIFICATION ADAPT A SUITABLE SPECIFICATION METHODOLOGY PLAN AND DEVELOP TEST BENCH TO SYSTEM IMPLEMENTATION REQUIREMENTS STAGE SPECIFICATION STAGE TEST BENCH STAGE Slide 24 Copyright 1995-1999 SCRA 2424 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The System Definition Process System Requirements Definition Overall Architectural Definition HW Requirements SW Requirements Production Rqmts - cost/schedule - methodology Operational Description - environment, user, signal Tools Editors Spreadsheets RDD-100 RTM F2D2 B-2 Specifications Interface Control Documents (ICD) B-5 Specifications Interface Control Documents (ICD) 4-6 mo Algorithm Choice - operational scenarios - Algorithm - Risk area/mitigation - Development plan Performance model Architecture HW/SW Requirements documents Traceability matrix Development plan Simulation, test/stimulus response Sizing Technology Assessment (packaging...) Alternative approaches COTS vs. Custom Bottlenecks and degradation Scalability, fault tolerances,... 1-3 mo Requirements "db" Analysis Report - Completeness report - Cost - Traceability Tools VHDL Simulators RDD-100 BONeS 1-3 mo Tradeoff Studies Slide 25 Copyright 1995-1999 SCRA 2525 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Methodology Comparison Traditional Re-specify Specify Design I & T Done Re-engineer Start Over Re-specify Re-design RASSP/CEENS Change = Complexity = Risk Systematic & Predictable Specify Design I & T Done Re-engineer Formalism Executable Requirements Specifications Slide 26 Copyright 1995-1999 SCRA 2626 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 9/29/98 Methodology Costs & Benefits Benefits outweigh costs Slide 27 Copyright 1995-1999 SCRA 2727 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis m Requirements Engineering Goals m Requirements Analysis m Requirements Validation l Specification Modeling Methodologies (SMM) l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary Slide 28 Copyright 1995-1999 SCRA 2828 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Engineering Goals l Requirements engineering is the description of m A proposed system's intended behavior and m Its associated constraints m By a disciplined application of proven principles, methods, tools and notations. l The following are the chief aims of this activity: m Identification and documentation of customer and user needs m Documentation of external behavior and associated constraints m Ensuring consistency, completeness and feasibility of the required document by analysis and validation m Sensitivity to the evolution of needs Slide 29 Copyright 1995-1999 SCRA 2929 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Analysis l Requirements Analysis Models: m Functional Model : Analysis of the system by considering its functional aspects m Structural Model: Analysis of the components or objects which form the system m Mixed Level Model: Structural analysis and decomposition of both the system and the functionality of the system iteratively m Communication Model: Description of message exchange between the system components m Behavioral Model: Description of the internal behavior of the components based on FSMs Slide 30 Copyright 1995-1999 SCRA 3030 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Requirements Analysis Process Requirements Analysis From: - Functional Analysis - Control Customer Expectations Project & Enterprise Constraints External Constraints Measures of Effectiveness Operational Scenarios System Boundaries Interfaces Utilization Environments Life-cycle Process Concepts Functional Requirements Performance Requirements To: Systems Analysis Technical Performance Physical Characteristics Human Factors Modes of Operations Establish Requirements Baseline Operational Functional Physical To Validation From: - Validation - Functional Verification - Physical Verification. Slide 31 Copyright 1995-1999 SCRA 3131 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements Validation From Requirements Analysis Validation Customer Expectations? Enterprise & Project Constraints? External Constraints? Variances & Conflicts To Req. Analysis Validated Req. Baseline To: - Control - Functional Analysis Slide 32 Copyright 1995-1999 SCRA 3232 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies m Definition and Application to reactive systems m Methodology Attributes l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning l Summary Slide 33 Copyright 1995-1999 SCRA3 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Phases of the Design Process l Specification Phase m Formulation of system requirements m Documentation as a specification l Design Phase m Alternative implementation strategies q Considered q Evaluated l Implementation Phase m Realization as a product Slide 34 Copyright 1995-1999 SCRA 3434 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP What is Specification Modeling? l Forms part of the Specification Phase of the Design Process l A Specification Model of a system incorporates its m Behavior m Design, and m Requirements l A Specification Model helps in making predictions about the system characteristics l Enhances understanding of the system design and behavior Slide 35 Copyright 1995-1999 SCRA 3535 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Defining a Specification Modeling Methodology (SMM) l A specification modeling methodology is a coherent set of methods and tools to develop, maintain and analyze the specification of a given system Slide 36 Copyright 1995-1999 SCRA 3636 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Definition of Reactive Systems l A reactive system is one that is in continual interaction with its environment l Reactive systems are typically control dominated l Control-related activities form a major part of the reactive system's behavior l A reactive system typically responds or reacts by changing its own state and generating further stimuli l A reactive system executes at a pace determined by its environment Slide 37 Copyright 1995-1999 SCRA 3737 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Application of Reactive Systems l Reactive systems are prevalent in military as well as in commercial applications l Such systems represent a very large and ubiquitous class of high technology products l Such systems are often employed in highly critical applications l Examples of reactive systems m Network protocols m Air-traffic control systems m Industrial-process control systems m Fire-power systems m Guided missiles Slide 38 Copyright 1995-1999 SCRA 3838 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Characterizing Reactive Systems l Important behavioral characteristics of reactive systems m State-transition oriented m Concurrent m Timing sensitive m Exception-oriented m Environment-sensitive l Nonfunctional characteristics Slide 39 Copyright 1995-1999 SCRA 3939 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Why Apply Specification Modeling to Reactive Systems? l Designing reactive systems poses one of the greatest challenges in the field of system design and development l Many reactive systems are employed in highly- critical applications l Reactive nature is extremely difficult to specify and implement l Reliability and safety issues must be considered too Slide 40 Copyright 1995-1999 SCRA 4040 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attributes of Reactive System Specification Methodologies l Three major attributes of a reactive system specification modeling methodology: m Language q To support ability to provide conceptual models m Complexity control q To cope with the complex nature of the reactive system m Model continuity q To focus on development and maintenance of a specification model instead of a proposed implementation Slide 41 Copyright 1995-1999 SCRA 4141 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Components of a System Specification Methodology l Underlying model m Used to conceptualize and comprehend the system requirements l Set of languages m Provides notations to express system requirements l Set of techniques, range m From q Loosely specified guidelines for proceeding with the specification process m To q Detailed algorithms needed to develop a complete specification from preliminary requirements and concepts Slide 42 Copyright 1995-1999 SCRA 4242 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attributes of a Reactive System SMM reactive systems specification modeling methodology conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration implementation assistance models Slide 43 Copyright 1995-1999 SCRA 4343 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 1-Specification Language reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models Slide 44 Copyright 1995-1999 SCRA4 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models System Views l Three complementary views m Activity q Specification represents the activities that occur in the system q Activity in a system closely tied to the flow of data in a system m Behavior q Specification represents ordering and interaction of activities q Often represented in terms of states and transitions, or the flow of control m Entity view q Entities in the system, are identified q Entities represent the system components that are responsible for the activities and behavior in the system q Often represented as the data-items present in a system Slide 45 Copyright 1995-1999 SCRA 4545 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Specification Style l Two primary styles of specification m Model-oriented q System is specified in terms of state-machines, processes, or set theory m Property-oriented q System is viewed as a black-box q Properties of the system specified in terms of the directly observable behavior at the interface q No assumption is made about the internal structure or contents of the system. l Model-oriented specifications considered easier to understand than property-oriented specifications l Property-oriented specifications considered less implementation dependent than model-oriented specifications Slide 46 Copyright 1995-1999 SCRA 4646 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Concurrency l Concurrent behaviors cooperate with each other to achieve the desired functionality l Concurrency is further characterized by the ability to express communication and synchronization among concurrent behaviors. Slide 47 Copyright 1995-1999 SCRA 4747 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Communication Among Concurrent Behaviors l Information exchange usually conceptualized in terms of m Shared-memory models m Message-passing models l Both shared-memory and message-passing models are interchangeable Slide 48 Copyright 1995-1999 SCRA 4848 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Synchronization Among Concurrent Behaviors l Synchronization needed to m Coordinate the activities of the components m Permit each component to wait for other components to reach certain states or generate certain data or events l Synchronization may be achieved using m Control constructs m Communication techniques Slide 49 Copyright 1995-1999 SCRA 4949 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Nondeterminism Among Concurrent Behaviors l Nondeterminism is an attribute for complexity control l Nondeterminism allows the specifier to: m Focus on allowable alternative behaviors m Not commit to any specific alternative Slide 50 Copyright 1995-1999 SCRA 5050 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Timing Constraints l Direct specification of timing constraints m Inter-event delays m Data rates m Execution time constraints for executing behaviors m Temporal logic l Indirect specification of timing constraints m Implied through a collection of specification language constructs Slide 51 Copyright 1995-1999 SCRA 5151 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Modeling Time l Reactive system behavior often specified in terms of a time metric l Time is considered in a separately modeled entity rather than referred to indirectly, in order to increase the ease of specifying timing behavior Slide 52 Copyright 1995-1999 SCRA 5252 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Exception Handling l Exception handling needed when certain events require instantaneous response from the system l Exception handling can be provided through explicit specification language constructs Slide 53 Copyright 1995-1999 SCRA 5353 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Environment Characterization l The reactive system expected to be in continual interaction with its environment l The environment itself is reactive in nature l A reactive system's operational environment can be specified as m An explicit model m A set of properties providing hints about various operational conditions, such as sleep, active, reset, modes, etc. Slide 54 Copyright 1995-1999 SCRA 5454 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language-Conceptual Models Nonfunctional Characterization l Support for expression of nonfunctional characteristics is required, e.g. m Reliability m Availability m Maintainability m Safety m Power m Size m Footprint l Mechanisms must be provided to represent m Hints m Properties m External constraints Slide 55 Copyright 1995-1999 SCRA5 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language Analysis Techniques l Based on sound mathematical formalisms l Enables automatic checking for specification inconsistencies l Formalisms available m Petri-nets m Finite state machines m State diagram m Temporal logic m Process algebras m Abstract data types Slide 56 Copyright 1995-1999 SCRA 5656 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Language Analysis Techniques (Cont.) l Language Support for model executability m Motivation- nontrivial complexity of the systems being designed today m Executability of the specification q Helps to improve the comprehensibility and robustness of the specification q Offers the ability to experiment with preliminary prototypes which are useful to validate the specification against the requirements of the system Slide 57 Copyright 1995-1999 SCRA 5757 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 2- Model Continuity reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models Slide 58 Copyright 1995-1999 SCRA 5858 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity l The maintenance of relationships between models created in different model spaces m The models must be able to interact in a controlled manner m The models may be utilized concurrently throughout the design process l Maintaining model continuity for a specification can be divided into three sub-problems: m Model integration m Implementation assistance m Implementation independence Slide 59 Copyright 1995-1999 SCRA 5959 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Features and Benefits l Supports transcending levels of abstractions for testbench and functional representations l Functional model evolves from functional requirement, through specification, implementation, detailed design, to fabrication l Testbench evolves from executable specification, through implementation to fabrication to provide verification and validation at each level Slide 60 Copyright 1995-1999 SCRA 6060 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration l The flow of information must occur in both directions across model boundaries l A methodology must support bidirectional information flow across model boundaries Slide 61 Copyright 1995-1999 SCRA 6161 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Conformance l The methodology should provide support for checking conformance between the models at various levels of abstraction or in different domains l Conformance checking may be viewed along two dimensions: m Vertical - involves validating conformance between models representing different levels of abstraction m Horizontal - involves validating conformance between models representing different modeling domains l The need may exist for checking both horizontally and vertically Slide 62 Copyright 1995-1999 SCRA 6262 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Model Interaction l Requirements of performing integrated modeling across different levels of abstraction and modeling domains: m A high degree of model interaction m Information flow among the models l Model interaction involves identification of how a methodology addresses the following: m Implementation assistance q Maintaining visibility of the specification model during the implementation phase m Implementation independence q Incorporating relevant details obtained from the implementation phase back into the specification model Slide 63 Copyright 1995-1999 SCRA 6363 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Complexity Control l Required: a means to control complexity during the development and analysis of models throughout the design stages l Support for this attribute is necessary for effective implementation of the conformance and interaction attributes l Complexity control achieved by supporting a hierarchy of representations Slide 64 Copyright 1995-1999 SCRA 6464 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Model Integration Complexity (Cont.) l A hierarchical approach allows incremental expansion of design without expanding the rest of the system l Model complexity can be divided into two dimensions: m Vertical - abstraction of a lower-level model into a higher-level is an example of managing vertical complexity m Horizontal - combining models from different modeling domains an example of managing horizontal complexity l The hierarchical representation must possess capability to manage both horizontal and vertical complexity Slide 65 Copyright 1995-1999 SCRA 6565 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Implementation Assistance l Two prime motivations for implementation assistance: m Reduction of designer effort m Increase in implementation accuracy l Synthesis of efficient implementations from system-level specifications m Generally based on the structure of the specification m Design space is limited Slide 66 Copyright 1995-1999 SCRA6 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Model Continuity Implementation Independence l A specification is considered implementation independent if it lacks implementation bias l Two key advantages of an implementation independent specification m The specifier can focus on describing the behavior of the system, rather than how it is implemented m Unnecessary restrictions are not placed on designer freedom Slide 67 Copyright 1995-1999 SCRA 6767 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Attribute 3: Complexity Control reactive systems specification modeling methodology implementation conceptual implementation independence specification language complexity controlmodel continuity analysis techniques representational complexity developmental complexity model integration assistance models Slide 68 Copyright 1995-1999 SCRA 6868 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control l Complexity control exists along two dimensions m Representational complexity control makes the specification concise, understandable and decomposable m Developmental complexity control supports incremental development and step-wise refinement Slide 69 Copyright 1995-1999 SCRA 6969 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Dimensions l Representational complexity m Hierarchy m Orthogonality m Representation scheme l Developmental complexity m Nondeterminism m Perfect synchrony hypothesis m Developmental guidance Slide 70 Copyright 1995-1999 SCRA 7070 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Hierarchy l An important tool in controlling complexity l Group similar elements together to create a new element m The new element represents the group of similar elements l Result m Introduction of common behavior m Support for multiple levels of abstraction Slide 71 Copyright 1995-1999 SCRA 7171 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Orthogonality l Decomposition of a reactive behavior into a set of orthogonal behaviors l Result, significant improvement in: m Clarity of intent m Understandability of function Slide 72 Copyright 1995-1999 SCRA 7272 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Representational Complexity Representation Scheme l Plays an important role in understandability of a specification l Two types of representation schemes m Graphical m Textual Slide 73 Copyright 1995-1999 SCRA 7373 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Nondeterminism l Nondeterminism supports an evolutionary approach to specification development l Details of design are avoided till later stages of implementation l Mechanisms to detect and resolve nondeterminism are required Slide 74 Copyright 1995-1999 SCRA 7474 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Perfect Synchrony Hypothesis l Perfect-synchrony hypothesis implies that a reactive system produces it outputs synchronously with its inputs l This assumption is supported in systems where the inputs change at rates slower than the system can react Slide 75 Copyright 1995-1999 SCRA 7575 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Complexity Control Developmental Complexity Developmental Guidance l Guidance for model development m Helpful in identifying the next step in the specification process q Bottom up approach The primitives are first identified and then combined q A top-down approach Decomposing a specification into smaller and more detailed components q Middle-out approach Combines both top-down and bottom-up approaches Slide 76 Copyright 1995-1999 SCRA 7676 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology (SMM) l SMM Survey m Survey of ten representative methodologies l CASE Tools l RASSP Requirement Capture and Test Planning l Summary RSM Outline Slide 77 Copyright 1995-1999 SCRA7 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Methodology Survey l Ten representative methodologies chosen: m Ward and Mellor's Methodology (SDRTS or RTSA) m Jackson System Development (JSD) m Software Requirements Engineering Methodology (SREM) m Object Oriented Analysis (OOA) m Specification and Design Language (SDL) m Embedded Computer Systems (ECS) m Vienna Development Method (VDM) m Language of Temporal Ordering Specification (LOTOS) m Electronic Systems Design Methodology (MCSE) m Integrated Specification and Performance Modeling Environment (ISPME) Slide 78 Copyright 1995-1999 SCRA 7878 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Review of Evaluative Parameters l Specification Language m Conceptual models m Analysis techniques l Complexity Control m Representational complexity m Developmental complexity l Model Continuity m Model integration m Implementation Independence m Implementation Assistance Slide 79 Copyright 1995-1999 SCRA 7979 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 1. Ward and Mellor's Methodology (SDRTS or RTSA) l SDRTS: Structured Development for Real-Time Systems l RTSA: Real-Time Structured Analysis l Reason for development: Specification and design of real-time applications System Views Data Flow Diagrams Used to model activities of the system Control Flow Diagrams Used to express the sequencing of the system activities Slide 80 Copyright 1995-1999 SCRA 8080 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Ward and Mellor's Methodology (Cont.) Methodology basis: Structured analysis to express system requirements graphically, concisely, and with minimal redundancy System Spec. Environment Model Operational context Stimulus System Model System behavior Development through successive iterations Slide 81 Copyright 1995-1999 SCRA 8181 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Ward and Mellor's (Cont.) l Language aspect not supported well m No direct support for specifying timing constraints or for handling exceptions l Lack of Formal Method support m Less useful in the specification and design of critical systems l Lack of orthogonality m Complicated systems more difficult to represent l Model continuity attribute not well supported Slide 82 Copyright 1995-1999 SCRA 8282 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 2. Jackson System Development (JSD) l Originally developed for program design l Considered suitable for design of information systems and real-time systems l Covers specification, design and implementation stages l Supports complexity control in development and representation Slide 83 Copyright 1995-1999 SCRA 8383 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) l Basis: "Structure of a system to be designed can be determined from the structure and evolution of the data it should manage" l Representation of system requirements as Jackson's diagram for entities l System specification diagram- a network of processes that model the real world l Explicit time modeling by introducing delays Slide 84 Copyright 1995-1999 SCRA 8484 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) Two phases Specification Environment described in terms of entities and actions Actions are ordered by the expected sequence of events Actions and entities represented as a process network using system specification diagrams Design Identify processes needed to execute the actions of each entity Thus expand process network Map completed process network to a set of hardware/software components Slide 85 Copyright 1995-1999 SCRA 8585 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP JSD (Cont.) l Timing considerations come very late, nearly after the design phase l Specification is implementation-dependent, thus reducing designer freedom l Lacks support for expressing reactive system characteristics such as exception handling l Does not support formal analysis Slide 86 Copyright 1995-1999 SCRA 8686 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 3. Software Requirements Engineering Methodology (SREM) l Developed for data processing applications of Specifications l Makes use of structured finite-state automata called requirement nets (r-nets) l Express the evolution of outputs and final state starting from inputs and current state, using r- nets. I/O - message sets l Behavior of a reactive system well-represented by this methodology l Performance and timing constraints can be added l Supports the attribute of model continuity Slide 87 Copyright 1995-1999 SCRA 8787 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SREM (Cont.) l Specification development steps in SREM: l Specification of interface between the system and the environment l Data processing requirements l Produce initial description using r-nets l Add functional details, timing and performance constraints l Perform validation and coherency tests on the specification l Conduct final feasibility test Slide 88 Copyright 1995-1999 SCRA8 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SREM (Cont.) l Does not support hierarchical decomposition of the specification m Task of specification requires too much detail l Specification and implementation are tied too close to one another, thus limiting model continuity support Slide 89 Copyright 1995-1999 SCRA 8989 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 4. Object Oriented Analysis (OOA) l Based on object-oriented paradigm of modeling l Classes and objects used to express the problem domain l Extension of data or information modeling approaches, and concerns data transformations l Complexity control attribute well-supported Slide 90 Copyright 1995-1999 SCRA 9090 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP OOA (Cont.) l Major steps in OOA are: m Identify objects, their attributes and the structure of their interrelationships m Entire specification developed as a hierarchy of modules m Refinement of modules take place vertically and horizontally Slide 91 Copyright 1995-1999 SCRA 9191 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP OOA (Cont.) l Must be combined with languages that support expression of reactive system characteristics l Languages must have both formal and operational semantics Slide 92 Copyright 1995-1999 SCRA 9292 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 5. Specification and Description Language (SDL) l Used for specifying and describing many types of systems l Standardized, semiformal l Can be used graphically or textually l Supports perfect synchrony hypothesis and has an associated formal semantics Slide 93 Copyright 1995-1999 SCRA 9393 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) System Views Structural ( recursive decompo- sition of hierarchical blocks) Structural ( recursive decompo- sition of hierarchical blocks) Behavioral ( specifies reactive nature of system) Behavioral ( specifies reactive nature of system) Data ( modeled as an abstract data type) Data ( modeled as an abstract data type) Slide 94 Copyright 1995-1999 SCRA 9494 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) Environment System Block Channels Topmost level Behavioral Model Process 2Process 3... Process 1 Signals Slide 95 Copyright 1995-1999 SCRA 9595 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP SDL (Cont.) l Does not support all reactive system characteristics m Exception handling not directly supported m Inputs are processed only when receiving process is ready to process them l Model continuity not well-supported Slide 96 Copyright 1995-1999 SCRA 9696 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 6. Embedded Computer Systems (ECS) l Based on the three views of system modeling: activities, control and implementation l Supports both behavioral and functional decomposition of the system's specification l Used by the CAD Tool Express VHDL that utilizes the visual formalism of Statecharts l Conceptual model of concurrency, hierarchy and reactive transitions supported by Statecharts l Supports both language and complexity control attributes Slide 97 Copyright 1995-1999 SCRA 9797 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP ECS (Cont.) l System is functionally decomposed into a number of subsystems using activity charts l Viewed as a collection of interconnected functions organized in a hierarchy l Top-down and iterative analysis used to gradually express all the requirements of the system Slide 98 Copyright 1995-1999 SCRA 9898 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 7. Vienna Development Method (VDM) l Abstract model-oriented formal specification and design method l Based on discrete mathematics l Specification is written as a specification of an abstract data type which is defined by a class of objects and a set of operations acting on these objects l Supports model continuity very well Slide 99 Copyright 1995-1999 SCRA9 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP VDM (Cont.) l Specification in that of an of an abstract data type m A program is an abstract data type specified in terms of variables and the operations allowed on them l The design and specification processes are closely tied l Specification methodology: m Use META-IV to develop a formal specification m Check specification for consistency using formal analysis m Refine and further decompose specification to get a realization m Check realization against specification for conformance m Do iterative step-wise refinement until realization and implementation coincide Slide 100 Copyright 1995-1999 SCRA 100100 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 8. Language of Temporal Ordering Specification (LOTOS) l Internationally standardized formal description technique l Originally developed for formal specification of OSI protocols and services l Based on process algebra and abstract data types m Process algebra: description of process behaviors and interactions m Abstract data type: deals with description of data structures and value expressions l Unambiguous precise and implementation independent Slide 101 Copyright 1995-1999 SCRA 101101 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP LOTOS (Cont.) l Specify system by defining the temporal relationships among its externally observable interactions as interactions between process black boxes l Specify processes using process algebra techniques l Achieve process interactions using events Slide 102 Copyright 1995-1999 SCRA 102102 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP LOTOS (Cont.) l Property-oriented: therefore supports implementation independence l Specification does not restrict structure of implementation l Hard to conceptualize the internal states of reactive system l Concept of time not directly supported Slide 103 Copyright 1995-1999 SCRA 103103 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 9. Electronic Systems Design Methodology (MCSE) l Methodology for specification, design and implementation of industrial computing systems l Structured approach to system design l Approaches design of real-time systems in a top- down style Slide 104 Copyright 1995-1999 SCRA 104104 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP MCSE (Cont.) l Specification process consists of two parts m Environment modeling m System modeling l Specification processes produces three kinds of specifications: m Functional specifications m Operational specifications m Technological specifications Slide 105 Copyright 1995-1999 SCRA 105105 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP MCSE (Cont.) l Pros m Provides a well defined methodology for developing a specification m Allows multiple system views and modeling approaches l Cons m Lack of support for formal techniques m Does not support a coherent integration of modeling approaches Slide 106 Copyright 1995-1999 SCRA 106106 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP 10. Integrated Specification and Performance Modeling Environment (IPSME) l Supports strong interaction between the specification, design and implementation phases m Better communication of design intent among phases l Based on Statecharts: supports behavioral view of the system l Also supports complementary modeling: modeling using Statecharts and modeling performance l Performance model developed using ADEPT l Supports activity view for a system Slide 107 Copyright 1995-1999 SCRA 107107 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP IPSME (Cont.) l Development in an incremental manner from specification to implementation l Increments correspond to implementation of a Statecharts component l Performance model verified against Statecharts specification l Refinement of Statecharts and ADEPT models simultaneously Slide 108 Copyright 1995-1999 SCRA 108108 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP IPSME (Cont.) l Supports the three reactive system attributes m Language and complexity approaches: Statecharts m Model interaction component of model continuity: ADEPT l Performance model developed independent of structure: implementation independence Implementation assistance supported by synthesizing Statecharts model itself Slide 109 Copyright 1995-1999 SCRA 109109 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Overall Comparison Specification Modeling Methodologies LanguageComplexity ControlModel Continuity SDRTS limited JSD limitedsupportedlimited SREM supportedlimited OOA limitedsupportedlimited SDL supported limited ECS supported limited VDM supportedlimited LOTOS supportedlimited MCSE supported limited ISPME supported Slide 110 Copyright 1995-1999 SCRA 110110 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attributes Methodologie s Available Conceptual ModelsSpecification Model System ViewsSpecification Style Environment Characterization activity+behaviormodel JSDentitymodel SREMbehaviormodelproperty OOAentity+behaviormodellimited SDLentity+behaviormodellimited ECSactivity+behaviormodel VDMentitymodellimited LOTOSentity+behaviorproperty MCSEactivity+behaviormodel, propertymodel ISPMEactivity+behaviormodel SDRTS Slide 111 Copyright 1995-1999 SCRA 111111 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attribute (Cont.) Available Conceptual ModelsSpecification Model Methodologies Timing Constraints Modeling Time Exception Handling indirectlimited JSDdirectsupportedlimited SREMdirectsupportedlimited OOAindirectlimited SDLindirectsupportedlimited ECSindirectsupported VDMindirectlimitedsupported LOTOSindirectlimitedsupported MCSEdirectsupportedlimited ISPMEindirectsupported SDRTS Slide 112 Copyright 1995-1999 SCRA 112112 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Language Attribute (Cont.) Analysis TechniquesSpecification Modeling Methodologies Model Executability SDRTSlimited JSDlimited SREMsemiformalsupported OOAlimited SDLsupported ECSsupported VDMsupported LOTOSformallimited MCSEsemiformallimited ISPMEformalsupported Formal Analysis Slide 113 Copyright 1995-1999 SCRA 113113 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Complexity Control Representational ComplexitySpecification Modeling Methodologies HierarchyOrthogonalityRepresentation Scheme JSDsupported graphical SREMlimited graphical OOAsupported textual SDLsupported graphical ECSsupported graphical VDMsupported textual LOTOSsupported textual MCSEsupported graphical ISPMEsupported graphical SDRTSsupportedlimitedgraphical Slide 114 Copyright 1995-1999 SCRA 114114 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Specification Modeling Methodologies Support for Complexity Control (Cont.) Developmental Complexity NondeterminismPerfect Synchrony Assumption Developmental Guidance SDRTSlimitedasynchtop down JSDlimitedasynchtop down SREMlimitedasynchbottom up OOAlimitedasynchtop down SDLsupportedsynchtop down ECSsupportedsynchtop down VDMsupportedsynchtop down LOTOSsupportedsynchtop down MCSElimitedsynchtop down ISPMEsupportedsynch/ asynch top down / bottom up Slide 115 Copyright 1995-1999 SCRA 115115 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Model-Continuity Attribute Model IntegrationSpecification Modeling Methodologies ConformanceInteractionComplexity JSDlimitedvertical SREMlimitedvertical OOAlimited vertical SDLlimited vertical ECSlimited vertical VDMsupportedvertical LOTOSlimitedverticallimited MCSElimited supported ISPMEsupported SDRTSlimitedvertical Slide 116 Copyright 1995-1999 SCRA 116116 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Support for Model-Continuity Attribute (Cont.) Specification Modeling Methodologies Implementation Assistance Implementation Independence JSDlimitedsupported SREMsupportedlimited OOAlimitedsupported SDLsupported ECSsupported VDMsupportedlimited LOTOSlimitedsupported MCSElimitedsupported ISPMEsupported SDRTSlimited Slide 117 Copyright 1995-1999 SCRA 117117 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RSM Outline l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodologies l SMM Survey l CASE Tools m RDD-100 m DOORS m SLATE m Requirements and Traceability Management (RTM) m Statemate m ADEPT l RASSP Requirement Capture and Test Planning l Summary Slide 118 Copyright 1995-1999 SCRA 118118 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RDD-100 Requirements Manager l Functional Flow Block Diagrams, N-Squared Charts and Hierarchy Views are used in graphical display l Configuration management done using a Multi-user Merge feature l Can run on a superior or subordinate capacity l Technical extraction and text editing from external source documents into the system design data; data can be navigated and edited l Equipped with a behavior modeling tool that allows for the modeling of predicted or anticipated operational scenarios l Coordination of work between all team members made possible by the allocation of superior or subordinate capacity Slide 119 Copyright 1995-1999 SCRA 119119 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP RDD-100 Requirements Manager l Core Features of Automated tools for Requirements Management: m Requirements Capture m Requirements Specification production m Requirements Specification Management m Text-oriented or model-oriented view of Requirements Management m Provide links between requirements and other elements of the System Engineering Process Slide 120 Copyright 1995-1999 SCRA 120120 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Dynamic Object-Oriented Requirements System (DOORS) l Generate, parse existing and link to external requirements documents l Assign attributes to requirements and restructure requirements into documents, tree structures, matrices and back-to-back trees l Create views of requirements by interactive sorting and filtering l Provides for requirements traceability by creating links between the tool and various other external documents and tools l Includes modifiable routines for cost-benefit analysis, bottom-up weight calculation, impact analysis and test results l Creation and customization of new document templates Slide 121 Copyright 1995-1999 SCRA 121121 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Systems Level Automation Tool for Engineers (SLATE) l Integrates requirements, design alternatives and technical performance measures l Use of textual outline, graphic block diagram and a functional, control or data flow diagram l Translate requirements into a system architecture and display it as a hierarchical block diagram/ functional flow diagram l Maps a requirements audit trial across system levels l Evaluation of alternative designs and implementation decisions before implementation l Multiple-perspective display of a conceptual design l Functional decomposition and requirements flowdown and traceability l Measures for technical performance Slide 122 Copyright 1995-1999 SCRA 122122 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements and Traceability Management (RTM) l Implementation independent l Requirements gathered in a central repository and apparent inconsistencies refined l Provides functionality, user interfaces, and hardware platform support relevant for each of the disciplines associated within a project's development l All project info stored in a central on-line database l Graphical tool to represent the chosen information flow l Standard template that can be reused and redesigned for each project l Manages information objects and relationships between them l Specifies user-defined attributes to be defined for each information class Slide 123 Copyright 1995-1999 SCRA 123123 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements and Traceability Management (RTM)- (Cont.) l Captures the contents of requirements documents into a project database l Identifies requirements by selecting the style or component type in the document corresponding to an information class l Requirements can be extracted from an ASCII document and stored in the database as information objects l Edit, merge or expand information to show information which is implied l Combine different documents in a number of different views l Assign attribute values to characterize each requirement l Select, view and edit individual records l Track dynamically, individual requirements through the project life-cycle Slide 124 Copyright 1995-1999 SCRA 124124 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Statemate Requirements Tracer l Parsing of requirements from original, imported or locally created documents l Linkages between original and derived requirements, and between system models and requirements l Checks for ensuring completeness and correctness of allocation l Access, modify or link requirements while editing or modifying model element l Link derived requirements to originals, and original requirements to design elements l Process development using multiple requirements files l Back-reference model elements to requirements l Impact assessment on requirements due to modification of design elements l Identification of requirements and design elements that have not been updated on changing original requirements Slide 125 Copyright 1995-1999 SCRA 125125 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Advanced Design Environment Prototyping Tool (ADEPT) l Developed by The Center for Semicustom Integrated Systems (CSIS) at The University of Virginia l Employs both simulation-based and mathematical approaches for analysis l Supports the integrated performance and dependability analysis of system level models l Extended version supports operational specification modeling and hardware / software codesign l Capable of simulating both interpreted and uninterpreted models in a common simulation environment using hybrid modeling l Founded on VHDL descriptions and Petri Net Representations of models l Spans numerous design phases, enabling the possibility of a common simulation environment Slide 126 Copyright 1995-1999 SCRA 126126 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP l The Motivation for RSM l Requirements Engineering and Requirements Analysis l Specification Modeling Methodology l SMM Survey l CASE Tools l RASSP Requirement Capture and Test Planning m Review of the problem and the approach to solution m Examples q FFT q SAR m Use of the virtual prototype l Summary RSM Outline Slide 127 Copyright 1995-1999 SCRA 127127 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP The Problem l A written set of requirements for the design must be converted to executable requirements l A methodology must be identified to proceed from the written to the executable, and then to the specifications, ultimately leading to synthesis of hardware l The design specifications would be driven by the requirements thus captured l The specifications are tested and validated against a test bench Slide 128 Copyright 1995-1999 SCRA 128128 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Requirements vs. Specifications l A Requirement describes a set of constraints which must be satisfied by the design, while a Specification describes the characteristics of the system developed to meet those constraints l Requirement denotes input to the overall design cycle; Specification denotes the detailed design data produced at the output of the design cycle l Requirements defines what needs to be done, while specifications outline how to do it Slide 129 Copyright 1995-1999 SCRA 129129 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP CEENSS-supported System Design Process Requirements Capture (product, systems, etc.) Requirements Modeling and Analysis Functional Architecture (high-level behavioral VHDL specification) Architecture Definition (hw-sw partitioning) Software Simulatable Specification (e.g, SDL) Autocode Generation or SW Reuse Software Compilation Hardware/Software Codesign, Cosimulation Hardware Simulatable Specification (Behavioral or RTL) VSPECDOORS Hardware Synthesis Hardware Architecture and Partitioning (Technology Independent) Renoir Analog/RF Models Technology Specific (VHDL-AMS) Digital Models Technology Specific (VHDL) Monet, Visual Architect Slide 130 Copyright 1995-1999 SCRA 130130 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP FFT Processor Latency delay of 200 us and noise specification of X dB Example1: FFT Description Sensor 32 bit data word @ 5 MW/s Clock @ 5 MHz Clock @ 20 MHz 32 bit data word FILE I/O Buffer 15:0031:16 16 bit in phase data samples from A/D converter 16 bit quadrature-phase (Q) data samples from A/D converter Buffered I and Q data arrays 2 at 512 words X 16 bits Sink FILE I/O Buffer 32 bit data word Integer Valued Known Golden Results @ rising_edge of 20 MHz 2 phase clock read_data Input Buf. Full Output Buf. Full @ rising_edge of 20 MHz 2 phase clock write_data Requirements for an FFT Processor System Slide 131 Copyright 1995-1999 SCRA 131131 Methodology Reinventing Electronic Design Architecture Infrastructure DARPA Tri-Service RASSP Example1: Requirement to Executable Requirement l Requirement: " The system clock will operate with 2 phases and at a certain given frequency" VHDL Code Fragment: Begin -- architecture internal_signals: phase1