业务流程考察

        需求调研需要充分细致的了解客户目标(需求调研必须有针对性)、用户业务内容、流程等，这是一个对需求用户业务内容 流程等采集过程，是进行需求分析的基础准备。 当我们已经了解、理解用户业务，于是可以开始分析需求。

提取出核心、主要、急迫的业务， 明晰业务流程(2-1)

        通过需求调研，我们会发现用户各方面的业务很多，从大处着眼，包括用户：

        各种业务项目、业务流程，再明细到业务过程 的每一个单据，每一条记录，如生产过程中每一个环节的记录， 办公中的每一个通知，甚至包括文件报刊的收发，计划生育指标统计等等。如此繁杂的各类业务，我们从何下手？这时需要 我们回头去查看软件的项目规格说明书，再次温故客户对软件 项目或产品的最初提出的需求目标和范围，我们的软件主要是为用户解决什么样的问题。 从众多的业务中提取出用户核心的、主要的、急需的业务，这些是我们软件需求主要关心所在。写一篇文章需要重点突出， 那些是我们软件需求主要关心所在 写 篇文章需要重点突出主次分明。

提取出核心、主要、急迫的业务， 明晰业务流程(2-2)

        从用户繁杂的业务中进行业务、业务流程的提取， 把那些分布在各个部门的同种业务提取出来。 把那些分布在各个部门的同一种业务提取出来。 比如物资的管理，涉及到生产部门的需用计划，汇 总到物资部门的采购计划，计划的审批，采购合同， 物资采购，物资部门的收发存业务，生产部门的物 资领用消耗等等，我门需要分析用户的这个业务流 程中哪些是系统能帮助管理的，哪些是要在系统外处理的，充分分析了用户现有的业务和业务流程， 我们进入下一步骤。

运用管理思想，优化业务流程

         我们提供的是管理软件产品，要帮助用户解决的是管理问题， 那么用户是这样的业务流程，就需要我们分析这样的流程合理 吗，还有缺陷吗，怎样做能提高效率、解决问题，可以运用更先进的管理思想吗? 一般情况下，我们需要从两个方面考虑业务流程的优化。

        一方面是我们采用了网络计算机这些新的技术手段，较之原先手工、电话等方式在信息的传递、信息的共享、数据的处理等方面将会带来新的方式， 必将改变原有的业务流程。 另一方面就是我们根据对用户业务的理解，考虑是否可以运用先进的管理 思想，比如MRPII、ERP、SCM、CRM、JIT、EIA、E-Business等等管 理模型，进行现有业务流程的重组或优化。当然一旦牵涉到业务流程的修 改一定要与客户的中高层管理者进行充分的沟通，只有客户认同方可确定， 因为这一定会在软件实施时需要相应的管理制度配套执行。

进行业务分类，规划系统蓝图(2-1)

        以上都明确了以后，我们可以描绘系统蓝图了。系统有几个子系统， 每个子系统有哪些模块，各个模块处理哪些业务，很重要的一点还有 各子系统模块之间的数据接口关系，基础数据从哪里进入，通过哪些 各子系统模块之间的数据接口关系 基础数据从哪里进入 通过哪些 处理生成哪些结果等等。这个过程需要整理、抽象用户业务，规划软 件实现，规划软件系统模块间的逻辑关系。因为系统的页面实现是按 照系统模块的规划，所以应尽量采用用户易理解、熟悉的方式、词语 进行模块的描述。

进行业务分类，规划系统蓝图(2-2)

        例如ERP系统中的物资管理子系统，首先明确这个子系统是ERP系 统中进行物资相关的业务处理系统，同时它为主生产系统、成本管理 子系统提供生产物资供应、领用消耗核算等的数据支持。因此在规划 子系统提供生产物资供应 领用消耗核算等的数据支持 因此在规划 子系统模块时，按照业务过程模型，应包含物资需用计划、物资采购 计划、出入库管理、库存管理等主要业务模块，再考虑软件运行必须 的初始数据设置，增加一个基础信息维护模块(包括物资大类、物资 编码等信息维护)，还有考虑到不同用户对此系统的不同需求，如更多的生产人员、管理人员的需求，再单独增加一个综合查询和分析模 块。另外还有与物资采购相关的业务如采购合同，可以放到合同管理 子系统统一考虑，这里只做查询。这样规划出了软件系统对物资管理 业务的处理，检查下是否包含了物资管理中所有核心、主要的业务， 业务的处理 检查一下是否包含了物资管理中所有核心 主要的业务 这时我们发现还有比如物资采购、验收、盘库等业务还是需要物资管 理业务人员来完成，系统可以做到的就是记录结果。软件系统是管理 的辅助系统，不能完全代替人的所有工作。管理软件再加上管理制度、 业务人员的操作才构成一套完整的管理体系。

