需求分析
第二阶段项目的需求分析
需求分析阶段的主要工作是由需求顾问负责走访用户，从用户访谈中归纳、抽取总结出用户的需求，一般要经过定义用户场景，定义用户用例，编写需求说明书三个主要步骤，如项目需求分析阶段图阶段图所示。软件测试工程师在需求分析阶段的工作主要是协助需求顾问或者开发工程师完成需求分析的辅助工作。
项目需求分析阶段工作图
需求分析阶段的工作是项目经理带领下，主要由需求顾问完成的。开发和测试团队中的资深工程师也会参与一部分需求说明书的编写工作。项目组中不同角色的人员与交付物之间的关系如如项目需求分析阶段各团队与交付物关系图所示。
项目需求分析阶段项目团队与交付物关系图
第四章用户场景
上一章的项目启动会完成了项目的启动和计划阶段，从本章起项目开始实施，进入正式开发阶段。软件项目的开发首先是需求分析，而需求分析的第一项工作就是定义用户场景。这一章的工作是定义用户场景，由需求顾问负责完成。资深的开发工程师和测试工程师会参与其中一部分分析和设计工作。技术文档工程师在这个阶段的主要工作是协助需求顾问编写场景定义，为后续的需求分析工作打下基础。本章对用户访谈、访谈整理、定义岗位职责、定义系统用户及定义系统用户场景等步骤做了详细讲解，并提供了相应的写作训练。
4.1 概述
定义用户场景的工作过程比较长，中间的交付物比较多，工作量也比较大，技术文档工程师需要协助需求顾问，参与其中的每一个步骤，并且在需求顾问的指导下编写每一步交付物的内容，实施步骤和交付物如图4-1所示。
图4-1 定义用户场景的交付物及实施流程图
1.背景
定义用户场景是确定系统需求的首要的工作。用户场景的主交付物——《用户场景描述》是尝试模拟用户的各种使用系统的情况，这是建立完善的测试用例的依据之一。定义用户场景需要从用户访谈开始，再经过访谈整理、定义岗位职责、定义系统用户、归类用户需求/导出系统模型等步骤中间工作，最后定义系统用户场景。技术文档工程师通过参与用户场景的编写来了解系统，熟悉系统，为后续其他技术文档的编写打下良好的基础。
以本书使用的《公交运营调度系统》为例，由项目经理组织用户访谈，需求顾问整理访谈内容后定义出岗位职责、系统用户、系统模型和用户场景，最终提交《用户场景描述》。
2.交付物
《用户场景描述》
3.团队分工
技术文档工程师在此阶段主要与需求顾问紧密合作，根据访谈记录整理出《访谈故事卡》；获取系统用户及其岗位职责信息，来完《岗位职责表》和《系统用户表》；并获取用户场景信息，来最后完成《用户场景描述》。并且还需要通过需求顾问的审核后，才能交付于整个开发团队。
表4-1 项目计划团队分工
表4-2 项目计划团队任务目标
4.知识目标
(1)了解需求分析的重要性。
(2)理解需求分析阶段工作流程及主要交付物。
(3)了解用户场景和用例的区别。
(4)了解岗位职责与系统用户的关系。
(5)掌握用户故事卡与系统需求的导出关系。
5.能力目标
(1)能够独立利用调查问卷和访谈调查表进行客户用户访谈，了解用户对系统的要求。
(2)能够独立利用用户故事卡整理访谈记录，熟悉用户业务。
(3)能够独立进行岗位、职责以及系统用户定义。
(4)能够在需求顾问指导下，进行系统需求模型的推导。
(5)能够在需求顾问指导下，定义软件的系统需求，为定义系统测试需求做好准备。
(6)能够独立撰写用户场景，在熟悉用户场景的基础上设计测试用例。
1.2实施步骤
1.步骤说明
定义用户场景主要由需求顾问负责，需要下面几步完成：
第一步用户访谈
走访用户，调查用户需求，将访谈结果形成《用户访谈原始记录》。
第二步访谈整理
对《用户访谈原始记录》进行整理，按6W的方式进行组织，整理成“故事卡”形式的文档。
第三步定义岗位职责
将“故事卡”进行总结、归类，列出用户单位中的每一个岗位，以及这个岗位从事的业务。
第四步定义系统用户
合并相同的职责，将职责相同的岗位合并为一个，形成系统用户，岗位的职责形成系统用户的业务需求。
第五步归类用户需求，导出系统模型
根据系统用户的业务需求推导出系统要实现的功能，以及为了实现这些功能系统应该具备的资源，包括网络、数据库和通信设备等。
第六步定义系统用户场景
根据岗位职责、系统用户的定义，将场景明确、详细地描述下来。
文档交付物：第二步：《访谈故事卡》；第三步：《岗位职责表》第四步：《系统用户表》；第五步：《用户场景描述》
文档质量要求：
?《访谈故事卡》所有访谈的结果需要按6W的方式进行组织，需要将整理后的结果与访谈对象书面确认。
?《岗位职责表》中的不能客户方干系人的岗位，也不能有任何遗漏；
?《系统用户表》定义出的系统用户不能超出客户方干系人的范围，也不能有遗漏。
?《用户场景描述》要分总场景和分场景来描述，分场景按照系统用户的职能来划分，每个分场景不能有重合的内容。
文档作用/质量要求：
?《访谈故事卡》是需求分析阶段所有分析的基础，所有的工作和文档都由此而来。
?《职责表》用于定义系统用户，职责相近或相同的用户被称为系统用户。
?《系统用户表》的系统用户将代替现实中的用户，作为系统的角色参与所有的需求分析中来，因此定义出的系统用户要全面，不能有遗漏，否则系统的功能将有缺陷。
?《用户场景描述》是定义用户用例的基础，所有用例都会从场景中抽取出来。为了让抽取工作更加准确，因此需要有清晰、明确的上下文环境，说明场景的发生背景及时间；需要从用户的角度出发，描述用户做什么，与系统的交互行为，同时需要描述用户对出现问题的反应
文档逻辑结构：
?《访谈故事卡》
o被访人员的信息，包括姓名、职位、部门、谈话时间等。
o用户谈话记录，用户谈话的原始内容
o整理出来的故事：按照事件、缘由、流程、人物、时间、地点来描述
o用户确认意见：用户对谈话整理成故事卡确认
?《岗位职责表》
o岗位名称：用户岗位的名称
o职责名称：该岗位这项职责的命名
o职责描述：职责内容
?《系统用户表》
o用户岗位：用户在系统中被定义的岗位
o用户职责：在某一岗位下用户的职责
o用户业务需求：某个用户职责下的业务描述
?《用户场景描述》
o用户场景汇总：所有用户场景的一个汇总表
o单个用户场景描述：描述单独一个用户场景，主要包括场景名称、场景代码、场景描述三部分。
2．完成环节
编写《用户访谈故事卡》。
访谈故事卡包含了被访人员的信息、用户访谈记录、整理故事、公用信息、整理人及用户和负责人的确认。
访谈故事卡模板如表4-7所示：
编写《岗位职责表》。
岗位职责表包含：岗位名称、职责名称、职责描述，如下表所示：
编写《系统用户表》。
用户表在岗位职责表的基础上，用系统用户和业务需求代替了职责描述和备注，用以表示用
编写《用户场景描述》。
用户场景描述包括《总场景描述》和《分场景描述》。
总场景描述以表格的形式列举了不同系统角色的每一个业务需求对应的用户场景。其中的“用户场景”是对场景的高度总结，也通常被用作用户场景的命名。
总场景模板包括系统角色、业务需求及用户场景这几部分。
分场景描述用于解释系统的所有单个场景，所有在系统总场景中出现的场景都要应用此模板进行详细描述。
《分场景模板》中包含了用户场景的名称、用户场景的代码以及场景描述。
4.3 实训任务
协助开发人员编写《用户场景描述》中的《用户分场景描述》
(1)交付物：《用户分场景描述》
(2)交付形式：MS Word文档
(3)提示：根据岗位职责和系统用户的定义，编写《用户场景描述》中的《用户分场
景描述》。
4.4评分标准
按照《用户分场景描述》的内容，每一部分的评分标准和分值如表4-8所示。
4.5技能应用小结
1.技术文档编写能力
从用户场景开始，技术文档工程师开始正式参与软件项目的开发工作，这个阶段是开始接触和参与需求分析的工作。通过协助需求顾问编写《用户场景描述》，使得技术文档工程师能够理解用户使用系统完成业务处理的过程，熟悉系统用户的业务需求，为后来的其他的开发工作中涉及的技术文档编写打下基础。
所在步骤：所有步骤。
4.6 本章知识点
1.用户故事卡
访谈故事卡是对软件（或系统）用户或客户有价值的功能的描述。用来总结每个用户从事的业务及其过程。
访谈故事卡由以下三方面组成。
(1)故事卡的描述信息，；例如被访人的信息、访问的时间和地点，用来作为故事卡的提
示。
(2)有关故事的对话，用户的原始谈话记录，是具体化的故事细节。
(3)故事卡的整理内容，用于表达和编辑故事细节且可用于确定故事何时完成。
编写需求故事卡是企业、分析师和IT开发人员等利益相关方协作的过程。
用户故事是从用户角度对应用程序做出的简短描述。他们是一些零散的具有商业价值的功能描述。一个高水平的用户故事非常简单：一个题目加一个或两个简单的英语句子加以描述。一个最基本的用户故事点明谁需要这个故事、这个故事需要做什么和为什么这个故事有价值：“作为X，我需要Y，以达到Z”。
首先，作为……，这一点定义了谁将是最终用户。这与以用户为中心的设计（UCD）十分相似：尊重和理解用户。企业、开发商和设计人员过于习惯事后猜测用户，开发出可能只适合商业“高级用户”的复杂功能，却忽视了大多数的初级用户。
我想要……，用于理解用户目标和任务，并达到该目标。为满足用户及其目标的要求，
会把开发重点放在需求上。考虑的内容不但是“如何开发”，还有“开发什么”。也许客户的一款金融产品的需求和银行、呼叫中心的需求看上去是一样的，但他们的实现和交付的信息是不同的。
用户故事仅仅是一种商业语言的表述，不应该明确具体的实施细节。例如，陈述需要存储信息，但是不要陈述满足这种需求的机制（例如，数据库、xml文件等）。用户故事必须有商业价值。在最原始的分析中，商业价值通常与金钱相关，例如促进收入增加，或者促进成本减少。因此，这种商业价值会定义用户故事的优先级别。那些具有最高商业价值的用户故事会最优先考虑，而最小商业价值的会最后考虑。开发团队先估计完成每个用户故事所需要的付出，然后在这个迭代中对用户故事的数量设置一个截点。客户可以重新定义用户故事的优先级别，直至他们满意的最高优先级的用户故事符合标准。
所在步骤：第二步访谈整理。1．岗位职责
岗位是组织为完成某项任务而确立的。由工种、职务、职称和等级内容组成。职责是职务与责任的统一，由授权范围和相应的责任两部分组成。
岗位职责一般包括两个部分的内容，首先是岗位工作概要，而后是具体职责。工作概要需要说明了岗位工作的内容，活动内容的权限，指导思想和执行的依据等。通常采用“三段论”的方式来描述，即“依据/按照……，执行……（行动），达到……结果”。
具体岗位职责包括责任和相应权限，依据岗位工作实际需要，按照工作重要性及比重，设计工作权重，依据权重逐项列出工作职责。工作权重指本项工作的工作量占本岗位工作总量的比例，一般情况下可以用时间比例来代替，所有工作的总权重为100%。责任包括领导管理责任和直接实务操作责任，非管理岗一般没有领导管理责任。不论何种岗位，其责任都应当由工作项目、工作描述、绩效标准三个部分构成。工作项目和工作描述应当说明本岗位的工作任务、培训、指导、服务、计划、沟通等方面的职能和各种责任。为了完善岗位说明书的功能，应当从时间、数量、质量和成本等方面来设计绩效标准，绩效标准是衡量各项工作完成情况的指标和标准，为绩效考核的可操作性提供保障。一般也采用“三段论”的格式撰写岗位具体职责。
工作权限是指在一定的工作岗位要承担相应的责任，必须要有相对应的人、财、物上的支配权限，包括岗位人员的决策权，以及管理人员的人事权限、监督权以及审批权等。
所在步骤：第三步定义岗位职责。
3.系统用户
系统用户是那些在通常意义上使用信息系统或者受到信息系统影响的“客户”--如收集、验证、录入、响应、存储、交换数据和信息的用户。
系统用户是信息系统的使用者，在信息系统中具有一定权限，能够使用系统的功能完成自己的业务活动。
在系统中，同样是使用系统，不同的用户在使用系统时能够使用的功能是不一样的，这是由用户的角色决定的。每个用户都有自己的角色，而不同的角色对信息系统操作的功能和权限是不一样的。例如，系统用户一般分为系统管理员（有的系统也叫超级管理员）和普通用户。系统管理员可以对整个系统进行管理，包括给系统增加用户、分配用户权限、数据备份、系统恢复等；而普通用户只能按照系统管理员分配的权限完成相应的功能，而不能对系统进行管理。
系统中根据不同的权限将用户划分为各种角色，每一种角色就是一个用户组。每个用户组里的用户具有相同的权限。例如在企业的进销存管理系统中，每个销售人员都是系统用户，但是都属于销售部门用户组，都具有使用系统完成销售业务的权限。而采购人员则不具备使用系统的销售功能的权限。
要想使用一个信息系统，必须要先成为系统的用户。而要成为系统的用户，必须先在系统注册用户名，并设置相应的口令，由系统管理员分配给一定的角色，也就是分配给一定的权限。这个过程就是注册。经过注册的用户才能成为系统用户。注册可以由系统管理员完成，也可以由用户自己填写注册信息，经过系统管理员审核、授权来完成。
所在步骤：第四步定义系统用户。
4.需求分析
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
需求分析是软件生命周期的重要工作，也是决定性工作。只有通过需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求说明，从而奠定软件开发的基础。
所谓“需求分析”，是指对要解决的问题进行详细分析，弄清楚问题的需求，包括需要输入什么数据、要得到什么结果、最后应输出什么。可以说，“需求分析”就是确定要计算机“做什么”。
在软件工程中，需求分析指的是在建立一个新的或改变一个现存的计算机系统时描写新系统的目的、范围、定义和功能时要做的所有工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定用户的需求。只有确定了这些需求后，才能够分析和寻求新系统的解决方法。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中，越来越多的人认识到它是整个过程中最关键的环节。如果在需求分析时分析者未能正确认识到用户需要，那么最后的软件实际上不可能达到用户的需要，或者软件无法在规定的时间内完工。
需求分析是一项重要工作，也是最困难的工作，该阶段工作有以下特点。
1.用户与开发人员很难进行交流。
2.用户的需求是动态变化的。
3.系统变更的代价呈非线性增长。
所在步骤：第五步归类用户需求导出系统模型。
5．用户场景
场景经常被交互设计师用来描述业务建模工作流程中用户的使用经历，但是在需求工作流中，场景则是用例的一个具体实例。
场景就是一个故事，是以特定的格式讲述的故事。术语“场景”通常用来表示电影或戏剧的情节草稿。但在需求工作中，用这个术语来表示研究的一部分工作的情节。使用“情节”这个词是为了暗示将工作分解为一系列的步骤或情景。
业务用例是一些不连续的功能，它按它自己的连续时间框架发生，可以认为它与其他部分工作的功能是分开来的。业务分析师使用场景向感兴趣的风险承担者描述业务用例。场景是一种中性的媒体，所有人都能理解，业务分析师用它来对工作需要做的事情取得一致意见。在达成一致意见之后，风险承担者可以决定多少工作将由产品来完成。然后会产生另一个描述用户或参与者与产品交互的场景。
场景讲述了业务用例的故事。
业务用例场景的目的是帮助需求分析师和风险承担者对适用于特定业务事件的业务规则达成一致的理解。编写场景可以测试是否进行了足够的需求分析工作，需求分析师是否需要问更多的问题并进行进一步的调研。
产品用户场景确定了针对特定业务用例的产品的边界或范围。限制条件、目标，以及技术上和业务上的指导原则是确定产品用例边界时必要的输入信息。
所在步骤：第六步定义系统用户场景。6． 6W分析
也叫六何分析法，是一种思考方法，也可以说是一种创造技法。可以用来对选定的项目、工序或者操作进行分析，即用Who（谁）、When（什么时候）、Where（在哪里）、What（什么事情）、Why（为什么）、How（如何发生），了解分析问题的来龙去脉以及实现目标的各种问题，6W为人员（Who）、地点（Where）、时间（When）、事件（What）、原因（Why）、方法（How）。
Why:用户使用该功能能够完成什么？用户对该功能的期望是什么？
Who：使用该功能的用户类型（用户/系统）有那些？他们的使用有什么差异？该需求是否涉及多用户使用，最大的并发数是多少？
When：什么时间使用该功能？
Where：用户使用该功能时，一般处在什么环境？在不同的应用环境中，对该需求有什么样的要求？
What：和该需求产生交互的需求有那些？交互的需求会对该需求有什么影响？
How: 用户使用该需求要完成的操作流程有那些？每一步又如何交互？如果用户无法完成该需求，会又那些异常退出情况？
同理，目标的制定也可以通过这种方法。这种方法看似有点枯燥、繁琐，但是却能深入地分析和理解自己的目标。通过制定6W分析表，可以对目标进行逐一分析，当整个矩阵都分析出来之后，目标的合理性也就出来了。
-需求分析方法论
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
什么是项目需求分析
什么是项目需求分析？ 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS 文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死. 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求. 三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审. 问题识别 就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标. 分析与综合
需求分析规范
1目的 对项目的需求分析活动进行控制，明确需求规格说明书的要求。 2适用范围 适用于项目的用户（包括确定顾客和潜在顾客）需求分析活动。 3职责 项目负责人指定人员组成用户需求分析小组，并委任需求分析负责人。 需求分析组了解和分析用户的需求，并编制《需求规格说明书》。 项目负责人负责组织对需求规格说明书的评审。 4工作流程 4.1确定需求分析人员 在项目立项，完成项目策划后，项目负责人指定人员组成需求分析小组，并委任负责人。 4.2需求分析实施 需求分析小组进行用户需求分析工作，主要了解以下的内容： 用户业务与项目有关的部分； 用户的工作流程； 用户的相关部门及职责； 使用人员的技术水平； 用户原有系统的现状； 用户对项目交付成果的期望和具体要求。 4.3编制《需求规格说明书》 在充分了解用户需求的基础上，需求分析小组编写《需求规格说明书》，要求参见《需求规格说明书》模板。该模板规定了《需求规格说明书》的内容和要求，编写时可根据具体的项目情况进行调整。必要时，可在有关的章节中引述其它资料作为附录。 4.4需求评审 为保证需求定义的正确性、完整性和清晰性，应对《需求规格说明书》进行评审，
评审主要考虑以下准则： 客户或潜在客户需要的可追溯性； 与客户或潜在客户需要的一致性； 可测试性； 系统(子系统)设计的可行性； 操作和维护的可行性。 4.5需求管理 《需求规格说明书》经评审后，按《配置管理程序》进行管理；需求的修改与变更，应按照《更改控制程序》执行。 5相关程序文件 序号名称编号 1 配置管理程序WAYOUT-QP-02 2 更改控制程序WAYOUT-QP-03 6记录 序号名称模板编号 1 需求规格说明书WAYOUT-QF-05 2 评审报告WAYOUT-QF-06
怎样做需求分析之五：调研之需求研讨.
怎样做需求分析之五:调研之需求研讨 作者 : fangang 发布时间 : 2012-02-08 00:20 前面我们探讨了业务研讨会应当怎样组织, 下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底, 那么讨论业务需求就是需求分析人员的功底。 以往我们常常认为, 需求分析是一件最简单的事情。客户说他们需要做一个什么软件, 有些什么功能, 我们照着做就可以了,所谓的需求分析员就是需求的记录员。我要说, 这是一个极大的错误,许多失败的软件项目, 或者说软件项目中的需求问题,大多都源于此。经过人们多年的研究发现, 在需求分析过程中, 客户存在的最大问题就是提不出正确的需求, 这表现为几种形式: 1. 由于对软件不了解,客户提不出需求,不知道软件最终会做成什么样子。这类客户在需求讨论过程中,往往只能描述目前自己手工管理的方式是怎样的,不知道计算机会怎样管理。 2. 能提出一些业务需求,但当软件做出来摆在自己面前时,需求就变了。这类客户,他们能熟练使用电脑, 对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的。但是,由于没有实物,在软件中的一些具体操作并没有完全想清楚。因此,当软件真正做出来摆在自己面前时, 甚至经过一系列流程操作以后, 会对一些操作提出变更需求。他们正如那句经典的话说的:“I have changed when it saw it.” 3. 能非常详细地提出业务需求,甚至有时候该怎么做的提出来了。这类客户,参与过很多软件信息化建设, 甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体, 甚至怎样实现都说出来了, 但这些有时候不是最佳设计方案、可能在技术上难于实现, 甚至有些就是过于理想化而不可实现。 因此, 我在进行需求研讨的时候, 首先跟客户探讨的不是软件功能, 而是客户现有的业务知识,用专业的话叫“ 业务领域分析” 。客户现有的业务流程是什么样的,
培训需求分析的方法和工具
培训需求分析的方法和工具 培训需求分析是企业培训的出发点，也是最重要的一步工作。如果需求分析不准确，就会让接下来的培训偏离轨道，做无用功，浪费企业的人力、物力和财力，却收不到应有的效果。企业要进行有效的需求分析，就必须采取合适方法和工具，本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。 一、需求分析的方法和工具 1.1 调研问卷法 调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题，以书面问卷的形式发放给培训对象，待培训对象填写之后再收回进行分析，获取培训需求的信息和数据。 调研问卷法进行培训需求分析，可以遵循以下五个步骤，见表1： 在设计调研问卷的问题时，应该注意下几个问题： 1、问题尽量简短，并注意使用简单的、固定用法的术语，避免使用读者不了解或者容易引起歧义的名词； 2、一个问题只涉及一件事，避免“结构复杂”的问句； 3、题目设计要简单，不要使作答者作计算或逻辑推理； 4、避免出现诱导答案的问题，保证作答者完全陈述自己观点。
备注：填表时在对应的内容下面用“√”标明。 1.2 访谈法 访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息，与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据，比如事实、数据等，包括印象、观点、判断等信息。 访谈法可以遵循以下几个步骤进行，见表3：
1.3现场取样法 现场取样法一般较多使用于服务性行业的培训需求调查（如饭店、卖场等），是通过选取培训对象现场实际工作的部分片段进行分析，以确定培训需求的一种分析方法。现场取样法主要包括两种形式：拍摄和取样。 拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备，对培训对象的现场工作过程进行实际拍摄，事后通过录影带进行观察分析，得出培训需求结论。表5为拍摄样板的示例。
需求分析最终结果是产生
一、选择题 1．需求分析最终结果是产生（） A．项目开发计划B．可行性分析报告C．需求规格说明书D．设计说明书答案：C 2．需求分析中，开发人员要从用户那里解决的最重要的问题是（） A．让软件做什么B．要给软件提供哪些信息 C．要求软件工作效率怎样D．让软件具有何种结构 答案：A 3．DFD中的每个加工至少有（） A．一个输入流或一个输出流B．一个输入流和一个输出流 C．一个输入流D．一个输出流 答案：B 4．数据字典总，一般不出现的条目是（） A数据流 B 数据存储C．加工D．源点与终点 答案：D 5．分层数据流图是一种比较严格又易于理解的描述方式，它的顶层图描述了系统的（）A．细节B．输入与输出C．软件的作用D．绘制的时间 答案：B 6．需求规格说明书的内容不应包括对（）的描述。 A．主要功能B．算法的详细过程C．用户界面和运行环境D．软件性能答案：B 7．需求规格说明书的作用不应包括（） A．软件设计的依据B．用户与开发人员对软件要做什么的共同理解 C．软件验收的依据D．软件可行性研究的依据 答案：D 8．SA方法用DFD 描述（） A．系统的控制流程B．系统的数据结构 C．系统的基本加工D．系统的功能 答案：D 9．一个局部数据存储当它作为（）时，就把他画出来。 A．某些加工的数据接口B．某个加工的特定输入 C．某个加工的特定输出D．某些加工的数据接口或某个加工的特定输入输出答案：D 10．对于分层的DFD，父图与子图的平衡指子图的输入、输出数据流同父图相应加工的输入、输出数据流（） A．必须一致B．数目必须相等C．名字必须相同D．数目必须不等 答案：A 11．需求分析阶段不适用于描述加工逻辑的工具是（） A．结构化语言B．判定表C．判定树D．流程图 答案：D 12．SA方法的分析步骤是首先调查了解当前系统的工作流程，然后（） A．获得当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的逻辑模型B．获得当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的物理模型
需求分析、概要设计、详细设计的标准格式.doc
需求分析，概要设计，详细设计的标准格式 一、开发计划 （一）引言 1、目的 说明编制开发计划的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）概述 1、工作内容 2、主要参加人员 3、成果 列出要提交给用户的程序文件、文档或服务的名称，及非移交 成果的名称。 4、完成的最迟期限 （三）实施计划 1、任务的分解及人员分工 列出各项任务及其负责人和主要参加人员。 2、进度 列出各任务的开始日期和完成日期。 3、关键问题 列出影响整个开发项目的关键问题，技术难度、风险及处理方 案。 （四）支持条件 1、计算机系统支持 2、需要由用户承担 二、需求分析说明书 （一）引言 1、目的 说明编制需求分析说明书的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）概述 1、目标 说明本项软件开发意图、应用目标、作用范围等，以及所开发的软件与其它软件的关系。
2、用户特点 列出使用本软件的用户类型、特点、其教育程度和技术特长。 3、约束和假定 列出本软件开发工作的假定和约束。 （三）需求规定 1、对功能的规定 根据功能模型逐项说明本软件各项功能的详细需求。 列出完成各项功能所需输入，处理，输出及所需控制等。 2、对性能的规定 包括精度、时间特性要求、灵活性。 3、数据要求 数据分为静态数据和动态数据两类。 静态数据是指在程序运行过程中一般不改变的数据； 动态数据是指在运行中发生变化、需要输入输出的数据。 （1）数据描述 （2）数据采集 （3）输入输出要求 （4）其它要求 （四）运行环境规定 （1）硬件 包括处理机、网络、输入输出设备及其它设备。 （2）软件 列出支持软件。 （3）接口 包括必要的硬件接口、软件接口、通讯接口等。 （五）关于不可能实现的用户要求的说明 三、概要设计说明书 （一）引言 1、目的 说明编制概要设计说明书目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 （二）总体设计 1、需求规定 简述本系统的主要功能、性能等要求。 详见需求分析说明书。 2、运行环境 简述本系统的运行环境规定。 详见需求分析说明书。
需求分析：需求调研的七种方法
需求分析：需求调研的七种方法要想给人做管理软件，首要的事情自然是把人家现在的业务内容、管理方式弄清楚。即使你是这个领域的业务专家，也要明白一点，无论业务内容是否相同，管理方式一定是不同的，业务可以复制，技术可以复制，管理不能复制。例如，要给仓库做管理系统，需要先了解这个仓库是怎么管理的，怎么出库，怎么入库，怎么盘点，怎么核算；需要给采购部做管理系统，需要先了解采购部是怎么运作的，怎么制定采购计划，怎么下采购单，怎么签订采购合同，等等。 开发信息管理系统，首当其冲的需求来源就是如何将现在的手工业务电子化，没有这一步，说什么资源整合，说什么提高效率，说什么降低成本，说什么智能决策，都是浮云。对于管理软件来说，需求获取重点在如何理解客户业务，这是需求获取阶段最重要，也是最困难的事情，当然，对于需求分析者来说，理解业务与需求获取往往是交错进行的，很难割裂开来。 需求获取一般包括这几种方式：观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法。这是需求调研的“七种武器”，它们各有优缺点，无论你想要了解的是什么需求，都需要将这些方式组合应用，针对你想要了解的内容，以及需要了解的对象的工作特点，采用不同的方式。学会并坚持使用这七种武器后，我想你很快就会成为需求调研的真正高手。 观察法 观察法，就是你自己跑到工作现场，看！这个看上去相当简单，貌似走马观花，有些不在行的兄弟会弄得跟公费旅游一般，车间里走走散散心，撩撩HR妹子，就认为是观察法调研了，其实不然。这种方法，关键是要看人家是怎么工作的，拿了什么，干了什么，用了什么工具，送出去什么，什么时候填写了什么单据，制作了什么报表，等等。 体验法 体验法，就是你自己亲自到相关部门去顶岗，做一段时间的业务工作，有了亲身体验自然更容易理解这个岗位的工作。这种方法，最大的优点就是理解业务比较深刻。一旦你几乎成了某岗位的一员后，想想，还有什么比自己帮自己做软件更能够把握需求呢？要给超市收银员写个软件，先到超市卖几天东西，要给仓库做软件，先到仓库发两天货，你的软件偏离用户需求的可能性会大幅度降低。
网站需求分析
网站需求分析模板 一、哪些人应该参与网站开发项目的需求分析活动 需求分析活动其实本来就是一个和客户交流，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）以明确项目目的的过程。这个过程中也同时包含了对要建立的网站基本功能和模块的确立和策划活动。所以项目小组每个成员、客户甚至是开发方的部门经理（根据项目大小而定）的参与是必要的。而项目的管理者在需求分析中的职责有如下几个方面： 1、负责组织相关开发人员与用户一起进行需求分析。 2、组织美术和技术骨干代表或者全部成员（与用户讨论）编写《网站功能描述书（初稿）》文档。 3、组织相关人员对《网站功能描述书（初稿）》进行反复讨论和修改，确定《网站功能描述书》正式文档。 4、如果用户有这方面的能力或者用户提出要求，项目管理者也可以指派项目成员参与，而由用户编写和确定《网站功能描述书》文档。 5、如果项目比较大的话，最好能够有部门经理或者他授权的人员参与到《网站功能描述书》的确定过程中来。 二、完整的需求调查文档记录体系 在整个需求分析的过程中，将按照一定规范的编写需求分析的相关文档不但可以帮助项目成员将需求分析结果更加明确化，也为以后开发过程中做到了现实文本形式的备忘，并且有助于公司日后的开发项目提供有益的借鉴和模范，成为公司在项目开发中积累的符合自身特点的经验财富。 需求分析中需要编写的文档主要是《网站功能描述书》，他基本上是整个需求分析活动的结果性文档，也是开发工程中项目成员主要可供参考的文档。为了更加清楚的描述《网站功能描述书》往往还需要编写《用户调查报告》和《市场调研报告》文档来辅助说明。各种文档最好有一定的规范和固定格式，以便增加其可阅读性和方便阅读者快速理解文档内容，相关规定将在本文后面讨论。 三、向用户调查些什么 在需求分析的工程中，往往有很多不明确的用户需求，这个时候项目负责人需要调查用户的实际情况，明确用户需求。一个比较理想化的用户调查活动需要用户的充分配合，而且还有可能需要对调查对象进行必要的培训。所以调查的计划安排：时间、地点、参加人员、调查内容，都需要项目负责人和用户的共同认可。调查的形式可以是：发需求调查表、开需求调查座谈会或者现场调研。调查的内容主要如下： 1、网站当前以及日后可能出现的功能需求。 2、客户对网站的性能（如访问速度）的要求和可靠性的要求。 3、确定网站维护的要求。 4、网站的实际运行环境。 5、网站页面总体风格以及美工效果（必要的时候用户可以提供参考站点或者由公司向用户提供）。 6、主页面和次级页面数量，是否需要多种语言版本等
详细的需求分析文档规范
需求规格文档 1 导言 1.1 目的 [说明编写这份项目需求规格的目的，指出预期的读者] 1.2 背景 说明： a)待开发的产品的名称 b)本项目的任务提出者、开发者、用户及实现该产品的单位 c)该系统同其他系统的相互往来关系 1.3 编写说明 [缩写] [缩写说明] 列出本文件中用到的外文首字母组词的原词组 1.4 术语定义 [术语] [术语定义] 列出本文件中用到的专门术语的定义
1.5 参考资料 [编号]《参考资料》[版本号] 列出相关的参考资料 1.6 版本更新信息 具体版本更新记录如表所列。 表版本更新记录 2 任务概述 2.1 系统定义 本节描述内容包括： ●项目来源及背景； ●项目要达到的目标，如市场目标、技术目标等； ●系统整体结构，如系统框、系统提供的主要功能，涉及的借口等； ●各组成部分结构，如果所定义的产品是一个更大的系统的一个组成部分，则应说 明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明 该系统和本产品其他各部分的联系和接口。 2.2 应用环境 本节应根据用户的要求对系统的运行环境进行定义，描述内容包括： ●设备环境； ●系统运行硬件环境； ●系统运行软基纳环境； ●系统运行网络环境； ●用户操作模式； ●当前应用环境。 2.3 假设和约束 列出进行本产品开发工作的假定和约束，例如经费限制、开发期限等。列出本产品的最终用户特点，充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。
3 需求规定 3.1 对功能的规定 本节依据合同中定义的系统组成部分分别描述其功能，描述应包括： ●功能编号； ●所属产品编号； ●优先级； ●功能定义； ●功能描述。 3.2 对性能的规定 本节描述用户对系统的性能需求，可能的系统性能需求有： ●系统响应时间需求； ●系统开放型需求； ●系统可靠性需求； ●系统可移植性和可扩展性需求； ●系统安全性需求； ●现有资源利用需求。 3.2.1 精度 说明对该产品的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2 时间特性要求 说明对于该产品的时间特性要求，如对： A）响应时间； B）更新处理时间； C）数据的转换和传送时间； D）计算时间等的要求。 3.2.3 灵活性 说明对该产品的灵活性的要求，即当需求发生某些变化时，该产品对这些变化的适应性能力，如： a)操作方式上的变化； b)运行环境的变化； c)同其他系统的借口的变化； d)精度和有效时限的变化；
软件需求分析方法
需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。 二需求分析方法论 第一阶段：“访谈式”
第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）
需求分析规格说明书
软件需求说明书 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 1 引言 1．1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1．2背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1．3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1．4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 任务概述 2．1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各
部分的联系和接口。 2．2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束2．3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3 需求规定 3．1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3．2对性能的规定 3．2．1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3．2．2时间特性要求 说明对于该软件的时间特性要求，如对： a．响应时间； b．更新处理时间； c．数据的转换和传送时间； d．解题时间；等的要求。 3．2．3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化； b．运行环境的变化； c．同其他软件的接口的变化； d．精度和有效时限的变化； e．计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
需求分析与测试的重要性
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
研发需求分析报告模板
研发需求分析报告 注：括号内容为输出要求和建议。 原则：开发人员拿到此文档就可以开始工作，不用再次跟市场人员反复沟通确认。 一、产品描述 1、产品（项目）名称 （软、硬件须注明产品型号；产品型号符合命名规范） 2、实现方案描述 （详细、全面地对产品进行描述，让参与产品开发的人员都可以无歧义地知道产品的最终形态；硬件平台及核心模块的选型，如sensor等） （1）在XXXX基础上，集合XXXX，兼容XXXX，后续产品升级支持XXXX。 （2）输出接口：XXXX。 二、研发需求 （按优先级从高到低排列，硬件产品明确规格、性能，作为最终产品是否达到设计要求和质量等级的依据；注明符合国际标准或客户要求的环保标准。） 三、研发需求分析 （以部门为单位，用研发语言列出可行的需求，对和项目任务书不一致的部分作出解释）备注：软件UI需求分析设计专用如下 功能结构图 (---操作与跳转流程、结构、布局、信息和其他元素、详细的结构流程图文档---) 使用场景分析 (----使用人群、时间、地点---) 交互流程分析 (---交互流程---) 界面原型 （---提供界面草图---） 要点说明 (-------)
四、研发人力投入和分工 1、涉及部门： 网络实验室：负责网络穿透…… 设计部：负责UI和包材设计…… BU研发：…… ……：…… 2、预估工作量： A投入50人天。 B投入30人天。 五、预期价格成本 1、预期价格 （注明市场建议销售价格，说明是否含税等。） 2、硬件成本 （硬件BOM含税价格，包含包装，不包含人工费用） 3、运营成本（带宽、维护成本等） 六、开发周期及产品质量要求和预估 （对发布周期的要求；对产品质量等级的要求。） 期望： （1）明确TR点； （2）产品质量为A级。 七、产品风险及措施 （根据以往常见的风险或产品成功所需要的条件，有何种应对措施。）（1）需求是否明确； （2）实现方案选择；
需求分析方法主要步骤
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
研究生科研信息管理系统需求分析
研究生科研信息管理系统需求分析 研究生科研信息管理系统功能要求 研究生科研信息管理系统的总目标是：在计算机网络，数据库和先进的开发平台上，利用现有的软件，配置一定的硬件，开发一个具有开放体系结构的、易扩充的、易维护的、具有良好人机交互界面的研究生科研信息管理系统，实现为导师和研究生提供充分的管理信息和快捷的查询。根据可行性研究的结果和客户的要求，分析现有情况及问题。 管理员 1．客户端系统： 在客户端系统的功能实现上，可以分为以下几个部分： [1]科研信息文件的输入和统计
管理员把科研相关信息输入。这部分功能是客户端子系统的基本部分，这个功能是以后各个部分的基础。系统要求做到即能够从其它子系统中共享一部分信息，又有方便的操作界面手工输入旅客信息。这部分要求对输入的数据进行简单的统计，供研究生以及导师进行查询。 [2]在客户端系统的功能实现上，可以分为以下几个部分： 1、该题目主要以高校应该为导师和研究生提供充分的管理信息和快捷的查询，如对导师信息、研究生信息、科研项目、论文、学术交流、专利申请、培养经费支出管理等研究生综合信息进行管理业务为背景，通过调研、分析现有的管理模式和已有的管理软件，建立系统模型；完成软件结构设计和数据库设计；完成软件开发，撰写设计说明书； 2、“研究生科研信息管理系统”主要包括研究生基本信息、导师信息、论文信息、项目信息、学术交流、专利信息、培养经费支出、统计分析等模块； 3、利用“抽象”设计原理，对系统设计并实现满足多种条件的统计分析功能，有些统计数据要采用图表（直方图、圆饼图、折线图、表格等）的格式呈现； 4、系统开发可采用C#.net技术或JSP技术和数据库（数据库可选MySQL或MS SQL Server 或 Oracle）； 5、系统所涉及的信息有： ●导师信息：教工编号、姓名、身份证号、年龄、性别、职称、导师类型(0-硕士生导师，1-博士生导师)、拟招专业、主要研究方向、科研项目、发表论文情况、办公地址、联系电话、E-mail、QQ号、在研学生人数等； ●研究生信息：学号、姓名、导师名、身份证、年龄、性别、政治面貌、学生类别(0-硕士，1-博士)、专业、家庭地址、宿舍住址、发表论文、参加科研项目、联系电话、E-mail、QQ号、备注等； ●科研项目信息：项目编号、项目名称、项目负责人、项目来源、本人排名、项目类型、项目等级、所在单位、项目总经费、承担的主要任务； ●学术论文信息：论文编号、论文名称、第一作者、第二作者、作者所在部门、是否编入教材、备注、刊物名称、卷号、页码范围、日期、期号、是否基金资助、资助金额、检索类型(SCI/EI/ISTP/CSCD)、检索编号等； ●教材专著信息：教材编号、论著名称、主编姓名、所在部门、出版社、出版时间、总字数、编写字数、发行版本、是否基金资助、资助金额、发行册数等； ●用户信息：用户名、用户密码、用户权限、邮箱； ●专业信息：专业编号、专业名称； ●培养方案：课程类别、序号、课程编号、课程名称、学时、学分、开课学期、考核方式、开课学院； ●研究生支出台账信息：学号、学生姓名、导师姓名、培养经费总额、支出时间、支出金额、余额。 ●专利信息：专利名称、专利所属学院、专利类型(0-发明专利，1-实用新型，2-外观
需求分析
第一章 1、利益相关者是在软件项目中存在利害关系的人。任何受到系统影响或对系统开发产生影响的人，都是利益相关者。主要的利益相关者：客户（用户或系统的所有者）、开发者（分析员、程序员等）。（P3） 2、迭代和增量过程的成功是以对系统体系模块的早期认识为基础的。这些模块应当有其相似的规模、高度的内聚和极小的重叠（耦合）。实现模块次序也很重要。如果模块依赖于其他上在开发的的模块中的信息或计算，那么它们可能无法发布。除非对迭代和增量开发进行规划和控制，否则过程会沦为不能控制项目实际进度的“特别黑客“。 3、能力成熟度模型（CMM , capability maturity model）是一种用来进行过程评估和改进的流行方法。 4、楼梯上的5个台阶是：混乱、项目管理、方法和工具、度量以及持续的质量改进。经验表明，要上升一个成熟度级别需要数年时间。（P5） 5、ISO 9000标准系列的主要前提是：如果过程是正确的，那么过程的结果也将是正确的。“质量管理的目标是通过在产品中建立质量而不是测试质量来生产优质的产品“。 6、对于又ISO认证组织来说，一个试金石是即使它的全部劳动力被替换掉，它也能够生产出优质的产品或提供优质的服务。为了这个目标，组织必须文档化并记录它的所有正式活动，必须为每个活动定义书面程序，包括当出现错误时或客户抱怨时应该做什么。（P6） RQ3 每个迭代中的增量版本是否向开发中的软件产品增加了新的功能？ 答：不，他没有；增量改进了非功能性的软件质量。 7、必须对信息系统项目进行规划，必须为初期开发、改进或者排除而进行识别、分类、排序和选择。问题时，那种IS技术和应用系统对系统对业务的回报价值最大？在理想情况下，
需求分析标准化
需求分析标准化流程
山西五联科技有限公司 2017年6月 目录 一、需求分析介绍 (3) 二、为什么需要需求分析 (4) 三、需求分析得出的结果是什么 (4) 四、需求定义文档各阶段要用到的工具软件 (4) 4.1 文档制作工具 (4) 4.2 用例图制作工具 (4) 五、需求定义文档规范 (4) 六、需求分析应该注意的问题 (5) 七、需求文档有那些内容组成 (5) 7.1 项目概述 (5) 7.2项目可行性（或建设目标） (5)
7.3 系统架构（或总体设计） (5) 7.4 系统功能概述 (6) 7.5 项目预算 (7) 7.6 公司简介 (7) 7.7 公司荣誉 (7) 7.8 公司资质 (7) 7.9 典型案例 (7) 八、需求分析完整版所要提供的资料 (8) 一、需求分析介绍 需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。 需求分析：是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的“需求分析”就是确定要计算机“做什么”，要达到什么样的效果。可以说需求分析是做系统之前必做的。 从广义上理解：需求分析包括需求的获取、分析、规格说明、变
更、验证、管理的一系列需求工程。 二、为什么需要需求分析 需求分析是项目开发的必要过程。项目开发人员通过需求调研形成需求定义文档，为项目的详细设计打好基础。 需求定义文档形成后，客户需要签字确认，这是双方签订合同时所涉及的内容。 需求定义文档的形成是报价的必要条件。 三、需求分析得出的结果是什么 形成需求定义文档。 四、需求定义文档各阶段要用到的工具软件 4.1 文档制作工具 Word、PowerPoint 4.2 用例图制作工具 visio、Photoshop、亿图、Axure RP Pro 7.0 五、需求定义文档规范 (一) 封面 (二) 目录
软件需求分析方法
欢迎阅读 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整?性，促 使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；
3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 （5）??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实负责人员、落实实施日期。 2）功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化： （1）??? 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；
（2）??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择， 重复，还是并发，然后说明步骤逻辑。整个描述必须单入单出。 （3）??? 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进行描述，这样便于功能的追踪和修改。 （4）??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采 2.2、 2.3、 （2）??? 处理容限、精度、采样参数的分辨率，误差处理等； （3）??? 可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。） 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况：某些用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。第二种情况：对一些可靠性和安全性要求较高的软件，有些必须描述软件不能做些什么。如控制点火时序，我们必须交代清楚在那些情况下不能点火，否则会造成故障。