一步一步做项目（1）软件需求

从一幅幽默画看到的需求问题

软件危机不是危言耸听，在软件开发过程中会发生各种各样的问题，甚至是挺荒唐的事，所以才有了下面这张经典的幽默画，以讽刺软件工程的低水平开发和管理，如下图所示。

图中表明了软件组织中各种角色对软件要实现的功能特性有不同的理解，经过各个环节，误差不断放大，最终产生令人啼笑皆非的结果。

• 客户没有把自己的需求描述清楚，一开始就有问题。
• 项目经理没有认真倾听客户的需求，客户的需求打了折扣。
• 分析人员进一步误解了客户的需求，设计的内容可能到了不可理喻的地步。
• 程序员写的代码也是漏洞百出，使原来就很糟糕的功能设计雪上加霜。
• 业务咨询师却将软件功能吹嘘得天花乱坠。
• 项目过程中忽视文档，几乎是一片空白。
• 软件在安装之后，某些功能不能正常工作，几乎不可用。
• 还是照样按照高科技产品收取客户的费用。
• 技术支持人员可能将问题弄得更糟糕……

软件需求的重要性

在软件开发中，很常见的问题是许多客户不知道他们需要什么，进一步来讲，即便客户真正了解他们需要什么，也有可能很难精确地把这些想法传达给开发者，因为大多数客户的计算机知识不如开发团队的成员。对开发人员来说，对软件产品及其功能进行形象化描述已经很难了，对并不精通软件工程的客户来说则更加困难。
另外，客户可能并不了解自己的企业正在做什么。例如，如果现有软件系统响应时间过长的真正原因是数据库设计得太差，那么客户要求开发一个运行速度更快的软件是毫无用处的，重新开发一个软件产品，运行效果还是会和原来一样慢，真正需要做的是在目前的软件产品中重新组织和改善数据的存储方式。又如，如果客户经营的是亏损的零售连锁店，那么客户可能会要求一个财务管理信息系统来反映诸如销售量、工资、应付账目和应收账目之类的项目，但是，如果亏损的真正原因是商品的损耗（或盗窃和雇员监守自盗），信息系统就几乎毫无用武之处，而且，如果真是这样的情况，需要的其实是一个库存控制系统而不是一个财务管理信息系统。
因此，没有专业的软件开发团队的协助，客户很难了解到需要开发些什么。另一方面，除非能与客户面对面交流，否则专业的软件开发团队也无法找出客户究竟需要什么。

如何获取用户需求

获取用户需求包括多种技术，下面会具体介绍。根据调查系统需求需要获取的信息不同，可能需要几个小时、几天甚至几周的时间。例如，报表格式或者数据输入界面的变化可能需要用户的电话号码或Email信息，因此新的库存系统需要包括一系列的面谈。在获取需求的过程中，需要分析组织结构图，进行面谈，审查当前文档，观察操作以及进行用户调查等。

分析组织结构图

在许多实例中，需要知道待研究部门的组织结构，这时，应该查看公司的组织结构图，以理解部门如何运作并确定进行面谈的人选。组织结构图可以从公司的人力资源部门获取，如果没有现成的图，应该直接从人力部门获取必要的信息并自己构建组织结构图。
有了组织结构图，应该检查其正确性。需要注意的是组织结构图反映的是正式的负责关系而不是组织的非正式结盟，这一点很重要。

进行面谈

需求阶段，获取信息的主要方法是面谈，如下图所示。

面谈的过程包括一系列步骤。

• 确定面谈人选；
• 确定面谈目标；
• 确定面谈要讨论的问题；
• 准备面谈；
• 进行面谈；
• 将面谈结果整理成文档；
• 对面谈进行评价。

面谈的目的是发现事实，这7步描述了事实发现技术，而不是劝说别人相信项目是合理的。系统分析员的态度应是提出有效的问题并仔细听取别人的意见。如果打算和几个人讨论同一个话题，应该为每一次面谈准备一个问题的标准集合。此外，一定要包括一些开放性的问题，例如，“你觉得我还应该了解系统的哪些方面？”或者“还有什么其他相关信息我们没有讨论吗？”。
进行面谈时，应该和一些对系统了解比较全面的管理人员进行广泛的交流，从而可以对业务过程有一个概括性的了解。根据当时的情形，还可以和操作人员进行交流以便了解系统日常的运作。

文档复查