遗留文档

            收集与当前项目相关的需求方的文档资料， 文档资料主要包含： 文档资料主要包含业务相关的文档：业务报表、规章制度等等 决策相关的文档：会议纪要、会议视频等等 遗留相关软件文档 ……

问卷调查

            问卷调查是以书面提出问题的方式搜集资料的一种研究方法， 即调查者就调查项目编制成表式，分发或邮寄给有关人员，请 示填写答案，然后回收整理、统计和研究。 

            问卷调查的最大优点是方法简便，节约时间（就调查者而言）， 材料也比较容易整理和统计。有时用无记名形式问卷可以获得面谈或开调查会不容易获得的某种有价值的资料。 问卷调查的局限性在于发出的问卷常常无法全部收回，收回的 问卷太少，往往影响所取得材料的代表性。其次，问卷调查应 用范围较广，搜集的资料往往是表面的，不能了解深层次的问 题。再次，问卷中的问题太多，答者生厌、置而不理；问题太 次 问卷中的问 太多 答者 问 太 少，所得的数据不能说明问题，有可能影响整个教育科学研究 结论的科学性。

原型化方法(4-1)

        原型化方法是十分重要的.原型就是软件的一个早期可运行的版本,它实现了目标 的 个早期可运行的版本 它实现了目标系统的某些或全部功能.

原型化方法(4-2)

        原型化方法就是尽可能快地建造一个粗糙的系统,这 系统实现了目标系统的某些或全部功能,但是这个系 统可能在可靠性,界面的友好性或其他方面上存在缺 陷. 建造这样一个系统的目的是为了考察某一方面的可 行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求, 可以用某些软件工具快速的建造 个原型系统,这个 可以用某些软件工具快速的建造一个原型系统,这个 系统只是一个界面,然后听取用户的意见,改进这个 原型.以后的目标系统就在原型系统的基础上开发.

原型化方法(4-3)

原型主要有三种类型:探索型,实验型,进化型.

            探索型:目的是要弄清楚对目标系统的要求,确定 探索型 目的是要弄清楚对目标系统的要求 确定 所希望的特性,并探讨多种方案的可行性. 

            实验型:用于大规模开发和实现前,考核方案是否 合适,规格说明是否可靠. 

            进化型:目的不在于改进规格说明,而是将系统建 造得易于变化,在改进原型的过程中,逐步将原型 进化成最终系统。 进化成最终系统

原型化方法(4-4)

在使用原型化方法是有两种不同的策略:废弃策略,追加策略.

废弃策略:先建造一个功能简单而且质量要求不高 的模型系统，针对这个系统反复进行修改,形成比 较好的思想,据此设计出较完整,准确,一致,可靠的 最终系统. 系统构造完成后,原来的模型系统就被废弃不用. 探索型和实验型属于这种策略。 探索型和实验型属于这种策略

领域专题讨论会议

        研究提出本领域的战略目标和发展重点； 研究提出本领域专题设置和项目立项建议； 研究提出本领域专题设置和项目立项建议 审核项目（标书）； 审核项目课题立项建议； 组织对重大项目实施方案的论证； 组织对项目、专题的评估和验收； 组织对项目 专题的评估和验收

议题

        需求与其他项目过程的联系 软件需求对其他项目风险承担者的影响 软件过程改进的基础 过程改进周期 需求过程的积累材料 需求过程改进路标

软件开发过程改进的目标

        从根本上说，改进过程包括使用更多有效的方法避 免使用过去使用过的令人头痛的方法。然而，改进 之路却是从失败、错误开始，还要历经诸如受人为 抵制的影响及因任务的时间紧迫导致改进被搁置这 样的挫折。 软件开发过程的改进有以下两个主要目标：

        解决在以前项目或目前项目中遇到的问题。 防止和避免你可能在将来的项目中要遇到的问题。

