谈谈需求分析规范化

最新推荐文章于 2023-05-30 14:36:09 发布

肖永威

最新推荐文章于 2023-05-30 14:36:09 发布

阅读量7.8k

点赞数 5

分类专栏：项目管理文章标签：需求软件工程

本文链接：https://blog.csdn.net/xiaoyw71/article/details/53259106

版权

项目管理专栏收录该内容

36 篇文章 25 订阅

订阅专栏

　　福特汽车创始人 - 亨利福特的一句名言常常被人们作为反面案例引用：“如果听用户的，我们根本造不出汽车来，用户就是需要一匹快马。”

　　需求是一个项目的源头，也是项目成功的关键所在。而需求本身，是一个复杂的过程，不仅需要业务领域知识，还需要掌握一些基本的技术和方法（建模技术、分析方法）。
　　
　　通过需求工程化来降低需求工程的复杂度，让需求分析人员有章可循，与用户形成共同语义环境，也就是需求分析的规范化。

　　本文重点谈谈需求分析的规范化。

　　对于商业化软件开发，是在满足一定用户需求的前提下，以盈利为目的做软件项目实施的，只有盈利，才能更好的服务，形成一个闭环。

　　在商业化软件开发过程，需求范围管理是项目管理中重要一环，也就是软件项目的利润＝需求－设计 [1]，在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。

1. 关于需求及需求分析

1.1. 需求及需求分类

　　需求是技术无关的。技术的实现细节通常是在后面设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了解业务的全貌，深入细节会浪费时间和精力。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。

　　在这里，首先说明用户需求、功能需求、业务需求、系统需求、产品需求的定义与差别：

　　用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。用户需求针对的是人，描述的是用户想做某件事情所遇到的问题，或所想满足的欲望；

　　功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。功能需求针对的是产品，描述是是产品如何解决用户所遇到的问题，或如何满足用户的欲望，是方式、方法；

　　业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

　　业务需求针对是公司，描述是公司想如何解决用户的问题，如何满足用户的欲望，并将利益最大化。重点是在后面，追求商业可行性与利益最大化。

　　系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

　　产品需求是提炼分析用户真实需求，并符合产品定位的解决方案。

1.2. 关于需求调研

　　需求调研工作中，需求分析人员引导用户挖掘真实的需求是至关重要的，应按如下图所示对应关系，分层综合的调研需求。
　　这里写图片描述
　　产品经理不能只听“二手需求”，那些是别人总结过的，已经没了“地气”，真正需要听的是用户讲真实的故事，故事里，有记叙文的六要素——时间、人物、地点、事情的起因、经过结果。有了这些信息，你才能感同身受。最终用我们产品的人，不是一个个“用户群体”，而是一个个活生生的个体。

1.3. 用户故事与用例

1.3.1. 用户故事

　　用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
　　1. 角色：谁要使用这个功能。
　　2. 活动：需要完成什么样的功能。
　　3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
　　一个好的用户故事应该遵循INVEST原则。

　　独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
　　
　　有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
　　
　　短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
　　
　　可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个可测试的用户故事例子：软件应该是易于使用的。

1.3.2. 用例

　　用例最早由Ivar Jacobson在1992年提出，用例通常与统一软件过程相联系。用例描述系统和角色之间的交互。

　　从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：
　　
　　参与者(Actor)
　　
　　参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
　　
　　用例(Use Case)
　　
　　用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
　　
　　通讯关联(Communication Association)
　　
　　通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

　　这里写图片描述

1.3.3. 用户故事与用例的区别

　　用户故事与用例的区别[2]，主要在于：
　　
　　（1）范围不同。二者都用来体现商业价值，但故事规模可以设定比较小（例如，10天完成），以便以此为单位安排工作。用例包含的范围可能比故事大得多。
　　
　　（2）完成程度不同。James Grenning曾指出：故事卡中的文字“加上验收测试用例就基本等同于用例”，这意味着故事对应于用例的基本流，而故事的测试要求对应于用例的备选流。
　　
　　（3）寿命不同。用例通常是持久的工作产品，在产品开发和维护时，用例一直存在。然而，故事通常只存在于实现该故事的迭代中。虽然故事卡可以存档，但是许多团队都将故事卡销毁。
　　
　　（4）编写目的不同。用例的目的是记录客户和开发团队的一致意见。故事是为了便于制定发布计划和迭代计划，并作为有关用户需求细节方面的交谈备忘录。

