第二章 需求获取与分析(下)

第二章 续---小张

2.5         需求说明书

       需求获取的主要成果就是需求说明书。需求说明书是用户对其想要的系统功能、性能、使用人员、使用方式的综合性要求。需求说明书通过上述的需求获取过程获得，通常也不是一次到位的，允许有不断的反复和完善。

       需求说明书一定要描述清楚用户的需求，用户也需要通过签字、会议等形式对该需求说明书进行确认。如果可以的话，最好是要用户的签字。签字的目的有二：（1）人们通常对于自己要签字的东西格外慎重，通过签字来约束他，能够尽量使得用户认真思考需求，避免乱写一气。（2）能够在以后万一（不怕一万，就怕万一）出问题的时候，防止用户不认账，对于自己认可的需求又进行推翻，这也是个良好的保护手段。

       需求说明书包括什么内容呢？主要的内容应包括：

（1）        系统的范围，也就是系统的功能描述。

（2）        用户的类型，倒是是哪些人在使用这个系统。

（3）        业务的流程，即这些人以什么方式，按照什么流程来做哪些事情。

（4）        数据的格式，即作的这些事情包括哪些信息和数据

（5）        系统的性能要求，即可以接受的系统响应时间，系统的用户数量

（6）        系统的可扩展性，即系统能够支撑多长时间，以后的扩展性如何，扩展规模多大。

（7）        对系统安全的要求，对于用户身份认证的方式，对于数据安全的要求，对系统稳定性的要求。

需要和用户声明的一点就是，用户总是希望系统月稳定越好，越快越好，性能越强越好，功能越丰富越好，但作为开发方则要与用户进行沟通，说明成本、时间、功能之间的关系，帮助用户寻找到一个各方均能接受的平衡点，实现成本、时间、功能三者的最优。功能越复杂，性能要求越高、时间要求越紧，对应的成本和投入就越大，项目的风险也会越高。相信用户是能够在乙方的引导下，得到一个各方可接受的系统需求范围的。

       另外，需要注意的是，需求文档中的文字应描述清晰，没有二义性，最好的方法是进行评审，由用户方组织人员进行业务需求的把握，开发单位从技术角度判断需求中是否存在难以实现的部分。双方都评审通过后，签字确认需求说明书。

在需求说明书中，对于需求的内容赋予优先级，特别是在项目时间紧的情况下，采用迭代开发的方式，首先实现的是重要的需求，以便于解决主要问题。

       以后的需求分析、概要设计、详细设计、以及编码、测试等均要依赖于需求说明书了。这也就是所谓的“基线”，也是整个系统的基础，万丈高楼始于基础。笔者多次见到过在开始阶段业务需求没有研究清楚，没有讨论清楚就匆忙上马的项目，最后往往一拖再拖，或者实现的系统并不是用户想要的。导致整个项目失利。

2.6         需求分析

       对于获取的需求，首先要做的事情就是进行需求分析，需求分析的形式有多种，可以以文字的形式，流程图的形式，用例图的形式等等，主要目的是要和用户将需求理解进行统一。也就是说能够使双方在需求理解上没有歧义。一般来讲，用户对于带有图形的需求分析会比较容易接受一些。

       通常来讲，用户对需求的描述和乙方技术人员对需求的理解是会存在一定的差异性的。这也就是搞技术的人员和非技术人员在理解系统方面固有的差异性。同样的一句话，不通的人，不同的角色就会有不同的理解，同一个人在不同的时候还可能理解不一致呢。这就需要系统分析人员能够具有良好的沟通能力，充分理解用户的需求描述，也能够很好的把用户的需求转化为需求分析，完整地传递给设计和开发人员手中。

       UML是做系统分析的常用工具之一，它的好处就是能够把系统需求转化为统一建模语言的方式，特别是用例图、系统时序图等能够让开发人员和用户都能看懂，这样把自然语言难以做到的。

       需求分析也需要和用户进行良好的沟通，向用户介绍、传递开发方对系统需求的理解，以及描述系统可能会做成什么样子。良好的沟通就能够尽量的减少后续的问题。另外，为了提高系统需求获取和分析的效果，可以使用前面讲到的原型系统的方式来尽可能的减少理解差异。

2.7         原型系统

       这里的原型系统不像实际系统那样，对于系统有严格的要求。而它的作用只是让用户能够更直观的感受到未来的系统的模样。因此，可以通过一些很快速有效的方法来展现给用户。比如，简单的方式是在纸上画出来系统的大致界面，说明系统该怎么操作；或者使用工具，画出可能的系统界面，再向用户描述一下以后的操作方式，操作可能产生的结果。如果时间和投入允许的话，可以做一个demo系统，比如，采用静态网页的形式，把各种页面组合在一起，不支持实际的数据输入，但可以展现出主要的系统操作流程。

       这个方法是一个有效的需求获取和确认手段，用户可以直观的看到将来系统的雏形，同时也能感觉到乙方做事情的规范和投入，也会产生对未来系统的信心和期待。后续的工作会配合的更好。

       笔者曾亲身经历过的一个项目，刚开始和用户整天讨论需求，讨论文字，流程图，数据等，用户也比较厌烦了。在这种情况下，由系统分析和设计人员知道开发人员作了一个初步的系统Demo，包括了几百个网页页面，其实做起来也比较快，而给用户看到后，他们的感觉很好，觉得开发方是下了大力气的，并且基本上理解的甲方的需求。甲方的领导、具体经办人员也都对系统给予了支持和期望。

       所以，笔者建议，在尽可能的情况下，还是能够做出一些基本的原型系统，以方便确认需求，更有利于项目的进展。

      

1.8