需求与其他项目过程的联系

        需求是软件项目成功的核心所在，它为其他许多技 术、管理活动奠定了基础。变更你的需求开发和管 理方法将对其他项目过程产生影响，反之亦然。需 求与其他过程的联系见图。

各过程间的接口

        1) 制定项目计划需求是制定项目计划的 基础。因为开发资源和进度安排的估计都 基础 因为开发资源和进度安排的估计都 要建立在对最终产品的真正理解之上。通 常，项目计划指出所有希望的特性不可能 在允许的资源和时间内完成，因此，需要 缩小项目范围或采用版本计划对功能特性 进行选择。 进行选择

        2) 项目跟踪和控制监控每项需求的状态， 以便项目管理者能发现设计和验证是否达 到预期的要求。如果没有达到，管理者通 常请求变更控制过程来进行范围的缩减。

        3) 变更控制在需求编写成文档并制定基线以 后，所有接下来的变更都应通过确定的变更 后 所有接下来的变更都应通过确定的变更 控制过程来进行。变更控制过程能确保：变更的影响是可以接受的。 受到变更影响的所有人都接到通知并明白这一点。 由合适的人选来作出接受变更的正式决定。 资源按需进行调整。 保持需求文档是最新版本并是准确的更新文档。

        4) 系统测试用户需求和功能需求是系统 测试的重要参考。如果未说明清楚产品在 测试的重要参考 如果未说明清楚产品在 多种多样条件下的期望行为，系统测试者 将很难明确正确的测试内容。反过来说， 系统测试是一种方法，可以验证计划中所 列的功能是否按预期要求实现了。同时， 也验证了用户任务是否能正确地执行。 也验证了用户任务是否能正确地执行

        5) 用户编制文档我曾在一个办公室里工作，办公室 里有为商业产品准备用户文档的技术写作人员。我 咨询其中一位写作人员为什么他们要工作那么长时 间。“我们是食物链的终结者”她回答道,“我们要 编写出用户显示界面及性能的最终变更版本”。产 品的需求是编写文档的重要参考，低质量和拖延的 需求会给编写用户文档带来极大的困难。

        6) 构造软件项目主要产品是交付可执行软件，而不 是需求说明文档。但需求文档是所有设计、实现工 作的基础。要根据功能要求来确定设计模块，而模 块又要作为编写代码的依据。采用设计评审的方法 来确保设计正确地反映了所有的需求。而代码的单 元测试能确定是否满足了设计规格说明和是否满足 了相关的需求。跟踪每项需求与相应的设计和软件 代码。

软件需求对其他项目风险承担者的影响

        当软件开发队伍改变他们的需求过程时，与其他项 目风险承担者沟通的接口也会发生变化。 为能顺利进行这些接口操作，要与其他领域的合作 者多交流，让他们知道你的改进想法和调整计划。 要向他们说明改进后的新过程会带来什么好处。 在开发过程中要遵从开发组与其他功能领域之间重 要交流接口的规范和内容，如系统需求规格说明文 档或市场需求文档。通常重要项目的文档从写作者 档或市场需求文档 通常重要项目的文档从写作者 角度是严格规范的，但往往不能给客户提供他们所 真正需要的全部信息。

软件过程改进的基础

条改进软件的原则(4-1)

        改进过程应该是革命性的、彻底的、连续的、 改进过程应该是革命性的 彻底的 连续的 反复的不要期望一次就能改进全部的过程， 并且要能接受第一次尝试变更时，可能并没 做好每一件事。不要奢求完美，要从某一些 过程的改进、实施开始。当你有一些新技术 的经验后，可逐渐调整你的方法。

条改进软件的原则(4-2)

        人们和组织机构都只有在他们获得激励时才 愿意变更而变更引起的最强烈的刺激是痛苦。 我的意思并不是要人为地制造痛苦（比如管 理者强加的进度压力使开发人员工作异常痛 苦），而是你曾在以前项目中经历过的真正 艰辛。

条改进软件的原则(4-3)

        过程变更是面向目标的在开始运用高级过程 之前，先确保你知道变更的目标。是想减少 需求问题引起返工的工作量？还是想更好地 控制需求变更？或是想在实施中不要遗漏某 项需求？有一份明确规定的实施蓝图将会有 助于你在改进过程中取得成功。

