禁止发言
- 最后登录
- 2021-8-11
- 注册时间
- 2018-11-28
|
需求分析对系统的成败影响甚大,所以对需求的描述应该尽可能的好。需求规约作为记录需求分析结果的文档应当具有如特征。软件之家安卓的具体问题可以到我们网站了解一下,也有业内领域专业的客服为您解答问题,为成功合作打下一个良好的开端!
优秀的需求规约是完整的,因为它可以充分析说明用户所期望的系统功能。而且每一个需求的描述均包含了开发人员设计和实现这项功能需要的所有信息。
对于每一项需求都必须正确地描述所需要的系统功能,要真是地反映用户的意图。需求的正确性只有提出需求的人-用户才能加以判断,所以需求在提交给给开发人员之前,必须请用户予以确认。
需求最大的用途是对待开发软件系统的知识实现共享,它将用户的期望准确地传递给系统的相关开发人员,如设计者、实现者和测试者等。所以需求的描述必须是可理解的。可理解性要求需求描述的信息要充分,要具有完整性。同时,过多的冗余信息会扰乱读者的思路,所以可理解性也要求描述仅包含必要的信息,即精确性。
需求必须能够在软件系统及其运行环境的已知条件和约束实现。显然,用户对需求的技术可行性是无法判断的,所以需求的可行性是由开发人员进行评审。在评审过程中,开发人员可能需要进行一定的分析和研究,而不是单纯的额凭借经验和直觉。对于难以判断的需求,必要的时候要通过开发原型来加以验证。
每一项需求都应该是必须的,它是满足用户的业务需求所必须的。如通过一条需求被忽略之后,系统仍然能够解决用户的问题,那么它就是非必要需求,应该删除。
需求规约能够实现共享的前提是参与软件系统开发的各种角色能够形成关于需求规约共同的理解。因此每一项需求都应该只能携带一种语义,即需求无歧义。而需求规约大多采用自然语言进行描述,这显然将会导致规约中含有大量容易导致歧义的因素。因此,在保证需求描述无歧义时,要格外注意需求描述中的词汇选择,通常在需求开发中要定义一个可以共同理解的词汇表,然后再在其基础上进行需求的描述。
需求应该是可验证的,即通过分析、检查、模拟或者测试等方法能够判断需求是否被满足。如果需求不可验证,就无法判断完成的软件系统是否满足了该需求,开发人员也无法选择一个能够实现该需求的方法。 |
|