R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Oper-ational Requirements to Technical Specifications," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Comp. Soc. Press, Los Alamitos, CA, 1997.
Eliciting Operational Requirements
The most important step in the system development process is the accurate communication of operational requirements from those who need the system to those who will build it.
[Fairley and Thayer, 1997]
Eliciting Operational Requirements
Problems with traditional ways of specifying problems:
1. customer may not adequately convey the needs of the user.
2. developer may not be an expert in the application domain, which inhibits communications.
3. users and customers may not understand the requirements produced by the developer
4. developer's requirements specifications typically specifies system attributes such as
• functions, • performance factors,
• design constraints, • system interfaces and
• quality attributes,
but typically contains little or no information concerning operational characteristics of the specified system.
[Fairley and Thayer, 1997]
The Concept Analysis Process
Concept analysis
- process of analyzing a problem domain and an operational environment for the purpose of specifying the characteristics of a proposed system from users' perspective.Traditionally, emphasis has been in documenting functionality with little concern for how that functionality will be used.
Concept analysis emphasizes an integrated view of a system and its operational characteristics, rather than focusing on individual functions or pieces of a system.
Goal of concept analysis: to avoid development of a system in which each individual function meets its specifications, but the system fails as a whole to meet the users' needs.
Case Study: A Child's Swing
Importance of operational requirements.
[Fairley and Thayer, 1997]
Guidelines for
Operational Concept DocumentOperational Concept Document (OCD) is a document that describes the mission of the system, its operational and support environments, and the functions and characteristics of the computer system within an overall system.
Several guidelines and standards exist to prepare an OCD:
• Mil-Std 498 for Department of Defense SW development
• IEEE Standard 1498 for commercial SW development,
• AIAA OCD 1992 for the American Inst/ of Aeronautics and Astronautics (for embedded real-time systems)
• ConOps 1997 proposed by Fairley and Thayer because they felt the above guidelines were systems-oriented and developer-oriented instead of user-oriented.
[Fairley and Thayer, 1997]
The Concept Analysis Document
Identifies
• classes of users and
• modes of operation
• normal mode • emergency mode
• maintenance mode • backup mode
• degraded mode • diagnostic mode
Users need to communicate
• essential needs
• desirable needs -- prioritized
• optional needs -- prioritized
Prioritized user needs provide the basis for
• establishing an incremental development process and
• making trade-offs among
operational needs, schedule and budget.
Concept Analysis
Concept Analysis Team
, include reprepresentatives from• user organization
• buyer organization
• developer organization or development experts/consultants
• training
• operational support
Results of concept analysis are recorded in the ConOps document written in narrative prose using users' language, and using visual forms (diagrams, illustrations, graphs, etc.) wherever possible.
Each operational scenario needs a test scenario to validate the system in user's environment. Validate proposed system by walking thru all scenarios, cover abnormal operations:
• exception handling, • stress load handling,
• handling incomplete data, • handling incorrect data.
(see p. 50-51 of Fairley and Thayer for ConOps Dev. Process)
Outline for a Concept of Operations Document
[Fairley & Thayer, 1997]
1 Scope
1.1 Identification
1.2 System Overview
1.3 Document Overview
2 Referenced Documents
3 The Current System or Situation
3.1 Background, Objectives, & Scope
3.2 Operational Policies & Constraints
3.3 Description
3.4 Modes of Operation
3.5 User Classes
3.5.1 Organizational Structure
3.5.2 Profiles of User Classes
3.5.3 Interactions
3.5 Other Involved Personnel
3.6 Support Environment
4 Justification for and Nature of
Proposed Changes & New Features
4.1 Justification
4.2 Description
4.3 Priorities among changes/ features
4.4 Changes/Features Considered but Not Included
4.5 Assumptions and Constraints
5 Concepts of Operations for the
New or Modified Proposed System
5.1 Background, Objectives & Scope
5.2 Operational Policies & Constraints
5.3 Description of Proposed System
5.4 Modes of Operation
5.5 User Classes
5.5.1 Organization Structures
5.5.2 Profiles of User Classes
5.5.3 Interactions among User
Classes
5.6 Other Involved Personnel
5.7 Support Environment
6 Proposed Operational Scenarios
7 Summary of Impacts
7.1 Operational Impacts
7.2 Organizational Impacts
7.3 Impacts During Developments
8 Analysis of Proposed System
8.1 Summary of Improvements
8.2 Disadvantages & Limitations
8.3 Alternatives/Tradeoffs considered
9 Notes, Appendices, and Glossary