条改进软件的原则(4-4)

        将改进活动看作一些小项目许多改进活动一开始 将改进活动看作 些小项目许多改进活动 开始 就失败了。因为缺乏计划或是因为所需资源并未 给予。为避免这些问题，把每个改进行为看作一 个项目。把改进所需的资源和任务纳入工程项目 的总计划中。执行计划、跟踪、衡量和报告那些 已在软件开发项目中所做的改进，缩减改进项目 的规模。为每个过程改进领域写 份活动计划。 的规模 为每个过程改进领域写一份活动计划 跟踪风险承担者们执行计划的情况，看是否获得 了预期的资源并知道改进过程实际消耗的费用。

需求分析误区(6-1)

要想说什么是好的需求分析，不如说什么 是不好的需求分析，知道什么是不好的， 是不好的需求分析 知道什么是不好的 自然也就知道了什么是好的。以下就是一 些不好的情况：

需求分析误区(6-2)

创意和求实

    毋庸质疑的，每个人都会为自己的 个新的Idea 毋庸质疑的 每个人都会为自己的一个新的Idea 而激动万分，特别是当这个Idea受到一些根本不 知道你原本要干嘛的人的惊赞时。但是请注意， 当你激动得意的时候，你可能已经忘了你原本是 在描述一个需求，而不是在策划一个创意、创造 一个概念。很多刚开始做需求分析的人员都或多 或少的会犯这样的错误，陶醉在自己的新想法和 新思路中，却违背了需求的原始客观性和真实性 新思路中 却违背了需求的原始客观性和真实性 原则。 永远别忘了：需求不是空中楼阁，是实实在在的 一砖一瓦。

需求分析误区(6-3)

解剖的快感

        几乎所有搞软件的人，做需求分析的时候，一上 几乎所有搞软件的人 做需求分析的时候 上 来就会把用户告诉你的要求，完完整整的作个解 剖，切开分成几个块，再细分成几个子块，然后 再条分缕析。可是当用户迷惑的看着你辛辛苦苦 做出来的分析结果问你：我想作一个数据备份的 任务，怎么做？这时，你会发现，需要先后打开 三个窗口才能完成这个任务。 三个窗口才能完成这个任务 永远别忘了：分解是必需的，但最终的目的是为 了更好的组合，而不是为了分解。

需求分析误区(6-4)

角度和思维

        经常听到这样的抱怨： 用户怎么可以提出这样苛刻的要 经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要 求呢？”。细细一了解，你会发现，用户只不过是要求把 一个需要两次点击的功能，改成只有一次点击。这样会导 致需要改变需求、改变编码、甚至重新测试，增加工作量。 可是，如果换个角度来想想，这个功能，开发的时候只用 了几次、几十次，可是用户每天都要用几百次甚 至几千次 几万次，改动一下就减少了一半的工作量，对他来说，这 样的需求难道会苛刻吗？ 永远别忘了：没有任何需求是不对的，不对的只是你的需 求分析。试着站在用户的思维角度想想，你的需求分析就 会更加的贴近用户，更加的合理。软件应该是以人为本的。

需求分析误区(6-5)

程序员逻辑

        从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好 的程序员就必然能成为一个好的系统分析员。一些程序员的固化 逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。 比如说１／０逻辑（或者是说黑白逻辑），认为不是这样就是那 样，没有第三种情况。可实际情况往往是，在一定的时候是这样， 其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可 能的情况列举出来，然后一个一个分别处理，每个占用三分之一 的时间；可是实际的情况往往是，三分之一的情况占了９９％的 比例，其它两种情况一年都不会遇到一次。实际中还有很多这样 的例子，不一一列举了。 的例子 不 列举了 永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是 重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你 的结论会截然不同。

需求分析误区(6-6)

        综合分析需求过程的失误的情况，提出相 关的改进措施。 

过程改进周期

评估当前采用的方法

        任何过程改进活动的第一步都是评估当前组织中 任何过程改进活动的第 步都是评估当前组织中 使用的方法。找出其优势和缺陷所在。评估本身 不能带来任何改进，但能提供信息，评估为你正 确选择变更奠定了基础。 一种更彻底的方法是让来自外部的顾问客观地评 估你目前的软件开发方法。这种正式过程的评估 方法要以一种已建立的过程改进框架工作为基础， 方法要以 种已建立的过程改进框架工作为基础 如软件工程研究所（ C M U / S E I1 9 9 5）开发 的软件功能成熟度模型(CMM)。评估者将会检查 软件开发和管理过程，而不限于需求活动.

