软工系列之---需求分析

第三章 需求分析

需求的定义、分类。

1）用户解决问题或达到目标所需的条件或能力。

2）系统或是系统部件要满足的合同、标准、规范或其他正规文档所需要具有的条件或是能力。

3）一种反映上面所描述的条件或是能力的文档说明。

需求就是以一种清楚简洁，一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的集合。

需求分析的目的：准确定义用户的需求i，进行细致的调查分析，将用户的非形式化要求i转化为完整的需求定义，再将需求定义转换为相应的形式的规格说明。

需求层次。

业务需求。

反映了组织机构或者客户对系统或是产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

是组织或客户对于系统的层次 目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。

业务需求的内容：

业务：产品术语哪些业务的范畴？应该完成什么功能？需求为什么服务？

客户：产品区别于其他竞争产品的特定是什么？

价值：产品的价值体现在什么方面？优先级：产品功能特性的优先级次序是什么？

用户需求。

用户需求是从用户的角度来描述系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统内部特性。

用户需求描述：原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言。

问题：自然语言表达容易含糊和不准确。

系统需求。

系统需求是更加详细的描述系统应该做什么，通常包括许多不同的分析模型，诸如对象模型、数据模型、状态模型等。

系统需求的描述：结构化英语（PDL），可视化模型，形式化方法。系统需求主要是面向开发人员进行描述，是开发人员进行设计的基础。

需求的质量特性。

正确性：需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正的需求。审查需求的正确性应该考虑的问题

用户参与需求过程的程度如何？每一个需求描述是否准确的反映了用户的需要？系统用户是否已经认真考虑了每一项描述？需求可以追溯到来源吗？

完整性：需求规格说明应该包括软件要完成的全部任务，不能遗留任何必要的需求信息，注重用户的任务而不是系统的功能有助于避免不完善。审查需求的完整性应该考

虑的问题。是否存在遗漏的功能或业务过程？在每个定义的功能之间是否有接口？是否有信息或消息在所定义的功能之间传递？是否定义了功能的使用者？是否已经清楚的定义

了用户与功能之间的交互？是否定义了与外部过程和系统之间的接口？所描述的功能是否可以映射到业务过程中？文档中是否存在待确定的需求引用？文档中是否存在未定义的

术语和引用？文档的各个部分都完整吗？需求包括非功能属性说明吗？是否考虑了软件的性能？是否考虑了安全性的要求？是否考虑了可靠性？是否考虑了系统容量问题？

无二义性。

需求规格说明中的描述对所有人只能有一种明确统一的解释，由于自然语言极易导致二义性，所以尽量把每一项需求用简洁明了的用户型的语言表达。

审查需求的无二义性应该考虑的问题：需求规格说明是否有术语词汇表？具有多重含义或未知含义的术语是否已经定义？需求描述是否可量化和可验证?每一项需i去都有测试准则吗？

可验证性。

需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。

审查需求的可验证应该考虑的问题。在需求文档中是否存在不可验证的陈述，诸如“用户界面友好”，“容易”，“简单“，”快速“、”健壮“，”最新技术“等？

所有的描述都是具体的可测量的吗？

一致性。

需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。审查需求的一致性应该考虑的问题：文档的组织形式是否易于一致？不同功能的描述之间是否存在矛盾？是否存在有矛盾的需求描述或术语？文档中是否存在时序上的不一致？

可修改性。

需求规格说明的格式和组织化方式应保证后续的修改能够比较容易的协调一致。我们可以使用目录表、索引和相互参照列表等方法。

审查需求的可修改性应该考虑的问题。是否存在明显的需求交叉引用？是否与内容列表和索引？是否存在冗余的需求，即同一个需求的描述出现在的文档的不同大方？如果存在，它们是交叉引用吗？

可跟踪型。

可跟踪性意味着每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来。可跟踪性的两种方式：每一项都可以在早期的文档中追溯到其来源，例如备忘录、法规、会议记录等。每项需求都有唯一的名称或索引号，与后期实现对应。