软件需求与分析须要掌握的内容

  读了老师推荐的这篇博文，我以为需求分析真的是一门博大精深的学问，本来只是以为需求分析就是找一个用户简单的询问她想要什么，就给他作一个软件来就行，可是读了博文以后发现需求分析原来有这么多须要注意的地方。

  需求分析需掌握的技能：

  1.初识  咱们应与客户深刻了解后，运用咱们专业知识，提出比客户的原始需求更加合理、可操做的解决方案，让客户感受你说的正是他们想要的。若是可以这样，客户不只可以欣然接收你提出的方案，并且会感受你很是专业，你在客户心目中的形象也会无形中提升，使你有更多的机会提出有利于开发的可行方案，下降开发的风险。

还要与不一样层次的用户具体交流

  2.拜访

需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工做（假如项目还有后期维护）。在这漫长的时间里，咱们须要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。不只如此，技术这东西总有不如意甚至实现不了的地方，咱们须要客户的理解与包容，这都须要有良好的客户关系。按照如今的软件运做理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务。按照这样的理念，软件供应商与客户创建的是长期双赢的战略协做关系，这更须要咱们与客户创建长期友好的关系。

  3.讨论会

采用这种集中式的研讨，可使问题的处理变得高效而及时。固然，也会因地区化差别而出现多个方案，每一个方案都是合理的，咱们必须在软件中分别对其进行处理的状况。

将业务人员划分为多个业务组也是一项比较成功的经验。因为业务人员自身的局限，不可能对全部业务领域的细节全面掌握，每每老是有本身熟悉的部分，也有本身不熟悉的部分。划分业务组，可让业务人员分别在本身最熟悉的业务范围内参与讨论，能够有效提升业务讨论的质量。同时，一个管理系统涉及的业务是复杂而系统的，若是划分红多个模块并行地进行业务讨论，也能够大大提升业务研讨的工做效率。

  4.需求谈论

在认识了客户的业务领域以后，咱们才能去分析他们提出的全部原始需求。他们为何要提出这项需求，提这项需求的目的是什么？只有通过这样的分析，咱们才能深入地理解需求，进而运用咱们的专业知识，提出更加合理的技术方案。但很是遗憾，咱们在需求分析中经常不是这样作的，甚至当软件都开发出来了，需求分析人员都说不出客户为何要提出这个需求，更谈不上了解业务操做流程。一句经典的话是：“客户让咱们这样作的。”

总之，咱们作需求分析，眼界不能仅仅停留在软件自己，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有创建在这种分析基础上的软件研发，才能保证需求的正确与变动的可控。

  5.迭代

当咱们完成了一系列的分析整理并造成文档之后，应当对及时地与客户进行反馈，确认咱们的理解是否正确，也就是需求验证工做。需求验证工做应当贯穿整个研发周期，而且在不一样时期表现出不一样的形式。首先，在需求分析阶段，需求验证工做表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一块儿，一项一项描述咱们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深刻地加以描述。咱们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，咱们还能够制做一些简单的原型，更加形象地描述咱们对需求的理解，会使咱们与客户的沟通更加顺畅。随后的设计开发阶段，咱们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样作的结果是，客户能够及时地提出咱们对需求理解的误差，或者及时提出对咱们设计不满意的地方，使咱们存在的问题获得及时地发现与解决。问题及时的解决，使咱们修复问题的代价得以降至最小。以后，当开发进入到验收测试阶段，咱们则是与客户一道，一项一项地验证咱们的软件是否知足需求列表中要求的业务需求。最后，当软件迎来下一次升级开发时，咱们将开启另外一次轮回。

  6.需求捕获

客户在提出来一系列业务操做之后，最后提出了一个统计报表的功能。这个统计报表是从前面这一系统操做数据中统计出来的，所以咱们就对这些业务操做及其结果数据进行了一个详细的分析，最后发现根据这些数据统计出来的数据存在不少的问题，甚至可能出现相互矛盾的地方。随后咱们与客户就这些问题进行了深刻地探讨，最终客户不得不认可，他当初在设计这个报表的时候考虑不周全。在提出问题的同时，咱们又提出了咱们的解决方案，这是很是关键的。当咱们提出咱们的合理化建议之后，客户欣然接受了。同时，客户对咱们这种很是专业的分析与处理过程大加赞扬，无形中也提升了咱们在客户心目中的威望。

不只如此，客户做为一个群体，客户与客户以前对同一问题也可能存在不一样的见解，这特别突出地体如今那些多组织机构的管理系统中。所以，对于一些客户非正式的场合提出的需求咱们要仔细甄别。一个比较可行的方法就是，先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户表明参加的需求评审会、需求定稿签字确认会等等，以比较正式的形式讨论和肯定下来。

  7.功能角色分析和用例图

面对的是一些对信息化管理没有经验的客户，状况就有些不妙了。在这种状况下，一般客户只能给咱们一些管理目标、基本想法，其它的调研工做就须要咱们本身去作了。这时，我给你们的建议是，首先从组织机构上划分清楚系统涉及哪些部门、哪些科室，而后在这个基础上划分出来这些部门这各个科室的人员都扮演哪些不一样职能的角色，以及完成哪些业务操做。系统中的一个功能，在通常状况下是组织机构中某个（或多个）角色，为该机构某项业务流程完成的某个操做，而且这个操做应当有某个肯定的结果（即产出物）。而这个功能就是咱们须要提取出来的用例。虽然功能角色分析在整个需求分析过程当中可能会随着认识的深刻而不断调整，但分析过程大致是这样进行的。

