已认证58290779
如何进行IT项目的需求调研
第一步：1：找全项目主要干系人，了解他们的想法.2：可用用多种方法进行调研，如问卷调查/头脑风暴/原型法/会议等.3：做好需求确认.第二步：做好调研表格，如下格式第三步：市场调查工作必须有计划、有步骤地进行，以防止调查的盲目性。
一般说来，市场 调查可分为四个阶段：调查前的准备阶段、正式调查阶段、综合分析资料阶段和提出调查报告阶段。
1：调查前的准备阶段。
2：正式调查阶段。
市场调查的内容和方法很多，因企业和情况而异。
3：综合分析整理资料阶段。
当统计分析研究和现场直接调查完成后，市场调查人员拥有 大量的一手资料。
对这些资料首先要编辑，选取一切有关的、重要的资料，剔除没有 参考价值的资料。
IT行业,用项目如何找需求清单
一、如何理解客户业务和客户需求？原则1：由粗到细，从宏观到微观。
必须先从宏观上了解客户业务的全貌，再逐步深入细节。
因为对于客户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。
同时要认识到，对于一个外行而言，我们对细节的深入也必定是有限的，不要指望自己能够无穷的彻底的了解每一个细枝末节。
一是不可能有无限的时间给你了解，二是没有这个必要。
因为未来的系统也不可能完全包办所有业务的细节，还有很多事情是要靠客户企业中这些具有专业技能的人来做的。
原则2：从不同层次的客户代表那里收集不同层次的需求 对于企业高层决策者，他会给你描述一个系统的大的功能蓝图，如使企业具有整体报价能力，能更好的服务于高端客户，能支持企业的重大业务决策等；对于企业各级管理者，他会给你讲述他这一层的管理需求，如能更好的进行部门员工的业绩考核、生成月度报表，更好的进行业务结算等；对于各级业务操作人员，他可能给你谈及很多业务细节和操作细节…… 在由上到下的逐级访谈中，对未来系统的描述就从一个大黑箱变成多个小黑箱，再变成透明、明确、详细的系统定义的过程。
客户业务调研和需求分析注定是一个不断细化的过程，不要指望一次访谈/调研就能穷尽，也不要指望一次开发过程就能得到完全满足客户梦中期待的那套系统来。
因为事实上很多需求是隐性的，连用户都不清楚自己的需求。
只有经过多次循环细化才可能把更多隐性的不断挖掘、暴露出来。
二、如何具体开展需求调研工作？ 在RUP中定义需求工作流程的工作目的如下： 客户和其他涉众在系统的工作内容方面达成并保持一致；2. 使系统开发人员能够更清楚地了解系统需求； 3. 定义系统边界（限定）； 4. 为计划迭代的技术内容提供基础； 5. 为估算开发系统所需成本和时间提供基础；6. 定义系统的用户界面，重点是用户的需要和目标。
首先要做好业务调研。
要尽早把已经收集到的业务资料熟悉起来，并在理解的基础上提炼出问题列表，制成调查问卷。
业务调研的要求是一定要沉下去，深入细致的了解客户的业务流程，而不是急着赶工完成自己的需求工件设计和业务模型的建立。
在了解各项业务流程的同时，与客户一同深入分析业务的实现逻辑，并记录下有关的实现案例信息，收集好、整理好、分析好有关的参考材料。
要把迭代的思想贯穿于从业务调研、需求分析，乃至项目实施的始终。
所谓迭代，就是我们老老实实承认我们没有能力一次就把事情做到尽善尽美。
所以我们就先把一大部分有把握的地方做好，再在前面成功的基础上不断做好剩余的部分，最终就能无限接近于成功。
设计编码过程是如此，业务调研和需求分析也是如此。
企业系统的设计开发与软件产品的设计开发有一个最大的不同，就是企业的需求肯定会变化，过去在变、调研的时候会变，系统实施后还会变。
而我们要做的就是去适应这种变化。
事实上，也正是因为我们采用的是面向对象的方法，才可能做到这一点。
因为面向对象的方法认为：对象的基本属性是客观的和不会频繁变化的，而对象间的关系则是可能不断变化的。
所以我们在业务调研和需求分析中也要认识到这一点，把不变的沉淀下来，把可变的灵活性和变化的自主性留给客户。
各位都是做技术的，在业务调研和需求分析中难免会不由自主的考虑一些技术实现的问题。
值得强调的是：需求与技术无关。
在业务调研的时候要忠实的进行记录，不要因为你个人对实现的疑虑而对用户需求进行（过早的）修改和裁减。
要善于争取客户方各级人员（均是项目干系人，RUP中称为涉众）的支持。
只有得到未来系统用户的充分参与，项目才有可能最终取得成功。
一套缺乏用户参与的系统，即使最后做出来也是注定没有人去用的。
一是要利用客户企业的组织关系，争取到上层的支持，由上到下进行调研配合；二是要会在调研过程中为目标用户树立有针对性的愿景，让他认同愿景的同时主动、积极的支持你的调研过程。
希望可以帮到您，谢谢！
信息系统项目需求调研最常用的有哪些方法
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。
因此，软件需求分析能力和水平，对软件项目至关重要。
一般的分析方法和步骤如下： ⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
展开
如何做需求分析
一、 我们应当如何做需求分析需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。
只有这样才能及时纠正需求理解的偏差，保证项目的成功。
二、我们应当怎样做需求调研1.初识。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
（1）高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析，应当与高层领导谈。
（2）中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。
（3）基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。
但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。
另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。
而他们关心的则是每项操作的细节。
俗话说：万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。
随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。
在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。
不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。
尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
（1）由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。
划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；（2）集中式的业务研讨形式和分散式的业务研讨形式；（3）有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：（1）由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。
这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
（2）能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。
这类客户，他们能熟练使用电脑，对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的 。
但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。
（3）能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。
这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。
解决办法：业务领域分析：客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？（1）我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
（2）在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。
（3）还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。
（4）需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。
只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代...
数据库需求分析
展开全部 数据库设计1、数据库需求分析1）针对超市进销存管理系统，分别对采购部门、销售部门和库存保管部门进行详细的调研和分析，总结出如下的需求信息：商品按类管理，所以需要有一商品类型信息。
商品必须属于一个商品类型。
如果一个商品类型存在商品，或存在下级商品类型，则该类型不可删除。
需要记录供应商品信息。
在涉及商品数量的地方，要给出相应的单位。
商品销售信息单中要包含登记商品销售数量、单价等信息。
在进货信息中要包含商品供应商等信息。
商品报损要有报损原因。
进货、销售、报损操作要有相应操作员信息。
只有管理员登录之后才可以使用系统。
默认的管理员不可以删除。
进货、销售、库存、报损信息都要可以添加、修改、删除、分类查找。
当进行进货、销售和报损操作后，能相应更新库存。
需要对进货、销售、库存、报损进行分析，总结热门商品。
2）经上述系统功能分析和需求总结，考虑到将来功能的扩展，设计如下的数据项和数据结构：商品类型信息，包括数据项有：商品类型编号、商品类型名称等。
商品信息，包括的数据项有：商品编号、商品名称、商品介绍、库存量等。
商品单位信息，包括单位编号、单位名称等。
供应商信息，包括供应商名称、介绍等。
进货信息，包括进货商品、数量、单位、单价、进货时间经手人等。
销售信息，包括销售商品、数量、单位、单价、登记时间等。
报损信息，包括报损商品、数量、单位、原因、登记时间等。
管理员信息，包括管理员账号、密码、是否是默认账号等。
2、数据库概念结构设计本系统根据以上的设计规划出的实体有：商品类型信息实体、商品信息实体、商品单位信息实体、供应商信息实体、进货信息实体、销售信息实体、报损信息实体和管理员信息实体。
...
软件开发项目需求调研怎么做
1.评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。
2.评审者在收到邮件后，进入评审任务中，对评审内容进行评审，同时填写并提交各自的评审意见。
3.评审组长汇总所有的评审意见，并在评审会上依次过所有的评审意见，对评审意见进行修改或删除，填写问题跟踪，形成此次评审会上最终的评审意见及问题跟踪表。
4.评审组长制作评审报告，并形成评审结论，以邮件的形式通知所有评审者。
6.评审组长跟踪所有问题，并可以依次关闭每个问题。
当然，在这个需求列表中，客户提出了一些名词，比如评审计划、评审意见、评审组长等。
我们在整理需求列表的同时，应当注意整理这些名称，弄清它的内涵外延，以及它们相互之间的关系、作用。
这将为我们后面的领域模型分析提供素材。
毫无疑问，这样的需求列表过于粗略。
因而在后面的业务讨论中，我们逐项对它们进行了细化：1.评审发起人填写一份评审计划，详细记录评审时间、评审内容、评审者、评审地点，制订评审组长，并预计评审工作量，发起一个评审任务。
1.1 评审时间应当分为数个阶段分别制订时间计划，如评审准备、评审会议、评审报告；1.2 评审内容应当可以上传数个文件，分别描述文件的内容、作者、编写日期、版本号，供评审者下载与查看；1.3 填写评审者时，选择一个评审者为评审组长，评审发起人不能是评审组长；1.4 评审地点与预计评审工作量只需直接填写；在我们后面的用例分析中，我们对这段需求列表进行了大量的分析设计。
但这些都是设计与实现，它们会出现在后面的用例分析及其模型中，却不应出现在需求列表中。
在后来的升级开发中，客户又提出了发邮件通知的功能。
将该功能描述出来，并添加到需求列表中：1.5 评审计划提交以后，以邮件的形式发送给每个评审者，通知该评审任务。
有了这样的需求列表，当需求分析工作完成时，我们将一项一项检查用例模型是否满足需求列表的内容；当软件开发完成时，我们将一项一项检查软件功能是否满足需求列表的内容；当用户验收时，我们同样使用需求列表，一项一项检查我们的软件是否满足用户需求。
我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：快速原型法我们应当怎样做需求确认：需求规格说明书我们应当怎样做需求确认：评审与签字确认会（续）
网站和软件的产品调研分析有哪几类,如何做用户需求的收集与设计？ ...
设计产品前，最好要面向用户、市场、竞品、自身、同事。
其中同事又分领导、设计、技术、测试、运营、数据、推广、销售。
如下是部分介绍，更多课程可以在馒头商学院找下刘佳讲师录制的。
调研的类型：建立用户画像（人群定位和特点）；调研用户体验、使用场景；调研用户的需求 （URD）;调研竞争和市场发展（MRD）;调研产品优缺点；调研领导、同事的需求；调研投入和可盈利性（SRD）过程和方法如下：明确收集类型：分析市场、用户、自身、领导、商业。
收集对象时网友、客户、运营部门、销售等部门。
选择采集方法：沟通方式、定量、定性执行需求收集：时间、地点、步骤等准备。
过程要高效、准确的记录。
需求整理和分析：利用5W2H原理分析出重点需求。
PM和领导和需求方确认。
测试计划有哪些定义的内容？
川软教育软件测试培训基地网站上面有详细的介绍，转抄过来看下，或者可以到他们网站上面详细看下，测试方面的技术知识内容挺全的。
一、 新产品或工程管理流程1、 需求调研在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。
2、 制定测试计划进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。
3、 需求Review开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。
4、 设计Review在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。
设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。
5、 测试设计在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。
然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。
每个测试用例必须包括以下几个部分：(1) 标题和编号(2) 测试的目标和目的(3) 输入和使用的数据和操作过程(4) 期望的输出结果(5) 其他特殊的环境要求、次序要求、时间要求等6、开发测试工具和准备测试数据在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。
7、测试执行当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。
在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。
为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。
8、回归测试在测试中发现的任何问题和错误都必须有一个明确的解决方法。
一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。
另一方面，对于版本更新后的软件也必须进行同样的测试过程。
9、测试分析报告测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。
如何系统的进行用户需求分析
展开全部 1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...
