体验需求分析

●需求管理的重要性：

  ◆在软件工程中，软件生命周期大体包括需求分析、设计、编码、测试、验收与运行、维护升级等几个阶段，需求分析是软件开发的第一要务；

  ◆实际开发中，一个项目的成败与否往往取决于它是否符合需求，对需求及需求变更的管理是项目成功最关键的因素；

  ◆有句俗话叫 "三岁看小. 七岁看老’，软件项目也是这样。 一个项目成功还是失败，往往在需求阶段就决定了；

        eg："南辕北辙" ，假如客户想要建一座烟囱, 结果你把客户提供的图纸拿反了，挖了一口井。 井挖得再好也是枉费人力，别指望客户会给你钱；

  ◆了解客户需求并不是，沟通能力很强就肯定能做好，软件需求的调研、需求的表达和需求的变更管理等是专门的技术，需要专门的方法和技巧。作为软件工程师，绝不是写好代码就可以了，能够迅速地、准确地理解户需求也是一项必备的技能；

  ◆有时候，软件开发人员经常困惑于软件分明是按照需求做出来的，可是为什么客户仍然不满意，客户总是在困惑为什么软件和自己想要的差距会那么大，这一现象的起因究竞是什么？问题是怎么产生的，又该怎么解决呢？

  ◆软件项目的需求管理包括需求调研、需求分析、需求变更管理等几个方面的工作，在需求调的过程中，可能遇到以下几种典型的情况：

     ★1、客户知道自己要什么，但表达不清：

         ☉如果客户有自己的 IT 团队, 那么情况稍好. 大家讲相同的 ’语言’, 沟通会相对顺畅, 但更时候. 我们需要和不懂软件技术的客户交流， 客户知道哪些数据和信息需要通过软件系统管理，软件系统需要给业务什么样的支持，但他们只能用自己行业的语言来表达。这时候首先需要我们对其行业和业务都要有一定的了解，然后才可以设计信息系统 （静态 Demo) , 并让客户确认。

　　　☉任何一个具有一定规模的信息化系统都会涉及很多人，很多岗位和角色。在调研的时候，对着些人我们都需要访谈. 每个岗位都有自身的立场、 眼界和

利益 . 对系统需求的描述也会出现相左的情况，这也是需要权衡处理的；

      ★2、客户不知道自己要什么：

           ☉有的时候，客户期望通过信息化系统提高企业的效率，但对具体怎么做就了解不多了。这候需要我们主动地发掘需求. 同时对我们的行业经验也是一种考验。

　　　　　　例如，一位客户想要买一电钻. 如果你是售货员，你直接给客户电钻没有错. 但如果你是做需求分析的，那么可以看以这段对话：

　　　　　　　　　　客户：我要买个电钻

　　　　　　　　　　需求分析人员：你要电钻做什么呢？

　　　　　　　　　　客户：我要在墙上打个洞

　　　　　　　　　　需求分析人员：你为什么要在墙上打洞呢？

　　　　　　　　　　客户：因为我卧室没有网线插头，我要把网线从客厅引过来；

　　　　　　　　　　需求分析人员：那我推荐你买个无线路由器吧；

　　     ☉其实很多时候在与客户沟通时，客户的描述并不是准确、完整的。像上面的客户真实需求是在卧室也能上网，而他的描述却是要一个电钻，如果不深入挖掘，两者很难牵扯到一起；

      ★3、客户的需求是动态变化的：

           ☉对于一个大型而复杂的软件系统，客户很难精确.完整地提出它的功能和性能要求.一开始能只能提出一个大概、模糊的功能，只有经过长时间的反复认识才能逐步明确。有时进入设计、编码阶段才能明确，更有甚者，到开发后期还会提新的要求，这无疑为软件开发带来困难；

      ★4、客户期望靠软件系统的实施，提高企业管理水平：

            ☉一般来讲. 软件系统是用来辅助企业管理的。随着中国经济的发展，市场对企业的管理水平提出了更高的要求。很多企业将实施信息化系统当作一个契机.希望能借此提高企业的管理水平，这时候往往涉及 ’企业流程改造’ 的工作。如果我们的行业积累比较雄厚，则可以给客户一定的议；否则，我们可以建议客户先做一个企业管理咨询的项目，完成企业的制度，然后们进行软件系统的需求调研。