有人说，咱们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以咱们对图形的描述，客户怎么会看不懂呢？关键问题在于，咱们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不三不四，客户固然就看不明白了。如今咱们看看用例绘制都有些什么常见问题。

1. 没有正确理解用例图的视角。前面我反复强调了，用例图的视角是用户，也就是说，站在用户的角度来观察的咱们须要设计的系统。从这个视角，用户看到的系统是什么呢？固然是一项一项的功能，这些功能是客户可以理解的、具体的、对客户存在价值的功能。从这个意义上说，那些技术性的功能不该当出如今这里，或者应当描述为用户能够理解的文字，好比“自动考核”。而那些应当绘制的用例，在取名时也应当站在用户角度去取名。举个简单的例子，一个员工档案信息系统，以往咱们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来说应当是作什么呢——填写新员工资料；“更新员工信息”对于用户来说又是作什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。不管是“填写新员工资料”、“更改员工资料”，仍是“员工注销”，对于客户都是平常工做中须要完成的操做，将用例命名为这些名字必然为用户所理解。同时，每个用例对于用户来讲应当是有价值的，也就是说，用户使用这个功能是要完成一项操做，或得到什么信息。好比上图的“自动考核”会产生一批考核结果，执行“预警监控单项查询”能够得到预警监控结果数据。

2. 图形绘制杂乱无章。一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。若是你想将全部的功能，无论粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。咱们之因此将分析设计图形化，是由于图形能给人形象立体的感官，令人当即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。所以，咱们绘制用例图要学会拆分，由粗到细地一个一个绘制。先总体的绘制，再划分红各个模块一个一个详细绘制，再进一步细化。因此，描述一个系统应当有许许多多的用例图。

3. 用例是一个场景。在现实世界中，咱们经常面对的是一个个长而复杂的操做流程，但在软件世界里，咱们要将它们拆分红一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操做，而且这些操做最终应当有一个明确的结果。

  8.业务流程分析

咱们进行业务流程分析，就是要分析业务流程中哪些是须要信息化管理的，而哪些则不须要。信息化管理过细，无疑会加剧基层业务人员的负担（这也正是为何许多基层业务人员会排斥信息化系统的缘由），而适当的信息化管理则能够提升工做效率。试想一下，若是你工做中的每个步骤都必须在计算机中操做一下，怎么不让人烦呢？而若是在工做中一旦须要先查一个什么信息，或者须要计算一下，系统当即能够替你完成这些工做，或者那些过去基本靠吼的操做，如今立马经过信息化就传递过去了，怎么不让人舒心呢？咱们作信息化管理，不是要加剧人的负担，而应是下降人的负担。以这样的思路去进行流程分析才能设计出优秀的、人见人爱的管理系统出来。所以，我作需求分析，最喜欢下到基层去了解基层业务人员的需求，去分析怎样设计流程才能提升他们的工做效率，而避免加剧他们的负担。“水能载舟，也能覆舟。”一套系统是否能顺利推行下去，基层人员是否支持每每起到十分重要的做用。另外，业务流程分析的另外一个重要的分析内容就是流程差别化分析。不一样的领导有不一样的思路，不一样的单位有不一样的状况。所以，咱们在进行流程分析的时候，经常面临流程差别化的问题。咱们说企业信息化就是一次改革，这首先体如今业务流程的规范化操做，也就是消除这种流程差别。但不一样的单位有不一样的状况，这特别体如今不一样地域和文化的不一样，又经常形成这种流程差别不可避免。分与合，分治与一统，经常是一个都要兼顾的问题，很是微妙，咱们要当心处理。在这个问题上你也许会问，使用工做流引擎就能够了嘛。工做流引擎不是万能的，它只能解决一部分问题，更多的问题还须要咱们的分析人员去分析与处理。

  9.用例说明

用例标识：就是用例的编号，通常采用“项目编号-子系统编号-模块编号-序号”来编号。

用例名称：没啥可说的，就是用例图中该用例的名称。注意用例的命名规则：用例名称一般是一个动词短语或短句，而不是一个名词短语。它能够是一个动词（如：自动考核），一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款，这个不推荐，由于主语就是参与者，显得有些多余）。

用例类型：在我看来，不一样类型的用例，其用例说明的格式是不同的。以上给出的是“业务操做”类用例的格式，它更加着重地在描述业务操做的流程。而“查询报表”类用例则没有什么流程，它更加着重地在描述报表格式及显示内容（后面再给出）。还有用例类型还包括“子用例”、“扩展用例”。

用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。同时，这部分还能够总体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。经过用例描述，阅读者能够对该用例有一个总体的认识。

参与者：用例图中该用例的参与者，一般是业务操做的触发者和施与对象（如外部系统）。

触发事件：谁干了什么，触发了这个用例。

前置条件：在触发该用例相关操做前必须达到的条件。

