如何进行软件需求分析

1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以上几点说...

软件开发需求分析时,做不到的需求怎么处理

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。

怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。

软件开发的意义也就在于此。

而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

--- 经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。

通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。

另外，我们也得为政府部门提供关于商品营运的报告。

”-- -分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。

”-- -经理觉得奇怪：“我不是刚告诉你我的需求了吗？”-- -分析员：“实际上，您只说明了整个项目的概念和目标。

这些高层次的业务需求不足以提供开发的内容和时间。

我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。

”-- -经理：“业务人员都在招商。

他们非常忙，没有时间与你们详细讨论各种细节。

你能不能说明一下你们现有的系统？”--- 分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。

我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。

我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。

”--- 经理坚持道：“行了，行了，我们没有那么多的时间。

让我来告诉您我们的需求。

实际上我也很忙。

请马上开始开发，并随时将你们的进展情况告诉我。

”--- 风险躲在需求的迷雾之后- --以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。

在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。

这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。

这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。

若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。

因此可见——需求分析奠定了软件工程和项目管理的基础。

-- -拨开需求分析的迷雾--- 像这样的对话经常出现在软件开发的过程中。

客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。

那么，我们就拨开雾影，分析一下需求的具体内容：-- -·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

--- ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

--- ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

-- -·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

--- ·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。

“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。

其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

--- 下一层次需求——用户需求，必须从使用产品的用户处收集。

因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。

例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

--- 经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。

用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。

如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

--- 在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。

除非遇到的需求极为简单；否则不能这样做。

如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

--- 优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。

只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

--- 由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

-- -客户的需求观-- -客户与开...

软件需求的沟通与分析是什么？

关于软件项目所存在的问题，互联网上曾经流传着一幅漫画，它十分生动地展现了这些问题。

也许很多人看完之后只是一笑置之，但如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的。

沟通失真 究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息的内容有了很大的改变。

因此，对于软件需求工程而言，克服沟通失真就成了一个要点。

根据相关的研究显示，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。

而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4%（如图2示），这是一个十分可怕的结果。

怎样才能够更好地避免这种问题的出现呢？其实关键的手段有两个： 文档：如果信息在传递的过程中仅靠口口相授的话，就难免发生遗忘、加工等情况，因此必须在这个过程中有效地利用文档，将达成共识的信息文档化。

但这种方法只是用来辅助沟通的，而不是代替沟通，这一点在后面还会提到。

Review：在此有意使用了英文，因为国内常将其翻译为“评审”，但这一翻译却容易给人误导。

评审在很多人的脑海中就是得出一个通过与否的结论，这也是导致需求评审工作流于形式的罪魁祸首之一。

顾名思义，Review就是再（Re）看（View）一遍的意思，其本质含义是通过再次的审读，尽早地暴露出错误。

而最简单、有效的Review就是在用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍，以确保沟通没有失真。

隐喻：经理叫来了小张，然后就下一阶段的工作做出了一些重要的指示和安排：“$%#^@（*）#@……”。

小张正要扭头走的时候，经理叫住了他，说到：“你简单地说说看，我刚才给你交待的任务有哪些”（看来管理人员早已掌握了这一招）。

提示：如果有一个测试人员对你说：“我前天仔细测试了一下你写的程序，发现一个问题也没有，恭喜你！”。

你会怎么想呢？ a. 觉得自己的程序写得很好！ . 觉得测试人员方法不得当或测试不细致。

我想大多数人都会做出“”的选择！可是到了需求评审时为什么却转了180度的弯呢？为什么期望需求评审时一点问题也没有呢？ “沟通失真”高度概括了其中所蕴藏的问题，但如果我们细细地思考第 1、 2、 3、 4、10幅图（这五幅图中的景象与需求活动有很大的相关性），并将其两两比较就会得到一些有益的启发。

下面我们就一起来看看。

客户：放大需求 当我们比较图1中的1幅和第10幅图时，就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。

“用户要么不会说，要么就会添油加醋”的现象，在我的实践中是屡见不鲜的。

而在这种现象的背后有什么潜在的原因呢？我认为至少有两方面关键因素： （1）客户希望支付的成本尽可能少，获得的效益尽可能多 这种思维对于任何一个客户、任何一个人而言都是本能反应。

而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。

要有效地克服这个因素的困扰，核心的要点在于建立客户对开发团队的信任度，而建立信任度的要点有两个方面：一是需求人员必须提升自己的专业主义（关于这一点我将在后续的文章中说明）；二是需求人员要多站在用户的角度想问题，让用户感觉需求人员的目标是帮助自己解决问题，而非一味谋取利益。

（2）解决方案的选择权交给了不熟悉技术的客户 也就是用户经常会谈解决方案，甚至许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。

但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而客户代表选择的解决方案不是最合适的话，就必将引发后续的需求变更。