　　　　☉在软件工程发展过程中，在相当长的时间里人们一直认为需求分析是整个软件过程中最简单的一个步骤，编码才是最重要的。但在过去几十年中，越来越多的人认识到需求分析是整个过程关键的一个过程，相反编码则是最容易的。假如在需求分析时未能正确地认识到客户的需求，那么最后的软件是不可能达到客户的要求的。必然会引起大量的返工，这样势必无法在规定的时间内完成工作，最终可能导致无法交付而失败。

　　　　☉在软件开发过程中，客户自身的组织结构、业务流程、软硬件环境等都可能发生变化，当软系统开发到一半的时候需求忽然变了，这对开发者可能是致命的。需求变更是软件项目中最大、后果最严重的风险! 如何管理好项目需求的变更，也需要专门的技术；

★综上所迷. 需求管理的工作至关重要，必不可少；

●要明确客户的需求，首先要开展需求调研工作；

 ●需求调研时要明确以下问题：  ◆调查组织机构情况，包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程做准备；

　　◆调查各部门的业务活动情况 . 包括了解各部门输入. 使用什么数据，如何加工处理这些数据，输出什么数据，输出到什么部门、输出结果的格式是什么等；

　　◆协助用户明确对新系统的各种要求，包括信息要求、系统要求、处理要求、安全性和完整性要求等；

　　◆确定新系统的边界，确定哪些功能由计算机完成或将来准备让计算机完成， 哪些活动由人工完成，由计算机完成的功能就是新系统应该实现的功能；

●需求调研的方式包括问卷、访谈、现场体验、需求会议等；

  ◆问卷：

　　★在需求调研时,当用户无法准确表达和描述自己的真实想法时，可以通过调查问卷的方式，这种方法方式可以通过一些具有启发性的问题挖掘用户的真实需求，如果调查表设计得合理，这种方法就很有效，也很易于被用户接受。但要注意在设计问卷时要明确问題的目的，每一个问题都要通过精心设计才能获得有价值的信息；

  ◆访谈：

      ★在需求调研时，访谈是必须经历的过程，分析人员应该与各种层次的客户进行充分的交流和沟通，包括决策领导、使用部门的领导、具体使用人员、系统维护人员等，在访谈时，要明确每次谈的目的和目标、客户也很忙、频繁的，漫无目的的访谈会引起客户的反感。另外，在做访谈时，需求分祈人员要注意聆听和记录，要尊重客户的需求；

  ◆现场体验：

      ★对于一些复杂系统，客户可能很难准确地描述其中的业务，这时就需要需求分析人员亲身参业务工作，了解业务活动的情况。同时也可以请求查阅与现有工作相关或与原系统相同的数据记录，包括原始数据、账簿、报表等。但这些数据如果涉及企业商业机密，则必须征得主管领导的同意并为客户保密，这种方法可以比较准确地理解客户的需求，但比较耗费时间；

   ◆需求会议：

      ★在需求调研开始时，可以召开需求会议，请客户的需求各方参与，通过座谈了解业务活动情况及客户需求。在座谈时，参加者之间可以相互启发。另外，在需求调研经过一个阶段后也可以召开需求会议，对已经获得的需求进行确认，并告知客户后续的调研计划，这样可以避免因前面不正的结论影响后续的需求调研工作。在召开需求会议前，要明确会议需解决的问題 . 并做好充分的准备，不要让会议流于形式或脱离主题；

☉在需求调研结束的时候，我们需要得到一个准确的，经过客户确认的需求规格说明，需求说明书经过客户确认后，成为下一个阶段设计和开发的重要依据，是项目组成员理解需求的最主要的工具；

