By: Mark Austin (...with help from Natasha Kositsyna, Vimal Mayank, and Jeff Coriale) | |
Table of Contents | Contact Information and Project Participants |
|
|
|
Institute for Systems Research,
Mark's e-mail: austin@isr.umd.edu
Current Industry Participants:
|
Top-Down Decomposition: Pathway from Requirements to System Architectures
We promote "Systems Engineering Development Procedures" that employ formal design/requirements representations connected by mappings and traceability. A simplified view of systems-level development is as follows:
Figure 1. Traceability Mappings for the Development Pathway, Goals/Scenarios through System Evaluation.
Points to note:
Requirements also flowdown (and are traceable) to the subsystem levels.
We expect, however, that selection of a suitable system structure/architecture will be guided by the details of required behavior. Suppose, for example, when large chunks of behavior can occur concurrently, a system structure that will support parallel execution of tasks is appropriate.
We verify that the system structure connecitivity is consistent with the flows of data/information defined in the models of system behavior. We also check that system-level timing requirements can be met by the proposed sequences of tasks and mappings to objects/subsystems.
Bottom-Up Synthesis of Engineering Systems, enhanced with Component Reuse
Bottom-up synthesis of engineering systems from reusable components is a key enabler of enhanced business productivity (i.e., shorter time-to-market with fewer errors) and return on investment (ROI).
Figure 2 shows elements of a top-down/breadth first development (decomposition) followed by a bottom-up implemenation procedure (composition). In the latter half, a key design decision is: should we custom build new components or buy/reuse them.
Figure 2. Elements of Top-down and Bottom-Up Development coupled with Component Reuse
Points to note:
We envision a library (XML database) of object-specification descriptions.
Present-Day Requirements Management Tools
Present-day requirements management tools (e.g., SLATE, DOORS) claim to be process independent. But!!!
Figure 3. Requirements Engineering WBS and Industry Toolset Weakensses. (For details, see Ramesh and Jarke, 2001)
The lack of "inference services" in the work breakdown structure impacts the systems engineering process in several ways. Current tools are incapable of analyzing requirements for completeness or consistency. Search mechanisms are limited to keywords, which can be limiting for custom jargon in multidisciplinary and multilingual projects.
A minimal implementation would check groups of requirements for logical consistency and compatibility.
Systems of Systems
The primary design focus is on the interfaces, specifically the communication standards, as very little can be done to modify the monolithic systems.
Chaotic Systems of Systems
Chaotic (or virtual) systems of systems do not have a centralised management structure.
Examples -- The Internet and Open Source Software Development
The penguin is the icon for Linux, an open source operating system.
Requirements Management Systems are Chaotic Systems of Systems
Requirements management systems need to deal with internal and external requirements. Internal requirements are generated from within a project. The latter eminate from external sources (e.g., the EPA may manadate that a system must satisfy certain environmental regulations).
Figure 4. Flow of requirements in team-based system development.
Points to note:
Monolithic System
A requirements management systems can be implemented as a monolithic system. But as soon as the need to leverage or reuse the requirements across projects, companies, and industries is found, a monolithic system approach is no longer viable.
Chaotic System of Systems
The chaotic system of systems is a more appropriate model because every project, company, and "regulations authority" will operate based on personal needs and desires.
Thus, an open standard is needed which will allow the various systems to share a common data structure and build customized tools to meet the personal needs.
Our Research Approach
Second Generation Semantic Web
Modeling
The Semantic Web Layer Cake
Figure 5. The Semantic Web Layer Cake (Berners-Lee, 2002).
The Semantic Web is an extension of the current web.
System-level design of a pulse-doppler radar system requires top-down decompositions of goals into layers of requirements, followed by a bottom-up implementation of the system from theatre components.
Design Goal
I need a pulse-doppler radar system.
Operations Concept
The pulse-doppler radar system will detect small aircraft at long
ranges, even when their echoes are buried in strong ground clutter (Stimson, 1998).
Our long-term development objective is to create an interactive design environment where the specifications for system components are found online. Component specifications will basically say "...if you supply a required set of inputs, then the component will gurantee a minimum level of performance (output).
Top-Down System-Level Development
The flowdown of requirements to the system architecture might be as follows:
Figure 6. Flowdown of Requirements to System Architecture for Pulse-Doppler Radar. Reuse of System Components.
Points to note:
Bottom-Up System Synthesis Enabled by Reusable Component-Specifications
Now we can implement the system economically via reusable component specifications.
Figure 7. System Synthesis Enabled by Reusable System-Component Specifications.
Points to note:
Generation and Evaluation of Design Alternatives
Alternative |
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clearly, design alternative 1 is inferior to design alternative 4. Design alternative 6 is infeasible because it exceeds the cost constraint.
Research Questions to be Answered
Attaching Specifications to Objects and Components
An object-specification pair defines a set of behaviors can be offered by a component/object. Object/component descriptions must be at least multi-input multi-output (MIMO). Otherwise they aren't useful.
Figure 8. Elements of an Object-Specification Pair
Interface Specification
An interface specification precisely defines what a client of that interface/component can expect in terms of:
Together the pre- and post-conditions and satisfaction of the input requirements constitute a contract.
Figure 9. Role of Pre- and Post-Conditions in Contract for Object Usage
(Source: Newton A.R., "Notes on Interface-Based Design," EECS, UC Berkeley).
Networks of interacting/communicating objects having a larger purpose/functionality can be synthesized by stitching together objects that have compatibly I/O requirements and pre- and post-conditions.
Writing Requirements and Specifications
Requirements and specifications need to be written in a manner that balances two key aspects: (1) they should be readable, and (2) they should lend themselves to various forms of automated processing.
Table 1 summarizes the key features of requirements and specifications.
|
|
Initial requirements tend to be "qualitative" statements for what we want ..... | Specifications tend to be "quantitative" statements that are based upon a detailed knowledge of a product and its (required or established) capabilities... |
The system should .... The system must .... |
Requirements and capabilities:
|
Natural language sentences....
Natural language sentences suffer the limitation of being informal and, often, incomplete and ambiguous. |
|
Validation of requirements supported by traceability to specifications and design subsystems/objects. | Verification of specifications supported by formal testing procedures, numerical simulations of system behavior, experiments in the lab ... etc. |
Table 1. Comparison of Requirements and Specifications
Sample Requirements Document -- Implemented in XML
We are designing an XML/RDF tagset for a family of "requirements templates." For the pulse-doppler radar system, implementation of the tagset might look something like:
<?xml version="1.0" encoding="UTF-8" ?> <!-- Requirement for a Pulse-Doppler Radar System --> <Project file="radarsystem.xml"> <ToBeChecked Value="false"> <Requirement ID="SYS.REQ.1"> <Name> System Description </Name> <Rationale> Overall System Objective </Rationale> <Verification> User Input </Verification> <Comment> No comments </Comment> <Revision Month="4" Date="8" Year="2003" /> <Mappedto> Signal Processing Unit </Mappedto> <Template No="-1" /> <Description> I need a Pulse-Doppler Radar System. </Description> </Requirement> <Requirement ID="SYS.REQ.2"> <Name> Total System Cost </Name> <Rationale> Overall Cost Objective of the system </Rationale> <Verification> Add the sum of the components of the system. </Verification> <Comment> No comments </Comment> <Revision Month="4" Date="8" Year="2003" /> <Mappedto> null </Mappedto> <Template No="-1" /> <Description> The total cost must be less than or equal to USD $8,000,000 </Description> </Requirement> ..... etc .....
An Open Question
System-level design methods for embedded systems assemble system structures from IP (Intellectual Property) blocks. The IP block manufacturer needs to describe functionality of the block in sufficient detail to:
At the same time, the embedded system designer needs to check that the system will actually work and that no unintended subsystem interactions occur.
At this time, a precise methodology for resolving these conflicting criteria does not exist.
Research and Development Issues
Object/component-specification pairs are the basic building block in an interconnect design methodology (Newton, 2002). We need to understand:
As a starting point, we envision an XML database containing collections of object-specification pairs and a graphical frontend for querying the database and graphically displaying the relevant contents.
Formulation of Sensor-Specification Pairs
We will work with NG to develop a framework for describing sensor-specification pairs.
Figure 10. Formulation of Sensor-Specification Pairs
We anticipate that sensor-specification pairs (see Figure 8) will be written in XML and RDF.
XML Database and Graphical Frontend
We will develop an XML database of sensor-specification pairs.
Figure 11. Architecture of XML database and graphical frontend.
Research questions to be answered:
Copyright © 2003, Mark Austin, All rights reserved. The contents of this talk may not be reproduced without expressed written permission of Mark Austin. |