事件流：这是用例说明中最重要的部分，它详细描述了该用例可能出现的全部流程。
1. 基本流程：另外一个名称更能表达它的意义：最佳流程（The Best Flow）。它描述的是该用例以最佳的、最正常的方式流转，没有出现任何异常，而且最终成功完成操做的流程。基本流程在编写时，应当经过数字对流程中的每一步进行编号。
2. 扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程当中可能出现的全部分支。扩展流程最大的特色就是，它应当是在基本流程的某一步骤发生的分支，所以它的编号规则是“基本流程号+序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。
另外一种状况是，某个扩展流程自己拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。
扩展流程在描述时，应当首先描述进入这个分支的条件，即“若是××则××”、“当××时××”。
3. 异常流程：就是发生异常状况时的处理流程。注意，用例说明是站在用例角度进行的说明，所以这里并非咱们一般同样的发生程序异常的处理流程，而是用户在处理业务操做时发生的异常状况，如：若是顾客不能提供身份证，则••••••

后置条件：又称为“成功保证”，就是执行基本流程得到成功之后所达到的状态（条件）。后置条件每每体现的是执行该用例的最终目的。如：完成用户档案的填写并提交。

非功能需求：简称为“URPS+”，便可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。这一部分的需求分析至关重要而又最容易被忽略，后面咱们再详细讨论。

假设与约束：就是隐藏于业务功能中的各项规则与条件，如各类逻辑条件、计算公式、环境限制等等。

优先级：没啥可说的，最关键的是怎么去评定。这里我卖一个官子，在需求评审阶段，我会给你们一个比较准确而又可操做的评定方法。

除此以外，我还每每在每个用例说明的后面与该用例相关的需求列表，便于需求跟踪。用例分析实质是需求人员的一份设计。既然是设计就可能出现误差，最终偏离原始的需求（这种状况特别容易出如今往后的升级维护中）。所以，将需求列表附在用例后面，便于往后的需求评审与确认。当每次须要升级时，则添加上新的需求，或对以往的需求进行更新。

  10.查询报表分析

报表做用：就是描述参与者使用这个报表作什么。若是有多个参与者，每个都应当描述。

报表内容：用简短的话描述一下。

输出列：罗列报表的输出列，若是须要的话，还应对输出列进行说明，或描述它的数据来源。

使用频率：参与者使用它的频率，便于设计者考虑报表的查询效率。

数据连接：哪些数据项有连接，连接到什么报表，或显示什么数据。

最后依然是那个需求列表，便于业务需求的跟踪。

查询报表的需求分析与通常的业务操做的需求分析存在着巨大的差别。而许多需求分析人员没有认识到这一点，这每每致使对查询报表的分析不到位，为项目的研发带来风险，所以在这里咱们认真探讨一下。

一个有效的报表，每每不是对数字的简单堆砌，它经过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。客户方的领导，特别是那些中层和高层领导，经过对这些报表的阅读，就能够掌握他们的工做进程、增强他们的人员管理、发现他们的管理漏洞、指导他们的战略决策。总之一句话，每一个报表都有他们的设计意图。

好比说，一份工做月报，领导但愿看到的，是按时间、按项目、按部门统计的各项工做的进展状况，以及有哪些异常状况，以便领导监控各项工做可以顺利完成；一份销售报表，领导但愿看到的，是按产品、按区域、按顾客类型统计的各项产品的销售状况，以便领导制订销售计划与各类营销战略。没有弄清楚一个报表的真实意图，就不算真正理解了这个报表的业务需求。

同时，报表的数据项应当都是来源与系统中各项操做的结果数据。许多业务系统的操做流程都是纷繁复杂的，其中还包括各类状况。更复杂的，一些商业智能与分析决策系统，报表所需的各类数据，甚至来源与各类各样的外部系统。分析一个报表的数据来源，就是在梳理各类业务流、数据流，以及各类数据间的关系。若是这方面的分析不到位，最终设计出来的报表每每是不许确的。

另外，用户使用报表的频率，经常决定了报表设计的方式。若是报表中的数据老是在实时变化，而且用户老是在密切关注这些数据的变化，那么报表必须设计成实时查询的；若是用户并非十分关注数据的实时变化，而且老是以天（或者月，或者年）来查看报表，则报表能够设计成按天（或者月，或者年）来预运算统计数字，使得报表查询效率显著提升，能够保证更多的并发访问。

最后，一个报表的核心就是展示给客户的报表格式，以及报表与报表间的各类连接。需求人员在进行需求分析阶段，应当准确地与客户敲定这些格式，并最终在用例说明中体现出来。报表格式是否体现客户的意图，报表数据项是否都能在系统中取到，数据间的逻辑关系是否正确，报表格式是否技术可行，都是需求分析人员在前期就必需要分析到位的内容。不然，报表是项目后期可能出现频繁需求变动的重灾区。

全部这些分析，都体如今了我提供给你们的用例说明格式中。报表做用体现的是报表对于不一样用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据连接、非功能需求，以及最后的界面原型，等等。只要咱们把这些都分析到了，咱们的查询报表就分析到位了。

  11.子用例和扩展用例