●在充分调研的基础上. 就可以开始定义需求了， 我们往往需要在软件项目实施合同中，明确定义要给客户做一个什么样的系统，客户要支付多少钱给我们。如果这时候对系统需求定义得不明确往往会引起纠纷或造成损失。如何明确甚至精准地定义需求，也需要专门的方法；

●需求规格说明书作为产品需求的最终成果必须具有综合性、必须包括所有的需求。开发人员和客户不能做任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明书，那么它将不能作为协议的一部分并且不能在产品中出现；

●需求规格说明书阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础. 也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为，除了设计和实现上的限制。需求规格说明书不该包括设计、构造、测试和工程管理的细节；

●近年釆，随着软件工程的不断成熟，在一些 Web 开发中，有人提出不需要编写需求规格说明书，而使用原型代替， 采用快速迭代不断完善系统功能的思想。 这种做法符合敏捷开发的要求，在一些企业自已开发的系统、小型系统或简单 Web 应用开发时，合理使用确实可以提高开发效率。但对于大型的、复杂的系统或参与部门和人员众多、开发周期较长的系统，还是要有完善的需求规格说明书；否则在开发后期可能会出现需求混乱、项目管理失控的局面；

●需求规格说明书模板是编写软件需求文档定义的一种标准模板。该模板为记录功能需求和各种其他与需求有关的重要信息提供了统一的结构；

  ●结构如下：

1、综合描述：

      1）、软件的概述：这里需要描述软件的背景。例如，软件是否是目前正在使用的软件的升级版本，是否是某个大型系统的新增部分，是否与其他系统存在某种联系等

　　2)、产品的功能：这里不是详细描述软件的功能，而是从业务层面描述软件的主要功能即可. 也可以采用图形的方式表现。

　　3)、用户及特性：需要确定使用该软件的用户类别，并且描述他们的特征，往往有些功能只和某些用户相关户，权限管理只和超级管理员有关，普通用户不涉及权限管理，再如，用户有没计算机操作基础，这决定了后续软件要满足易操作性和要为用户提供必要的培；

　　4)、运行环境：需要清楚软件运行的环境，一般包括以下几个方面：

    　  　★硬件平台

　　　　★操作系统及其版本

　　　　★支撑系统，如数据库的类型和版本

      ★与该软件共存的应用程序

 　  5)、设计和实现上的限制：设计和实现上的限制主要用于限制和规范软件开发人员，例如：

　　　　★必须使用的特定技术、工具、编程语言和数据库

　　　　★不能使用的特定技术、工具；

　　　　★必须遵守的开发规范和标准

 2、外部接口需求：

　　　1)、用户界面：描述用户界面上的软件都包含哪些组件，描述每一个用户界面的逻辑特征，而不是用户界面，内容如下：

　　　　　　★将要采用的界面标准

　　　　　　★有关屏幕的布局或者限制

　　　　　　★界面上组件的使用，如按钮、选择框、导航、菜单、消息框、快捷键、以及这些组件对齐方式、错误信息显示标准等

　　　2)、硬件接口：描述软件与系统硬件接口的特征，内容如下：

　　　　　　★支持的硬件类型

　　　　　　★软、硬件之间通信的数据

　　　　　　★使用的通信协议

　　　3)、软件接口：描述软件与其他软件的联系，内容如下：

　　　　　　★操作系统

　　　　　　★数据库

　　　　　　★工具

　　　　　　★第三方组件

　　　　4)、通信接口：描述软件所使用的通信功能相关的需求，内容如下：

      　　　　★电子邮件

　　　　　　★浏览器

　　　　　　★网络通信标准

3、系统功能性需求：

　　★功能性需求用来描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响及特定条件下系统的行为。对于功能性的系统需求.需要详细地描述系统功能、输入和输出、异等。功能性需求取决于软件的类型、软件的用户及系统的类型等；

　　★系统的功能性需求应该具有全面性和一致性，全面性即应该对用户所需要的所有服务进行描述，而一致性则指需求的描述不能前后自相矛盾，在复杂的大型系统中，做到这两点都会有一定的困难，但只有做到了这两点。才能保障项目的顺利进行；

