第4章.需求获取概述
需求获取的注意事项
需求获取的注意事项
1.明确需求来源：需求来源有多种，如用户需求、市场需求、技术需求等。
在进行需求获取前，需要明确需求来源，以便更好地理解和满足需求。
2.了解用户需求：用户需求是最重要的需求之一，需要通过调查、访谈、问卷调查等方式来了解用户需求。
要充分了解用户的目标、需求、痛点等，以便设计出更符合用户需求的产品。
3.注意需求的可行性：在获取需求时，要考虑到需求的可行性。
需求不仅要符合用户需求，还要在技术、成本、市场等方面实现可行性。
4.注意需求的优先级：需求的优先级是不同的，有些需求是必须的，有些是可选的。
在获取需求时，要根据需求的重要性和优先级来确定开发的重点和时间安排。
5.及时沟通和反馈：在获取需求的过程中，需要及时与用户、开发团队进行沟通和反馈。
这样可以在开发过程中随时进行调整和优化，避免出现不必要的错误和延误。
6.不断迭代和改进：需求获取是一个不断迭代和改进的过程。
在获取需求后，要及时进行评估和反馈，发现问题和不足，并进行持续的改进和优化。
- 1 -。
软件工程需求分析(精品PPT)
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页，共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务：
•确定对系统的综合要求
•系统功能要求
第四章 析根底
软件工程 需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页，共七十七页。
第四章 需求分析 根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页，共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识，重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件，了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求 规格说明,对软件的需求获取是很有必要的
第十六页，共七十七页。
✓需求调查对象
对组织的高层管理者，进行组织管理目标或经营方 针等组织战略问题的调查
对中层的管理者，进行全部业务流的调查 对业务工作人员，进行详细业务信息的调查
✓市场调查 了解市场对待开发软件有什么样的要求；了解市场上 有无与待开发软件类似的系统
第十页，共七十七页。
需求(xūqiú)分析流程
第十一页，共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域 信息域应包括：
常见需求获取方法
常见需求获取方法之——概述高。
3、问卷调查法相比用户访谈，问卷调查是一种定量的调研方式，常用于用户访谈之后；通常先通过定性的用户访谈判断基本方向及要点，再通过问卷对各需求关键点进行定量验证，了解其特点后再次通过1V1的深度访谈把脉需求（一般在问卷调研过程中发掘深访对象）。
当然视产品的具体情况选择最适合的方法。
全流程的问卷调查，执行过程中一般会涵盖调研方案（调研时间、地点、主题、投放数量、受访者构成等）、问卷设计（问卷设计完成后，可小范围投放测试）、实际调研（网络、电话、实地）、问卷回收（审核问卷真实性、有效性）、问卷分析（分析调研数据，出具分析报告）几个方面。
其中的问卷设计，有几个原则：1）问题通俗化，忌专业术语；2）选择题为主，问题设置由浅入深，逻辑性；3）选择题答案闭合，标准化。
4、运营数据分析法从运营数据报告中获取需求，一般针对已上线的产品/业务，通过现产品的运营监控，为产品迭代提供一定依据。
通常来自于采集运营数据（如UV、PV、浏览轨迹、转化率等）和市场、客服等其他合作部门的建议反馈。
案例解析：蚂蜂窝这一案例中的酒店预定、机票预定功能，如果订单数量很多，但最终完成支付的很少，可以怎么解决？1、梳理下订单之后的各个环节，下单成功后，需要什么环节才能成功支付；2、分析各个环节的转化率，找到用户流失的关键步骤；3、从产品角度考虑产品功能优化，以降低用户流失。
现场简要分析，用户流失可能因为：1）登录注册繁琐；2）支付方式太少；3）页面跳转环节过多等等。
针对这几个问题，从用户需求的角度来看，1）简化登录注册，最好可以支持通用的如QQ、微博等社交类帐号；2）丰富支付方式，支持常用网银、支付宝等支付工具；3）简化非必要跳转页面。
市场、客服等合作部门的反馈，因为市场、客服人员是与一线用户直接接触的，对于用户对产品的反馈和建议是能够快速掌握的，有时可能就是用户的一句抱怨，可能会给产品带来很大的价值，因此留意用户，接触用户也是非常关键的。
需求处理流程-概述说明以及解释
需求处理流程-概述说明以及解释1.引言1.1 概述需求处理流程是指在软件开发或项目实施过程中，如何获取、分析、整理和管理需求的一系列步骤和方法。
需求处理流程起源于需求工程领域，旨在确保项目团队能够全面理解客户或用户的需求，并将其转化为可执行的软件规格或项目计划。
在软件开发和项目实施过程中，需求处理流程起到了重要的作用。
它可以帮助项目团队从客户或用户那里获取正确的需求信息，并合理地转化为项目的目标和任务。
需求处理流程包括了需求获取阶段、需求分析与整理阶段以及需求确认与变更管理阶段。
在需求获取阶段，项目团队会主动与客户或用户进行沟通和交流，了解他们对软件产品或项目的需求和期望。
这个阶段的主要目的是收集尽可能多的信息，明确各个利益相关者的期望和要求，并建立起有效的沟通渠道。
在需求分析与整理阶段，项目团队会对收集到的需求信息进行详细的分析和整理。
他们会对需求进行分类、排序和优先级划分，以便更好地理解和把握需求的实质。
同时，他们还会将需求转化为软件规格、用例模型或系统设计文档等形式，以便后续的系统设计和开发工作。
在需求确认与变更管理阶段，项目团队会与客户或用户进行反复的确认和反馈，以确保需求的准确性和完整性。
他们会共同审查和验证需求，及时发现并解决需求中的问题和风险。
同时，如果客户或用户提出了新的需求或变更需求，项目团队也需要及时进行评估和调整。
综上所述，需求处理流程是一个全面、系统地管理需求的过程，它能够帮助项目团队更好地理解和满足客户或用户的需求。
通过合理地运用需求处理流程，可以有效地减少需求误解和变更，提高系统的质量和客户满意度。
因此，对于任何一个软件开发或项目实施过程来说，需求处理流程都是至关重要的一环。
1.2文章结构1.2 文章结构本文主要介绍需求处理流程的整体结构。
为了保证需求的准确性和可行性，一个完整的需求处理流程通常包含以下几个关键步骤：1.2.1 需求收集与分析阶段：在这个阶段，需求团队与相关利益相关方进行密切合作，通过面对面的访谈、问卷调查、用户调研等方式，全面收集和理解不同利益相关方的需求和期望。
需求工程总结
第1章. 需求工程导论本章小结⏹从20世纪60年代末期软件工程产生起，需求分析就一直是软件开发的重要主题⏹20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求”问题⏹应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程⏹需求工程是软件工程当中一项重要和复杂的活动，需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动第2章. 需求基础实例分析（系统A—招标书）⏹请说出下列需求的类型，是否存在问题？❑1、实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化；❑2、实现工作流程合理化、高效化，决策支持科学化、准确化；❑3、统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。
⏹请说出下列需求的类型，是否存在问题？❑先进性：软件系统采用三层B / S 系统结构，以“界面表示层－逻辑处理层－数据访问层”分层设计实现。
采用国际上先进成熟的、厂商广泛支持的计算机技术、网络技术与软件技术对系统进行规划，保证系统整体架构在未来几年内都处于国际领先的地位。
❑安全性：软件系统具有较高的安全要求，系统必须具备充分的安全措施，包括具备严格的权限控制机制和完备的日志记录，以确保信息安全。
❑可靠性：保证系统核心功能可以7×24小时连续运行；❑规范性：系统必须遵循国家有关法律法规要求，符合国家有关标准要求以及关于信息系统建设的各项标准和规范。
⏹请说出下列需求的类型，是否存在问题？❑收文管理应包括:⏹来文登记、拟办、领导审批、办理、归档、查询统计等功能。
附件支持WORD 、PDF 、EXCEL 、HTML 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。
⏹来文登记：完成来文登记功能。
登记来文基本信息（来文编号、来文标题、主题词、来文单位、来文时间），还要对原文进行扫描处理，引入到公文库中。
IT需求管理办法V12
IT需求管理办法V12IT需求管理办法V121. 引言本旨在规定了IT需求管理的办法，以确保项目需求能够被合理地管理、分析和满足。
本适合于所有涉及IT项目的需求管理工作，并将涵盖以下方面的内容：需求定义、需求分析、需求评审、需求变更和需求跟踪。
2. 需求定义2.1 需求概述本章节将对项目的需求进行概述，包括项目的背景、目标、范围和所需的功能。
需求概述将作为后续需求分析和评审的基础。
2.2 需求分类本章节包括对需求的分类和分级，根据不同的需求类型和重要性进行划分，并说明每一个需求分类的定义和影响。
2.3 需求获取本章节将阐述需求获取的方法和流程，包括面对面访谈、问卷调查、分析等，以确保获取到完整、准确的需求信息。
3. 需求分析3.1 需求分析流程本章节将详细说明需求分析的流程，包括需求确认、需求分解、需求建模等，以确保对需求的细化和准确理解。
3.2 需求澄清和确认本章节将介绍对需求进行澄清和确认的方法和技巧，以确保需求的一致性和准确性。
3.3 需求优先级评估本章节将说明对需求进行优先级评估的方法和标准，以确保对需求的重要性和紧急性进行合理评估。
4. 需求评审4.1 需求评审流程本章节将详细阐述需求评审的流程和要点，包括需求评审会议的组织、议程的制定、评审意见的记录等。
4.2 需求评审准则本章节将介绍需求评审的准则，以确保评审过程的客观性和一致性，并提供常见问题的解决方法和经验总结。
4.3 需求评审结果反馈本章节将阐述需求评审结果的反馈和处理方式，包括需求修改、需求补充、需求删除等。
5. 需求变更5.1 需求变更流程本章节将详细说明需求变更的流程和步骤，包括变更申请、变更评估、变更批准等，以确保变更的及时处理和控制。
5.2 需求变更管理本章节将介绍需求变更的管理方法和工具，包括变更请求的跟踪、变更影响的评估、变更后果的通知等。
6. 需求跟踪6.1 需求跟踪方法本章节将详细阐述需求跟踪的方法和工具，包括需求追踪矩阵、需求追踪工具等，以确保需求的追踪和控制。
客户需求分析流程分几步
客户需求分析流程分几步在进行产品设计或服务提供过程中，了解客户需求是十分重要的一环。
只有充分掌握客户的需求，才能满足客户的期望，提供高质量的产品和服务。
客户需求分析是一个系统性的过程，通常可以分为以下几个步骤：第一步：需求获取需求获取是整个需求分析流程的起点。
在这个阶段，我们需要与客户进行沟通和交流，通过不同的途径获取客户的需求信息。
根据不同的行业和产品特点，可采用多种方式获取需求，如在线调查、面对面访谈、市场调研等。
通过与客户的密切接触，我们可以了解客户对产品的期望、使用场景、功能要求等信息。
第二步：需求整理和分类在需求获取的基础上，我们需要对所获取到的需求进行整理和分类。
将相似的需求进行归类，以便更好地理解并分析客户的需求。
这一步骤可以帮助我们发现需求的共性和差异，为后续的需求分析提供基础。
同时，通过需求整理和分类，我们可以确保不会遗漏客户提出的任何需求。
第三步：需求确认需求确认是保证需求准确性和一致性的重要环节。
在这一步骤中，我们需要与客户进行反馈和确认。
将整理过的需求以清晰明确的方式呈现给客户，确保客户对需求的理解与我们的理解一致。
如果客户对某些需求提出了修改或补充意见，我们需要及时进行记录并进行商议。
通过需求确认，可以有效避免因为需求理解上的误差导致的项目进展延误或需求变更。
第四步：需求分析需求分析是将客户需求转化为具体的功能和特性的过程。
在这个阶段，我们需要对客户的需求进行深入研究和分析。
通过对需求的细化和梳理，我们可以将抽象的需求转化为可实施的解决方案。
需求分析往往涉及到对系统的功能、性能、可靠性、安全性等方面的要求进行详细的分析和描述。
第五步：需求验证需求验证是确定所分析和描述的需求是否与客户期望一致的最后一步。
在这个阶段，我们需要与客户进行反馈和确认，确保所提供的解决方案满足客户的需求。
通过需求验证，可以避免由于需求分析不准确而导致的后续开发或实施出现问题。
如果客户对需求有任何进一步的修改或补充意见，我们需要及时记录并进行相应的调整。
《需求工程》知识要点
~ 1 ~
பைடு நூலகம்录
1 引言....................................................................................................................................... 4 2 软件需求............................................................................................................................... 4 2.1 需求的内涵................................................................................................................ 4 2.1.1 什么是需求？................................................................................................. 4 2.1.2“做什么”与“怎么做” ............................................................................... 5 2.2 需求分类.................................................................................................................... 5 2.2.1 广义需求分类.............................
需求工程期末复习
第一章:需求工程导论1.需求工程定义：是所有需求处理活动的和,它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应.2.需求工程的基本活动：1）需求开发:需求获取,需求分析，需求规格说明，需求验证2）需求管理3.1）需求获取的目的是从项目的战略规划开始建立最初的原始需求；2）需求分析的目的是保证需求的完整性和一致性;3）需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来;4）需求验证的首要目的是保证需求及其文档的正确性,即需求正确的反映了用户的真实意图；另一个目标是通过检查和修正,保证需求及其文档的完整性和一致性；5）需求管理的主要工作是跟踪后继阶段中的需求实现与需求变更情况,确定需求得到了正确的理解并被正确的是想到了软件产品中。
4.软件需求规格说明定义：软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为,产生软件需求规格说明。
第二章:需求基础5.软件系统能够与问题域进行交互和相互影响的原因在于,软件系统中的某些部分对问题域中的某些部分具有模拟特性.6.需求分类:1）功能需求：业务需求，用户需求，系统需求2）性能需求3）质量属性4）对外接口5）约束第三章：（不考）第四章：需求获取概述7.需求工程需要获取的内容主要有三种：1）需求2）问题域描述3）环境与约束8.需求获取信息的主要来源：1）涉众2）硬数据3）相关产品4）重要文档5）相关技术标准和法规9.获取信息的方法：1）传统方法：问卷调查，面谈，文档分析,文档检查,需求剥离2）集体获取方法：头脑风暴，专题讨论会，JAD，JRP3）原型4）模型驱动方法：基于场景，基于用例5）认知方法：任务分析,协议分析6）基于上下文的方法：观察，民族志，话语分析10.常见的组织方式是依照系统特性,确定系统的边界，建立上下文图或系统用例图，然后按照遍历上下文图和系统用例图的方式开展获取活动.第五章：确定项目的前景和范围11.前景：描述了产品的作用以及最终的功能,它将所有涉众都统一到一个方向上。
软件工程实用案例 第4章 结构化需求分析
3项目范围 3.1 第一版范围 3.2 后续版本范围 3.3 限制与排除
4项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性
词汇表 参考资料 附录
4.3 需求获取
4.3.3 选择信息的来源
• 1. 涉众
• 包括用户、客户、领域专家、用户替代源(市场人员、销售人员) 等。
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-12 功能分解示意图
4.4 需求分析
4.4.1 过程建模
4.4.1.1 数据流图
3. 分层结构 （3）N层图
图4-13 食物订货系统的1层图
4.4 需求分析
4.4.1 过程建模
4.4.1.2 微规格说明
正式规定文档所需具有的条件或能力。
(3) 对(1)或(2)所描述的条件或能力的文档化表述。 其中，(1)是从用户角度定义的，(2)是从开发人员、
系统的角度定义的。
4.1 需 求
4.1.2 需求的层次
需求通常体现为三个层次：业务需求、用户需求和系 统需求。
4.1 需 求
4.1.2 需求的层次
4.3 需求获取
4.3.2 定义项目前景和范围
• 1.明确问题
P1 决策者：生产的废品过多。
• 2.发现业务需求
BR1：提供销售订单的准确性，减少因此而产生废品。
BR2：提供销售订单的准确性，在使用后3个月内，减少50%因此而产生 的废品。
4.3 需求获取
4.3.2 定义项目前景和范围
• 3.定义解决方案及系统特性
4.3 需求获取
4.3.4 需求获取的方法
第4章 需求开发
第4章需求开发 (1)4.1 介绍 (1)4.2 用户需求调查 (2)4.2.1目的 (2)4.2.2角色与职责 (2)4.2.3启动准则 (2)4.2.4输入 (2)4.2.5主要步骤 (3)[Step1] 准备 (3)[Step2] 调查与记录 (3)[Step3] 分析需求信息 (3)[Step4] 撰写用户需求说明书 (3)[后续活动：需求确认] (3)4.2.6输出 (4)4.2.7结束准则 (4)4.2.8度量 (4)4.3 产品需求定义 (4)4.3.1目的 (4)4.3.2角色与职责 (4)4.3.3启动准则 (4)4.3.4输入 (4)4.3.5主要步骤 (5)[Step1] 细化并分析用户需求 (5)[Step2] 撰写产品需求规格说明书 (5)[后续活动：需求确认] (5)4.3.6输出 (5)4.3.7结束准则 (5)4.3.8度量 (6)4.4 需求分析方法概述 (6)4.4.1问答分析法 (6)4.4.2建模分析法 (6)一、结构化分析法 (7)二、面向对象分析法 (7)三、恰当地使用图形符号 (8)4.5 实施建议 (8)第4章需求开发需求开发（Requirement Development, RD）的目的是通过调查与分析，获取用户需求并定义产品需求。
需求开发过程域是SPP模型的重要组成部分。
本规范阐述了需求开发过程域的两个主要规程：✧需求调查[SPP-PROC-RM-SURVEY]✧需求定义[SPP-PROC-RM-DEFINE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
需求分析是需求开发过程域的重要活动之一，但是不宜用“规范”这种形式来论述。
本章对需求分析方法作了概括性介绍，请读者阅读更加专业性的需求分析论著。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
第4章.需求获取概述
3.5 获取的结果
肯定会产生获取笔录（Elicitation Notes）
用户需求、问题域知识和约束 可能具有组织差、冗余、遗漏、自相矛盾等诸多问 题 可以包括文字记录、录音、摄像等各种形式
可能会产生两份定义明确的正式文档
项目前景和范围文档 用例文档
主要内容
1. 2. 3.
4.
需求获取概述主要内容尽力去研究应用的背景理解组织的状况形成一个能够和用户进行有效沟通的粗略的知识框架利用有效的获取方法与技巧角色扮演观察等来发现并获取默认知识普通用户的知识结构就相对局限于一些具体的业务细节开发人员在与用户接触之前就先行确定获取的内容主题然后设计具体的应用环境和场景条件由用户根据细节业务的执行来描述问题表达期望
默认（Tacit）知识现象
1. 需求获取的非平凡性
普通用户缺乏概括性、综合性的表述能力
普通用户的知识结构就相对局限于一些具体的业务 细节
善于表达具体业务的细节问题
专家用户的知识结构因其渊博性而具有概括性和广 泛性
能够回答概括性和综合性的问题
开发人员在与用户接触之前就先行确定获取的内容 主题，然后设计具体的应用环境和场景条件，由用 户根据细节业务的执行来描述问题、表达期望。
1. 需求获取的非平凡性
用户存在认知困境
潜在（Latency）知识
需要利用各种有效的需求获取方法和技巧
用户越俎代庖
用户提出的不是需求，而是解决方案
注意保持业务领域和解决方案的区分界限 分析用户的深层目的，找到隐藏在背后的需求
第4讲需求获取报告
的执行过程； 设计时，描述操作的流程。 在描绘对象之间的交互协作方面，活动图不如交互 图；在描绘对象的行为方面，活动图不如状态图。
2018/10/12
23
活动图事物
活动 (ActionState) 动作的执行 起点 (InitialState) 活动图的开始 终点(FinalState) 活动图的终点
2018/10/12
UML表示法
19
假如A类的某个方法中，使用了B类，那么
类之间的关系
就说A类依赖于B类，它们是依赖关系。 A类的某个方法使用B类，可能是方法的参 数是B类，也可能是在方法中获得了一个B 类实例。但无论是哪种情况，B类在A类中 都是以局部变量的形式存在的。
依赖关系是有向的
-attr11 -attr12 +op11() +op12()
1
*
（e）实现关系的表示
Class1 -attr11 -attr12 +op11() +op12()
c）组合关系的表示
Class1 -attr11 -attr12 +op11() +op12()
Class2 -attr21 -attr22 +op21() +op22()
用例 图
需求 获取 类图
2018/10/12
活动 图
7
4.1.1 用例
（一）用例的概念 从外部用户的视角看，一个用例（use case）是 执行者(actor)与目标软件系统之间一次典型的交 互作用，其效果就是执行者在软件系统的帮助下 完成了某项业务功能，或达成了某项业务目标。 从软件系统内部的视角出发，一个用例代表着系 统执行的一系列动作，动作执行的结果能够被外 部的执行者所察觉。
软件工程中的软件需求管理
需求与设计的关联
建立需求-设计映射
确保设计是基于准确需求的
需求验证
验证设计是否符合需求规格
持续跟踪需求变化
不断迭代确认需求和设计的一致性
需求跟踪工具
JIRA
强大的项目管理和 跟踪工具
VersionOne
适用于敏捷开发的 需求跟踪软件
Trello
简单直观的需求管 理工具
●05
第五章 需求管理工具
需求管理工具概述
需求管理工具是通过软件工具来支持需求管理活动的工 具，包括需求收集工具、需求建模工具、需求跟踪工具 等。这些工具可以帮助团队更好地管理和跟踪需求，提
高项目管理效率。
常用的需求管理工具
JIRA
功能强大，适用于大型团队
Trello
简单易用，适用于小型团队
Rational RequisitePro
软件需求的分类
功能性需求
指明系统应该做什么
非功能性需求
指明系统应该如何做
软件需求管理的重要性
按时交付
预算内完成
满足用户需求
有效的需求管理可以确保项目 按时交付
有效的需求管理可以确保项目 在预算内完成
有效的需求管理可以确保项目 满足用户需求
软件需求管理的挑战
需求不明确
需求可能存在不明 确、不完整、不一大型团队需要强大 的需求管理功能
预算
需求管理工具费用 也是考虑因素
项目需求
不同项目需要不同 的需求管理方法
易用性
工具易用性影响团 队使用效率
需求管理工具的使用
培训团队成员
建立统一流程
有效使用工具
团队沟通
对工具的培训可以提高团队使 用效率 定期更新培训内容以跟上工具
需求获取
广州大学软件工程实验需求获取学院：数学与信息科学学院班级：信计121小组成员：杜健成（1215200028）梁文海（1215200022）指导教师：麦红P2P即时聊天系统需求获取组员：杜健成、梁文海1.引言1.1编写目的在网络越来越发达的今天，人们对网络的依赖越来越多，越来越离不开网络，由此而产生的聊天工具越来越多，类似QQ、网络聊天一类的聊天系统的发展日新月异。
因此，基于我们实际的知识结构构成以及网络聊天在当今时代的盛行趋势，本课程设计小组选择了课程设计题目点对点数据交换（P2P），用于实现基于服务器转发的任意多点间的数据共享与交换。
1.2项目背景随着网络的普及，人类生活越来越依赖网络，人与人之间的交也更多的是在网上进行，于交流的实时性，即时通讯系统也被越来越多的人所使用。
即时通讯系统除了普通的生活上的交流，也在商业交流中越来越受到重视，它可以是个很好的与客户之间即时交流的平台，在时间上它要比电子邮件更加具有实时性，而费用相对电话交流也要经济的多。
在这种环境下，聊天软件作为一种即时通讯工具，得到了很好的发展。
1.3 参考资料软件工程清华大学出版社2．任务概述2.1目标应用Socket编程创建客户端和服务器端，它们之间通过一个交互的连接来实现数据通信；然后在客户端设置一个监听器，用于监听服务器发来的消息；最后在客户端设置点对点的文件交互需要用到的接受和发送类，以及表征文件传输过程的进度条。
（1）提供简单、方便的操作。
（2）使用者能够科学高效地对相应数据进行管理。
（3）准确处理数据避免人工统计处理数据出现差错。
（4）保障数据库安全，优化数据库。
（5）实现界面的友好性以及图形化的操作界面。
3.系统流图图 14.数据流图图 25.系统数据模型（E-R图）图 31）服务器端，主要实现向各个客户端发布系统消息，接受来自客户端的各种信息并分别处理。
具体功能如下：①连接控制：②管理作用：③刷新列表：④登陆信息：⑤聊天记录：⑥消息处理：2）客户端：主要实现向服务器端发布消息，并且对来自服务器的消息做出相应的响应。
四步搞定需求｜需求获取、需求分析
如上所述，需求获取这一步主要包括三个方面的内容：渠道、方式、记录。
一、需求获取渠道对产品经理而言，需求获取的渠道主要可分为两类：外部渠道和内部渠道。
1.外部渠道1）市场需求和产品常常会受到行业政策调整的影响。
如“净网行动”、“打车软件专车服务属非法营运”等。
2）用户产品设计的初衷就是为了满足用户需求。
3）竞品所谓的竞品，主要可分为两种。
一种是用同样的产品功能满足同样用户需求的产品，另一种是用不同的产品功能满足同样用户需求的产品。
竞品对用户需求的满足程度、满足方式既会对我们产生影响，也可以为我们的产品设计带来一定的启发。
4）合作伙伴合作伙伴在商业模式当中扮演着重要的角色，因此他们的需求亦不容忽视。
2.内部渠道1）产品用户在使用产品时会产生行为数据，这些客观的数据一定程度上会反映出用户的需求。
2）老板企业运转的根本目的在于盈利。
产品在满足用户需求的同时必须兼顾公司的战略需求。
而这方面需求通常是由老板或公司的高层来把握。
3）同事一款产品从诞生到投入市场，主要需要以下角色参与：产品、研发、设计、运营、市场、销售、客服。
其中，运营、市场、销售（解决合作伙伴对产品价值的质疑）、客服（解决用户遇到的问题）是距离用户最近的人，往往最能理解用户抱怨的点也最能提出产品建设性的意见。
4）自己产品经理应该成为自己产品的用户，而且是产品的目标用户，在使用产品的过程去发现用户需求，如此一来才能更好地帮助用户解决问题。
二、需求获取的方式需求获取的方式依来源渠道差异可分为外部和内部两大类：1.外部1）市场●政策调整关注行业相关的政策调整，并思考其对需求和产品的影响。
●动态资讯关注行业资讯，思考行业动向对需求和产品的影响。
●行业数据利用行业数据报告、行业数据统计工具获取需求。
CNNIC、199IT、易观智库、艾瑞咨询等机构会不定期发布行业的相关报告，这些机构的报告相对而言比较有权威性，具有一定的参考价值。
除了行业相关的数据报告，还有诸如百度指数、360指数等基于大量用户数据的数据统计工具。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目范围
项目的边界定义不清晰，或者根本就没有定义项目 的边界； 定义的项目边界错误，使得最终的需求不完备或者 冗余； 没有控制已建立的项目边界，使得项目范围失控
尤其是因为时间压力而抛弃需求的问题和开发人员 “镀 金”的问题非常普遍
4. 需求获取的实践调查情况
用户参与不足
3.4 获取的过程 ——结束获取活动的判断条件例； 用户想出的新用例都是导出用例（通过其他 用例的结合可以推导出该用例）； 用户只是在重复已经讨论过的问题； 新提出的特性、需求等都在项目范围之外； 新提出的需求优先级都很低； 用户提出的新功能都属于后继版本，而非当 前版本
没有能够有效的选择参与项目的用户 认识不足 用户抵制 没有明确的用户 管理上的障碍
4. 需求获取的实践调查情况
交流问题
最大的问题就是理解偏差 常用的交流方式：非正式的电话交谈、正式的电话 交谈（例如客户热线或者远程电话会议）、邮件、 web反馈表、文档以及一些面对面的交流（例如 JAD会议、原型等） 面对面的交流方式是最有效，也是最受欢迎的 直接交流途径优于间接交流途径
用户数量太多，选择困难 用户认识不足，不愿参与 用户情绪抵制，消极参与 没有明确的用户
对系统的用户以及用户的替代源等相关涉众进行分 析
主要内容
1. 2.
1. 2.
需求获取的非平凡性 需求获取的活动过程
子活动 过程描述
3. 4.
需求获取活动的要点 需求获取的实践调查情况
2.1 需求获取的子活动
知识内化的 特性 要求
已认知知识 默认知识
情景性工作知识
惯性知识 潜在知识
x
√√ √√ √√
x
x √ √√ √√ √ 1 1 √√ √√
x
x √ √√ √ 1 1 √ √√
x
√ √√ √√ √ 1 1 √ √√
x
√ √ x √ √√ √√ 1 1 √ x
x
√ √ x √ √√ √ 1 1 √ x
x
√√ √√ √√ x √√ x x 1 2 x √
研究应用背景，建立初始的知识框架； 根据获取的需要，采用必要的获取方法和技 巧； 先行确定获取的内容和主题，设定场景； 分析用户的高（深）层目标，理解用户的意 图； 进行涉众分析，针对涉众的特点开展工作。
2.2 需求获取的活动过程
问题域 业务数据资料 硬数据采样 样本数据 文档资料 系统环境
x
√ √ √ √ x x 1 6 x x
可观察的现象 需要开会 需要准备时间 需要采集信息的时间 约束 需求工程师数量 涉众数量 需要涉众友好 无前导技术要求 需要获得需求的时间
x √√ √ 1 1 √
本章小结
需求获取是一个困难和复杂的任务 需求获取的成功执行需要有效组织子活动过程 执行需求获取时既要尽可能全面，又要防止不 完备，更要注意进行过程控制 实践调查情况表明，需求获取活动还是一个具 有挑战性的任务
结构化面 谈 √ √ √√ √
头脑风暴
原型
场景分析
民族志
群体面谈
√ √
√√ √
√√ √√
x x √√
x x √√ √√
知识的类型
处理过程
数据 新知识 明显的知识
√
x x √√
√
√ √√ x -
√
√ √√ x -
√
√ √ √ -
√
√ √√ √√ √
√√
√ √√ √√ √√ √
√√
√ x x √√
√√
√√ √√ √√ √√ √
4. 需求获取的实践调查情况
获取方法的使用
没有在实践当中得到充分的应用
存在选择问题 需求的目的 知识的类型 知识内化的特性要求 可观察的现象 约束
五个方面的选择依据
采样观察 维度 建立规格说明 需求的目的 选择软件开发工具包 建立需求方案 抽象行为 类型 x x √√
非结构化 面 谈 √√ √
相关产品
原有系统 竞争产品 协作产品（和解系统存在接口 的其他软件系统）
相关技术标准和法规
相关法律、法规及规章制度 行业规范、行业标准
3.3 获取的方法
传统方法
问卷调查、面谈、硬数据分析、文档检查、需求剥离等 头脑风暴（Brainstorming）、专题讨论会（Workshop）、 JAD等
需求获取的非平凡性 需求获取的活动过程 需求获取活动的要点 需求获取的实践调查情况
4. 需求获取的实践调查情况
实践中的需求获取活动主要关注以下几个问题：
项目目标；
项目成功的十大影响因素之一[Standish Group]
项目范围； 用户参与； 交流问题； 获取方法的使用；
4. 需求获取的实践调查情况
应用背景资料 对 问 题 解 决 的 期 望 采集范围
获取源
获取环境
问题分析
业务需求
目 标
定义项目前景 和范围
高层次解决方案 系统特性
项目前景和范 围文档
获取内容
选择获取方 法、执行获取
业务问题的期望 业务解释
用户需求 内容
业务范围 高层次问题 获取源
问题域特性
内容
记录结果
成果
涉众
特征
涉众分析
采样涉众
3.5 获取的结果
肯定会产生获取笔录（Elicitation Notes）
用户需求、问题域知识和约束 可能具有组织差、冗余、遗漏、自相矛盾等诸多问 题 可以包括文字记录、录音、摄像等各种形式
可能会产生两份定义明确的正式文档
项目前景和范围文档 用例文档
主要内容
1. 2. 3.
4.
1. 需求获取的非平凡性
用户存在认知困境
潜在（Latency）知识
需要利用各种有效的需求获取方法和技巧
用户越俎代庖
用户提出的不是需求，而是解决方案
注意保持业务领域和解决方案的区分界限 分析用户的深层目的，找到隐藏在背后的需求
用户固执的坚持某些特征和功能
1. 需求获取的非平凡性
缺乏用户参与
默认（Tacit）知识现象
1. 需求获取的非平凡性
普通用户缺乏概括性、综合性的表述能力
普通用户的知识结构就相对局限于一些具体的业务 细节
善于表达具体业务的细节问题
专家用户的知识结构因其渊博性而具有概括性和广 泛性
能够回答概括性和综合性的问题
开发人员在与用户接触之前就先行确定获取的内容 主题，然后设计具体的应用环境和场景条件，由用 户根据细节业务的执行来描述问题、表达期望。
确定系统的边界，建立上下文图或系统用例图
维护项目的前景和范围 引导和控制获取过程 接受需求的不稳定性 控制探索性工作
3.4 获取的过程 —— 防止需求遗漏
务必让所有的涉众都表达出自己的意见。 不要以抽象和模糊的需求作为结束。对抽象和 模糊的需求，要进行细化，让真正的需求显露 出来。 使用多种方法表达需求信息。利用不同的分析 技术为相同的需求进行建模，通过分析不同的 关注点，考察需求是否完整。 注意检查边界值和布尔逻辑。
集体获取方法
原型 模型驱动方法 认知方法
任务分析（Task Analysis）、协议分析（Protocol Analysis） 等 观察、民族志（Ethnography）和话语分析（Conversation Analysis）
基于上下文的方法
3.4 获取的过程 ——注意事项
在整体上制定组织方案
需要注意的是不要忽略系统的环境和约束
问题域特性
获取的内容不是一次得到的，而是逐步积累的
3.2 获取的来源
涉众
用户 客户 领域专家 市场人员、销售人员等其他用 户替代源
硬数据
登记表格、单据、报表等定量 文档 备忘录、日志等定性文档
重要文档
原有系统的规格说明 竞争产品的规格说明 协作产品的规格说明 客户的需求文档（委托开发的 规格说明、招标书）
涉众特征
获取笔录
主要内容
1. 2. 3.
1. 2. 3. 4. 5.
需求获取的非平凡性 需求获取的活动过程 需求获取活动的要点
获取的内容 获取的来源 获取的方法 获取的过程 获取的结果
4.
需求获取的实践调查情况
3.1 获取的内容
在项目的范围之内 所有为用户创建解决系统必须的信息
需求
通常体现为用户的观点、看法、目标或者问题
第4章. 需求获取概述
主要内容
1. 2. 3.
4.
需求获取的非平凡性 需求获取的活动过程 需求获取活动的要点 需求获取的实践调查情况
1. 需求获取的非平凡性
用户和开发人员的背景不同，立场不同
首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够 和用户进行有效沟通的粗略的知识框架 利用有效的获取方法与技巧（角色扮演、观察等）来发现 并获取默认知识