案例&场景： 在一次CRM软件开发的过程中…… 负责输入客户信息的用户向开发人员提出：“你看这个界面，光电话就有快10个输入框，太麻烦了，每次按ta键都按酸了。

我希望把他们合并成两个，一个为常用电话，一个为其他电话”。

“那有多个电话怎么办？”，开发人员回应道。

“其他电话的输入框可以设置为多行的、较宽的，这样我可以输入多个，中间用逗号分开它！”。

“好的，没问题” 。

…… 当经理看到了这些客户信息之后，向开发人员提出：“我需要一个功能，输入任何电话号码，自动找出相应的客户。

” “啊……” 如果我们细究这个场景，分析一下负责输入客户信息的用户所提出的变更就会发现：“将10个电话输入框合并成两个”显然是解决方案，而真正的需求是“输入太麻烦了，每次按ta键都按酸了”。

你或许就会想到如下所示的解决方案： 也就是说，默认情况上只显示左边的部分，当需要时点击“其它”按钮就可以将右边的不常用输入项显示出来。

总而言之，因为对于一个特定的问题可能的解决方...

软件需求分析的需求类型有哪些呢？

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。

因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。

针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。

我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。

本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1~2分钟左右的响应时间，让客户无法忍受。

（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。

在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。

注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，客户端采用Windows 98，程序架构采用的是传统的C/S结构。

鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得 （第1）步结果的基础上写出基本需求，交由客户评审补充，（3）在 （第2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。

下面按上述三步分别加以论述。

第一步是实施逆向工程，获取原有系统的基本需求 由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。

在这一阶段，我们采用的主要工具是PB自带的Power Designer和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。

采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。

在使用Power Designer分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。

这里指出，使用Power Designer的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。

第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充 通过第一步的逆向工程，我们获得了系统的基本需求。

为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro、Clear Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。

但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。

之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。

正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。

在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Pro进行需...

如何系统的进行用户需求分析

项目管理以及相关项目功能中都起了重要的作用：&quot：定义需求基线（迅速制定需求文档的主体），因为另外一些可能属于子系统（或软件部件）.作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.结果这个小组只好手工抄写源代码文档以供代码检查.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.1.这种合同都包含在编写的需求文档与模型中，现在我要的就是给我编一个系统&quot，这在使用实例（use case）文档或方案脚本说明中予以说明.3.功能需求（functional requirement）定义了开发人员必须实现的软件功能.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适.估计变更需求所产生影响并在此基础上协商新的承诺.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、评价、编写文档等所有活动.需求开发活动包括以下几个方面，当他们开发完这个工具后.同时这也是一旦做错.将所收集的用户需求编写成文档和模型、产品高层次的目标要求，它们在项目视图与范围文档中予以说明.2.用户需求（user requirement） 文档描述了用户使用产品必须要完成的任务、用户需求和功能需求（也包括非功能需求）.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件，如图4-1所示，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.了解相关质量属性的重要性.商讨实施优先级的划分.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同&quot，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能；性能要求；设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是：＂用户能有效地纠正文档中的拼写错误＂，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是＂找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词＂.同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换.从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系，它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的.5.需求分析的原则不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险，这里的＂成功＂是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.不适当的需求过程所引起的一些风险：1. 无足够用户参与客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与.究其原因：一是因为开发人员感觉与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了.在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程.系统人员在实践过程中，也有些感觉，在实施一家公司的项目时，若无足够的用户参与，系统人员获得的需求是片面的，不完整的，这样系统在需求之初就埋下风险.2. 用户需求的不断增加在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决.实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改.要想把...

迷宫探路这个小的C语言程序的需求分析

软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。

在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。

软件开发，能否获得成功，最重要的是需求分析的工作。

因此，软件需求分析能力和水平，对软件项目至关重要。

一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。

⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。

⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。

⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。

由计算机完成的功能就是新系统应该实现的功能。

常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。

这种方法可以比较准确地理解用户的需求，但比较耗费时间。

⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。

座谈时，参加者之间可以相互启发。

⑶请专人介绍。

⑷询问 对某些调查中的问题，可以找专人询问。

⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。

⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。

分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

软件产品设计中如何进行需求分析？

软件产品是指软件开发商根据市场需要开发的、具有一定适用性和潜在客户的、可销售的软件成品。

它区别于应特定客户需求或根据订单开发的软件商品，通常应具有更高的通用性和适应性。

但它的通用性和适应性不是轻而易举就能达到的。

要实现软件的产品化，就必须在软件产品的设计上下一番功夫。

本文结合一个＂多媒体远程教学系统＂实例，探讨软件产品设计中的一些经验与看法。

一、软件产品设计的重要意义 所谓软件产品设计，在本文中指对软件产品的功能与架构进行设计。

用传统的软件工程术语来说，它覆盖软件工程的可行性研究、需求分析、系统设计几个阶段。

用RUP(Rational Unified Pocess-统一软件过程)术语来说，它是需求定义与软件构架设计的结果。