　　★系统的功能分析一般会很复杂，用文字描述很难表述清楚，一般需要一些专用的图像和文档助描述。

4、非功能性需求：

　　★非功能性需求是指那些不直接与系统的具体功能相关的一类需求，它们与系统的总体特征相关，如可靠性、可扩展性、安全性、响应时间等，甚至包括界面易用程度和文档及代码规范性的要求，非功能性需求定义了对系统提供的服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。它源于用户的限制，包括预算的约束、机构政策、与其他软硬件系统间的互操作，以及如安全规章、隐私权保护的立法等外部因素；

      ★与关心系统个别特性的功能性需求相比，非功能性需求关心的是系统的整体特性，因此对于统来说，非功能性需求更关键。一个功能性需求得不到满足会降低系统的能力，但一个非功能性需求得不到满足则有可能使系统无法运行；

　　★非功能性需求不仅与软件系统本身有关，还与系统的开发过程有关。与开发过程相关的需求包括在软件过程中必须使用的质量标准的需求，设计中必须使用的建模工具的需求，以及软件过程所必须遵守的原则等

　　★按照非功能性需求的起源，可将其分为三大类——产品需求、机构需求、外部需求，进而还以细分。产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。

　　　　　  　◆非功能性需求的分类如下表：

●需求是一个详细地描述一个应用程序外在的功能和特性。需求应该是清晰的、完整的、详略得当的、紧密的、可获得的和可测试的；

　　◆来看下面两项需求的描述：

　　　　1)、实现用户的增、删、改、查功能

　　　　2)、本系统需要较高的反应速度和一定的可扩展性。

    　　　　 分析：开发工程师可以根据第一条需求的描述，完成数据库的设计并完成程序编码吗?验收系统时，如果客户对系统的反应速度不满意而拒绝支付合同余款，这份需求规格说明书可以帮开发者解决纠纷吗？

        ◆再看看下面两条需求描述：

  　　   1)、用户信息包括用户编码 (系统自动生成的流水号)、用户名、用户部门、用户密码和用户状态。系统需要提供用户添加的功能，用户名、用户部门和用户密码为必输项；密码不能少于六位，新建后，用户状态为 ‘正常’。 系统提供用户信息修改的功能，除用户名和用户状态外的信息都可修改。系统需要提供删除用户功能，删除用户时，仅把用户状态改为 ’已删除’。并不物理删除数据，系统需要提供用户查询功能，可以根据用户名和用户部门查询，用户名支持模糊查询，用户部门查询条件可以从下拉列表框中选择输入；

　　　　2)、系统性能的需求是在网络正常情况下 , 主要页面响应时间不超过 5s, 大批量业务或复杂计算业务响应时间不超过 30S。随着系统业务数据规模的增长, 系统要满足两年内业务量发展的需求，并满足上述性能要求。系统扩展性的需求是采用三层架构，采用 MVC设计模式, 代码规范易读，据库设计在不严重影响性能的基础上符合第三范式，命名规范，并有注释。交付系统的同时交付系统的概要设计文档和详细设计文档 (含数据库设计文档)；

●以上两种形式，显然是第二种方式更容易编写代码。所以我们要以有用的和有效的方式决定和组织一项详细的需求描述。在描述需求过程中，需要涉及一个项目中所有与“用户”相关的各个方面。 此处的 “用户’ 涉及所有与项目有关系的相关人员，包括公司内部和外部的支援，以及最终的用户、可接受测试人员、用户的合同签订者、软件维护工程师、用户管理员、销售人员等；

●需求规格说明书所具有的特征：

 　  ★完整性：每项需求都必须描述清楚将要实现的功能 以使开发人员获得设计和实现这些功能所需的全部必要信息；

　　★正确性：每项需求都必须准确地陈述其要开发的功能。如果软件需求与对应的系统相抵触，那么该项需求是不正确的。只有用户才能圈定用户需求的正确性，这也是一定要用户积极参与的原因，没有用户参与的需求，评审可能是评审者自己的猜测；

