第4章需求定义阶段 需求是驱动整个软件开发的因素。如果无法准确了解需求，显然是无法开发 出让用户满意的软件产品来的。需求定义是所有软件项目取得成功的前提，它的 好坏直接关系着软件的成败，目前，软件项目中百分之四十至百分之六十的问题 都是需求分析阶段留下的隐患。但是，需求的获取存在困难性：需求存在于用户 的脑海中，软件开发者需要通过沟通和交流，理解用户的需求，进而以用户能够 理解的方式把需求记录下来：由于需求都是和领域相关的，而软件开发者并不是 领域专家，因此理解用户的需求存在一定的障碍：有时候，用户实际上对自己的 需求也不是很明确，往往要再看到系统之后才了解自己需要什么，不需要什么： 此外，需求在开发过程中会发生变更。鉴于需求获取的困难性和需求的重要性， 需要采用系统化的方法定义需求。 4.1需求定义阶段的主要内容 IEEE软件工程标准中将需求定义为： (1)用户为了解决问题或达到某些目标所需的条件或权能(Capability)。 (2)系统或部件为了满足合同、标准、规范或其它正式规定文档所规定的要求 而需要具备的条件或权能。 (3)反映上面(1)或(2)所描述的条件或权能的文档化表述。 从另一方面看，软件的需求又可以分为三个层次： 1、业务需求：反映了组织或客户对业务的高层次的目标要求。业务需求通 常来自项目投资者、实际用户的管理者或产品策划部门。开发软件都是为了达成 某种业务目标。业务需求一般在项目立项前就给以了定义。 2、用户需求：描述了用户使用软件产品必须要完成的任务或者满足的条件。 用户需求派生自业务需求，用户希望通过软件来达到业务上的目标或者满足业务 上的要求。 3、功能需求：定义了设计开发人员必须实现的软件的功能，使得用户能够 通过软件来完成他们的任务，从而也满足了用户需求和业务需求。 软件需求获取有不同的渠道和形式，以下是经常采用的形式： 面谈和问卷调查：通过和用户面对面的沟通进行需求获取是最经常采用的方
第 4 章 需求定义阶段 需求是驱动整个软件开发的因素。如果无法准确了解需求，显然是无法开发 出让用户满意的软件产品来的。需求定义是所有软件项目取得成功的前提，它的 好坏直接关系着软件的成败，目前，软件项目中百分之四十至百分之六十的问题 都是需求分析阶段留下的隐患。但是，需求的获取存在困难性：需求存在于用户 的脑海中，软件开发者需要通过沟通和交流，理解用户的需求，进而以用户能够 理解的方式把需求记录下来；由于需求都是和领域相关的，而软件开发者并不是 领域专家，因此理解用户的需求存在一定的障碍；有时候，用户实际上对自己的 需求也不是很明确，往往要再看到系统之后才了解自己需要什么，不需要什么； 此外，需求在开发过程中会发生变更。鉴于需求获取的困难性和需求的重要性， 需要采用系统化的方法定义需求。 4.1 需求定义阶段的主要内容 IEEE 软件工程标准中将需求定义为： （1）用户为了解决问题或达到某些目标所需的条件或权能(Capability)。 （2）系统或部件为了满足合同、标准、规范或其它正式规定文档所规定的要求 而需要具备的条件或权能。 （3）反映上面(1)或(2)所描述的条件或权能的文档化表述。 从另一方面看，软件的需求又可以分为三个层次： 1、业务需求：反映了组织或客户对业务的高层次的目标要求。业务需求通 常来自项目投资者、实际用户的管理者或产品策划部门。开发软件都是为了达成 某种业务目标。业务需求一般在项目立项前就给以了定义。 2、用户需求：描述了用户使用软件产品必须要完成的任务或者满足的条件。 用户需求派生自业务需求，用户希望通过软件来达到业务上的目标或者满足业务 上的要求。 3、功能需求：定义了设计开发人员必须实现的软件的功能，使得用户能够 通过软件来完成他们的任务，从而也满足了用户需求和业务需求。 软件需求获取有不同的渠道和形式，以下是经常采用的形式： 面谈和问卷调查；通过和用户面对面的沟通进行需求获取是最经常采用的方
式，为了达到效果，必须具有一定的谈话技巧，否则可能引起用户的反感或 者效率不高。有时，也会结合问卷调查来获取更加明确的需求。 ●小组讨论：通过将用户和开发团队组织在一起通过会议的形式进行小组讨论 也是需求获取经常采用的方式。小组讨论的组织也要有一定的技巧，避免在 会议中经常出现的效率低下，少数人占有了发言权的问题。 ●情景串联：将若干界面通过讲解串联起来，以描述针对特定的功能用户如何 与各个界面进行交互，使得用户可以有直接的感受，从而可以提供直接的意 见和建议。 观察业务流程：对实际的业务流程进行观察，从中了解业务中需要解决的问 题，确定将来利用计算机和软件可以如何重新组织业务流程，以及软件如何 适应用户的实际工作习惯。 ●现有产品和竞争产品的描述文档：如果一个产品的目标是取代现有产品或者 竞争产品，那么现有产品和竞争产品的功能和性能就是目前待开发软件所要 比照的，并且通常待开发产品应该具有比现有产品和竞争产品更好的功能呢 和性能。 ●市场资料：通过各种渠道获取市场上对产品的期望。 需求定义阶段的任务就是获取正确的需求，并通过规范的方式进行需求的表 达。这个阶段的结果将主要体现在“软件需求规格说明”文档中。 有时也会把软件需求描述中的一些内容列成单独的文档，如： ● 补充规格说明：用以描述非功能需求、对软件产品的约束等。 ● 词汇表：用以对需求中涉及到的关键术语进行明确定义。词汇表可以作为需 求分析时识别类的依据之一。 4.2功能需求的表达 4.2.1基于用例的功能需求获取 需求是一个普遍使用的词汇，但是又是一个颇为复杂的概念。需求具有不同 的抽象层次。有些需求非常宏观笼统，例如对教室预订系统的一个需求是“系统 使用要很方便”，有些需求则非常细节具体，例如教室预订的时候先要进行登录。 显然，这种对需求的不同理解不利于需求的获取。 用例(Use Case)提供了以一致的方式来获取和表达功能需求的手段。不同
式，为了达到效果，必须具有一定的谈话技巧，否则可能引起用户的反感或 者效率不高。有时，也会结合问卷调查来获取更加明确的需求。 小组讨论；通过将用户和开发团队组织在一起通过会议的形式进行小组讨论 也是需求获取经常采用的方式。小组讨论的组织也要有一定的技巧，避免在 会议中经常出现的效率低下，少数人占有了发言权的问题。 情景串联；将若干界面通过讲解串联起来，以描述针对特定的功能用户如何 与各个界面进行交互，使得用户可以有直接的感受，从而可以提供直接的意 见和建议。 观察业务流程；对实际的业务流程进行观察，从中了解业务中需要解决的问 题，确定将来利用计算机和软件可以如何重新组织业务流程，以及软件如何 适应用户的实际工作习惯。 现有产品和竞争产品的描述文档；如果一个产品的目标是取代现有产品或者 竞争产品，那么现有产品和竞争产品的功能和性能就是目前待开发软件所要 比照的，并且通常待开发产品应该具有比现有产品和竞争产品更好的功能呢 和性能。 市场资料：通过各种渠道获取市场上对产品的期望。 需求定义阶段的任务就是获取正确的需求，并通过规范的方式进行需求的表 达。这个阶段的结果将主要体现在“软件需求规格说明”文档中。 有时也会把软件需求描述中的一些内容列成单独的文档，如： 补充规格说明：用以描述非功能需求、对软件产品的约束等。 词汇表：用以对需求中涉及到的关键术语进行明确定义。词汇表可以作为需 求分析时识别类的依据之一。 4.2 功能需求的表达 4.2.1 基于用例的功能需求获取 需求是一个普遍使用的词汇，但是又是一个颇为复杂的概念。需求具有不同 的抽象层次。有些需求非常宏观笼统，例如对教室预订系统的一个需求是“系统 使用要很方便”，有些需求则非常细节具体，例如教室预订的时候先要进行登录。 显然，这种对需求的不同理解不利于需求的获取。 用例（Use Case）提供了以一致的方式来获取和表达功能需求的手段。不同
于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者(Actor)与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1)参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在UML中，参与者的符号如下图4.1所示。 Actor 图4.1参与者的UML符号 2)场景(Scenario)：某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。 ●场景名称：教室预订 参与者实例：教室申请人员小王，教室管理员小张 ●事件流： 1.小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2.小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功
于一般的直接以文字来进行需求表达的方式，用例是从用户的角度，把整个系统 看做黑盒子，通过描述在完成功能过程中用户与系统的交互来刻画需求的手段。 用例是一系列动作和事件的列表，它定义了单个外部参与者（Actor）与系 统之间的交互，通过这种交互，系统提供了可见的价值。 为了理解用例，我们需要区别以下概念： 1）参与者：是位于系统外部、与系统具有交互的事物，可以是人，计算机系统 或组织，例如教室管理员。需要注意的是参与者不是某一个具体的人、系统或组 织，而是一类人、系统或者组织。在 UML 中，参与者的符号如下图 4.1 所示。 图 4.1 参与者的 UML 符号 2）场景（Scenario）: 某一特定的参与者和系统之间的一次交互，也称为用例实 例。场景是使用系统的一个特定情节或用例的一条执行路径。在获取需求时，我 们通过列举若干重要的场景来发现用例。通俗地理解，场景就是讲一个有主人公 参加的一段故事，这个故事我们会分为若干步骤来描述。例如我们可以针对教室 预订系统，讲述一个小王如何在网上预订教室的一个故事。 场景名称：教室预订 参与者实例：教室申请人员小王，教室管理员小张 事件流： 1. 小王根据活动需要打算使用教室预订系统预订一间教室。他在已接入互联网 的终端上激活了教室预订系统中的教室预订功能。 2. 小王填写一份包含申请人信息、使用时间、使用目的、活动人数、希望安排 的教室规格和位置的表单并提交。然后小王等待系统的教室预订答复信息。 3. 教室管理员小张受到系统提醒后，收到了小王的申请表。小张根据目前的教 室预订情况以及小王的申请信息安排相应的教室并确认。 4. 小王通过预留在系统中的电子邮件收到了来自教室预订系统的确认信息，教 室预订成功
3)用例：对相关的各种场景（包括成功的、失败的场景）的概括，用来描述参 与者如何使用系统实现其目标。场景是有具体的主人公参加的故事，用例则要把 这些故事上升为一个一般性的过程，在这个过程中主人公被角色所替代，描述中 的一些具体细节被通用的信息所替代。在UML中，用例的符号如下图4.2所示。 Use Case 图4.2用例的UML符号 4.2.2用例的编写方法 用例建模并非是画一个用例的UML符号，而是通过文字对用例进行表述。 用例的编写可以有不同的详略程度：在早期，可以是简略的写一段话，也可以用 几段话描述，而在详细描述的情形下，需要按照规定的格式，用几页纸来加以定 义。 用例的编写格式如下： 1.用例名字 在给用例起名字时，一般采用一个动宾词组，如果你发现很难用一个动宾词 组来刻画，那么很可能是用例选择的不恰当造成的。 2.范围 说明该用例是系统用例还是业务用例。系统用例是软件系统本身的用例。业 务用例是业务功能的描述，通常用于对业务分析。 3.级别 说明该用例是用户目标级别还是子功能级别。用户目标级别代表了一个参与 者会发起的完整用例。子功能级别代表了可能在几个用例中可以重用的子功能用 例，进一步的说明参考4.2.3。 4.主要参与者 定义这个用例中的参与者。用例必须有一个发起者(Initiating Actor),同时 可能有若干个参与这个用例的参与者(Supporting Actor)。注意参与者并不一定 是人。 5.涉众及其关注点 定义在此用例中各个人员关注的因素。 6.前置条件 定义该用例发生的前提条件
3）用例: 对相关的各种场景（包括成功的、失败的场景）的概括，用来描述参 与者如何使用系统实现其目标。场景是有具体的主人公参加的故事，用例则要把 这些故事上升为一个一般性的过程，在这个过程中主人公被角色所替代，描述中 的一些具体细节被通用的信息所替代。在 UML 中，用例的符号如下图 4.2 所示。 图 4.2 用例的 UML 符号 4.2.2 用例的编写方法 用例建模并非是画一个用例的 UML 符号，而是通过文字对用例进行表述。 用例的编写可以有不同的详略程度：在早期，可以是简略的写一段话，也可以用 几段话描述，而在详细描述的情形下，需要按照规定的格式，用几页纸来加以定 义。 用例的编写格式如下： 1. 用例名字 在给用例起名字时，一般采用一个动宾词组，如果你发现很难用一个动宾词 组来刻画，那么很可能是用例选择的不恰当造成的。 2. 范围 说明该用例是系统用例还是业务用例。系统用例是软件系统本身的用例。业 务用例是业务功能的描述，通常用于对业务分析。 3. 级别 说明该用例是用户目标级别还是子功能级别。用户目标级别代表了一个参与 者会发起的完整用例。子功能级别代表了可能在几个用例中可以重用的子功能用 例，进一步的说明参考 4.2.3。 4. 主要参与者 定义这个用例中的参与者。用例必须有一个发起者（Initiating Actor），同时 可能有若干个参与这个用例的参与者（Supporting Actor）。注意参与者并不一定 是人。 5. 涉众及其关注点 定义在此用例中各个人员关注的因素。 6. 前置条件 定义该用例发生的前提条件
7.后置条件 定义该用例完成后，系统中发生的改变以及对参与者的影响。 8.主流程 以事件流的方式定义参与者与系统进行的交互过程。在描述时必须能够清晰 刻画每一个事件的参与者以及产生的结果。主流程指的是正常的、一般的情形。 那些意外的情形将放在扩展中。 9.扩展流程 以事件流的方式描述各种意外或者特别的情形。必须说明是从主成功场景的 第几步跳到扩展中描述的事件流片段进行执行，然后再返回主流程。 10.特殊需求 描述与该用例相关的非功能需求，质量属性或约束。 11.发生频率 描述该用例发生的频繁程度。 以下为教室预订系统的一个用例的例子。 ● 用例名称：ApplyforClassroom ● 范围：系统用例 级别：用户目标 ●主要参与者：教室申请人员，教室管理员 ●涉众及其关注点： ”教室申请人员：希望能够方便、快捷地提出申请，并及时得到系统关于 是否同意使用申请的响应。 >教室管理员：教室使用审批符合无冲突原则。 前置条件：教师或学生具有合法的身份。 ●后置条件：更新教室使用记录，发送教室使用提示信息；或提示用户申请不 批准。 ● 主流程：
7. 后置条件 定义该用例完成后，系统中发生的改变以及对参与者的影响。 8. 主流程 以事件流的方式定义参与者与系统进行的交互过程。在描述时必须能够清晰 刻画每一个事件的参与者以及产生的结果。主流程指的是正常的、一般的情形。 那些意外的情形将放在扩展中。 9. 扩展流程 以事件流的方式描述各种意外或者特别的情形。必须说明是从主成功场景的 第几步跳到扩展中描述的事件流片段进行执行，然后再返回主流程。 10. 特殊需求 描述与该用例相关的非功能需求，质量属性或约束。 11. 发生频率 描述该用例发生的频繁程度。 以下为教室预订系统的一个用例的例子。 用例名称：ApplyforClassroom 范围：系统用例 级别：用户目标 主要参与者：教室申请人员，教室管理员 涉众及其关注点: 教室申请人员：希望能够方便、快捷地提出申请，并及时得到系统关于 是否同意使用申请的响应。 教室管理员：教室使用审批符合无冲突原则。 前置条件：教师或学生具有合法的身份。 后置条件：更新教室使用记录，发送教室使用提示信息；或提示用户申请不 批准。 主流程：