软件产品设计包括了需求分析、功能定义、技术方案以及需求管理的策略。

我们可以看见很多这样的例子：企业做完一个产品后，便不得不长期甚至永久地投入几个人（通常还是曾参与研发的技术骨干）对产品进行维护、跟踪和服务；企业在做同类项目时，还不得不投入几乎相等的资源；系统集成企业或以管理类项目为主的研发企业长期为工程所困，良好的市场需求并不能带来利润回报的规模增加，等等。

造成以上现象，一是由于企业的软件过程成熟度不高，另一个原因，就是缺乏清晰、深入的软件产品设计。

优秀的产品设计可能是软件企业发展的重要契机。

好的产品设计可能使企业走向产品系列化、服务规范化、内部管理规范化的良性发展之路；而差的产品设计不仅将造成现实的资源浪费，甚至有可能使产品从此成为软件企业的一个枷锁。

其实，产品设计的来源最终都是市场。

设计的好与不好，反映了设计者对技术、业务、以及用户需求诸方面的现状以及变化规律把握的结果。

下面从功能定位入手，探讨怎样进行产品设计。

我们所举的例子的主体假设是一个典型的系统集成企业，在多媒体系统集成项目上有较多的工程经验，在软件研发上也小有积累，市场研究认为多媒体技术在培训、教学领域将大有可为。

二、软件产品的分类及定位 与一般的针对用户明确需求的软件项目的需求分析稍有不同，软件产品的功能定义更多的是一种＂定义＂，而不象面向特定用户的系统，其需求定义是一种记录、归纳和分析的过程。

它看起来的自由度比较大。

正是这种自由度可以带来产品的升华，使工程产品化。

即使对于特定用户的软件需求，我们也有必要在满足特定用户的特定需求的同时，对相关技术和业务进行适当的分析和预期，使得项目的成果具有更好的适用性和重用价值。

软件产品可以分为两种：面向最终用户的和面向软件开发或集成商的。

第一种主要指面向不限于计算机技术人员、完成一定应用功能的系统；后者指供专业的软件开发人员使用、用于构造第一种产品的＂中间＂产品，它可能是一个完整的系统平台，也可能是一个开发包或一个小的程序工具。

不同种类的产品具有不同的特性要求：面向集成商开发商的产品要求可靠、可扩充、有详尽的技术说明、有一定的技术适应性；面向最终用户的产品则要求功能完整、可靠、可维护、有较好的应用适应性。

其实，设计人员还可以根据市场形式开发介于以上二者之间的＂半产品＂，即通过简单定制可以＂生产＂出应用系统的＂半成品＂，但又不同于严格意义上的开发平台或是零散的开发工具包。

这种＂半成品＂很实用，不仅可以提高本企业的生产率，为产品系列化打好伏笔，还可以在适当的市场时机作为商品提供给系统集成商，为企业带来额外的利益。

到底要开发什么类型的产品，是软件产品设计的第一个重要决策。

我们假设的＂多媒体远程教学系统＂定位在＂半成品＂上，希望开发出能直接用于某种应用场合（如企业培训），但可以根据应用需要进行定制、扩充，广泛应用于其他相关应用，如专业培训机构、网络化学校教育等。

三、软件产品的非功能性需求定义 软件产品的需求可以分为功能性需求和非功能性需求。

其中软件产品的非功能性需求是常常被轻视、甚至被忽视的一个重要方面。

其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。

如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。

所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有的、除功能需求以外的特性。

软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性、对技术和对业务的适应性，等等。

下面对其中的某些指标加以说明。

1、系统的完整性 指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的。

典型的功能有：联机帮助、数据管理、用户管理、软件发布管理、在线升级，等等。

并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。

例如，在线升级、软件发布管理适用于具有因特网或内网环境的软件产品；而数据管理对于产生数据存储的产品则是必须的，设计人员不应假设用户同时是一个合格的DBA，而且系统所产生信...

软件工程中需求分析的任务是什么？（具体点）

一。

确定对系统的综合要求1. 功能需求这方面的需求指定系统必须提供的服务。

通过需求分析应该划分出系统必须完成的所有功能。

2. 性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。

3. 可靠性和可用性需求可靠性需求定量地指定系统的可靠性。

可用性与可靠性密切相关，它量化了用户可以使用系统的程度。

4. 出错处理需求这类需求说明系统对环境错误应该怎样响应。

例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么？注意，上述这类错误并不是由该应用系统本身造成的。

5. 接口需求接口需求描述应用系统与它的环境通信的格式。

常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。

6. 约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。

在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，只是说明用户或环境强加给项目的限制条件。

常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。

7. 逆向需求逆向需求说明软件系统不应该做什么。

理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。

8. 将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。

注意：举例让学生理解：这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

二 。

分析系统的数据要求任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。

分析系统的数据要求通常采用建立数据模型的方法（举例）。

三。

导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

四。

修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

...