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

USER CUSTOMER

DEVELOPER

USER

CUSTOMER

DEVELOPER

Traditional requirements elicitation Better requirements elicitation

The most important step in the system development process isthe accurate communication of operational requirements fromthose who need the system to those who will build it.

[Fairley and Thayer, 1997]

Eliciting Operational RequirementsProblems 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 requirementsproduced by the developer

4. developer's requirements specifications typically specifiessystem attributes such as

• functions, • performance factors,• design constraints, • system interfaces and• quality attributes,

but typically contains little or no information concerningoperational characteristics of the specified system.

[Fairley and Thayer, 1997]

The Concept Analysis ProcessConcept analysis - process of analyzing a problem domain andan operational environment for the purpose of specifying thecharacteristics of a proposed system from users' perspective.

Traditionally, emphasis has been in documenting functionalitywith little concern for how that functionality will be used.

Concept analysis emphasizes an integrated view of a systemand its operational characteristics, rather than focusing onindividual functions or pieces of a system.

Goal of concept analysis: to avoid development of a systemin which each individual function meets its specifications, butthe system fails as a whole to meet the users' needs.

Case Study: A Child's SwingImportance of operational requirements.

What the user wanted How the customer described it How the analyst specified it How the designer implemented it

[Fairley and Thayer, 1997]

Guidelines for Operational Concept Document

Operational Concept Document (OCD) is a document thatdescribes the mission of the system, its operational and supportenvironments, and the functions and characteristics of thecomputer 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 anddeveloper-oriented instead of user-oriented.

[Fairley and Thayer, 1997]

The Concept Analysis DocumentIdentifies• 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 AnalysisConcept 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 ConOpsdocument written in narrative prose using users' language, andusing visual forms (diagrams, illustrations, graphs, etc.)wherever possible.

Each operational scenario needs a test scenario to validate thesystem in user's environment. Validate proposed system bywalking 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 Scope1.1 Identification1.2 System Overview1.3 Document Overview

2 Referenced Documents3 The Current System or Situation

3.1 Background, Objectives, & Scope3.2 Operational Policies & Constraints3.3 Description3.4 Modes of Operation3.5 User Classes

3.5.1 Organizational Structure

3.5.2 Profiles of User Classes3.5.3 Interactions

3.5 Other Involved Personnel3.6 Support Environment

4 Justification for and Nature ofProposed Changes & New Features4.1 Justification4.2 Description4.3 Priorities among changes/ features4.4 Changes/Features Considered but Not

Included4.5 Assumptions and Constraints

5 Concepts of Operations for theNew or Modified Proposed System5.1 Background, Objectives & Scope5.2 Operational Policies & Constraints5.3 Description of Proposed System5.4 Modes of Operation5.5 User Classes

5.5.1 Organization Structures5.5.2 Profiles of User Classes5.5.3 Interactions among User

Classes5.6 Other Involved Personnel

5.7 Support Environment6 Proposed Operational Scenarios7 Summary of Impacts

7.1 Operational Impacts7.2 Organizational Impacts7.3 Impacts During Developments

8 Analysis of Proposed System8.1 Summary of Improvements8.2 Disadvantages & Limitations8.3 Alternatives/Tradeoffs considered

9 Notes, Appendices, and Glossary