在用例中还存在许多扩展流和异常流。当系统在运行到基本流程中某个步骤时，因为知足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。扩展流和异常流其实不那么泾渭分明。在业务逻辑上扩展流依然是一种正常的操做，仅仅只是正常操做的另外一个操做，而异常流其自己就是有什么东西不对劲了，须要进行一些异常处理，好比用户密码输错了、用户忘带身份证了，等等。扩展流和异常流最终均可能回到基本流程中，也可能不能回来，而从另外一个结束点结束。

与子用例类似，扩展流和异常流中的流程若是相对独立、能够为其它流程所共享，则能够提取出来，造成一个单独的用例，叫扩展用例。若是扩展用例是直接从基本流程中某个环节扩展出来，则该环节被成为扩展点，进入扩展用例的条件叫扩展条件。在用例图中，扩展关系被绘制成一根虚线，从扩展用例指向被扩展的用例，并标注为extend。

用例分析中对子用例与扩展用例的分析，使咱们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使咱们在往后的设计与开发中得以很好地复用，提升了系统的内聚并下降了系统的耦合，是一个优秀软件设计的开始。

  12.行动图和状态图

将参与者由繁琐的泳道改成了用例图中的小人。同时，在这张图中还增长了对象流与对象。图中，自动考核结果、申辩申请单、调整后考核结果，都是数据对象，是该流程中相关环节操做的结果。从活动节点指向对象的虚线箭头，则表示了一个对象流，如“申辩申请”活动指向“申辩申请单”的虚线箭头，表示了申辩申请活动的最终结果是产生申辩申请单；从“调整后考核结果”指向“过错追究”的虚线箭头，表示过错追究活动读取了调整后考核结果。

固然，活动图还有其它的元素，但我我的认为其实并不实用，使用以上元素就足以表述咱们的业务流程了。活动图打破了子系统与子系统的壁垒、用例与用例的壁垒，使咱们可以从总体上了解整个系统的流程，所以经常使用在对整个系统的概述、对整个子系统的概述，以及对整个功能模块的概述中。同时，与其它视图同样，活动图也应当有它的文字说明，以便对图中的每一个活动节点、分支进行描述。但对于一些流程相对简单，甚至没有什么流程的查询报表类功能模块，绘制它们的活动图则显得有些牵强附会。

  13.业务领域分析

在需求分析工做中，最后一项分析工做就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面咱们谈到了功能角色分析，或者说用例分析，它是从总体的角度对整个系统人机交互的分析与整理。随后咱们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操做。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操做。可是，全部的行为，全部的操做，最终施与的对象都是那些实体。这句话怎么理解呢？好比，咱们执行填写操做，施与的对象必然是那些表单，最终产生的结果必然是造成一份完整的表单，表单就是那个行为施与的对象。再好比，咱们执行查询操做，施与的对象必然是一个报表，最终产生的结果必然是查看到了这个报表的结果。这里的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。所以，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。

  14.原文分析法

在进行原文分析的时候，咱们首先要作的事情就是对用例说明中事件流部分的文字描述，提取其中的名词。在这个实例中都有些什么名词呢？这些名词我在用例中用蓝色标注了出来，通过整理就是这些：触发器、考核指标（简称指标）、执法行为、指标定义、过错标准（过错判断标准）、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。

领域模型中的实体，每每就在咱们经过原文分析提取出来的这些名词中，但须要咱们进行进一步分析。并非全部名词均可以成为实体，那么哪些能够呢，而哪些又不能呢？首先，系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物，但它自己存在于系统以外，好比用户使用鼠标点击了一个按钮，而领域模型是描述系统以内的事物，所以系统外的参与者应当被排除。本例中的触发器就是系统外的参与者（参见《功能角色分析与用例图》），它应当被排除。

其次，系统以内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。什么变成实体而什么变成实体中的属性呢？自身有本身的属性，能够成为系统中行为的执行者或施与者的，才是实体。好比考核指标就是实体，由于它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性，它在系统中会去执行考核，因此是实体；分子数是否是实体呢？它仅仅是一个数据，没有本身的属性和方法。另外一个判断是实体仍是属性的方法就是判断它将如何持久化。若是一个事物被持久化到数据库中时是一个表，则是一个实体；若是仅仅是表中的一个字段，则是一个属性。

然而，是实体仍是属性并非那么绝对，关键看系统对这个事物进行怎样的处理。好比过错标准是一个实体仍是一个属性呢？若是咱们在系统中仅仅是一个文字描述则是考核指标中的一个属性，若是须要对它进行分解，有它的判断公式，须要让它去执行判断，则应当是一个实体。在需求分析的初期，能够先将其设计成一个属性，待往后的细化阶段再进行调整。

另一个很是重要、值得咱们着重关注的地方是名词的多义性。在本例中，咱们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”表明的是一种类型，有它的过错定义与判断标准；“一个过错行为”则表明的是一个实例，一个执法行为中的某个错误的行为。正由于它们概念上的差别，咱们在领域模型中将其分为“过错类型”与“过错行为”。

  15.领域驱动设计

