A method for capturing, specifying, and analyzing software requirements
languages/ada/docs/reguide: File Name Size --------- ---- README 4,153 reguide.zip 3,913,497 Totals ============== ============== 2 Files 3,917,650
Consortium Requirements Engineering Guidebook The Consortium Requirements Engineering (CoRE) method is a method for capturing, specifying, and analyzing software requirements. The Consortium has worked with industrial developers of real-time and embedded systems to identify their key problems and to provide a method that addresses their needs. CoRE supports the development of precise, testable specifications that are demonstrably complete and consistent. CoRE also supports key process issues, such as managing changing requirements and reuse. CoRE is a single coherent requirements method that: * Integrates Object-Oriented and Formal Models Behavioral requirements in CoRE are written in terms of two underlying models: the behavioral model and the class mode. The behavioral model provides a standard structure for analyzing and capturing behavioral requirements (i.e., what the software must do) in a form that is is precise, analyzable, and testable. The class model provides facilities for organizing a CoRE specification into parts; it provides facilities supporting change management, reuse, and concurrent development. These models are integrated in a single CoRE specification. * Integrates Graphical and Rigorous Specifications. A key goal of the method is to improve communication among the parties involved in requirements engineering. CoRE provides a graphic representation that helps all parties, customers, engineers, designers, and programmers grasp essential relationships among system components. CoRE also provides a rigorous underlying model for capturing detailed behavioral, timing, and accuracy constraints. This rigorous model allows you to develop requirements that are precise, unambiguous, testable, and demonstrably complete and consistent. CoRE provides a consistent interpretation of both graphical and rigorous notations so they combine smoothly in a single specification. * Uses Existing Skills and Notations. The language used to specify requirements in CoRE is based on familiar concepts and existing notations. You can apply CoRE using basic concepts familiar to programmers and others writing requirements, e.g., events, Boolean expressions, and state machines. Although CoRE is based on an underlying mathematical mode, just as programming languages are based on formal models, CoRE can be applied without a detailed understanding of formalisms. * Avoids Premature Design Decisions. CoRE allows you to specify requirements without prematurely specifying design or implementation details. CoRE describes required behavior in terms of relations that the software must maintain between quantities that the software monitors and those it controls. This allows you to specify what the software must do without having to provide an algorithm or detailed design. * Provides Guidance. The CoRE behavioral model provides practical guidance in eliciting software requirements, developing a requirements specification, and analyzing the specification for completeness and consistency. The behavioral model defines exactly what requirements information must be captured, and in what form, to develop a complete and consistent specification. This guidebook provides a detailed guide to the practice of CoRE. It is intended as an engineering handbook that systems and software engineers can use as a reference when applying the CoRE method. It describes the following: * The goals and benefits of the CoRE method * The underlying concepts and principles used to develop rigorous requirements specifications in CoRE * The set of notations and specification techniques needed to write a CoRE specification * A complete requirements development process starting with system-level requirements as input and ending with a software requirements specification as output * Heuristics for applying specific techniques to accomplish your specification goals, such as reuse or change management * Criteria and a process for checking a CoRE specification for completeness and consistency * Illustration of the techniques and heuristics through a common example-the Fuel Level Monitoring System (FLMS)
1.0.9 1 June 94 Initial release to the PAL
Approved for public release; Distribution unlimited
This documentation is provided "AS IS" and without any expressed or implied warranties whatsoever. No warranties as to performance, merchantability, or fitness for a particular purpose exist. The user must assume the entire risk and liability of using this document. In no event shall any person or organization of people be held responsible for any direct, indirect, consequential or inconsequential damages or lost profits.