In the agile community, there is always some comment or opinion about how hard it is to define what the requirements are. How we can't possibly estimate the work since all the work is emergent. If this were the case in practice, we'd all be working on death march projects, with no end in sight, no idea of what Done looks like.
Here's the way we work projects using agile development practices. It's called the Concept of Operations and here are a few definitions from various sources.
A Concept of Operations (CONOPS) is a user-oriented document that "describes systems characteristics for a proposed system from a user's perspective. A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative system characteristics to stakeholders.” -
IEEE Computer Society, March 19, 1998, IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document (IEEE Std 1362-1998).
This definition focuses on the user and what the user needs to accomplish the mission - the business outcome for commercial IT projects.
A CONOPS "describes the proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used. CONOPS can be tailored for many purposes, for example, to obtain consensus among the acquirer, developers, supporters, and user agencies on the operational concept of a proposed system. Additionally, a CONOPS may focus on communicating the user's needs to the developer or the developer's ideas to the user and other interested parties."
Office of Management and Budget, December 5, 1994, Operational Concept Description (OCD), Data Item Description DI-IPSC-81430.
Another one with a similar focus on the user but includes communicating needs the development organization.
A Concept of Operations (ConOps) document is produced early in the requirements definition process to describe what the system will do (not how it will do it) and why (rationale). It should also define any critical, top-level performance requirements or objectives (stated either qualitatively or quantitatively) and system rationale.
Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4th Edition, INCOSE
A current definition from the Systems Engineering point of view. The focus here is on what and why, not how.
The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems, as black boxes, to forward the organization’s goals and objectives. The ConOps document describes the organization’s assumptions or intent in regard to an overall operation or series of operations of the business with using the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of the future business and systems, for the project to understand its background, and for the users of [ISO/IEC/IEEE 29148] to implement the stakeholder requirements elicitation.
This is a newer IEEE guide about the ConOps. Here's where the ConOps fits in the overall scheme
One underlying principle illustrated by the figure is that when a decision is made to satisfy a need, that need gives rise to a corresponding requirement or set of requirements. This traceability from the need to the requirement is critical to the success of the project. Requirements without needs are a waste. They're Features that have no purpose in the larger scheme of things.
This is how software becomes bloatware. Features are placed in the system without an identified business need. There are straight forward ways to prevent this, starting by building a Balanced Scorecard for the project.
Here's How To Start Building the ConOPS
- Identify the required mission(s) in functional terms. Define the risks to accomplishing the functional outcomes.
- Describe capabilities required by the customer or its’ stakeholders/partners to accomplish the mission.
- Describe the capabilities independently of whether or not customer currently possesses them.
- Do not specify capabilities in terms of assets, equipment or other means that might satisfy the need; i.e., state the capability (need), not the solution (equipment). The next part of this section also builds upon and references the MNS section cited below. More detail than in the Mission Needs Statement may be provided.
And each Capability in the ConOps needs units of measure meaningful to the decision makers
- Measures of Effectiveness - Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
- Measures of Performance ‒ characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.
- Key Performance Parameters ‒ capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program
Without the ConOps, we're laying the ground work for project trouble and these root causes ...
