OpsCon
OpsCon
Operational Concept
(for reference, outside the scope of this course)
Operational Concept
(for reference, outside the scope of this course)
"A System Operational Concept (OpsCon) document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements."
29148:2011 Annex A
The OpsCon is like an enhanced project mission statement.
Everyone involved in the organization and the project should be able to read it to confirm understanding of the existing situation and make sure development of a new system is on the right track before much time and money is spent doing the wrong thing.
Required Reading
29148:2011 Annex A
MITRE Systems Engineering Guide: Concept Development including Operational Needs Assessment, Concept of Operations, Operational Requirements, and High-Level Conceptual Definition - pages 275-300. VERY USEFUL. READ! Especially Best Practices.
Life Cycle Processes and Enterprise Need sebokwiki
Concept Definition sebokwiki
Operational Concept (glossary) sebokwiki
Template with guidance (PDF) City of Tulsa
Example from USGS (PDF)
An interesting description of how this process fits into the SDLC for the State of Maryland - Phase 4: Requirements Analysis
This is just an example outline. Some organizations may use a different template. Your OpsCon does not necessarily need to include all sections.
A.2 Operational concept document (OpsCon) You can drop all of the "A.2"s in your document. Do include "Operational concept", perhaps with your project name or something similar as a title. A title page with a graphic, the name of the people or organization who created the document, the name of the organization for whom the document was created, and the date, would be nice.
A.2.1 Scope Describe the scope of the document as it relates to your project. What aspects of the system / organization / project are addressed? Think about what this document should do and what it doesn't need to do. Review the description of the OpsCon document from the standard (at the top of this page).
A.2.1.1 Identification Identify the document. Things like a Document Number, Document Version, Publication Date, Change Number. See section 3 of Standards & Procedures for Document Identification.
A.2.1.2 Document overview Provide an executive summary of the document and describe how it is organized (the tl;dr of the document). Write this last.
A.2.1.3 System overview Paint the picture of what is going on with the system currently, not your project. How does the organization's operation work as it relates to what your project aims to address? This is a good place for a diagram.
A.2.2 Referenced documents Identify any other documents you refer to, such as your StRS and Use Cases, or a policies and procedures manual.
A.2.3 Current system or situation This can just be a heading. Remember, everything that starts with A.2.3 in this outline should be about the current system or situation, not your project.
A.2.3.1 Background, objectives, and scope How did the current system or situation come to be? What are the goals? What does the current system try to do vs. what doesn't it try to do?
A.2.3.2 Operational policies and constraints What policies influence the current system or situation? 10 Types of Business Constraint
A.2.3.3 Description of the current system or situation How do things work now?
A.2.3.4 Modes of operation for the current system or situation "Operationally, modes of operation represent options available for selection at the User’s discretion, assuming certain conditions and criteria are met." Like a car's modes of operation are Park, Reverse, Neutral, and Drive assuming conditions such as: "The vehicle is at a safe location conducive to the action permissible under law and safe driving rules. The vehicle is safely stopped and the brake pedal is depressed. The driver can view on-coming traffic from all directions. The action can be safely completed before other traffic arrives." Source
A.2.3.5 User classes and other involved personnel This can just be a heading. Remember, everything that starts with A.2.3 in this outline should be about the current system, not your project.
A.2.3.5.1 Organizational structure How are different types of users organized? What roles are in the system and how do they relate? Administrators and regular users?
A.2.3.5.2 Profiles of user classes This should come from the StRS.
A.2.3.5.3 Interactions among user classes This should come from the StRS.
A.2.3.5.4 Other involved personnel This should come from the StRS.
A.2.3.6 Support environment Who is available to help users with the current system, such as trainers and help desk personnel? Who fixes, updates, and maintains the current system?
A.2.4 Justification for and nature of changes This can just be a heading. This section is important to get buy-in.
A.2.4.1 Justification for changes Talk people into it. Consider business value.
A.2.4.2 Description of desired changes At a high level. Can be a numbered list.
A.2.4.3 Priorities among changes Identify what is a must have and what would be nice to have.
A.2.4.4 Changes considered but not included When appropriate, demonstrate that other changes have been thought about and the rationale for not including them. By describing changes and features considered but not included in the proposed system, the authors document the results of their analysis activities. This information can be useful to other personnel involved with the system, whether it be users, acquirers, or suppliers should they want to know if a certain change or feature was considered, and if so, why it was not included. In software especially, there are few, if any, outward signs of what has been changed, improved or is still unsafe or unsecure. System Operational Concept (OpsCon) - BidNet
A.2.4.5 Assumptions and constraints 10 Types of Business Constraint
A.2.5 Concepts for the proposed system This can just be a heading. Remember, everything that starts with A.2.5 in this outline should be about the proposed system, your project.
A.2.5.1 Background, objectives, and scope Has something similar been tried before? SMART goals. What does the proposed system aim to do vs. what doesn't it aim to do.
A.2.5.2 Operational policies and constraints Policies should be published by the organization somewhere. Find and include ones that are relevant to the project. 10 Types of Business Constraint
A.2.5.3 Description of the proposed system This is the heart of this document. Put the most time and energy into this. Write a detailed and thorough description. Remember to focus on what and why, not how. A good place for context diagram.
A.2.5.4 Modes of operation See description of modes of operation in A.2.3.4 above. Reference your use cases and use case diagram.
A.2.5.5 User classes and other involved personnel This section could just be a heading.
A.2.5.5.1 Organizational structure How will different types of users be organized? What roles will be in the new system and how will they relate? Administrators and regular users?
A.2.5.5.2 Profiles of user classes Identify and describe users from your use cases and use case diagram, as roles, not individuals. Identify and describe types of users. Not about code object classes but could be useful for developing them by considering attributes / fields, and activities / methods. Could include use case diagram.
A.2.5.5.3 Interactions among user classes How does one type of user interact with another type of user. Could be useful for developing code interfaces and inheritance relationships.
A.2.5.5.4 Other involved personnel Who else has something to do with the system that you haven't already identified?
A.2.5.6 Support environment Who will need to be available to help users with the new system, such as trainers and help desk personnel? Who will fix, update, and maintain the new system?
A.2.6 Operational scenarios Describe an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components, or write stories which describe the expected utilization of the future system in terms of actions. https://www.sebokwiki.org/wiki/Operational_Scenario_(glossary) Can be the same as StRS 6.2.
A.2.7 Summary of impacts This can just be a heading or contain an introductory sentence.
A.2.7.1 Operational impacts How will what is done or how it's done change?
A.2.7.2 Organizational impacts How will the organization change? More or less staff? Different structure?
A.2.7.3 Impacts during development
A.2.8 Analysis of the proposed system This can just be a heading. Show evidence of critical thinking about the project.
A.2.8.1 Benefits Make this quantitative and qualitative. Again, make the case for development of the system.
A.2.8.2 Disadvantages and limitations What won't the proposed system be able to do? Why might someone say not to develop it?
A.2.8.3 Alternatives considered Develop in house vs contract out? Develop a new product or modify an off the shelf product?
A.2.9 Appendices
A.2.10 Glossary A list of acronyms and terms that are used in this document in a special way along with their meaning.
Operational concept document (OpsCon)
1 Scope
1.1 Identification
1.2 Document overview
1.3 System overview
2 Referenced documents
3 Current system or situation
3.1 Background, objectives, and scope
3.2 Operational policies and constraints
3.3 Description of the current system or situation
3.4 Modes of operation for the current system or situation
3.5 User classes and other involved personnel
3.5.1 Organizational structure
3.5.2 Profiles of user classes
3.5.3 Interactions among user classes
3.5.4 Other involved personnel
3.6 Support environment
4 Justification for and nature of changes
4.1 Justification for changes
4.2 Description of desired changes
4.3 Priorities among changes
4.4 Changes considered but not included
4.5 Assumptions and constraints
5 Concepts for the proposed system
5.1 Background, objectives, and scope
5.2 Operational policies and constraints
5.3 Description of the proposed system
5.4 Modes of operation
5.5 User classes and other involved personnel
5.5.1 Organizational structure
5.5.2 Profiles of user classes
5.5.3 Interactions among user classes
5.5.4 Other involved personnel
5.6 Support environment
6 Operational scenarios
7 Summary of impacts
7.1 Operational impacts
7.2 Organizational impacts
7.3 Impacts during development
8 Analysis of the proposed system
8.1 Benefits
8.2 Disadvantages and limitations
8.3 Alternatives considered
9 Appendices
10 Glossary