Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 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 is the accurate communication of operational requirements from those who need the system to those who will build it.
  2. 2. [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,
  3. 3. but typically contains little or no information concerning operational characteristics of the specified system.
  4. 4. [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.
  5. 5. 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.
  6. 6. What the user wanted How the customer described it How the analyst specified it How the designer implemented it
  7. 7. [Fairley and Thayer, 1997] Guidelines for Operational Concept Document Operational 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.
  8. 8. [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
  9. 9. • 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.
  10. 10. 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
  11. 11. 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