　　★可行性：每项需求都必须是在已知系统和环境的限制范围内能够实施的。为了避免不可的需求，最好在获取需求过程中，始终有一位软件项目组成员与需求分析人

员或销售人一起工作。这名项目组成员负责检查技术的可行性；

　　★必要性：每项需求都应记录客户真正所需要的和最终系统所需遵从的标准，也可以理解每项需求都是用来授权编写文档的根源。每项需求应该都能回溯到用户的某项输入；

　　★划分优先级：为每项需求、特性或使用实例分配一个实施优先级，以指明它在特定产品中所占的分量。如果把所有的需求都视为同等重要，那么项目管理者在开发或节省预算或调度中，可能会无法舍去，丧失控制；

　　★无二义性：所有阅读开发文档的读者对每项需求说明都只能有一个明确统一的解释，由于自然语言容易引起二义性，因此尽是使用简洁明了的语言描述每项需求，避免二义性的效方法包括对需求文档的正规审查、编写测试用例、开发原型. 以及设计特定的方案脚本；

　　★可验证性：检查每项需求是否能通过设计测试用例获取它的验证方法，如用演示、检测等方法确定产品是否确实是按照需求实现的。如果需求不可验证，则确定这项需求是否正确就会成为主观臆断，而非客观分析. 对于一份前后矛盾、不可行或有二义性的需求也是不可验证的；

●怎样才能编写出一份合格的需求规格说明书呢？以下是编写需求规格说明书的要求，在编写时满足这些要求就会写出合格的需求文档， 同时也会开发出更好的产品；

 　　 1、基本要求：在编写需求规格说明书时.对于需求的描述应坚持遵循下面的要求：

　　　　1）、详细：足以指导开发。文档的内容要完整、详尽、不得有遺漏；例如，对于 ‘ 歌曲的字数由系统自动算出’的需求，应明确描述中文、英文的不同实现方法；

　　　　2）、明确、无二义性：对所有阅读本文档的读者来说，每个需求说明都只能有一个明确统一解释， 尽量用简洁明了的自然语表达每项需求，避免二义性。

　　　　　　例如，在需求 “歌曲次数可以不由用户输入" 中，因为出现了 “可以" 字样， 可能会使读者产生二义性，所以无判断到底是否需要输入；

　　　　3）、以客户为中心：从客户使用的角度出发编写每项需求时，语言要简明扼要。既不要喋喋休，也不要描述不清。例如，描述当系统提交成功的处理时，不需要详尽到给出系统的提示信息 "恭喜您“提交成功了；

　　 2、语言规范：在软件需求规格说明书中，语言的描述要符合以下规范：

　　　　1)、使用简洁、简单、直观且用户可以理解的语言，不要出现晦涩难懂的描述；

　　　　2）、避免使用导致含糊或者读者不清楚的主观词汇。在需求规格说明书中，对需求虻描述要详细、具体、可量化、可实施，不要出现如容易、筒单、有效、快速、几个、很快、全面等不准确或宽泛的词汇；

　　　　3）、避免使用计算机专业词汇，为了保证文档的可读性，尽量不使用计算机专业术语. 例如使用业务逻辑层添加数据；

●功能性需求一般采用用例 (US Case) 的平式进行直观描述，它是一种图形化的描述方式，方便用户 “看懂’。用例是一种描述系统需求的方法， 使用用例的方法描述系统需求的过程就是用例建模；

●用例：

  ★我们在做需求调研的时候, 需要回答这些问题: “这个系统涉及哪人? 他们对系统有什么期望？

　　　eg：用一个生活案例思考这些问题；

         ☉我们大多数乘客都使用过一卡通自动售票机，其使用者是乘客，乘客主要利用售票机投掷硬币，获得交通卡；

　　   ☉“投掷硬币“、“获得交通卡" 是售票机提供给乘客的服务，这就是我们所说的用例。用例完全是站在用户的角度上描述系统的功能。

