著名的需求工程开发设计师Melin Dorf man和Richard H.Thayer对软件需求提出了一个包容且更为精练的定义——用户解决某一问题或达到某一目标所需的软件功能:系统或系统构成为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。需求应该是来源于用户的调查——即客户的需要, 来源于某个特定行业的一些抽象的提炼;并参照行业规范进行业务分析的结果, 考虑用户自身的特性与要求。这些从客户处获得的“需要”, 被分析、确认后形成完整的文档, 该文档详细地说明了产品“必须或应当”做什么或对于模糊的部分不做什么。而并不是通过一些零碎的邮件, 或者与用户的对话, 收集的一些零乱的资料, 就是说我已经做好了需求, 而这一种情况, 恰恰就是导致项目失败的因素。
1 软件需求的层次
软件需求包括三个不同的层次——业务需求、用户需求和功能需求 (也包括非功能需求) 。
(1) 业务需求。
业务需求反映了组织机构或客户对系统、产品高层次的目标要求, 它们在项目视图与范围文档中予以说明。
(2) 用户需求。
用户需求文档描述了用户使用产品必须要完成的任务, 这在使用案例文档或方案脚本说明中予以说明。
(3) 功能需求。
功能需求定义了开发人员必须实现的软件功能, 使得用户能完成他们的任务, 从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合, 给用户提供处理能力并满足业务需求。
2 需求分析的实现
要做好需求分析, 必须要严格遵循需求分析的步骤——开展需求调研、进行需求分析、写好需求文档以及需求评审和需求确认。
(1) 开展需求调研。
通常, 需求调研涉及三个问题, 一是如何确定调研对象;二是如何确定被调研对象;三是采用何种调研方法。调研对象一般用户熟悉业务的人员、开发商技术专家以及项目经理。被调研对象主要是对方主要负责业务的人员以及业务操作人员。而且调研范围是关键, 它包括关键域和关键活动。而关键活动又由关键流程加上关键点构成。找到关键域, 明确关键流程和关键点, 对需求调研至关重要, 需要专家介入。而能否把握这一时机并找准需求提炼的关键点, 是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在, 还能藉此获取足够多的知识, 最后成为问题领域的专家。
(2) 进行需求分析。
需求分析是指在需求开发过程中, 对所获取的需求信息信息进行分析, 及时排除错误和弥补不足, 确保需求文档正确地反映用户的真实意图。通常, 我们所用的需求分析方法有三种:问题分析法、界面原型法以及可运行原型系统法。问题分析法, 比较简单, 通常是我们设计好问题, 然后让用户填写来完成。界面原型法则是开发方根据自己所了解的用户需求, 描画出应用系统的功能界面后与用户进行交流和沟通, 通过“界面原型”这一载体, 达到双方逐步明确项目需求的一种需求获取的方法。可运行原型系统法是指开发方根据合同中规定的基本需求, 在以往类似项目应用系统的基础上进行少量修改得出一可运行系统。
(3) 写好需求文档。
这是我们要对我们进行的需求分析, 进行分类规划总结, 由专门的技术人员完成需求分析文档的书写, 通常, 需求文档也可以按照指定的文档模板来写需求, 这样做一是降低了写作难度, 开发人员可以把精力集中在文档的内容上;二是按照文档模板写出来的需求文档比较规范, 容易被用户和开发人员接受。
(4) 需求评审和需求确认。
做好软件需求规格说明书后, 要进行需求评审和用户确认。项目经理应邀请客户代表共同评审需求文档, 尽最大努力使需求文档正确无误地反映用户的真实意愿。在双方都评审完毕后, 确定需求文档已经没有问题的时候, 要请双方代表队需求文档进行确认, 签订合同。
只有经过以上四步后, 才能真正的完成一个项目的需求分析过程, 如果缺少任何一个步骤, 需求分析过程都将回不完整, 并且可能会给整个项目的开发带来严重的后果。
3 需求分析时经常遇到的问题及对应策略
(1) 用户说不清楚需求。
用户说不清楚需求是普遍现象, 这是让开发人员头痛的大问题。有些用户真的不知道需求是什么, 或者对需求只有的是感觉。这种现象有些时候是正常的, 例如开发方的营销人员水平比较高, 他能够在用户不清楚自己要什么的情况下引导用户。用户说不清需求, 当然也有表达能力的问题。遇到这种问题, 我们常见的方法有以下几点。
(1) 需求分析员根据客户的表述, 把模糊不清的需求写出来 (或者用图形画出来) , 再让客户哪些内容是他真正需要的, 哪些是他随意说说的。
(2) 如果文字不能清楚需求, 那么开发方构造软件的原型 (只有界面和演示功能) , 请客户一边体验软件原型, 一边阐述他的真正需求。
(2) 双方误解需求。
用户表达的需求, 不同的开发人员可能有不同的理解。如果需求分析员误解了需求, 那会导致后续的不少开发人员将错就错、白干活。无论是复杂的项目还是简单的项目, 需求分析员和用户都有可能误解需求。所以需求确认必不可少。
(3) 写不好需求文档。
写不好需求文档的一种原因是:需求调查工作不充分, 获取的需求信息太少或者太乱, 以至于写不成需求文档。因此, 要写出好的需求文档, 前提条件是把需求调查工作做好, 至少要有东西可写。另一种原因是:开发人员写作能力比较差, 虽然在调查过程中已经获得了不少需求信息, 却写不出好的需求文档来。
可以毫不夸张地说, 国内90%以上的软件开发人员, 他们的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让人多练习写文档。另外, 企业应当提供合适的文档模板以及比较好的示例文档, 尽可能是降低写作难度。
(4) 用户经常变更需求。
需求变更通常会对项目的进度、人力资源、经费产生很大的影响, 这是开发商非常畏俱的问题。如果在项目开发的初始阶段, 开发人员和用户没有搞清楚需求或者搞错了需求, 到了项目开发后期才将需求纠正过来, 导致产品的部分内容需要重新开发。毫无疑问, 这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的, 双方应好好反省, 认真学习需求开发和管理的方法, 避免再犯相似的错误。
其实需求变更并不可怕, 可怕提需求变更失去控制, 导致项目混乱。所以不论是客户还是开发方提出需求变更, 都要按照“申请-审批-执行”的流程操作。
摘要：本文对如何实现软件需求分析进行了探讨分析, 详细分析了软件需求分析中的各个步骤, 并对需求分析中存在的问题进行了概括总结。本文的研究对于做好软件需求分析具有重要的意义。
关键词：需求分析,需求调研,需求文档
参考文献
[1] Swapna Kishore, Rajesh Naik.软件需求与估算[M].北京:机械工业出版社, 2004.
[2] 赵池龙, 杨林, 孙伟.实用软件工程 (第2版) [M].北京:电子工业出版社, 2006.
[3] 楼浩.大型信息系统集成项目的项目管理研究[J].对外经济贸易大学, 2007.