System requirements specification

Abstract: DeMarco's "Structured Analysis and System Specification" is the final paper chosen for inclusion in this book of classic articles on the structured revolution. It is last of three on the subject of analysis, and, together with Ross/Schoman [Paper 22] and Teichroew/Hershey [Paper 23], provides a good idea of the direction that structured analysis will be taking in the next few years. Any competent systems analyst undoubtedly could produce a five-page essay on "What's Wrong with Conventional Analysis." DeMarco, being an ex-analyst, does so with pithy remarks, describing conventional analysis as follows" "Instead of a meaningful interaction between analyst and user, there is often a period of fencing followed by the two parties' studiously ignoring each other... The cost-benefit study is performed backwards by deriving the development budget as a function of expected savings. (Expected savings were calculated by prorating cost reduction targets handed down from On High.)" In addition to providing refreshing prose, DeMarco's approach differs somewhat --- in terms of emphasis --- from that of Teichroew/Hershey and of Ross/Schoman. Unlike his colleagues, DeMarco stresses the importance of the maintainability of the specification. Take, for instance, the case of one system consisting of six million lines of COBOL and written over a period of ten years by employees no longer with the organization. Today, nobody knows what the system does.t Not only have the program listings and source code been lost --- a relatively minor disaster that we all have seen too often --- but the specifications are completely out of date. Moreover, the system has grown so large that neither the users nor the data processing people have the faintest idea of what the system is supposed to be doing, let alone how the mysterious job is being accomplished! The example is far from hypothetical, for this is the fate that all large systems eventually will suffer, unless steps are taken to keep the specifications both current and understandable across generations of users. The approach that DeMarco suggests --- an approach generally known today as structured analysis --- is similar in form to that proposed by Ross and Schoman, and emphasizes a top-down, partitioned, graphic model of the system-to-be. However, in contrast to Ross and Schoman, DeMarco also stresses the important role of a data dictionary and the role of scaled-down specifications, or minispecs, to be written in a rigorous subset of the English language known as Structured English. DeMarco also explains carefully how the analyst proceeds lrom a physical description of the user's current system, through a logical description of that same system, and eventually into a logical description of the new system that the user wants. Interestingly, DeMarco uses top-down, partitioned dataflow diagrams to illustrate this part of the so-called Project Life Cycle --- thus confirming that such a graphic model can be used to portray virtually any system. As in other short papers on the subject, the details necessary for carrying out DeMarco's approach are missing or are dealt with in a superficial manner. Fortunately, the details can be found: Listed at the end of the paper are references to three full-length books and one videotape training course, all dealing with the kind of analysis approach recommended by DeMarco.

Abstract: Requirements definition encompasses all aspects of system development prior to actual system design. We see the lack of an adequate approach to requirements definition as the source of major difficulties in current systems worlk This paper examines the needs for requirements definition, and proposes meeting those objectives with three interrelated subjects: context analysis, functional specification, and design constraints. Requirements definition replaces the widely used, but never well-defined, term "requirements analysis."

Abstract: Developing secure-critical systems is difficult and there are many well-known examples of security weaknesses exploitedin practice. Thus a sound methodology supporting secure systems development is urgently needed.Our aim is to aid the difficult task of developing security-critical systems in an approach basedon the notation of the Unified Modeling Language. We present the extension UMLsec of UML that allows to express securityrelevant information within the diagrams in a system specification. UMLsec is defined in form of a UML profile using the standard UML extension mechanisms. In particular, the associatedc onstraints give criteria to evaluate the security aspects of a system design, by referring to a formal semantics of a simplifiedfragm ent of UML. We demonstrate the concepts with examples.

Abstract: The next article, by Ross and Schoman, is one of three papers chosen for inclusion in this book that deal with the subject of structured analysis. With its companion papers --- by Teichroew and Hershey [Paper 23] and by DeMarco [Paper 24] --- the paper gives a good idea of the direction that the software field probably will be following for the next several years. The paper addresses the problems of traditional systems analysis, and anybody who has spent any time as a systems analyst in a large EDP organization immediately will understand the problems and weaknesses of "requirements definition" that Ross and Schoman relate --- clearly not the sort of problems upon which academicians like Dijkstra, Wirth, Knuth, and most other authors in this book have focused! To stress the importance of proper requirements definition, Ross and Schoman state that "even the best structured programming code will not help if the programmer has been told to solve the wrong problem, or, worse yet, has been given a correct description, but has not understood it." In their paper, the authors summarize the problems associated with conventional systems analysis, and describe the steps that a "good" analysis approach should include. They advise that the analyst separate his logical, or functional description of the system from the physical form that it eventually will take; this is difficult for many analysts to do, since they assume, a priori, that the physical implementation of the system will consist of a computer. Ross and Schoman also emphasize the need to achieve a consensus among typically disparate parties: the user liaison personnel who interface with the developers, the "professional" systems analyst, and management. Since all of these people have different interests and different viewpoints, it becomes all the more important that they have a common frame of reference --- a common way of modeling the system-to-be. For this need, Ross and Schoman propose their solution" a proprietary package, known as SADT, that was developed by the consulting firm of SofTech for which the authors work. The SADT approach utilizes a top-down, partitioned, graphic model of a system. The model is presented in a logical, or abstract, fashion that allows for eventual implementation as a manual system, a computer system, or a mixture of both. This emphasis on graphic models of a system is distinctly different from that of the Teichroew and Hershey paper. It is distinctly similar to the approach suggested by DeMarco in "Structured Analysis and System Specification," the final paper in this collection. The primary difference between DeMarco and Ross/Schoman is that DeMarco and his colleagues at YOURI]DN inc. prefer circles, or "bubbles," whereas the SofTech group prefers rectangles. Ross and Schoman point out that their graphic modeling approach can be tied in with an "automated documentation" approach of the sort described by Teichroew and Hershey. Indeed, this approach gradually is beginning to be adopted by large EDP organizations; but for installations that can't afford the overhead of a computerized, automated systems analysis package, Ross and Schoman neglect one important aspect of systems modeling. That is the "data dictionary," in which all of the data elements pertinent to the new system are defined in the same logical top-down fashion as the rest of the model There also is a need to formalize mini-specifications, or "mini-specs" as DeMarco calls them; that is, the "business policy" associated with each bottom-level functional process of the system must be described in a manner far more rigorous than currently is being done. A weakness of the Ross/Schoman paper is its lack of detail about problem solutions: More than half the paper is devoted to a description of the problems of conventional analysis, but the SADT package is described in rather sketchy detail. There are additional documents on SADT available from SofTech, but the reader still will be left with the fervent desire that Messrs. Ross and Schoman and their colleagues at SofTech eventually will sit down and put their ideas into a full-scale book.