当咱们站在技术人员的视角去绘制设计图时，客户必然看不懂，由于图中使用的都是专业的术语、专业的符号，表达的都是专业的设计思想。反过来，若是咱们站在业务人员的视角去绘制设计图时，状况就不同了。若是一个用例图，图中的功能都是客户平常常常作的业务操做，而且命名都是业务人员可以理解的业务术语，试问客户会不理解吗？一样，在领域模型中，咱们按照客户的思路，运用客户的术语，去绘制一个一个的对象，按照他们的思路去描绘对象间的关系，描绘对象间的操做，他们真的就会看不明白吗？这说得彷佛有一些抽象，咱们举一个实际的例子吧。

有一次，我与客户在讨论一个考核系统，首先客户描述着他们的需求：
客户：咱们这个考核系统是由许多个考核指标组成的，每一个考核指标就标志着咱们的某项工做的完成状况。每一个考核指标中有一个分母数，标志某段时间全部应当完成的工做数量，有一个分子数，标志这段时间正确完成的工做数量，最后还有一个过错数，标志那些错误的，或者没有按时完成的工做数量。
需求人员：为何是分子分母？
客户：由于最后要计算正确率，用正确率来考核一个单位完成工做的状况。
这样，咱们在纸上绘制出一个考核指标，在属性中写下分母数、分子数、过错数、正确率。

需求人员：那么每一个考核指标都有一个过错判断标准了？
客户：固然啦，每一个考核指标都有它的过错判断标准。一个考核指标可能会有多个过错行为，每个过错行为都有各自的过错判断标准，任何一个过错了，这个执法行为就算过错啦。
需求人员：先等等，你刚才提到执法行为了。执法行为和考核指标是什么关系？
客户：哦，执法行为嘛，就是执法人员对某个用户执行的一次业务操做。考核指标中的分母数就是全部执法行为的个数；分子数就是正确的执法个数；过错数就是错误的执法个数。
这样，咱们就绘制出这样一个草图：



客户看了这个草图有些不一样明白：过错类型是什么东西？
需求人员：过错类型就是某种类型的过错行为呀，它定义了某种过错行为，有它的过错判断标准。下面这个过错行为就是那些具体的过错，好比张三今天犯了什么错，李四明天犯了什么错。
客户：哦，明白。这两个箭头怎么跟其它箭头不同，后面还跟了个菱形框？
需求人员：哦，这表明的是包含关系，表示一个考核指标包含了多个类型的过错行为呀。

通过一番交流，咱们已经明白客户的意思了，客户也明白咱们画的图了。你们对彼此的交流都比较满意。

全部的爱情都是以浪漫开始的，需求分析也不如此。随着需求分析的不断深刻，咱们发现问题了。在这张图中，咱们把执法行为与过错行为仅仅描述为一对多的包含关系，彷佛没有什么特别的。但对大量考核指标具体需求的分析，咱们才发现其实不是这样简单。当考核指标只有一种过错行为的时候，那很是简单，这个过错行为对就是对，错就是错。但当考核指标存在多种过错行为的时候，状况就复杂了，必须分红三种状况：

1. 一个执法行为同时包含多种过错行为，每一个过错行为就是一个考核点，任意一个考核点错了整个就判错，只有全部考核点都正确才判正确。这种状况就像填一个表单，全部数据项都填对了才算对，任意一个错了就算错，而后画出这样一个对象图：



2. 虽然一个考核指标定义了多个过错行为，但它把全部执法行为分为多个类型，每一个类型的执法行为只对应一个过错行为，这个过错行为对就是对，错就是错：



3. 最后一种就是那些限期完成的考核指标，正确的行为只有一个：按时完成的行为，过错行为却有两个：逾期完成与逾期未完成。



虽然图形有些复杂，但这正是表明了现实世界业务的复杂性。咱们拿着这些图与客户进行了简单的描述，因为图中的全部元素都是用客户熟悉的术语描述的，所以他们很快就可以理解。同时，开发人员拿到这样一个图，很快就制订了四套不一样的方案，来分别解决四种不一样的状况。

随后，在对这四种状况更加深刻的分析时，咱们发现第一种状况在计算过错数时彷佛有一些问题。在第一种状况中，一个执法行为包含了多个过错行为，若是出现了过错，过错数算几？假如一个执法行为包含三个过错行为，若是都作对了，分子数算1；但假若有2个过错行为错了，过错数算2？还有那一个正确的行为呢？这彷佛有些矛盾！当咱们向业务人员提出这个问题时，他也有些懵了，这样的结果彷佛是咱们双方都没有预料到的。通过反复的思考与讨论，最后咱们作出这样的决定：将原有的过错数拆分红过错户与过错数。在以上状况中，若是一个执法行为有2个过错行为错了，过错户为1，过错数为2。试想，若是不对需求进行如此深刻分析与理解，能发现这样的问题吗？若是不及早发现这样的问题，是否会给项目后期带来巨大的风险？

应该说，从最初的粗浅认识，深刻到后来对四种状况的认识，正是体现了DDD的另外一个思想：持续学习。需求人员在开始一个新的管理系统的分析工做时，都有可能面临着一个全新的业务领域。在这个领域中，他们不可能一晚上成为专家，也没必要要成为专家。他们须要时间去学习领域知识，但这并不意味着学习全部的领域知识，而是与软件相关的领域知识。作财务软件，你没必要考财务师，但你必需要学会与财务软件相关的财务知识。你对领域模型的认识被延伸到了整个软件生命周期中，包括以后一次一次的升级完善。你每认识深刻一点儿，就可能会体现到你的分析设计中，并最终体如今开发的软件中。你对领域知识认识再深刻一点儿，软件就再完善一分。

  16.非功能需求

