软件项目中的需求管理系统设计与开发软件工程课程设计.docx
《软件项目中的需求管理系统设计与开发软件工程课程设计.docx》由会员分享，可在线阅读，更多相关《软件项目中的需求管理系统设计与开发软件工程课程设计.docx（36页珍藏版）》请在冰豆网上搜索。
软件项目中的需求管理系统设计与开发软件工程课程设计
《软件项目中的需求管理系统设计与开发》
软件工程课程设计
引言
人们常问：
“需求、设计、编程、测试四者究竟哪个重要？
”
这个问题并不好回答。
四者都是软件开发过程中必不可少的环节，只做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏的影响。
若站在风险管理的角度讲，我认为需求开发与管理是最重要的环节。
因为需求是产品的根源，需求工作的优劣对产品的影响最大。
就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：
“开发软件系统最困难的部分就是准确说明开发什么。
最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。
此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
”
对于一个软件项目，开发和实现用户所真正需要的产品是非常重要的。
软件产品的成功与否很大程度上取决于对需求的管理。
像我下面要介绍的项目——“厦门**公司墓石cad设计系统”的成功，我觉得首先就要归功于我们对它进行了有效的需求管理。
但是，谈到软件产品的需求管理，我们认为遇到了一个非常棘手的问题。
实际上由于面对的客户和市场环境的不同，需求可以变得非常复杂，这种复杂往往又是动态的和难以描述的。
客户的需求往往是很概括的，有时又是很具体的。
客户有时会说:
“我们需要一个整体解决方案”，有时又说:
“图纸上的作者要这样写”。
显然这样的需求无法被我们完全接受。
客户的要求显然是重要的，产品应该以客户为导，如何把客户的需求变成我们技术人员能够接受的功能说明书，相反如何在产品开发前就让客户认可最终的产品，或者使用户的需要与产品之间不应有过大的偏差。
此外，软件项目的需求管理，涉及到用户、市场、产品与开发等各种职能和角色，涉及到客户的需求、项目开发的时间和资源；如何平衡各方面的要求，从整体上实现客户需要的产品，对需求进行有效的管理和控制。
对需求管理的方法和应用进行系统的分析，提出一些利于实际操作的方法是十分必要的。
第一章需求及需求管理概述
1.1.软件需求的定义
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
IEEE软件工程标准词汇表（1997年）中定义需求为:
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力
（3）一种反映上面
（1）或
（2）所描述的条件或权能的文档说明。
1.1.1.关于“需求”的解释
工EEE公布的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。
关键的问题是一定要编写需求文档。
另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”下面的定义则从用户需要进一步转移到了系统特性：
需求是指明必须实现什么的规格说明。
它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
上述需求定义的一种解释如下：
所谓需求，应该是来源于用户调查——即客户的需要，来源于某个特定行业的一些抽象的提炼；并参照行业规范进行业务分析的结果，考虑用户自身的特性与要求。
这些从客户处获得的“需要”，被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么或对于模糊的部分不做什么。
而并不是通过一些零碎的邮件，或者与用户的对话，收集的一些零乱的资料，就说，我已经做好了需求，而这一种情况，恰恰就是导致失败的因素。
1.1.2.需求的层次
软件需求包括三个不同的层次——业务需求、用户需求和功能需求（也包括非功能需求）。
业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用用例文档或方案脚本说明中予以说明。
功能需求（functionalrequirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
1.2.需求管理的概念
1.2.1需求管理的概念
需求管理的定义如下：
顾名思义，需求管理是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。
一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。
对关键需求的疏忽很可能是灾难性的。
不同的需求组合起来，构成了一套完整的需求模型。
用户需求决定了系统设计所要解决的问题，所要带来的结果。
可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。
用通俗的话来说，需求管理就是：
一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
我认为需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解，并对此需求进行有效的控制，使项目走向成功。
需求管理的过程，从需求获取开始贯穿于整个项目生命周期，力图实现最终产品同需求的最佳结合。
通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
1.2.2.需求管理目标及需求管理要点
需求管理的目标是:
1．使软件需求受控，并建立供软件工程和管理使用的基线。
2．使软件计划、产品和活动与软件需求保持一致。
3．控制需求变更，保证项目进度。
需求管理要点:
1．要明确和建立需求来源渠道，既为了避免需求蔓延，又要避免忽视客户需求、重复劳动、和不严肃的承诺；
2．建立需求管理小组，对需求进行评审，如需求对系统的影响范围等；
3．对需求变更进行管理，对于不同等级的需求，采取不同的测量；
4．需求文档要进行版本控制。
需求亦有基线和分支，并要和代码、文档等其它产品的基线和分支保持一致；
5．需求文档中的SRS要其有唯一编号，可以通过项目号+SRS编号，唯一定位具体的需求；
6．在后续的代码、文档等数据中引用需求要确保和需求文档保持一致；
7．需求管理小组要严格控制进人设计和开发之后的需求变更，并根据变更频率，改进项目需求分析过程。
8．要正确对待用户提出的新的需求以及需求变更，不能老报着“顾客是上帝”的心理，一味地答应用户的新需求。
1.3.小结
这一章主要讲述了需求和需求管理的定义，并着重解释了需求管理的概念、目标、流程等，我们可能有一些疑问：
需求和需求管理有什么用？
没有开发出一行代码，在整个软件工程过程中浪费这么多时间岂不是无用功吗?
下面就需求及需求管理的重要性进行一下阐述。
首先我们要树立一个概念：
需求是根本，是我们一切开发活动的依据。
由于忽略需求过程造成的项目返工是恶性的，后果不堪设想，大量的项目在需求阶段就注定了它的失败。
以下是两个需求过程不科学的典型例子:
1．开发人员在用户处呆了两三天就埋头开发；
2．用户告诉开发人员我要开发一个xx系统，但是我很忙，你先开发一个让我看着，开发人员就盲目答应。
上面的这两种态度都意味着项目的不成功，应该说上面的开发人员和用户都应该对此负责。
需求是开发者和用户交互的一个过程，任何一方的不投人都会导致项目的失败。
当然，由于用户不是专业人士，开发者有权利告诉用户应该采用何种态度来对待项目的需求。
所有最成功的项目都有一个重要的特性：
用户非常的支持。
评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题就是体现为用户的需求，需求也就顺理成章的成为项目的成功标准。
而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工，而需求的不慎不是说你小心就可以的，因为很多需求是隐性的，连用户都不清楚自己的需求。
这时候就需要一种科学的方法来帮助软件项目组实施需求过程，。
是不是我们在项目开始之前将所有的需求搞明白就可以使项目开发成功?
我们姑且不讨论这种做法是否可行，只假设我们做到了这一点，可不幸的是：
客户的需求是变化的，并且是一定要变化的。
怎么办?
全盘接受?
全盘否定?
这两种做法都是项目失败的种子。
解决这些问题的办法就是用需求管理的办法，顾名思义，就是要把需求“管理”起来，让它为我所控制，从而顺利地完成整个项目。
可以说，软件项目中绝大多数失败是需求的失败:
或者是需求开发的失败，或者是需求管理的失败。
所以，我们讨论在软件项目中进行需求管理就是十分必要的了。
以下的章节，我将结合实际中的一个项目来具体谈一下小组软件项目中的需求管理问题。
第二章项目及项目背景简介
2.1.“厦门**公司墓石cad设计系统”项目背景介绍
厦门**公司员工一直以来都是使用一套叫“雅”的设计系统进行墓石设计，该系统由该公司从日本购进，成本较高。
而且由于其是由日本人开发，好多使用方法不符合**公司习惯，致使该公司员工设计效率低下，不能很好的适应市场需求。
为了适合**公司员工的工作需要，提高其工作效率，降低其开发成本，该公司迫切需要一套适合自己的开发设计系统。
经过多方面考虑和挑选，最终选择委托给我们小组来进行新的系统的设计和开发。
2.2.“厦门**公司墓石cad设计系统”项目介绍
该项目是autocad的二次开发项目，使用ObjectARX开发包以及VC6.0进行开发。
各模块最终生成各自的ARX模块，相对而言比较独立。
下面我主要介绍一下系统的总体功能以及整体工作流程。
系统总体功能如下：
各子模块如下:
系统的整体流程图如下：
第三章需求获取阶段的控制和管理
3.1.概述
需求获取阶段，即需求开发阶段，也可以叫需求分析阶段。
在这个阶段，要对客户提出的需求进行提炼、分析，最后形成客户认可的需求规格说明书。
在需求获取阶段还要编制一份开发计划。
3.2.前提
需求获取的前提是:
用户与公司签定开发合同或者是需求调研合同。
需求分析阶段是完成由公司的销售人员为重点转变为公司系统开发部门为重点过程中的第一步。
对于用户来讲已经对多家开发商进行了挑选,最终明确一家开发商，并签订了开发合同。
现在要进行提供具体需求并明确需求的过程——明确告诉开发商要开发一个具有什么功能、什么特性的软件产品。
这个前提是不可或缺的，在没有签定合同之前什么事情都会发生。
在今年春节以前，我曾经遇到过这么一件事情:
厦门的一家旅游公司，升级自己的门户网站，由于各种原因，决定不进行招标，直接选择厦门**软件公司进行开发。
当需求已经谈完，合同已经到了谈论细节的时候，合同突然被另外一家公司抢走了。
进行需求调研的另外一个前提是甲乙双方签定了需求调研合同。
这个情况一般发生在甲方在几家公司之间做选择时。
从上面的情况可以看出，进行需求调研的前提就是有合同保障，否则就会像我上面说的那样，会造成不必要的损失。
3.3.约定
用户对于其用什么系统平台，已经大概知道，并且已经认可。
如WEB服务器的操作系统是WINDOWS2000server，数据库服务器是redhatlinux，WEB服务器的软件是Apache，EJB中间件服务器是Weblogic/Websphere，数据库软件是ORACLE/SQLserver等等。
客户服务器的软硬件配置要经过客户的认可，并写入需求，签字确认，否则如果以后用户要提出更改，有可能会对我们的开发造成很大的影响造成不必要的损失。
像“厦门**公司墓石cad设计系统”这个项目中，在进行需求分析时，我们就和客户约定好我们的平台是搭建在autocad2002上的，所以我们的开发、测试等活动都是在autocad2002的基础上进行。
当我们的项目快接近尾声时，客户突然又提出要我们设计的系统能够兼容MDT6和autocad2004。
我们进行了详细的分析，因为autocad2004和autocad2002的内核已经有很大的差别，如果要兼容的话大量的模块都要返工，这就意味着我们要进行重新设计开发，开发进度会落后很多。
所以我们就拿签字的需求文档去跟客户谈，跟他们讲清楚我们开发困难等一些原因，而且由于我们开始也有签字约定，所以客户也就答应了。
最终我们就只有兼容MDT6。
如果我们当时没有约定，客户坚持他们的意见，那后果真的是不堪设想了。
所用技术体系一般情况下在进行需求分析前最好是明确的，不然就要求系统分析人员了解所有的技术体系。
不然运气好，系统分析人员所了解的技术体系和用户相求的相同，进行了正确分析;如果运气不好可能会把一些认为可以简单实现而实际实现却很难的需求答应下来。
在所用技术体系大概范围已经明确的情况下，选择合适的系统分析人员。
要求系统分析人员对相应技术体系有一定的了解，以便在相应的分析时有所依据。
不同的技术体系有一定的局限性，而有些需求对某些技术体系有一定的难度。
如WAP（手机上网）是不太可能实现打印。
虽然没有绝对不能实现的用户业务需求，但一般情况下开发协议上明确的费用，已经决定系统功能做到什么程度。
3.4.获取需求规格说明书
3.4.1.调研前的准备
在需求调研过程中，应该做好三种准备，保持两种心态，做到五种提高:
三种准备：
1）调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。
2）做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。
3）做好不怕一切困难的准备。
两种心态：
1）保持一种和客户平等合作的心态，确定需求调研是为了给客户解决问题，探讨问题而不是接受问题，更不是来指导工作的。
2）平静面对需求变更的心态，在需求调研过程中，往往双方对需求理解不一致，造成需求调研前后矛盾，应当心平气和的去引导客户，达到需求理解基本一致。
五种提高：
1）首先提高自己业务知识，对于CAD制图，墓石设计的标准业务应该基本熟悉。
2）其次应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。
这就需要我们阅读用户所在行业的资料、文章，尽量多选取一些整体性介绍的文章，这样可以在短时间内能够对该行业有一个全面的认识，这样我们就能够较好的和用户进行交流了。
3）需求调研中，学会尽量不使用专业术语，而采用浅显易懂的口头语言来解释软件开发中的术语，以便用户能够很好的理解，提高自己的沟通交流能力。
4）提高自己的速记能力，文字表述以及归纳能力，能迅速的记录需求调研核心的问题，总结归纳形成原始的需求调研资料。
5）提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。
3.4.2.调研过程
在调研的过程中应该对会议进行记录。
这项工作一般由开发商的需求分析人员进行，并在每日会议结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。
第二日复印或发送电子文件给参加会议人员及相关人员。
以便做到有据可查，明确过程。
开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、是否有问题、是否需要用户协助等，这是一个好的加强双方沟通的方法。
注意:
在调研过程的中系统开发人员的变更会对计划产生重大的影响，不要简单认为是人员更换的问题。
因为在调研过程中对业务的理解，不是通过看看文档就可以达到。
3天通过讨论达到对需求理解的程序，9天对文档的学习也不一定能达到。
3.4.3.整体调研
对于调研过程中的整体调研，一定要让用户各部门的主管以及用户全体人员（含用户IT人员）参加，第一个目的是了解用户的整体需求细节，第二个目的使用户人员从各自的角度也了解到用户方要做一个什么样的系统。
需求提供者如果是一个人，他知道自己要一个什么样的系统。
但如果是多人，在开发商系统分析人员进行调研前，每人也不过是计划自己的需求而已，即使有时沟通，一般也是在讨论而不是进行结论。
使业务需求并不是很明确。
整体调研的其中一个目的就是把用户的多人需求组成一个整体，整体调研过程也是一个用户人员沟通并整合需求的一个过程。
用户方多人在进行开发商需求确认前，业务互相有分歧是相当正常的，开发商系统分析人员必须要在需求调研过程中，使其达成一致。
一般情况下需明确以下问题:
1）当前整体业务需求的目的
2）要求提供的需求功能列表
3）已经定义的需求规则
4）将来发展的设想
5）明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等）
6）用户目前相关的技术人员和业务人员情况
7）将来最终系统操作人员的技术及业务人员情况
8）用户需求的系统及用户本身或其它系统的接口要求
9）用户的其它要求
3.4.4.具体业务调研
对于整体调研过后就要进行各个具体业务需求的调研，对于具体需求调研如果是用户提供的现有的文档，开发商的需求分析人员（或系统分析人员）只是对业务进行了解及进行修改为需求分析人员（系统分析人员）及业务人员全可以看懂的需求说明书，那么这个过程就比较容易。
只要系统分析人员把业务文档看懂看明白，并且对于一些难理解的业务描述修改为易懂（有些业务名词有一定的专业性就要进行额外的说明）、明确进出的单据（数据项）就可以。
当然编写需求说明书具体的细节可以参见其他的众多的书籍及文件模版了。
如果用户对于自己的需求在调研开始并没有完全明确，需要进行引导及细化，那么这个过程就比较麻烦了。
对于用户本身需求不明情况下，对于业务要先从基本业务进行细化，对于不明业务或不确定业务在后面进行。
对于进出的单据（数据项）只需明确单据的进出的必须数据源就可以，如果做到细节，由用户在需求调研期确定单个数据项，是不太可能的——只是设计单据的样式、风格就不是短时间可以完成的。
对于报表也只能明确基本报表要求及数据项。
一般这种情况使用原型法进行，先做一个简单的，在简单的上面再进行完善。
对于用户本身需求不明情况下的调研要做每日（或2到3天最多3天为间隔）的工作（分析进展）记录，由双方签字，因为调研过程会出现为用户要求添加一支新业务，对新业务进行分析后，因某些原因发现不能添加。
这个过程的结果是一个0，但为证明是0这结果可能花了很长的时间。
要记录这个过程，说明调研过程中做了什么事情，有时有些人可能会说为什么这么长时间才出这点东西，到时以便说明原因。
关于选取开发模型
有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。
一般来说对于应用开发——为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。
当然在需求明确的情况下自然也要使用瀑布模型
对于自主开发及客户需求不明并有较长的设计时间——可以用演化模型。
而螺旋模型适合于大型软件开发，吸收了“演化”概念，不过有时也用于用户需求不明的情况下。
当然还有其他开发模型，没有在本文讨论。
名词定义:
•瀑布模型:
规定了各项软件工程活动。
包括:
制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。
特点:
自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。
•演化模型:
第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称“原型”
特点:
减少由于软件需求不明确而给开发带来的风险。
•螺旋模型:
将瀑布模型及演化螺旋模型结合起来，并且加人被两种模型都忽略了的风险分析，弥补了两者的不足。
3.4.5.对需求说明书的确认
需求规格说明书完成后，先由需求分析人员（系统开发人员）对编写的文档进行内部审核及修订，特别是文字问题。
内部审核后将需求规格说明书交由用户业务人员进行确认，明确需求分析人员（系统开发人员）已经了解业务需求，并进行签字确认。
对需求规格说明书的签字确认，主要表明经过双方的努力，对系统的功能界定已经取得了初步的共识，形成了开发的一个基线。
以后的开发、验收、需求更改要围绕着这个基线进行。
3.4.6.总结
需求调研是对合同中规定的用户需求确认的过程。
在这个过程中，不但要详细、正确地了解客户的真正需求，最后形成需求规格文档，还要考虑到整个项目开发的成本等因素。
一般在项目签定合同之前，用户已经提交了一个粗略的需求清单，这个清单是签定合同的基础。
但是不能以这个清单作为项目开发的基础，这有如下的原因:
1、客户提出的需求清单是很简单的，没有确定细节，不能作为系统开发的依据
2、在客户提出的需求清单中，有些名词的意思和开发人员通常理解的是不一样的。
这些要逐一进行澄清。
例如，在一个网站项目的需求调研中，客户原来提出一项“广告”的需求。
按照一般的理解，广告功能有各种各样的形式，可能做的很复杂。
可与客户实际一了解，原来客户所说的广告只是我们通常所说的“友情链接”而已。
另外一个，客户提出一个“客户端”的需求（这个单词的意义上讲的范围就比较大了），实际上这是对客户以弹出窗口的形式进行提醒罢了。
试想，如果对这些双方有分歧的地方，不进行澄清的后果有多可怕。
3、需求调研的成果之一就是形成客户认可的需求规格说明书。
这是对客户提出需求进行提炼、总结、归纳的过程。
是进行设计、开发时的依据，也是很重要的。
4、需求调研中要考虑项目的成本控制问题。
对于用户来说，既然已经签定了合同，总工程款已经确定，当然希望获得的功能越多越好;而对于开发商来说，功能不断扩充、项目延期是最可怕的事情。
这就需要把客户一些不切实际的想法消灭掉。
另外，要向客户解释清楚哪些功能不能实现。
这些都是需求分析人员的工作。
5、需求调研过程是为客户解决问题的过程。
通过与客户密切交流，解决客户心中的疑虑，为客户提供完善的解决方案。
最终要让用户满意。
备注:
让用户满意并不是答应用户提出的所有要求。
6、需求调研过程要对整个系统的扩展性进行考虑。
客户的想法会改变，业务会改变，甚至业务部门也会改变，这些在系统设计中都要通盘考虑。
3.5.编制开发计划
需求规格说明书编制完成后，就可以编制出这个系统的开发计划。
开发计划的内容如下:
1）项目名称
2）项目委托方与承接方
3）项目组成员
4）项目实施进度计划
5）项目开发实施步骤
6）项目任务分配及资源
7）项目风险及资源
8）项目风险分析及管理
9）承接方需委托方配合的工作
10）双方关于项目管理的约定
再上面这些内容中，最主要的是编制“项目实施进度计划”。
编制开发计划不但要考虑功能需求多少，客户对时间的要求，还要考虑公司开发人员情况，其他项目情况等等。
3.6.小结
在需求获取阶段，通过与客户进行交流，弄清楚客户的真正需求。
综合考虑客户需求、项目成本，时间进度等情况，形成最初版本的需求说明书、项目开发计划书。
这是整个项目的开始阶段，直接决定了以后项目开发的成本、进度完成情况。
对这个阶段进行有效的管理，就显得尤其重要了。
进行完需求调研，获得了得到用户签字确认的需求规格说明书，下一步就进入项目开发阶段，签字确认的需求规格说明书将成为我们一切开发活动的依据。
第四章项目开发过程中的需求管理
4.1.概述
在软件项目或产品开发过程中，一般地来讲，把与需求直接相关的活动统称为需求工程。
站在需求工程的角度来说，可以分为两大部分，即需求开发与需求管理。
需求开发过程在需求获取阶段已经完成;而软件项目开发开始后，怎样对需求变更、版本进行控制就属于需求管理的范畴。
在目前来说，需求工程是国内大学软件工程教育最薄弱的环节之一，那么，在这种教育模式下诞生的软件工程师会存在一种这样的习惯：
他们在开发产品时并不
升级会员 