尽管面谈是获取信息的很重要的方法，还是应该对当前的系统文档进行审查，文档可能不是最新的，因此应该通过和用户一起复查来确定所得到的资料是准确和完整的信息。

观察操作

另一个事实发现的方法是观察当前系统的操作。可以观看工人如何实施一些常规的任务。选择跟踪一些实际的流程，例如，输入源文档或者输出报表等，当然，除了对操作进行观察，还要抽样系统的输入或输出。

实施跟班作业

跟班作业是一种有效地获取信息的方法，但跟班作业花费时间长，因此经常用于对项目的关键问题进行分析。通过现场跟班作业，共同作息，分析员更容易发现问题，加深对项目的理解，并提出合理的解决方案。

进行用户调查

由于面谈很耗时，所以有时可能希望通过从一个更大的群体中进行用户调查获取信息。在这种情况下，可以设计一种表格，由用户填写完，收回之后，就可以进行统计分析了。调查并不像面谈那样灵活，但成本低，而且通常花费的时间少，并可以进行大范围的调查，获取广泛的代表性意见。

网络资源

在网络飞速发展的今天，请不要忽视网络上能够获取的资源，这通常是你对你要完成的项目进行初步理解的第一手资料。

软件需求技术

软件需求技术主要有数据流图、用例技术、用户故事等，这里主要介绍用例技术。

用例技术

构建用例图需要：确定参与者、确定用例、确定参与者和用例之间的关系。

确定参与者

当存在业务模型时，确定参与者很简单。系统分析员可以为业务中的每个工作人员建议一个参与者，也可以为每个使用信息系统的业务参与者（即每个业务的客户）建议一个参与者。否则，不管有没有领域模型，系统分析员都要与客户一起来确定用户，并设法将他们组织成不同类别的参与者。在这两种情况下，需要将表示外部系统的参与者与用于系统维护和操作的参与者确定下来。
在挑选候选参与者时有两个标准。首先，至少确定一个用户来扮演候选参与者，这有助于获得相关的参与者而避免只是想象中的参与者。其次，不同参与者扮演的角色之间的重叠应该最少，不应该两个或多个参与者实际上担当相同的角色。如果出现了这种情况，应设法将这些角色合并，或设法确定一个更一般化的参与者来充当重叠参与者的公共角色，新的参与者可以使用泛化关系进行特化。最初几轮确定的参与者数目多而且有较大的重叠，通常，经过几轮探讨才能最终确定恰当的参与者集合及其泛化关系。系统分析员为参与者命名，并简要描述每个参与者的角色以及参与者使用系统做什么。

确定用例

当起点是业务模型时，可以按照“根据业务模型确定用例”中讨论的方法来确定参与者和用例，为参与业务用例实现和使用信息系统的每个工作人员所充当的角色设计用例。另外，系统分析员通过专题讨论会与客户及用户共同商讨来确定用例。系统分析员逐个检查参与者，为每个参与者设计候选用例。例如，可以通过访谈和故事板来了解需要用例做些什么。参与者通常需要用例支持其工作，可以创建、修改、跟踪、删除或研究业务用例中的业务对象（如“雇员”和“收费代码”）。参与者可能要将某些外部事件或其他类似的方法告知系统，或反之，即参与者可能需要系统告知自己某些已经发生的事件（例如账单）。可能还需要有附加的参与者来执行系统启动、终止或维护等工作。
为每个用例选择一个恰当的名字，由此能想到为参与者增值的具体动作序列。用例的名字通常以动词开始，应该反映参与者和系统之间的交互。在例子中，如“记录工时”和“设置收费代码”等用例。
有时很难确定用例的范围。用户与系统交互可以在一个用例中确定，也可以在参与者引用的几个用例中确定。在决定候选用例是否应该作为一个单独的用例时，必须考虑用例是否完整，或是否总是作为另一个用例的延续。前面介绍过用例可以为参与者带来增值的方法，也就是说，用例会产生一个对具体参与者有价值的结果，这种方法有助于确定用例的适用范围。注意，这里有两个关键，有价值的结果和具体参与者，表示了确定用例的两个原则。

• 有价值的结果。每个可以成功执行的用例都应该对其参与者提供某些价值，使参与者实现预定目标。有时候，参与者愿意为获得价值而付出代价，一个用例实例（如打电话）可能涉及多个参与者。此时，“有价值的结果”应该针对最初的参与者，也避免确定太小的用例。
• 具体的参与者。向真正的用户提供有价值的用例，可以使用例不会变得太大。