　　用户故事是在讲述用例中某个或某几个场景。

1.4. 基于SOA的需求分析[3]

　　基于SOA的需求分析可以归纳为以业务和流程建模为驱动，以用例分析为核心，以服务建模为最终目标的三个层面的内容。

1.4.1. 流程分析和业务建模

　　对于传统的面向结构和面向对象的分析方法，都少了流程分析和业务建模这个关键步骤，后续UML发展增加了业务建模部分的内容。SOA一个重要概念就是流程驱动IT，如果不从最起始的流程和业务建模入手，将会使我们只见局部而无法看到全貌；只知道有这个功能或服务，而不知道功能或服务产生的业务场景。

　　对于流程分析，体现由高端到低端逐层分解的过程，高端流程主要还是价值链流程分析，由价值链分析结合业务主题域的情况分解到1级和2级的业务架构视图。在 SOA的业务建模里面有个重要概念就是业务组件，业务组件可以是业务域按执行，控制，引导三个层面的进一步分解。每个业务组件本身就是由相互关联的业务活动组成，实现独立的业务价值，业务组件本身是粗粒度的。业务组件之间的交互必须要通过服务进行。对于业务组件，可以从五个方面进一步进行描述，如下：

　　业务用途 – 业务组件在组织内存在目的，表明其提供了业务价值
　　业务活动 – 为实现业务用途，每个业务组件需要实现一系列相互独立的活动
　　资源 – 需要什么样的人员或资产来支持这些活动
　　治理方式 – 每个组件是自治的，以相互独立的方式进行管理业务服务 – 提供或接收业务服务，外界交互的唯一渠道

　　业务组件本身高内聚，松耦合，完成一个长流程需要业务组件间相互协作完成。对于业务组件的识别可以由顶向下或由底向下两个方面进行分析和识别，由底向上可以是根据业务域列出所有核心的业务功能，根据传统的UC矩阵分析方法，按照高内聚松耦合的原则来归类和抽象相应的业务组件；或者是由顶向下，进行高端业务和流程分解，充分考虑业务职能划分和流程阶段分解因素，端到端流程分解中的核心活动就是关键的业务组件。

　　业务架构图矩阵分两个维度，一个是业务能力，一个是责任级别。业务能力可以根据高端业务价值链分解来确定，责任级别包括战略规划，控制和执行三个层面。业务组件图本身是动态活动的静态构图。在业务组件图出来后，针对单个的业务组件，可以进一步做流程分解和流程分析，这个分析通常有两个方面，一个是跨职能带的流程图分析，一个是EPC流程图分析，在分解到较为底层的流程图的时候，我们都推荐EPC事件驱动的流程链分析方法，这个方法和现在BPM工具的流程建模方法基本类似，很容易直接过渡到BPM流程建模。

1.4.2. 从业务流程到业务用例分析

　　在原来谈基于SERU的软件需求最佳实践的时候，我们就经常谈到了业务流程分析到用例的转化，对于流程分解和流程分析，到了底层后出来的就是活动，这个活动需要识别和转化为用例。业务用例是可以独立实现一个业务价值的业务过程，可以看做是业务组件本身进一步的细化分解。在SERU分析方法里面，强调了如下几点：

　　主题域分解 – 类似业务建模中的业务组件分析流程分析 – 识别业务用例的关键步骤
领域建模 – 建立领域模型，识别关键的业务对象

　　业务用例是否是服务？很多时候业务用例本身就已经是流程服务或业务组合服务，因为它是一个实现了业务价值的业务过程。在SOA里面强调了业务操作和业务数据的分离，在传统的使用ROSE工具进行用例建模的过程中也可以看到用例分析和建模从前面的流程分析到后面的两个关键模型组件即是用例模型和业务对象模型。
　　
　　模型部分：用例模型，业务对象模型，序列图活动图
　　
　　文档部分：业务场景，基本流，扩展流，业务规则，数据描述，界面原型