简单概括为“URPS+”，便可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分咱们能够进一步细化。

可用性是一个很是宽泛的概念，它泛指那些能让用户顺利使用系统的指标，包括易用性（易操做、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。

可靠性就是系统能够可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。

性能，我认为是需求分析阶段最主要的分析内容。用户对性能的要求没有止境，但现实倒是残酷的。性能受到许多因素的影响，包括业务需求、软件设计、数据库设计、系统部署方式，等等。其中，业务需求和部署方式，对性能的影响是最大的，咱们必须在需求分析阶段就想清楚，解决掉。有一次，客户提出了一个数据导出的功能，这看似一个很是普通的功能。可是通过仔细地分析咱们发现，客户在执行数据导出前的查询时，若是选择时间跨度数年，查出的数据量可能达到数十万。要将数十万数据一次性地导入到一个excel文件中，这不论从运行效率、系统稳定性，仍是技术可行性分析都是不可取的。最后，咱们通过与客户的协商，一次性导出数据最大不超过2万，同时提供了分页导出的功能，可让他们选择导出从第几页到第几页的数据。这样，若是数据量大，客户能够通过屡次将数据导出，数据导出的性能得以保证。

系统部署架构对性能的影响也是巨大的。一个管理系统，是市级集中，仍是省级集中，甚至全国集中，对性能的考量是不同的。市级集中不会过于担忧性能的问题；省级集中就必需要考量并发访问量，是否要创建集群；全国集中就必须考量是否使用消息队列，全部流程是否有性能瓶颈，以及采用什么技术架构更适于并发访问等等。而这一切都是系统架构师应当考量的内容。

最后一个内容，也是最容易被忽略的一个内容，就是可支持性。可支持性，就是软件的可维护性、易变动性。可支持性对于客户是透明的，不可见的，所以客户一般不关心这个。因为时间紧、人员素质良莠不齐，这部分也经常为管理者所忽略。但试问，谁没有维护糟糕系统的痛苦经历？谁们的系统维护了数年通过数次升级后还能维护？在需求分析与设计阶段，可支持性实际上体如今，咱们是否能有效识别系统可变的需求，并可以提供合理的方案。这体现的也是架构师的功底。一次分析和设计ERP软件的时候，我发现应付单须要生成凭证，随后又发现应收单、采购单、销售发票都要生成凭证。既然这么多单据须要生成凭证，是否还有其它咱们还不知道的单据也要生成凭证，是否能够有一个统一的接口。果不其然，核销单、工资单、固定资产核定都须要生成凭证。最后咱们设计成了一个统一的生成凭证接口。还有一次，咱们发现客户报表在查询SQL、过滤条件、显示列等部分常常变，所以设计成一套可配置的报表系统，大大提升了系统可维护性。

  17.需求列表

需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，从此要开发的这个系统应当提供给他们的各项功能。

首先，需求列表不掺杂咱们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。从用例模型到领域模型咱们不难发现，它是一个分析与设计的过程。需求分析员对业务需求进行捕获、认识、理解之后，须要结合软件专业知识进行分析设计，还要听取系统架构师和设计师对需求可行性的分析，最后才整理和编写出用例模型。在这样一个过程当中，随着业务需求复杂度的提升，以及各类技术分析的掺杂，最终的结果颇有可能偏离原有的业务需求。这种偏离经常表现为对业务需求正确性与完整性的偏离，即需求已经变味儿了，或者某些需求项目缺失。需求列表就是那个最开初的、最完整的、正确的业务需求。用这样一个列表来开始咱们的分析，最后用它来验证咱们的设计，使之成为咱们的分析设计之旅树立的一个正确的航标。有了这样一个航标，就可使咱们最终可以到达一个正确的彼岸。

其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。一个纷繁复杂的、业务庞大的管理系统，通过整理之后，被分解成一个一个的需求项目。每一个需求项目是一句简明扼要的话。简明扼要意味着清晰易懂；分解成需求项目意味着分解复杂问题为简单问题。每一次与业务人员讨论完业务需求之后，咱们就整理成这样一个需求列表，使咱们与客户的讨论都有一个清晰明了的讨论结果。当下一次与业务人员讨论时，咱们拿出咱们上一次讨论的需求列表，又使下一次的讨论有一个基点，使业务讨论能以演进的方式推动下去，提升咱们的工做效率。

然而，需求列表中应当剔除那些客户对系统设计的内容。前面咱们提到，客户，特别是那些对信息化建设有必定经验的客户，容易提一些对系统设计的指望，好比什么功能应当作成什么样子，功能界面是怎样的。客户提的这些意见，也许不是最佳的，咱们通过深刻的分析设计之后，可能会提出一些更加合理的方案。所以，这样内容不能成为咱们验证系统功能的基石，于是不该当写入需求列表中。需求列表描述的更应当是客户对软件功能的意图，即客户使用这个功能所达到的目的，而不是功能的具体实现。这一点咱们在后面经过具体实例详细说明。

  18.一个需求列表的实例