　　   ☉乘客是自动售票机的使用者，就是用例中的参与者 (Actor )；

         ☉用例是如何定义的？

   ★用例的定义是与系统使用者交互的，并且为使用者提供可观测的、有意义的结果的一系列活动的集合。简单地说，用例描述了这个系统有哪些人要用，以及每个人是怎么用的；

   ★用例常被用来描述一个系统外在可见的需求情况，常被用于项目的需求阶段，对项目的测试计划和用户指南也有用处。它们被用来创建和验证设计，并确保该设计满足所有的需求；

   ★这里，我们使用用例描述系统的功能性需求：

　　▲在软件开发项目的需求分析阶段，用户对系统的使用方式决定了系统如何设计和建造。所以 "用户的观点出发" , 对帮助分析人员理解用户需求，建立可用的系统是非常重要的；

　　▲用例定义了外部实体 (执行者) 启动系统时，执行或完成的特定功能或过程，它描述系统应该做什么；对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能，用例可以解释为一系列完成一个特定目标的 ‘功能“ 的组合，针对不同的应用场景，这些“功能”体现不同的组合方式，实际上.把用例解释为某个参与者要做的一件事可能更为合适。用例是一种沟通的工具，使最终用户和开发人员可以使用它进行交流，并在系统需求上达成共识。

●用例图 (Use Case Diagram) 是由参与者、用例、以及它们之间的关系构成的图；

  ★系统中出现的各种事务处理或过程的图形，或者表达系统能够执行的各种功能。图形表示不仅包括过程，而且包括各种使用这些过程的人或元素，以及他们与这些所谓系统过程的交互的方式；

  ★下图是“易买网”的后台管理系统的用例图, 当管理员登录进入后台后，可以进行用信息管理、商品信息管理、订单管理、留言管理、新闻管理操作；

●用例图是一种 UML (Unified Modeling Language, 统一建模语言) 图, 要理解厍例图我们需理解以下几个概念：系统、参与者、用例、箭头。

●用例模型包含的要素，用例图的各个组成部分如下：

　　1、系统：系统是用例图的一个组成部分，它代表的是一个活动范围，而不是一个真正的软件系统。系统的边界用来说明构建的用例的应用范围；

　　　　★在用例图中，用矩形框表示系统的边界，系统的名字通常写在方框的里面或上面。

　　　　★系统边界就一个盒形结构，可将各种用例或系统的功能或过程封装到一个代表系统的边界表内。因此，系统是包含边界或盒子中的功能的集合；

　　　　★上面的图中圈起六个用例的框边界被称为系统边界，而六个用例正是系统有的六项功；

　　2、参与者：

　　　　★一般来说，参与者是扮演特定角色或描述特定特征的人。在我们的词汇中，参与者可以是启系统过程中的任何人、外部过程或对象，也可以是与系统功能有关的对象。因此该对象、过程或个人需要针对系统扮演特定的角色，这些因素统称为 "参与者"。一般情况下，参与者就是系统的用户。有时也是外部程序或系统；

            ★上面图中, 管理员就是参与者，在用例图中使用 "火柴棒人‘ 符号表示参与者；

      3、用例：

         ★用例定义了参与者启动系统时执行或完成的特定功能或过程。现在，所有这种由外部执行者，甚至由内部功能或其他过程启动的功能或过程，都可以通过用例表示。因此，系统是由所有这种例组成的；

　　   ★在上图中"登录"、"用户信息管理"、"商品信息管理"、"订单管理’、“留言管理’ 和 ’新闻管理"这六个功能是系统的六个用例，他们描述了系统的完整功能。用例图用椭圆形表示，它包含用或用例要执行的功能的名称，使用连接线连接参与者与用例；

          ★用例图的优势：

              ☉将重点放在系统的可能用户上；

　　　　  ☉确定用户与系统交互时要扮演的角色；

　　　　  ☉确定用户出于各自的角色，期望从系统中获得什么基本服务（用例）；

　　　　  ☉描述每个用户或角色与其期望从系统获得的服务之间的交互；

       4、箭头：

           ★箭头用来表示参与者与系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方；

