03软件需求之开发客户需求.docx
《03软件需求之开发客户需求.docx》由会员分享，可在线阅读，更多相关《03软件需求之开发客户需求.docx（90页珍藏版）》请在冰点文库上搜索。
03软件需求之开发客户需求
软件需求之开发客户需求
XXXX公司
XXXX年XX月XX日
通过项目启动过程，我们已经站在比较高的层面，就项目的目标、问题、概念、范围、愿景达成了共识，也建立了双方项目信任的关系，下面要做的事情就是组织正式的分析团队，收集、分析和求精客户需求，引出客户对产品生存周期所有阶段的需要、期望、限制和接口，挖掘客户需求背后的需求。
收集需求的要点并不仅仅是询问和回答，解决这个问题最直接的方法，就是对所确定的业务领域和需要进行的工作进行学习，理解他们正在做以及他们希望做的事情，理解了才可能沟通。
如果不能直接参与对方的工作，也需要分析团队向用户（包括易用性专家、安全专家、操作人员等）咨询，使我们知道产品将来工作是什么样子的。
在项目的开始阶段，需求分析人员需要尽可能把关注点放在与项目大的目标有关，以及与体系结构有关的需求上，每一项需求都不需要详细描述，而是描述出一系列的客户要求，而需求的详细描述可以放在后期迭代过程中去完成。
本章将沿着如下图所示思路逐渐展开。
1.需求获取过程说明
需求获取的工作是由需求分析师来策划的，但是他不是单独完成这个工作，一方面大型项目需要一个分析团队共同完成这项工作，另一方面，用户和其他利益相关方亦一起来协作收集需求。
因此，需要定义人们能够在一起协调工作的过程。
1.1需求获取过程
需求获取的活动处于需求过程的中心位置，其过程如下图所示.
需求获取使用项目启动阶段的输出作为起点，从利益相关方那里收集需求。
制作原型是一个并行的过程，注意这个阶段收集的需求是潜在的需求，它还是要通过质量关的质量检查。
在需求分析中，需求分析师是解释者，他必须理解用户所说的关于工作方面的事情，并把它解释成一个产品的需求规格说明，并且为工作注入一些新的东西。
也就是说，需求不仅仅是被动的描绘一件已经存在的东西，而是包含一些创新，让工作更容易、更好、更有趣或者更舒服，在这个过程中，需求分析师必须承担几种角色：
●观察和学习该项工作：
从用户的角度力理解它，研究它们的工作，询问他们正在做什么，为什么要这样做，所听到的每一条信息，都同时自己个层面得到处理。
●解释这个工作：
用户对某项工作的描述，必须作为实事来对待，用户毕竟是这项工作的专家。
分析师必须对用户的描述进行过滤，跳过对当前技术或者做事方式的描述，而发现这项工作的本质，而不是它的表象。
●发现完成该项工作的更好方法：
一旦分析师看到本质，或者真正的工作，他会解释产品必须做什么以满足那部分工作。
同时他会和利益相关方一起来构建一个产品用以改进工作。
●以需求规格说明和和分析模型的方式来记录结果：
分析师必须保证他与利益相关方对产品的理解是一致的，利益相关方同意这就是所要的产品。
在需求获取的时候要注意的问题是从利益相关方角度，需求有“有意识”和“无意识”两种，有意识需求是利益相关方头脑里上层的东西，他常常代表利益相关方想改进的东西。
无意识需求是利益相关方常常忘记表述的东西，因为他对这些需求知道太多，并假定别人也有这个知识，但利益相关方没有想到实现这些有用需求的可能性。
在收集活动中发现所有的需求非常重要，因为一些没有发现的需求最终还是会显露出来，但在后期为这些需求所做的修改，代价就太高了。
1.2学习工作
学习工作是需求分析的第一步，其主要目的是获取业务用力，业务用例对于需求活动来非常基础，所以我们强烈建议，不论处于什么样的情况，或者项目属于哪个类型，都要考虑每次针对一个业务用例进行收集，业务用例的获取过程如下。
获取业务用例主要需要做如下的事情：
●复查当前状况；
●做用户的学徒；
●确定本质需求；
●需求头脑风暴；
●用户访谈；
●文档考古学；
●召开用例研讨会；
●构建事件模型；
●构建场景模型；
●举行创造性研讨会。
这部分工作是需求分析中最重要也是最难处理的部分，后面我们会详加讨论。
1.3确定产品范围
研究业务问题首先需要定义范围，确定项目范围的过程如下图所示，其过程图如下。
其工作主要包括：
●研究相邻系统；
●定义用例边界；
1.4进行事件勘查
1）收集业务事件知识
这项活动是观察所有的工作知识，这些知识存在于每个业务事件之中，使用事件边界作为收集所有工作知识和知识来源的指导，这项活动的成果是学习详细的工作的起点，其过程图如下。
针对每个业务事件，寻找任何可能包含于该事件相关的工作知识的文档。
寻找报告、表格、规范、用户手册、组织结构图、可行性研究、产品文档、市场广告文档等任何可能包含深藏起来的需求文档。
●列出工作知识的来源名称；
●在工作上下文范围边界之内的人；
●相邻系统；
●在工作上下文范围之外的人；
●一个可能具有该事件知识的团体名称。
是否存在一些领域包含了该事件的知识？
是否存在一些可复用的需求包含了该事件的知识？
2）选择合适的获取技术
为了选择最合适的业务事件获取技术，需要考虑如下问题：
●可能的知识来源是什么？
●你能直接与人交谈吗？
●这种知识是有意识的、无意识的还是从没有想到过的？
以下是一些获取技术及其特点：
复查当前情况：
●善于揭示无意识的需求；
●有助于增加新的需求或者对现有系统作维护性改动；
●作为业务过程再工程的基础。
做用户的学徒：
●有助于揭示无意识的需求和有意识的需求；
●如果用户“太忙”而无法交谈，这种方法会很有用。
确定本质需求：
●有助于把需求和解决方案分离；
●是理解系统真正目标的一个好办法；
●有助于揭示无意识的需求，同时提供见解，触发从未想到过的需求。
用户访谈：
发现有一是需求的最好办法。
头脑风暴：
●有助于发现从没有想到过的需求；
●当发明了新产品，而钱咋爱用户的情况不太清楚的时候，这很有用。
举行用例研讨会：
●让用户参与解释模糊、复杂、困难的事件；
●善于揭示有意识和无意识的需求。
文档考古学：
●用于信息来源已经被文档化的情况。
构建事件模型：
如果业务事件的边界比较模糊，那么可以建立一个详细的模型来进行调查。
我们后面会对网罗需求的重要问题作详细的讨论。
1.5询问澄清问题
复查需求问题和系统限制条件问题，使用需求模板作为辅助。
●能确定需求类型吗？
●是否存在这类需求的度量实例？
●哪个利益相关方有可能提供这类问题的答案？
要研究问这个问题最好的媒介/方式是什么？
是面对面询问，还是通过电话、电子邮件、网站或者原型来询问？
●您的需求应该包括了已知需求的所有东西。
在进行需求收集的时候，必须理解用户现在正在做什么，利益相关方希望将来完成什么样的工作，在理解了工作之后，可以帮助利益相关方就多少工作应该自动化达成一致意见，然后为自动化的产品编写需求。
在这个阶段，业务用例分析是一个很好的工具。
2.通过建立模型来理解业务
需求获取活动使用了一些来自启动阶段的输出，启动阶段确定了工作的上下文范围，项目的目标，以及任何解决方案都必须满足的限制条件，启动阶段也确定了项目涉及的利益相关方和潜在用户，因为我们需要知道对谁进行访谈，和谁一起研究并理解工作。
但是，为了更好地理解客户就需要学习客户的业务，这就是说，收集需求最好的方法，是在学习客户业务的过程中发现需求。
这需要分析师具有很好的学习力、理解力和沟通能力。
2.1在建立业务模型的过程中获取需求
1，为什么要了解业务与怎样学习业务
让我们来设想这样的场景，分析师在收集一个完全陌生行业客户需求的时候，他会怎么去做？
他不断地向对方询问你要我做什么？
这会发生什么？
我们会立刻说，这样效果是非常不好的。
但是怎样才能使需求收息的效果好呢？
1）收集需求的入口点是什么呢？
做任何事情都有一个入口点，需求收集的入口是什么呢？
我们认为，正确的入口是首先学习对方的业务。
需求获取事实上是在学习工作的过程中完成的，需求获取既包含了对工作的学习和研究，也包含对工作进行改进，当对产品做什么达成一致意见以后，就可以编写产品的需求，以反映这种双重的本质。
2）学习什么业务呢？
另一个问题就是学习什么？
一个行业从形成到成熟的过程中，业务将会非常复杂。
我们不可能在短时间把所有的业务务方法都做到熟悉，也没有必要去做对方各种业务方面的专家。
我们需要知道：
我们的目标是构建一个IT产品，所以关注点应该在对方业务与IT相关的部分。
那么什么样的业务是与IT相关的呢？
假定有一个简单的业务是我们需要找人商量一个事情，在早期的业务方法是：
了解对方住址→坐上公交车找到他的家→敲门→坐下来谈事。
后来有了电话（IT），业务方法就变成：
查对方电话号码→拨通电话→在电话上反复交流。
后来有了E-mail，业务方法变成：
给对方发一封邮件把自己对问题的观点谈清楚→接收对方的邮件了解对方的响应→拨通电话确认几个比较含糊的事情。
这个简单的例子使我们发现，IT的加入会极大地改变业务流程，因此，了解业务主要是了解业务主要是了解对方的业务流程。
当然有业务流程也可能会发现一些相关的兴趣点的，例如一些算法。
3）怎样学习业务呢？
第三个问题就是怎样学习，我们会发现单纯的询问是不可取的，因为此时用户也没有办法条理性的把需求讲清楚，漫无目的询问往往会引起对方的厌烦和无从说起。
我们应该有一种主动的学习方法。
最好的方式建立业务模型，在这个模型建立过程中发现疑难问题的时候和客户一起商量，双方都对自己的问题越来越清楚，客户对这项工作也会越来越感兴趣，客户需求会在这个过程中象涌泉一样的喷出，这样的学习才是有效的学习。
收集需求从学习业务开始，在学习中逐步建立业务模型，反过来又在在建模中学习工作、在学习工作的过程中发现需求，或者进一步明确需求，这样几个方面有机的结合起来，成为收集需求的很好的方法。
4）重点是研究工作的业务过程
注意，我们强调的并不是泛泛的学习工作，而是重点研究工作的业务过程，建立模型更便于理解工作，发现问题并抽取出相应的需求。
不理解工作就没有足够的问题，也不可能得到足够多的正确答案。
这个模型记录了工作，并且对工作进行了演示（至少是对自己），模型是作为与利益相关方的共同语言，以保证对工作有共同的看法。
在这个过程中，最有效的模型就是业务用例。
2，建立合适的业务用例
什么时候使用业务用例最为合适呢？
一般来说，当业务问题是以业务流程来表述的时候，业务用例是非常有效的方法。
从方法论来说，业务用例是一种面向过程的方法。
1）通过建立业务模型理解业务
所谓业务用例是工作对业务事件的响应。
注意，我们现在关注的仍然是工作，我们还没有思考产品，从触发数据进入工作的那一刻起，工作内的功能就开始处理它。
由谁或怎样做并不重要，重要的事要做什么事情，这种工作是需求获取需要研究的。
在对当前工作建模的时候，一定记住这不是在规定一个新产品，而只是建立用户目前的工作模型。
不论当前的工作方式有什么问题，它都不会毫无价值的，它包括了很多功能，这些功能对工作做出了积极的贡献，这些功能自然的也会包含在将来的系统内，我们可以运用新的技术，用不同的方式来实现，但它们的底层策略几乎是不变的
2）建模必须简明扼要
对任何目前工作系统的建模都必须简明扼要，并尽可能快地完成，而且应该是团队共同完成。
这是团队第一个能力，也就是分析问题的能力的第二个层面。
现实业务的特点本身就是过程的集合，我们可以把业务看成一个过程的集合体，由人和机器共同完成一个任务，计算机与数据交互、读出数据、进行处理又把结果写回到计算机里面去，这样就构成了业务用例分析的基础。
3）建模必须用户参与
整个需求分析过程都需要用户的参与认可，要尽可能清晰的把需求定义清楚，并且请用户提出意见。
分析的特征是采用“抽象”和“分解”两个基本手段，用抽象模型的概念，按照具体业务内部数据传递、变换关系，由顶向下逐层分解，直到找到满足需要的所有可实现的业务元素为止。
2.2业务的上下文范围与视图
分析的方法可以总结为由粗而精、自上而下、从外而内。
一切都是从构造上下文关系开始。
在确定范围的基础上，我们可以画出系统所有处理活动的上下文关系。
与项目启动阶段不同，这时候的上下文模型应该比较详细，对于数据流向应该用文档详细地描述出来。
例如对于我们讨论过的“道路除冰系统”上下文范围，把图绘制如下。
我们知道，在任何情况下，图形都没有办法表达细节，但更容易表达关系。
为了更精确的描述外部系统与系统之间数据流动关系，需要通过表格仔细列出每一个参与者与系统之间的数据流动，下表列出了这样的数据流清单。
道路除冰系统数据流清单
编号
参与者
输入数据流
输出数据流
1
气象站
气象站读数
2
气象预报服务
区域气象报告
3
热像图提供者
热像图
4
道路工程部门
改变的道路
新的气象站
改变的气象站
失效的气象站告警
5
卡车车库
卡车改变
修订的除冰调度计划
道路除冰调度计划
已处理的道路
卡车故障
修订的除冰调度计划
对没有处理的道路进行提醒
2.3过程分解与事件分解
1，过程的自顶向下逐步分解的方法
当问题比较大也比较混沌的时候，采用“自顶向下逐步分解与求精”的方法，可以使复杂的问题变得比较简单。
如果一个功能对人脑来说太大，以至于不能立刻勾画或者实现它，那么就把它重复分解成小到足以能够处理的子功能，并且定义好它们之间的关系。
用户所需求的每个功能都可以精确分配给一个设计元素，保证每个功能都被实现，每个设计元素都可以回溯到需求的功能，保证设计不包括多余的元素。
这样做还有个附带的好处：
不同的子功能可以分配给不同的工程师或者团队，使他们各自处理不同的设计单元。
对于一个大型系统，这样的分配是必需的，这样就有可能把一个复杂的问题变得比较简单和可行。
1）DFD的符号
建立业务模型最主要的工具是数据流图（DFD），在业务分析的第一步，通过数据流图来建立产品数据的业务流动关系是很有必要的。
我们甚至可以根据数据流图来建立业务过程单元与产品结构的某种程度的映射，这对于保证需求与设计之间的追朔关系十分有益。
数据流图可以表示任何一个系统（人工的、自动的、或混合的）中的数据流；对每个可以加工的过程可能需要进一步分解以求得对问题的全面理解；数据流图着重强调的是数据流而不是控制流。
DFD只用了6个符号来表达概念，如下图所示。
2）基于过程划分的系统过程模型
如果一个DFD片断包括更多的处理，可以把把每个过程逐步按层分解，以便作更详细的研究，这称之为过程分解。
这种过程分解的最后结果，是每个独立的过程可以用单个的业务组件来实现。
例如，对于“公安远程教育课程注册子系统”，其上下文关系（0层图）如下图所示：
在过程分解中，其1级数据流图的分解如下图（A）所示。
如果需要，可以再对过程“1”（课程安排）进行进一步分解，如下图（B）所示。
这种分解的过程，将使我们对整个系统的业务模型由粗而精理解得非常清楚。
过程分解是以一种事先定义的方式来规范工作流程的方法，我们经常在定义一个工作的时候采用过程分解的方法，比如在建立需求工程的时候，我们使用了典型的过程分解方法，使过程变得清晰明了，而且易于操作。
同样道理，如果一个过程包括更多的处理，可以把每个过程进行再分解，以便作更详细的研究。
2，为什么要采用事件分解
1）过程分解是基于工作职责划分
过程分解实际上是一种工作职责划分方法，不过，过程分解一般是一个事先方法，当过程定义清楚一后，所有的参与者都必须遵循这个过程，当我们需要了解一个工作的时候，如果这个工作存在一个已经定义的过程，仔细阅读这个过程是非常有意义的，它可以使我们对整个工作方式有一个概貌的、框架性的理解。
如果不存在这个过程，则我们需要分析整个工作状况，描绘出整个工作的过程分解结构，并取得利益相关方的认同。
这是理解工作的第一步，也是后续工作的基础。
2）事件分解是对业务事件的响应分析
我们应该看到，仅仅靠过程分解是不够的，因为这时候的过程研究还是属于静态的、理解性的、事实上可能还是事先的，甚至是主观的。
对工作的进一步理解和分析，还需要进行动态的，更加客观的、更加深入的分析，这就要考虑利用事件及其业务响应来建立过程模型。
事件分解本质上是基于工作对业务事件的响应分析，这是在需求分析中应用更多的一种分解方式，下面我们进一步进行讨论。
3）业务事件
所有的系统或者工作都会对外部发生的事件做出响应，这些事件称为“业务事件”。
例如顾客从书架上取出一本书，然后走到收银台，这样发生一个业务事件：
“顾客想买一本书”。
店员响应这个事件的做法是：
扫描条形码，告知书价，向信用卡公司查询并要求认证，把款项记入收银机，把书放入袋子并递给您。
4）业务用例
我们把对业务事件的响应称为“业务用例”。
例如，向信用卡公司查询并要求认证事实上又发起了另一个事件，并且产生了另一个业务用例，也就是由事件把业务用例激活。
一般来说，业务事件的产生是随机的，但也有时间触发的业务事件，比如事先确定的一个日期所发起，比如保险公司在某人的保单一周年的时候给他寄一份续保通知，银行每个月15号给他寄一份结算表等。
通常对一个时间触发的业务响应是产生某种信息并发送到相邻系统，而且总是牵涉到存储数据。
在这个过程中，关键是要发现业务事件，这些事件让业务以某种方式做出反应，业务用例的每一层，都是一个事件响应的结果。
2.4为什么业务用例是好想法
对于许多一眼看起来相当明显的事情，我们在描述的时候往往会发生麻烦。
但是我们的经验告诉我们，以客观的方式划分工作的价值，以及在规划解决方案之前先理解工作本身的价值，结果就会使我们发现真正的需求，而且会更快地发现它们。
1）事件是非主观方式：
事件是一种非主观方式来划分工作的，也就是确定工作对外界的响应。
毕竟这是顾客看待业务的方式。
无论在过程分解中内部的划分是怎么样的，外界都不感兴趣。
类似的，任何工作当前的划分（比如过程分解），都是基于当初在具体情况下策略上的考虑，这些决定在新的自动化系统加入的时候可能不再有效，至少应该质疑它们，避免只是因为它们存在，就认为理应如此。
不是从内部看，而是从外部看，这样我们就可以清楚地发现划分工作的最有效方式。
2）事件指明了相互间的配合：
业务事件指出了哪些东西是在一起配合工作的，从而我们可以提交一些内聚的部分，并且使这些部分的接口最小化。
同时，这也可以使工作的这一部分成为详细需求调研的基础。
这些部分的依赖性越少，分析师就越有可能关注与这部分的细节，而不需要知道其它部分。
3）不要用假定系统来研究工作：
使用业务用例最重要的原因，是研究业务事件到来的时候到底发生了什么。
我们不能够假定系统已经存在，再围绕着这个假定系统来研究业务，这非常危险，因为一开始就以产品为中心来研究问题，可能会忽略掉许多深入工作的其它部分，从而丧失了改进产品和业务的机会。
4）利用事件的响应更能发现问题：
如果分析师不敢去问“为什么是这样的？
”、“有没有改进的机会？
”就可能使“业务化石”从一代产品传到下一代产品。
分析师必须超越那些显然的东西，这意味着理解工作真正的本质，当然如果太沉溺当前的工作方式也是危险的，有时候就难以发现业务事件，为了克服这种困难，我们建议通过一个非正式的过程来发现业务事件。
2.5发现业务事件和“无事件”
业务事件是发生的一些事情，这些事情让工作做出某种反应，他们发生在工作的范围之外，或者是某个时间到达的时候。
发现事件主要从上下文模型开始，研究相邻系统与整个系统的信息交换，定义高层事件，然后逐步的分解，继而发现底层事件。
1）每个数据流都可能与一个事件发生联系
上下文范围是在“项目启动”阶段确定的，一般来说，在上下文范围图中每个数据流都可能与一个业务事件相联系，现在我们的眼睛盯住具体的细节，来发现每个事件。
在研究事件的时候，往往需要了解所有的数据存储，但是分析的时候并不需要数据库的详细设计，而只是把数据存储实体的方式从大的方面规范清楚，以此作为详细设计的一个必要的输入。
我们已经说过，在需求获取的时候，我们可以通过研究上下文范围图中的边界数据流来确定业务事件。
如果发生一个外部业务事件，相邻系统就会向工作发送数据流并且从工作得到响应。
因此，每一个进入边界的数据流都意味着一个可能的外部业务事件。
出去的数据流要么是对外部事件的响应（处理输入数据流并产生输出数据流），要么是一个时间触发的事件的结果（报表、发出邮件、警告等）。
大多数事件图包括一个单一过程，并且需要说明以下内容：
●输入及输入来源，来源被描述为外部代理。
●输出及输出目的地，目的地被描述为外部代理。
●必须读取记录的任何数据存储都应该被加入到事件图中，事件流应该加入命名。
●对数据的任何增、删、改、查都应该加入到事件流中，事件流应该加入命名。
根据我们已经描述过的“道路除冰系统”数据清单，经过分析，我们可以得出相应的事件清单如下。
道路除冰系统事件清单
编号
事件名称
输入数据流
输出数据流
1
气象站传送数据
气象站读数
2
气象局预报天气
区域气象报告
3
道路工程师通知改变的道路
改变的道路
4
道路工程师安装了新的气象站
新的气象站
5
道路工程师改变了气象站
改变的气象站
6
到了测试气象站的时间
失效的气象站告警
7
卡车车库改变了卡车
卡车改变
修订的除冰调度计划
8
到了检查结冰道路的时间
道路除冰调度计划
9
卡车处理了一条道路
已处理的道路
10
卡车车库报告卡车出问题
卡车故障
修订的除冰调度计划
11
到了监控道路除冰的时间
对没有处理的道路进行提醒
2）“无事件”用于发现例外和遗漏的事件
仅仅依靠输入数据流发现业务事件只能得到一个初步的事件表，我们还需要采用一些方法发现更多的遗漏事件。
有些遗漏事件是显而易见的，但有些可能被掩盖在某些事实之下，发现这些遗漏事件一个比较好的方法就是寻找一下“无事件”。
术语“无事件”指的是如果基本事件没有发生将会引起什么事件，从而扩充我们的思维空间，在大多数情况下可能由此发现例外和遗漏的事件。
比如一个事件是“客户付款”，无事件指的是客户没有付款将会怎样？
是不是引发“跟踪信义不佳的付款者”的另一个事件？
或者是引发“向未付款者发送提醒通知”的事件？
在上面的表中出现了两个无事件：
事件9“卡车处理了一条道路”，但是如果卡车没有处理那条道路又会怎样？
这就是无事件。
事件11“到了监控道路除冰的时间”，工作时间查道路是不是按照指令进行了处理，如果没有处理，将发出提醒。
仔细的研究自己的业务或者事件清单，问一下“如果事件没有发生又会怎样？
”这就可能发现更多的事件。
不是所有的事件都有无事件，比如“如果这个事件没有发生将会怎样？
”回答是“不会怎样”，出现这种情况不需要介意，因为检查清单致力于找出无事件的目的，是帮助我们发现一些遗漏的事件。
请把在这个过程中发现的新事件加入到业务事件清单中，并更新上下文模型中相应的数据流。
不可否认，确实需要一些工作知识才可能弄清楚这些业务事件，我们建议在项目的启动阶段就开始确定这些业务事件的过程，那时候利益相关方都在，他们都非常熟悉这些业务事件。
但是需求分析师的兴趣在于工作是事件的响应，这就是对业务用例的分析。
2.6需求项框架
1）发现业务用例最好的方法就是做学徒
通过上面的一系列讨论，我们发现了获取需求应该在学习和建立业务模型的过程中挖掘，而发现业务用例最好的方法就是做学徒，在实际中观察业务是如何工作的。
因为一个大的系统，不太可能一个客户方的代表能给你讲清楚所有的业务节点都在做什么，使开发者完全理解业务工作，并且获取他们所需要的需求。
当某人给你解释一个业务的时候，他倾向于用行业内专用的抽象术语来解释，时间会非常短，也没有办法和耐心来演示一切。
2）分析人员最好能参加到对方工作中去
这就需要分析人员参加到对方工作中去，几乎所有人都善于把自己正在做的事情给你解释清楚
升级会员 