Premium
GRAPHICAL DESCRIPTION LANGUAGE:™ A SOLUTION FOR THE SYSTEM‐SOFTWARE INTERFACE PROBLEM
Author(s) -
LaBudde Edward V.
Publication year - 1996
Publication title -
incose international symposium
Language(s) - English
Resource type - Journals
ISSN - 2334-5837
DOI - 10.1002/j.2334-5837.1996.tb02070.x
Subject(s) - computer science , timeline , software requirements , requirement , software requirements specification , software engineering , notation , system requirements , requirements analysis , software system , requirements elicitation , programming language , software design , software , software development , software construction , arithmetic , mathematics , archaeology , history , operating system
A growing gap exists between the systems engineer and the software engineer. A major source of this gap is the failure of both engineering groups to adequately address certain system, function, and performance requirements during the decomposition process. This is especially true for logic, sequencing, and timeline requirements (LaBudde 1995). One reason for this gap is that the old reliable system engineering tools like functional flow designs diagrams and N 2 charts fail to capture all the requirements. In addition, the new software techniques like object‐oriented design also fail to capture all the requirements including sequencing, timeline, and performance. Another reason for this gap is the proliferation of software requirements and design methodologies. These have created a “Tower of Babble” of notations (Alford 1992). The confusion created by different notations can have serious consequences to system behavior and performance (Shaw 1995). We define the requirements for a general purpose system engineering requirements and design capture method and tool. Furthermore, a proposed solution to this problem which will meet the specified requirements is presented. We have developed a robust Graphical Description Language™ (GDL™) which ensures that all the requirements can be described and related using graphical representations. This method is simple to execute and easy to understand by all team members. The method works equally well on describing requirements for mechanical, electrical, optical, and software implementations. The approach provides a single, common method of communications for all engineers on the program and solves the system‐software interface problem.