●建立用例模型的步骤：

    (1)、清晰定义系统或系统边界。这将有助于将不同的元素归类为外部元素或内部元素，从而更易于查找参与者和用例 (参与者在系统之外，用例在系统之内)；

　  (2)、标识与各种过程或用例直接相关的参与者，这些参与者是启动系统的不同过程的元素，简单地说，是使用系统的人或对象。标识参与者后，就可以将各个用例明确地定义为参与者的更能或目标。定义每个参与者后，应该定义其目标。这一步是必需的，因为一旦列出每个参与者的目标，遗漏用例的机会就会非常小，或者说， 开发人员能够更方便地标识各个用例；

     (3) 标识各个用例。由于已经定义参与者及其目标，这一步便简化了。接下来只要定义符合这些目标的用例即可，这正是开发的主要目的，即设计满足用户需要的系统；

　  (4)确定用例和用例之间的关系。系统都包含一个或多个用例，当存在多个用例时，通常描述用例之间的关系；

●描述用例规约：

  ★在用例图中，每个用例只有一个名字，拿用例图当作需求规格文档还远远达不到“明确”的要求，这是因为我们还有一项工作没有做. 那就是详细描述每个用例，即用例规约；

  ★用例规约主要包含下面内容：

 　  1、前置条件：前置条件指执行用例之前，系统必须所处的状态。

　　2、事件流：事件流 (Flow of Events) 包含基本事件流和备选事件流、事件流应该表示出所有场景；

　　3、后置条件：后置条件指用例执行完毕后，系统可能处于的一组状态。

　　　　eg：以“易买网“的 “用户登录’ 用例为例：讲解如何详细描述一个用例；

　　　　　　★前置条件：会员在“易买网“首页输入用户名和密码；

　　　　　　★基本事件流，内容如下：

　　　　　　　　　　▲会员在易买网首页输入用户名和密码，单击 " 登录“ 按钮时用例开始；

　　　　　　　　　　▲会员向系统提交用户名和密码；

　　　　　　　　　　▲保存当前用户信息在 "会话 (Session)"中；

　　　　　　★备选事件流，内容如下：

　　　　　　　　　　▲在基本事件流步骤 2 中，若会员提交错误用户名或密码，则系统提示用户名密码错误，转至本事件流步骤1；

                   ★后置条件，‘会话“ 中保存了已登录用户的信息：

                    　　    ▲前置与后置条件。前置与后置条件表示用例开始和结束会发生什么。即在用例开始时系必须处在什么状态 (前置条件), 或者在用例结束时系统必须处在什么状态 (后置条件)，不管紧随用例之后是哪一个分支或选择，后置条件必须为真；

                   　　     ▲事件流。事件流包含基本事件流和备选事件流；

                        　　　　☉基本事件流描述的是该用例最正常的一种场景，在基本事件流中系统执行一系列活动步骤，响应参与者提出的服务请求；

　　　　　　　　　　　　☉备选事件流负责描述用例执行过程中，异常的或偶尔发生的一些情况；

　　■从参与者的角度来看，事件流是一系列陈述句，它列出了用例的各个步骤：告诉我们它如何始，使用一个像 “当……时，用例开始” 的描述. 如果用例是为软件做的.那么软件如何知道什么时候用例开始？同样地，用例如何结束？这可以使用如 "用例结束’ 的短语清晰地陈述它。

　　■事件流包含顺序、分支和循环三种结构。使用分支可以表示选择。当需要重复一个或者一系列步骤时，可以使用循环。要清楚地指出循环在哪里开始和在哪里结束，还要清楚地指出将如何结束，它可能因为已经到达这一系列的终点而结束，或者有些条件导致了循环的结束；

　　■当详细描述了每一个用例时，我们的需求规格说明书也就完成了。一般在需求规格说明书功性需求的部分，我们会首先放上系统级的用例图，然后对逐个模块进行描述，采用规范的模式详地描述每个用例。

　　■以上就是我们得到软件需求的方法