软件开发过程改进的周期

制定改进活动计划,一个需求管理改进的计划包括如下活动条目

1) 起草一个需求变更控制过程草案。 2) 评审并修改变更控制过程。 3) 以一个项目A来实验(pilot )变更控制过程。 4) 以实验反馈为基础修改变更控制过程。 5) 评估问题跟踪工具并选择其一来支持变更控制过程。 6) 定制并购买问题跟踪工具以支持变更控制过程。 7) 在组织中使用新的变更控制过程和工具。

建立、实验和实施新的过程

        实施一项活动计划意味着开发新的、更好的方法， 实施 项活动计划意味着开发新的 更好的方法 并且相信它能提供一个比目前过程更好的结果。 然而，并非第一次就能使新过程完美无缺。许多 看起来很不错的方法付诸实施后会变得既不实用 又低效。因此，要为你建立的新过程或文档模板 计划一个“实验”。运用在实验中获取的经验来 调整新技术，这样将它运用于整个目标群体时， 调整新技术 这样将它运用于整个目标群体时 改进活动会更有效果。请铭记下面这些关于引导 实验的建议：

        选择实验参与者（ p a r t i c i p a n t），他们将尝试新方法并 提供反馈信息，这些参与者可以是生手也可以是老手，但他们 不应该对过程改进持有强烈的反对意向。 确定用于评估实验的标准，使得到的结果易于解释。 通知那些需要知道实验是什么以及为什么要实施的工程风险承 担者。 考虑在不同的项目中实验新过程的不同部分。用这个方式可使 更多的人尝试新方法，因此能提高认知水平，增加反馈信息。 作为评估的 部分工作，询问实验参与者，如果他们不得不回 作为评估的一部分工作，询问实验参与者，如果他们不得不回 头采用他们原有的工作方法，他们会觉得怎样。

评估结果

        过程改进周期的最后 步就是评估已实施的活动及取得的 过程改进周期的最后一步就是评估已实施的活动及取得的 成果。这样的评估有助你在将来的改进活动中做得更好。 评估实验工作进行得如何，采用新过程解决问题是否很有 效。下一次在管理过程实验工作时是否需要稍作变更。

需求过程的积累材料

        如果想要项目不断取得满意的结果，你需要有效地 执行需求工程的各个过程：信息获取、分析、编写 规格说明、验证以及管理。为了执行这些步骤，你 应当把过程中积累的材料收集起来。过程包含已完 成的活动和可交付的产品。过程中积累的材料有助 于小组成员一致而有效地执行过程，还有助于大家 理解他们遵从的步骤及要开发的产品。积累的材料 包括下面几种类型的文档：

检查清单

        清单列出各项活动，交付的结果和其它应注意或验证 的条目。检查清单是用来提示记忆的，有助于确保处 于忙碌中的工作人员不要忽略重要细节。

实例

一种特定类型工作产品的代表，积累起能在你组织中 运用的更好的实例。

计划

概括说明怎样完成目标与完成时需要什么样的文档。

方针

        确立活动期望、产品期望和交付产品期望的指导原则。 过程都应遵从的方针。

过程

        描述完成某个活动的任务顺序或步骤，说明要执行的 任务及其在项目中所扮演的角色。不要包括示范信息。 任务 其在 中 扮演的角色 包括 范信息

过程描述

        一组完成某些目的活动文档的定义。过程描述应包括 过程目标、里程碑、参与者和执行任务的适合时间、 交流步骤，期望结果以及与过程相关的输入和输出数 据。

模板

        一种完成整个工作产品的指导方式。重要工程文档的 种完成整个 作产 的指 方式 重 程文档的 模板提醒你检查是否遗漏了什么。一个结构很好的模 板提供了许多捕获和组织信息的栏目( s l o t )。模板 中包含的指导信息将帮助文档作者有效地使用它。

需求开发过程的积累材料

        项目视图与范围模板 需求开发过程 需求分配过程 使用实例模板 软件需求规格说明模板 需求优先级确定过程 SRS和使用实例审查清单

需求管理过程的积累材料

        变更控制过程 变更控制委员会过程 需求变更影响分析检查清单和模板 需求状态跟踪过程 需求跟踪能力矩阵模板

需求过程改进路标

        在需要把这些改进活动排序以便能用最小的投资得 到最多的收益。过程改进流程图描述了改进活动的 一种前后次序。