这是一个公司内部的评审系统，它分为制订评审计划、执行评审、制做评审报告与问题跟踪四部分。通过初次与评审人员的业务讨论之后，咱们整理出这样一个需求列表：

1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工做量，发起一个评审任务。
2．评审者在收到邮件后，进入评审任务中，对评审内容进行评审，同时填写并提交各自的评审意见。
3．评审组长汇总全部的评审意见，并在评审会上依次过全部的评审意见，对评审意见进行修改或删除，填写问题跟踪，造成这次评审会上最终的评审意见及问题跟踪表。
4．评审组长制做评审报告，并造成评审结论，以邮件的形式通知全部评审者。
5．全部评审者对评审报告进行回复意见，若是都选择赞成，评审组长关闭这次评审。
6．评审组长跟踪全部问题，并能够依次关闭每一个问题。

固然，在这个需求列表中，客户提出了一些名词，好比评审计划、评审意见、评审组长等。咱们在整理需求列表的同时，应当注意整理这些名称，弄清它的内涵外延，以及它们相互之间的关系、做用。这将为咱们后面的领域模型分析提供素材。毫无疑问，这样的需求列表过于粗略。于是在后面的业务讨论中，咱们逐项对它们进行了细化：

1．评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工做量，发起一个评审任务。
1.1 评审时间应当分为数个阶段分别制订时间计划，如评审准备、评审会议、评审报告；
1.2 评审内容应当能够上传数个文件，分别描述文件的内容、做者、编写日期、版本号，供评审者下载与查看；
1.3 填写评审者时，选择一个评审者为评审组长，评审发起人不能是评审组长；
1.4 评审地点与预计评审工做量只需直接填写；

在咱们后面的用例分析中，咱们对这段需求列表进行了大量的分析设计。但这些都是设计与实现，它们会出如今后面的用例分析及其模型中，却不该出如今需求列表中。在后来的升级开发中，客户又提出了发邮件通知的功能。将该功能描述出来，并添加到需求列表中：

1.5 评审计划提交之后，以邮件的形式发送给每一个评审者，通知该评审任务。

有了这样的需求列表，当需求分析工做完成时，咱们将一项一项检查用例模型是否知足需求列表的内容；当软件开发完成时，咱们将一项一项检查软件功能是否知足需求列表的内容；当用户验收时，咱们一样使用需求列表，一项一项检查咱们的软件是否知足用户需求。

  19.快速原型法

咱们就应当在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，而后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐做法。当咱们捕获了一批业务需求之后，就当即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求之后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。

原型开发的快速与模拟到什么程度，是一对矛盾，咱们要去把握。要快速开发，必然不可能和最终交付的软件系统如出一辙，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。所以，模拟到什么程度是关键，既能说明问题，又不耽误时间。根据个人经验，通常能拿出界面，并能够走通关键性流程就能够了。一些快速开发平台为快速原型法提供了可能。

当用户拿到原型能够本身操做时，需求研讨的气氛当即变得不太同样了。当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。这时候的需求，就再也不是枯燥无味的文字游戏，而是生动形象的图形界面。往后，若是项目采用迭代开发，让用户看着软件一点儿一点儿地成长，这又是多么美妙的体验啊。与此同时，你与用户的信任也在一步一步创建起来，软件风险在下降，项目将朝着正确方向前进。

快速原型法是美妙的，它给你与用户带来了从未有过的体验。但美妙的同时，也会带来一些的尴尬，没必要要的误会，咱们必定要注意。最多见的误会就是让用户将原型误觉得最终交付的系统。开发一个系统须要持续数月，但你倒好，几天就搞定了，为何还要在这个系统上投入大量资金呢？若是对方领导开始有这样的想法时，双方就开发费用进行的谈判就有一些不妙了。因此在给用户看到原型前，必定要跟用户解释清楚。

  20.需求规格说明书

理论上讲，需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。可是，我认为，用户需求规格说明书与产品需求规格说明书的差异并不大。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达你们都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。

那么需求规格说明书怎么写呢？不一样的公司、不一样的人、不一样的项目，特别是在需求分析中采用不一样的方法，写出来的需求规格说明书格式都是不同的。在这里，我给你们一个，采用RUP统一建模的方式分析需求，编写需求规格说明书的模板，供你们参考。

1．引言
1.1 编写目的
如题，描述你编写这篇文档的目的和做用。但最关键的是，详细说明哪些人可使用这篇文档，作什么。需求规格说明书是用来作什么的？毫无疑问，首先供用户与开发公司确认软件开发的业务需求、功能范围。其次呢，固然就是指导设计与开发人员设计开发系统。固然，还包括测试人员设计测试，技服人员编写用户手册，以及其它相关人员熟悉系统。描述这些，能够帮助读者肯定，阅读这篇文档是否能够从中得到帮助。

1.2 业务背景
描述业务背景，是为了读者了解与该文档相关的人与事。你能够罗列与文档相关的各类事件，也能够描写与项目相关的企业现状、问题分析与解决思路，以及触发开发该项目的大背景、政策法规，等等。

