操作概念是指从用户的角度，使用非技术性的语言，描述未来产品的特征及其整个生命周期，包括使用、维护和废弃。操作概念是一种有效地与所有干系人进行沟通、并获得早期验证的手段。操作概念有时也称为“业务需求”或“商业需求”。

关于操作的概念最早出现在“IEEE 1362-1998 IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps)”。然后不断进化，最新的标准是“ISO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes.” （CMMI认证）  

我在美国国防部征兵总部负责过程改进的5年多时间里，听的最多的就是ConOps，即Concept of Operations，操作场景。在国内做评估的时候，听的最少的也是这个词。查资料才知ConOps最早是在美国陆军使用，然后在美国政府和国防部内普遍使用。在美国国防部联合军事行动领域，操作概念作为一个术语里被定义为：“联军指挥官使用可用资源来准确和清晰地描述期望完成的任务、以及怎样完成任务的口头或书面的陈述。” 因为最早编写CMMI的美国软件工程学院（Software Engineering Institute – SEI）是美国国防部和卡内基梅隆大学联合成立的研究机构，所以ConOps这个概念很早就被加入CMMI模型里面。

场景在CMMI里的定义是用户和产品之间的交互活动，以实现某种操作结果。这些交互活动，通常也称为“故事”或“用例”。场景是对操作概念的细化，通常使用一组场景来支持对操作概念的描述。

根据SWEBOK（Software Engineering Body of Knowledge），场景属于需求挖掘技术，也是一种基于模型的分析技术，同时场景也用来支持验收测试。（CMMI认证）

场景，或者听的更多的“用例”，经常会用到UML，RUP等方法里，也可以在软件需求文档里用来描述功能需求。在敏捷开发里，我们听到的更多的是“故事”。

使用场景来描述需求时也有局限性，对于那些不是基于用户交互的需求，比如算法、非功能需求等，就不适合用场景来描述。

操作概念和场景一起，共同展示了未来产品的特征和目标，是干系人沟通和确认的桥梁。经过验证和确认的操作概念和场景，为后续的用户需求和软件需求奠定了坚实的基础。有的企业在做需求跟踪矩阵时，也把操作概念和场景，与用户需求、软件需求等一起来进行跟踪。

文章来源作者高山

上一篇：ITSS升级趋势分析

下一篇： 软件和信息技术服务业统计公报