1.4.3. 从业务用例到服务识别和设计

　　在用例到服务转化的时候，可以看到一个用例实现可能还涉及到多个原子服务的识别和设计，这些原子类服务业务人员不关心，但是却能够较好的应用于服务的组合和流程的编排。用例到服务的转化一个重点是通过序列图来分析用例实现的过程，在这个过程中我们抛弃点泳道前面用户到界面层的交互，而重点关注逻辑层的所有交互点，这些逻辑层的交互点很可能都是重要的原子类服务。

　　在没有基于SOA前，可以看到业务和系统组件是强绑定的，业务变动会带来大量的技术层面的修改。而实施SOA后，在业务和IT之间会增加一个服务层，服务层实现了业务和IT的解耦。业务组件之间交互抽象和暴露为服务，服务用于业务实现时候的组合和编排，以增加组件对业务变化应对的灵活性。

　　这里有一个过程，即通过业务用例的实现分析，可以识别出大部分的原子类服务，然后对服务进行进一步的归类，合并和整理。这些原子类服务里面有些是需要跨组件或跨系统协作的，而有些仅仅是用于内部协作。服务本身的可重用性和管理成本又涉及到我们如何来控制服务的粒度，对于仅仅用于内部协作的建议仍然需要保留相应的服务接口，方便后续在有需求的时候很方面的转化为服务。

2. 需求分析规范化的内容

　　通过上述需求分析工作内容的介绍与分析，本文推荐使用UML的用例图、用例描述做为需求规范化的核心内容，相关文档模版介绍如下。
　　
　　（1）需求说明书模版
　　
　　用户需求说明书
　　软件需求说明书
　　
　　（2）用例模版

2.1. 需求说明书模版

2.1.1. 用户需求说明书模版

　　需求说明书模版，章节要求：
　　
　　这里写图片描述

　　文档模版目录中需要特殊说明的如下：

　　术语、缩略语，就是列出需求中用到的专业术语，以及专业词汇的缩写、简略用语。在编写需求文档过程中，容易出现忽略术语、缩略语现象，造成部分读者阅读文档困难，沟通也出现障碍。为此，需要尽量写全这部分内容。
　　
　　组织结构，应用系统是给人使用的，有人就涉及到组织，所有，在编写需求分析时，需要详细调研、分析组织机构及其角色。
　　
　　非业务需求，可靠性需求、性能需求、可用性需求、安全性需求、环境需求、接口需求等。
　　

2.1.2. 软件需求说明书模版

　　这里写图片描述

2.2. 用例模版（建立用例模型）

　　使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容[6] ：
　　
　　（1）用例图(Use Case Diagram)
　　
　　确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。
　　
　　（2）用例规约(Use Case Specification)
　　
　　针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。
　　
　　在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

2.2.1. 寻找参与者

　　所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：
　　
　　（1）系统开发完成之后，有哪些人会使用这个系统？
　　（2）系统需要从哪些人或其他系统中获得数据？
　　（3）系统会为哪些人或其他系统提供数据？
　　（4）系统会与哪些其他系统相关联？
　　（5）系统是由谁来维护和管理的？

2.2.2. 确定用例

　　找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：
　　
　　参与者为什么要使用该系统？
　　参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
　　参与者是否会将外部的某些事件通知给该系统？
　　系统是否会将内部的某些事件通知该参与者？

　　在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。
　　
　　可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。
　　
　　对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种”最佳”（或”较佳”）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

2.2.3. 描述用例规约

　　应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：
　　
　　（1）简要说明 (Brief Description)
　　简要介绍该用例的作用和目的。
　　（2）事件流 (Flow of Event)
　　包括基本流和备选流，事件流应该表示出所有的场景。
　　（3）用例场景 (Use-Case Scenario)
　　包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
　　（4）特殊需求 (Special Requirement)
　　描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
　　（5）前置条件 (Pre-Condition)
　　执行用例之前系统必须所处的状态。
　　（6）后置条件 (Post-Condition)
　　用例执行完毕后系统可能处于的一组状态。
　　
　　用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。
　　
　　这里写图片描述
　　
　　
　　再举个早期的样例，用例编写格式如下。