1、,Software ProjectManagement,软件项目需求管理,主要内容,软件需求分析 需求规格说明书 需求分析法则,引言：失败产品博物馆,美国纽约有一个“失败产品博物馆”，里面展出的“失败产品”高达万多件，其中不乏有很多大公司的产品，有的功能强大，有的还很新奇。 博物馆提供了这样一组数字：美国每年推向市场的新产品达54000多种，而真正受到青睐的只有20。 产品失败的原因有很多种，但最主要的就是产品功能与消费者的需求相去甚远所造成的。 失败产品博物馆是典型的没有很好地实施需求管理的方法来指导产品开发的例证。,软件需求定义,需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿，
2、分析出软件系统的功能、性能、数据等诸方面应该达到的目标，从而获得有关软件的需求规格定义的过程。 需求分析需要实现的是将用户对软件的一些列要求、想法转变为软件开发人员所需要的有关软件的技术规格说明，它涉及面向用户的用户需求和面向开发者的系统需求两个方面的内容。,用户需求,用户需求是关于软件的一系列想法的集中体现，涉及软件的功能、操作方式、界面风格、报表格式等。 用户需求的特点： 用户需求直接来源于用户 用户需求需要以文档的形式提供给用户审查 可把用户需求理解为用户对软件的合理请求 用户需求主要是为用户方的管理层撰写的，但用户方的技术代表、软件今后的操作者等也要认真阅读用户需求文档,系统需求,系统
3、需求是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点和基本依据。 系统需求需要对系统的功能、性能、数据等方面进行规格定义。 用户的问题体现为系统需求，也是成为项目成功与否的标准。 为保证系统需求表述具有一致性，往往用形式化语言表述系统需求。,系统需求的内容,功能需求,功能需求是软件系统的最基本的需求表述，包括对系统应该提供的服务，如何对输入做出反应，以及系统在特定条件下的行为描述。,非功能需求,包括对系统提出的性能需求、可靠性、可用性，系统安全及系统开发过程、时间、资源等约束。,数据需求,包括输入数据、输出数据、加工中的数据和保存在存储设备上的数据等。可用数据字典定义。
4、,需求规格说明书,需求开发的结果一般是通过需求规格说明书的形式来呈现。 编写需求规格说明书的目的是使用户和开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 需求规格说明书精确的描述软件产品做什么，以及产品的约束条件等。 需求规格说明书还给软件设计提供了一个蓝图，给系统验收提供了一个验收标准集。,需求规格书的写作范例,引言 编写目的：编写的目的，预期的读者 项目背景：待开发产品名称；项目的任务提出者、开发者及实现产品的单位；该系统同其他系统的相互关系等。 专用术语定义：列出文件中用到的专门术语的定义 参考资料：列出相关的参考资料 版本更新信息,需求规格书的写作范例,任务
5、概述 系统定义：描述项目来源、系统整体结构、各组成部分的结构。 项目目标：描述本项目要达到的市场目标、技术目标等。 用户特点：描述用户的业务特点和计算机应用水平等，充分说明操作人员、维护人员的教育水平和技术专长。 项目假设与约束：列出开发本项目的假设与约束，例如，经费限制、时间限制等。,需求规格书的写作范例,需求规定 对功能的规定：包括功能编号、所属产品编号、优先级、功能定义、功能描述。 外部功能 内部功能 对性能的规定。 响应时间 开放性 精度需求 可移植性 灵活性,需求规格书的写作范例,需求规定 输入输出要求：描述各输入输出数据的类型、格式、数值范围、精度、媒体等，输入及输出的数量和频度等
6、。 数据管理能力要求：说明需要管理的文件和记录的个数、表和文件大小规模等，要按可预见的增长对数据及存储要求作出估计。,需求规格书的写作范例,需求规定 故障处理要求：列出可能的故障及其对各项性能所产生的后果。 内部故障 外部故障 其他要求。 保密性：对不同的模块通过分配不同的权限，增加系统的保密性 可维护性：系统结构设计要合理、清晰，文档齐备，并具有较强的可维护性,需求规格书的写作范例,运行环境规定 设备配置：列出处理器的型号、内存容量、外存容量等。 支持软件：操作系统、相关系统软件等 接口。 用户接口 软件接口 其他,需求管理过程,定义需求 需求确认 建立需求状态 需求评审 需求承诺 需求跟踪
7、 需求变更控制,软件需求的变更控制,软件需求变化是每个项目都会遇到的问题，一旦发生需求变化，就不得不修改软件设计、重写程序代码、修改测试用例、调整项目计划等。 需求变更可能来自开发方、客户或产品供应商等，也可能源于项目组内部。主要变更原因： 范围没有圈定就开始细化 没有良好的软件结构适应变化 用户改变需求 对于需求变更的处理流程分为以下步骤：提出变更、变更评估、实施变更。,需求变更控制流程,软件项目需求分析的20条法则,1、分析人员要使用符合客户语言习惯的表达,需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语(例如：采价、印花商品等采购术语)教给分析人员；而客户不一定要懂得计算机
8、行业的术语。,软件项目需求分析的20条法则,2、分析人员要了解客户的业务及目标,只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。,软件项目需求分析的20条法则,3、分析人员必须编写软件需求报告,分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分
9、析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。,软件项目需求分析的20条法则,4、要求得到需求工作结果的解释说明,分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值;虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不
10、一致等。,软件项目需求分析的20条法则,5、开发人员要尊重客户的意见,如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。,软件项目需求分析的20条法则,6、开发人员要对需求及产品实施提出建议和解决方案,通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求；同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效;在彻底弄清业务领域内的事情后，分析人员
11、就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。,软件项目需求分析的20条法则,7、描述产品使用特性,客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。,软件项目需求分析的20条法则
12、,8、允许重用已有的软件组件,需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。,软件项目需求分析的20条法则,9、要求对变更的代价提供真实可靠的评估,有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出
13、一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。,软件项目需求分析的20条法则,10、获得满足客户功能和质量要求的系统,每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。,软件项目需求分析的20条法则,11、给分析人员讲解您的业务,分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标;不要期望分析人员能把握客户业务的细微潜在
14、之处，他们可能不知道那些对于客户来说理所当然的“常识”。,软件项目需求分析的20条法则,12、抽出时间清楚地说明并完善需求,客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。,软件项目需求分析的20条法则,13、准确而详细地说明需求,编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不
15、准确性。在需求分析中暂时加上“待定”标志是个方法。用来指明哪些是需要进一步讨论、分析或增加信息的地方。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。,软件项目需求分析的20条法则,14、及时作出决定,分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。,软件项目需求分析的20条法则,15、尊重开发人员的需求可行性及成本评估,所有的
16、软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。,软件项目需求分析的20条法则,16、划分需求的优先级,绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来
17、缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。,软件项目需求分析的20条法则,17、评审需求文档和原型,客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求;原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。,软件项目需求分析的20条法则,18、需求变更要立即联系,不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚
18、期出现，其影响越大;变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。,软件项目需求分析的20条法则,19、遵照开发小组处理需求变更的过程,为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。,软件项目需求分析的20条法则,20、尊重开发人员采用的需求分析过程,软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过
19、程不太划算，但请相信花在需求开发上的时间是非常有价值的;如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。,需求开发的主要困难与策略,1、知识技能,问题：需求分析员缺乏应用域知识。应用域的知识是无边无际的，任何人都不可能是“万事通”。需求分析员可能是某一领域的专家，但一个企业要谋求发展，不能总在做老的业务，当他接手陌生的业务时，他可能是个“无知”者。策略：要勇于实践，不要逃避。还应当赶紧补习应用域知识，不论是通过自学还是培训的方式。可能的话，最好请既懂软件又懂应用域知识的行家来帮忙。,需求开发的主要困难与策略,2、态度,问题：很多开发人员习惯于被动
20、地对待需求开发。每当遇到麻烦、挫折时，他们会找一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗?如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。,需求开发的主要困难与策略,2、态度,策略：用户说不清楚需求或者需求发生变更都是常见的问题，人们可以设法解决的。开发人员不应该把这些问题当成借口。需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。,需求开发的主要困难与策略,3、合作关系,问题：需求分析员不能与用户建立良好的合作关系。对于一些竞标项目
21、，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你。搞需求开发。用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，你们自己想办法把工作做好,需求开发的主要困难与策略,3、合作关系,策略：出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。对于重大的、复杂的项目，不能完全期望双方能够自发地建立起良好地合作关系。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。如果条件允许，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的
22、危害性，从而促使他们积极友善地参加需求工程中的各项活动。,需求开发的主要困难与策略,4、用户说不清楚需求,问题：用户说不清楚需求。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。有些用户虽然心里明白想要什么，但却说不清楚需求。策略：需求分析员不能以用户说不清楚需求为借口而草率地对待需求开发工作，无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。,需求开发的主要困难与策略,5、双方误解需求,问题：人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了，而用户表达
23、的需求，不同的开发人员可能有不同的理解。 策略：如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，所以应当做好需求确认工作。,需求开发的主要困难与策略,6、开发人员写不好需求文档,问题：需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。或者开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。 策略：要想写出好的需求文档，前提条件是把需求调查工作做好。提高开发人员写作能力，让他们多练习写文档。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降
24、低写作难度。,需求开发的主要困难与策略,7、用户需求变更频繁,问题：在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。或者由于市场变化而导致产品需求发生变更。策略：做好需求变更控制。需求变更通常会对项目的进度、人力资源、经费产生很大的影响，但需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。,需求分析的误区,1、创意和求实,毋庸质疑的，每个人都会为自己的一个新的Idea而激动万分，特别是当这个Idea受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一
25、个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。,永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。,需求分析的误区,2、解剖的快感,几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做?这时，你会发现，需要先后打开三个窗口才能完成这个任务。,永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了
26、分解。,需求分析的误区,3、角度和思维,经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢?”。细细一了解，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次，可是用户每天都要用几百次甚至几千次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗?,永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。,需求分析的误区,4、程序员逻辑,从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说1/0逻辑(或者是说黑白逻辑)，认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。,永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，结论会截然不同。,作业,1.可行性研究的目的是什么？ 2.可行性研究的基本内容有哪些？ 3.需求分析指的是什么？如何进行需求分析？ 4.什么是用户需求？用户需求有哪些特点？,