1.3 项目目标（或任务概述）
就是项目能为用户带来什么利益，解决用户什么问题，或者说怎样才算项目成功。前面提到过，这部分对项目成功做用巨大。

1.4 参考资料
参考资料的名称、做者、版本、编写日期。

1.5 名词定义
没啥可说的，就是文档中可能使用的各类术语或名词的定义与约定，你们能够根据须要删减。

2．总体概述
这部分是对系统总体框架性地进行描述。

2.1 总体流程分析
绘制的总体行动图，及其对它的说明。

2.2 总体用例分析
绘制的总体用例图，以及对每一个用例的用例说明。若是项目比较大，存在多个子系统，能够将用例图改成构件图，详细描述每一个子系统及其相互的接口调用。

2.3 角色分析
一个用例图，描述系统中全部的角色及其相互关系。在随后的说明中，详细说明每一个角色的定义及其做用。

这部分还能够根据项目须要编写其它的内容，如部署方案、网络设备、功能结构、软件架构、关键点难点技术方案，等等。

3．功能需求
3.1 功能模块（子系统）
一个一个描述系统中的每一个功能模块（或子系统），即总体用例分析中的每一个用例。这部分是需求规格说明书最主要的部分。

3.1.1 用例图
绘制该模块的用例图（详见《功能角色分析与用例图》）。

3.1.2 用例说明
对用例图中的每一个用例编写用例说明（详见《用例说明》）。

3.1.3 领域模型
为用例绘制领域模型，并编写领域模型说明，对每一个实体进行说明。对实体的说明包括对实体的定义、属性说明、行为说明、实体关系说明等等。若是实体间关系复杂，还要使用对象图说明实体关系的全部状况（如《领域驱动设计》中的描述）。

4．非功能需求
这里描述的是软件对非功能需求的通常要求，即总体设计原则。那些与具体功能相关的非功能需求应该放在用例说明的“非功能需求”部分（详见《非功能需求》）。

5．接口需求
若是项目涉及到与外部系统的接口，则编写这部分需求。
5.1 接口方案
详细描述采用什么体系结构与外部系统的接口。
5.2 接口定义
接口的中文名、英文名、功能描述、参数、返回值、使用者、使用频率，等等。

  21.评审与签名确认会

，用户对需求的变动只发生在某些固定的范围内，弄清楚了这些范围，咱们的问题就迎刃而解了。

1. 总体需求不变，具体细节变化。咱们说需求是分层次的，总体框架、功能模块、每一个操做的细节。若是用户变动到了将整个框架都推翻了，这个项目就别作了。因此总体框架是必须在需求分析阶段完成的，是往后不可能改变的。功能模块可能要变，但一般是某个部分在变，而更多的是那些具体操做的细节在变。

2.  界面风格与操做易用性是最容易发生变动的。咱们说用户看到软件之后不满意，其实主要是对界面风格与操做性不满意，而不是软件功能。界面不够美观，操做不方便，不符合用户的操做习惯，都是形成用户不满意的地方。

3.  增长其它功能。软件是对现实的模拟，而现实也是复杂多变的。咱们与用户在进行业务流程分析时，也许一些流程没有考虑到，或者还有特殊状况须要处理。这些是客户要求增长功能的主要动因。

通过以上分析，需求分析阶段要作到什么程度就能够清楚了：总体框架与功能模块必须肯定下来，至于各个功能模块下的具体操做，尽可能作，能到什么程度先到什么程度。至于界面风格与操做性，咱们能够在往后迭代开发的每一个迭代期，拿出样品之后再与用户确认。

OK，万事俱备只欠东风，当全部工做都完备之后，咱们的需求分析工做开始进入最后收尾的阶段。咱们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。

需求评审会的主要目的就是确认需求，以便以此开始咱们的设计开发工做。从理论上说，需求评审会应当由用户表明，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不一样角色的人汇集在一块儿开会是不现实的。所以，咱们能够将需求评审会分为内部评审会与外部评审会两部分来开比较现实。

处理外部问题，必先要从内部统一思想。先召开一个内部评审会，听听系统架构师、设计人员、测试人员、QA经理对需求分析工做的意见，而后由领导讲讲话，布置一下后面的工做，是十分有必要的。按照个人经验，系统架构师这时的做用至关重要，他应当仔细阅读需求，仔细思考技术是否可行，以及预测该系统是否可以达到用户方领导对该项目制订的目标。若是答案是否认，当即进行调整。

最后就是与用户的外部需求评审会了。外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能彻底抑制住用户的变动，但至少从很大程度上抑制住了用户的大改。然而，在召开外部需求评审会以前，咱们建议你们就需求规格说明书，先与各个单位或部门的用户表明讨论并肯定下来，避免在最终的签字确认会上出现分歧，影响工做进度。毕竟你们都不容易，工做一大堆，聚在一块儿不容易。

通过数月的分析讨论，最终在一片和谐的气氛中，双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，仍是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析一定起到决定性的做用，一定为往后的软件开发扫清了许多许多的地雷。

  最后，本文内容部分来自http://blog.csdn.net/yqmfly/article/details/7679781