需求规约(Software Requirement Specification)
目录 |
软件需求规约是指分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
需求分析对系统的成败影响甚大，所以对需求的描述应该尽可能的好。需求规约(Requirement Specification)作为记录需求分析结果的文档应当具有如下特征。
1．完整性
优秀的需求规约是完整的，它可以充分地说明用户所期望的系统功能。每一个需求的描述均包含了开发人员设计和实现这项功能需要的所有信息。
2．正确性
对于每一项需求都必须正确地描述所需要的系统功能．要真实地反映用户的意图。需求的正确性只有提出需求的人——用户才能加以判断，所以需求在提交给开发人员之前，必须请用户予以确认。
3．完整性与精确性
需求最大的用途是对待开发软件系统的知识实现共享，它将用户的期望准确地传递给系统的相关开发人员，如设计者、实现者和测试者等。所以需求的描述必须是可理解的。可理解性要求需求描述的信息要充分，要具有完整性。同时，过多的冗余信息会扰乱读者的思路，所以可理解性也要求描述仅包含必要的信息，即精确性。
4．可行性
需求必须能够在软件系统及其运行环境的已知条件和约束下实现。显然，用户对需求的技术可行性是无法判断的，所以需求的可行性是由开发人员进行评审。在评审过程中，开发人员可能需要进行一定的分析和研究，而不是单纯的凭借经验和直觉。对于难以判断的需求，必要的时候要通过开发原型来加以验证。
5．必要性
每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够解决用户的问题，那么它就是非必要需求，应该删除。
6．无歧义
需求规约能够实现共享的前提是参与软件系统开发的各种角色能够形成关于需求规约共同的理解。因此每一项需求都应该只能携带一种语义，即需求无歧义。而需求规约大多采用自然语言进行描述，这显然将会导致规约中含有大量容易导致歧义的因素。因此，在保证需求描述的无歧义时，要格外注意需求描述中的词汇选择，通常在需求开发中要定义一个可以共同理解的词汇表，然后再在其基础上进行需求的描述。
7．可验证
需求应该是可验证的，即通过分析、检查、模拟或者测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的软件系统是否满足了该需求，开发人员也无法选择一个能够实现该需求的方法。