软件工程软件需求规约

1.制定软件需求规约的原则

1979年Balzer和Goldman提出了一系列规约原则：

（1）功能与实现分离，即描述要“做什么”，而不是“怎样实现”。

（2）开发一个系统期望行为的模型，该模型包含系统对来自环境的各种刺激的数据和功能反应。

（3）通过刻画其他系统构件和软件交互的方式，建立软件操作的语境。

（4）定义系统运行的环境。

（5）创建认知模型，而不是设计或实现模型，该认知模型按照用户感觉系统的方式来描述系统。

（6）规约必定是不完整的，并允许扩充。它总是某个通常相当复杂的现实（或想象）情形的一个抽象，所以它是不完整的，并将存在于多个细节层次。

（7）建立规约的内容和结构，并使它能够适应未来的变化。

（8）以上基本规约原则为表示软件需求提供了基础。在具体实现时，要注意一些表示需求的基本指导原则。

（9）表示格式和内容应该同问题相关。可以为软件需求规约的内容指定一个通用的大纲，但是包含在规约中的表示形式有可能随应用领域而发生变化。

（10）包含在规约中的信息应该是嵌套的。需求的表示应该展示信息的层次，以使得读者能够定位到需要的细节级别。可使用段落和图的编号模式来指明其细节层次，有时还需在不同的抽象层次表示相同的信息来帮助理解。

（11）图和其他符号形式应该在数量上有所限制并在使用上一致。混乱不一致的符号体系会妨碍理解并导致错误。

（12）表示应该是可修订的。规约的内容会发生变更，最好通过CASE工具来更新每次变更所影响的所有表示。

2.软件需求规约

软件需求规约（简称SRS）是软件开发人员在分析阶段需要完成的文档，是分析任务的最终产物。通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准以及其他和需求相关的数据，给出对目标软件的各种需求。通俗地说，SRS就是软件的定义。早在计划时期的“问题定义阶段”，开发方就与用户共同确定了“软件的目标和范围”。在分析阶段，上述目标与范围被细化为SRS。在IEEE830—1998号标准和我国国家标准GX856D—88中，都提出了关于软件需求规约的建议内容。

（1）引言主要叙述在问题定义阶段确定的关于软件的目标与范围，简要介绍系统背景、概貌、软件项目约束和参考资料等。(www.xing528.com)

（2）需求规约的主体描述软件系统的分析模型，包括信息描述、功能描述和行为描述。这部分内容除了可用文字描述外，也可以附上一些图形模型，如E-R图、DFD、CFD等。

（3）信息描述给出对软件所含信息的详细描述，包括信息的内容、关系、数据流向、控制流向和结构等。

（4）功能描述是对软件功能要求的说明，包括系统功能划分、每个功能的处理说明、限制和控制描述等。对软件性能的需求包括软件的处理速度、响应时间和安全限制等内容，通常也在此叙述。

（5）行为描述包括对系统状态变化以及事件和动作的叙述，据此可以检查外部事件和软件内部的控制特征。

（6）质量描述阐明在软件交付使用前需要进行的功能测试和性能测试，并且规定源程序和文档应该遵守的各种标准。这一节的目的是为了检验所交付的软件是否达到了SRS的规定。这可能是SRS中最重要的内容，但在实际工作中却容易被忽略，值得引起注意。

（7）接口描述包括系统的用户界面、硬件接口、软件接口和通信接口等的说明。

（8）其他描述阐述系统设计和实现上的限制、系统的假设和依赖等其他需要说明的内容。

软件需求规约作为产品需求的最终成果必须具有综合性，应该包括所有的需求。开发者和客户不能做任何假设。如果任何所期望的功能或非功能需求未写入软件需求规约，那么它将不能作为协议的一部分并且不能在产品中出现。

3.需求标识方法

为了满足软件需求规约的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以使开发人员在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。要达到这一目的，用单一的项目列表是不够的。因此，下面将描述几个不同的需求标识方法，并阐明它们的优点与缺点。

（1）序列号。最简单的方法是赋予每个需求一个唯一的序列号，如SRS-13。当一个新的需求加入商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号。序列号的前缀代表了需求类型，如SRS代表“软件需求说明”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。

（2）层次化编码。这是最常用的方法。如果功能需求出现在软件需求规约中第3.2部分，可以采用“3.2.4.3”这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。即使在一个中型的软件需求规约中，这些标识号也会扩展到许多位数字，并且这些标识也不提供任何有关每个需求目的的信息。如果要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要减少。对于这种简单的层次化编号的一种改进方法是对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。

在编写SRS时，可能会发现缺少特定需求的某些信息，在解决这个不确定性之前，可能必须与客户商议，检查与另一个系统的接口或者定义另一个需求。使用“待确定”（TBD）符号作为标准指示器来强调软件需求规约中这些需求的缺陷。通过这种方法，可以在软件需求规约中查找所需澄清需求的部分，记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号记录并创建一个TBD列表，这有助于跟踪每个项目。

在继续进行构造需求集合之前，必须解决所有的TBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。当开发人员遇到一个TBD问题或其他模糊之处时，他可能不会返回到原始需求来解决问题。如果有TBD问题尚未解决，而开发人员又要继续进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。

编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。经常总结编写SRS，对经验的积累是非常有益的。许多需求文档可以通过使用有效的技术编写风格和用户术语得以改进。在编写优秀的需求文档时，希望读者还需牢记以下几点建议。

需求陈述应该具有一致的样式。通常“系统必须”或者“用户必须”应紧跟一个行为动作和可观察的结果，例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的库存清单”。为了减少不确定性，必须避免模糊的、主观的术语。例如，用户友好、简单、有效、最新技术、优越的、可接受的等。当客户说“用户友好”或者“快”时，分析人员应该明确它们的真正含义并且在需求中阐明用户的意图。避免使用比较性的词汇，定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”“支持”或“管理”某些事情时，分析人员应该能理解客户的意图。由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”“等等”之类的连词。