Early in the system design process, a design method must be chosen. This choice is usually dictated by what methods the designer has previously used, not by an open selection process. In this paper, we provide descriptions of some available design methods and examples of their use. In this project, we will develop benchmark problems that will be solved by a variety of design methods and will identify characteristics of problems that might make one system design method more or less appropriate. The top-level question we wish to answer is "for which type of problem is each method best?"If a system is to be built, then the system must ultimately be described as a collection of state machines. However, these state machines are often not created by the systems engineers. The systems engineers use some method to create a high-level abstraction of the desired system. Then they turn this abstraction over to the specialty engineers who actually reduce it to a collection of state machines. In this paper, we present solutions for a simple design problem by using the following 11 high-level system design methods: state transition diagrams, algorithmic state machine (ASM) notation, model-based system engineering, Graphical Description Language, RDD-100, structured analysis (using entity relationship diagrams, data-flow diagrams, and state transition diagrams with Ward-Mellor notation), functional decomposition, object-oriented analysis (OOA) with Shlaer-Mellor notation, OOA and object-oriented design (OOD) with Booch notation, an operational evaluation modeling-(OpEM)-directed graph, and IDEF0. Each method was used by an expert user of that method. The solutions presented make it obvious that the choice of a design method greatly effects the resulting system design. Index Terms-Architecture, design methodology, logic design, object-oriented methods. ).M. Alford is an independent consultant, Dean (M'97) received the M. A. degree in information system consulting from Brigham Young University, Provo, UT, in 1989 and the Ph.D. degree in management information systems from the University of Arizona, Tucson, in 1995. He is a Research Scientist at the Center for Management Information, University of Arizona. He provides consulting and research services on a number of topics, including electronic meeting systems (EMS), collaborative business process reengineering methods, and collaborative systems analysis and design methods. He has helped develop group-enabled activity and data modeling software to support technical and nontechnical users. He also developed structured meeting methods for use with these tools. The activity model software has since been made commercially available through Ventana Corporation, Tucson. His research interests include electronic meeting support of process and data modeling, business process reengineering, systems analysis and design, and group elicitation of information systems requirements.Jeremy Duke received the B.S. degree in systems (software) engineering in 1994 and the M.S. degree in systems engine...
The reader who wishes to learn how to write software requirements using the SREM techniques should first study the language and support software capabilities described in the REVS Users Manual [1]. However, a general understanding can be obtained from this manual alone. To facilitate this, a brief overview of RSL and REVS is provided here. i.3.1 The Requirements Statement Language (RSL) RSL is an extensible language which means that certain primitive concepts are built in and the user can use these to define more complex language concepts. The primitives are elements, attributes, relationships, and structures. From these, we have defined a nucleus of concepts which to date have proven sufficient. Future users of the language can add to these by means of the extension features as required. These concepts are introduced as they are used in this manual, and are presented in full in Appendix A. The Requirements Statement Language is a user-oriented mechanism for specifying requirements. It is oriented heavily toward colloquial English, and uses nouns for elements and attributes and transitive verbs for relationships; a complementary relationship uses the passive form of the verb. Both syntax and semantics echo English usage, so that many simple RSL sentences may be read as English with the same meaning. However, the precision of RSL, enforced through machine translation, is not typical of colloquial speech; as a result, most complex RSL sentences are a somewhat stylized form of English. 1.3.2 The Requirements Engineering and Validation System (REVS) REVS is an integrated set of tools used to support the definition, analysis, simulation, and documentation of software requirements. A key concept of REVS is that all requirements are translated into a central data base called the Abstract System Semantic Model (ASSM). The RSL statements themselves are not stored in the ASSM. Instead, they are translated into representations of the information content of the requirements statements. This provides an efficient and flexible means of maintaining a large software specification in a relatively small computer data base.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.