描述用例模型

可以用图和文字从整体上解释用例模型，尤其是说明用例如何彼此相关以及用例如何与参与者相关。对图中应该包括哪些内容没有严格的规定，因此，选择能明确说明系统的图。例如，可以画图来表示参与业务的若干用例，或表明参与者所执行的若干用例。
每个参与者都参与一个或多个用例，每个用例都由一个或多个参与者触发，创建高层用例图就需要描述用例和参与者之间的这种关系，从参与者指向用例的箭头表明参与者参与的用例。

用例技术案例

项目背景

本案例以普通高校艺术类招生考试业务为背景，提供普通高校艺术类招生考试考生志愿填报、考生信息、院校校考申请、考点考试安排、管理部门监控等综合业务集成管理，院校通过网络申请考试，管理部门审核通过后考点进行考试日程安排，之后，考生可以进行志愿填报并通过网络进行缴费，考点下载考生志愿信息，进行考场分配，在考场分配后考生可以打印准考证，同时，院校可以下载报考该院校的考生志愿，考试完成阅卷后，院校上传考生成绩，考生可以查询个人考试成绩，考生、院校、考点、管理部门构成整个系统的业务过程，可以完成相关信息的录入、修改、查询、打印和删除等，能够导入、导出数据，便于通过Excel等工具做进一步的处理。
和用户的沟通只是接收到这些基本信息，而且，远没有上面描述的那么流畅，流程也不像上面描述的那么清晰，只是了解了要完成一个什么样的系统，得到的信息非常简陋，甚至连考生的基本信息也不清楚（暂时的，这在后面的迭代中逐步完善），在这样的背景下进行迭代式软件开发。

确定参与者

游客、考生、院校、考点、管理部门

确定用例

初始的用例（第一次迭代）
管理培训学校、管理用户、管理用户日志、管理考生联系方式、管理通知公告、管理考点信息、管理院校信息、管理考试申请、管理招生简章、管理招生、管理考场信息、管理考生信息、管理专业信息、管理志愿信息、安排考场、管理前台信息发布…

描述用例模型

建立用例图（第一次迭代）

详细用例描述

正式的软件项目开发，还应该有详细的用例描述（通常使用用例描述模板），尤其是大型软件项目，更是必不可少，作为小型的软件开发项目，通常在了解了用户的基本需求后就开始边开发边完善了，先开发出原型，再逐步完善，一次一次迭代，直到最终完成项目。
用例描述模板一般如下所示：
用例名称 动词短语，描述用例目的的简短动词短语。
描述 简要的段落，介绍用例目的，强调用例为参与者提供的价值。如果无法在一个简短的段落中描述，那么用例可能不够集中。
前置条件 简短的段落，描述在哪些用例成功执行之后，才会触发该用例，描述其中的依赖关系。
部署约束 简短的段落，描述如何使用系统来完成用例。例如，某个特定的用例是由“雇员”参与者触发的，而该参与者是位于保护雇员客户端的防火墙之后。那么，忽略这类约束就会导致严重的后果，因此必须尽快获得这些信息。
正常事件流 交互动作的有序序列，描述所有的系统输入以及系统响应，组成了该用例的正常流程。正常事件流表明事件按计划进行时的交互动作，揭示了用例的目的。
可选事件流 交互动作的有序序列，描述组成该用例的一个可选流程的所有系统输入及其响应。可选事件流显示系统是如何对用户的误操作做出响应，例如，输入一个无效的数据或按不正常的顺序来执行一个流程。需要编写每个可选事件流。
异常或错误事件流 交互动作的有序序列，描述组成该用例的一个异常流程的所有系统输入及其响应。异常流程捕捉系统对错误的响应，例如，无法获取系统内部的或外部的资源。需要编写每个异常事件流。
活动图 在图中显示事件流的所有流程，能够完整地描述事件流，为度量用例的复杂度提供方法。
非功能性需求 用一两个简短的段落来介绍用例成功执行的判断准则，该准则不适合在事件流中描述。例如，系统对用例的响应可能必须限制在3秒钟以内；或者，在遍历某个用例的事件流时，鼠标点击次数的上限是7次。
说明（可选） 确定不符合上面类别的其他事务，其中可能包括对系统功能的限制。
未解决的问题（可选） 需要进一步询问相关人员的问题列表。
这里，详细的用例描述就不再赘述。

示例文档请下载普通高校艺术类招考综合管理系统需求规格说明书.pdf