软件需求管理

需求管理

一、需求

1.概念

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

2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

2.需求的类型

1) 业务需求（Business Requirement）：表示组织或客户高层次的目标。业务需求描述了组织希望达到的目标。

2) 用户需求（User Requirement）：描述用户的目标。或用户要求系统必须完成的任务。场景描述和事件响应表都是表达用户需求的有效途径。

3) 系统需求（System Requirement）：描述包含多个子系统的产品的顶级需求。

4) 功能需求（Functional Requirement）：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

需求类型

需求工程

3.需求的三个层次

1) 显式需求

    符合需求规格：符合开发者明确定义的目标，即产品是否是在做规定的动作。需求必须是可度量的，这样才会有质量的概念。

                                这个就是内部质量，即从软件（产品）启动到交付用户之间所产生的所有中间产品的质量。

2) 隐式需求

    符合用户的显式需求：符合用户明确说明的目标。即用户认为的质量是产品是否按照用户的需要运行。

                                            此即是验收质量，用户在验收软件时评价产品的质量。

3) 用户的实际需求

    符合用户实际需求：实际的需求包含用户明确说明的和隐含的需求。而隐含的需求往往容易被忽略。

                                        这就是使用质量。即用户在实际使用过程中对产品的质量评价。

二、需求开发

1.需求开发是由需求分析人员与用户接触、交流，并对市场需求进行分析的一系列活动。

需求开发包括四个阶段的活动：

1) 需求获取：通过与用户的交流，对现有系统的观察及对任务的分析，从而开发、捕获和修订用户的需求；

2) 需求分析：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3) 需求定义：生成需求模型构件的精确的形式化描述，作为用户和开发者之间的一个协议；

4) 需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。

三、需求管理

1.概念：一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

需求工程包括获取、分析、规定、验证和管理软件需求的所有活动，而“软件需求管理”则强调对所产生需求的管理和控制。

需求的生命周期

2、需求跟踪

        需求跟踪使你跟踪一个需求在软件生命周期的全过程（从用户需求到需求规格到下游工作产品）。表示需求和别的系统元素之间

的联系的最普遍的方式是使用需求跟踪矩阵（RTM）。

        需求的三个层次：

                a.显式需求==>内部质量

                b.隐式需求==>内部质量

                c.用户的实际需求（显式需求+隐式需求）==>外部质量（或称：使用质量。用户在实际使用过程中对产品的质量评价）

        RTM：

                需求项==>功能需求子项==>对应的实现代码==>对应的测试用例

通过需求跟踪矩阵，我们可以做到（根据需求评审通过这个里程碑来分割）：

1.已经通过了需求评审，并形成需求规格文档的：

1)需求项是否被正确的实现（代码），代码是否被正确的测试；

2)需求项是否被不正确的实现了，即画蛇添足的情况（包括后面的针对无效代码的测试）；

3)需求项是否被遗漏了（包括后面缺失的开发测试过程。）

2.待评审的需求文档还原用户（客户）需求的准确程度。

        有时候会遇到这种问题，测试员是依照需求规格书（已评审、已签字确认的）来进行测试的，但是测试终结后，提交给客户，

客户做验收测试的时候，就是不给通过。这种情况，有可能就是已经评审过的需求规格文档与客户原始需求之间存在差异，而又没有

及时发现造成的。

        所以，熟悉产品或项目涉及的相关业务，能够做好需求评审、需求跟踪，才算是一个合格的测试人员（假设团队只是安排你做

测试执行，没有分配给你前端的工作，比如需求评审、测试设计怎么办？那你就应该主动的去学习、了解这部分，这对你一定是非常

有益的）。

注：