第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 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。
⏹来文登记：完成来文登记功能。
登记来文基本信息（来文编号、来文标题、主题词、来文单位、来文时间），还要对原文进行扫描处理，引入到公文库中。
软件工程-课程目录-大纲视图(全国高等教育自学考试指定教材-计算机网络专业-独立本科)
第一章绪论1.1 软件工程概念的提出与发展1.2 软件开发的本质1.3 本章小结第二章软件需求与软件需求规约2.1 需求与需求获取2.1.1需求定义2.1.2 需求分类2.1.3 需求发现技术2.2 需求规约2.2.1 需求规约定义2.2.2 需求规约（草案）格式2.2.3 需求规约（规格说明书）的表达2.2.4 需求规约的作用2.3 本章小结第三章结构化方法3.1 结构化需求分析3.1.1 基本术语1.数据流2.数据存储3.数据源和数据谭3.1.2 系统功能模型表示数据流图（Dataflow Diagram）3.1.3 建模过程1.建立系统环境图, 确定系统语境2.自顶向下, 逐步求精, 建立系统的层次数据流图3.定义数据字典数据流条目给出所有数据流的结构定义数据存储条目给出所有数据存储的结构定义数据项条目给出所有数据项的类型定义4.描述加工（1）结构化自然语言（2）判定表（3）判定树3.1.4 应用中注意的问题（1）模型平衡问题（2）信息复杂性控制问题3.1.5 需求验证3.2 结构化设计3.2.1 总体设计1.总体设计的目标及其表示（1）Yourdon提出的模块结构图（2）层次图（3）HIPO图2.总体设计步骤（1）变换型数据流图——变换设计（2）事物型数据流图——事物设计3.模块化及启发式规则（1）模块化1）耦合①内容耦合②公共耦合③控制耦合④标记耦合⑤数据耦合2）内聚①偶然内聚②逻辑内聚③时间内聚④过程内聚⑤通信内聚⑥顺序内聚⑦功能内聚（2）启发式规则1）改进软件结构, 提高模块独立性2）力求模块规模适中3）力求深度、宽度、扇出和扇入适中4）尽力使模块的作用域在其控制域之内5）尽力降低模块接口的复杂度6）力求模块功能可以预测3.2.2 详细设计1.结构化程序设计2.详细设计工具（1）程序流程图（2）盒图（N-S图）（3）PAD图（Problem Analysis Diagram）（4）类程序设计语言IPO图、判定树和判定表等也可以作为详细设计工具3.3 本章小结第四章面向对象方法——UML 4.1 UML术语表4.1.1 表达客观事物的术语1.类与对象1）类的属性（Attribute）2）类的操作3）关于类语义的进一步表达①详细叙述类的职责（Responsibility）②通过类的注解和/或操作的注解, 以结构化文本的形式和/编程语言, 详述注释整个类的语义和/或各个方法③通过类的注解或操作的注解, 以结构化文本形式, 详述注释各个操作的前置条件和后置条件, 甚至注释整个类的不变式④详述类的状态机⑤详述类的内部结构⑥类与其他类的协作4）类在建模中的主要用途①模型化问题域中的概念（词汇）②建立系统的职责分布模型③模型化建模中使用的基本类型2.接口（Interface）（1）采用具有分栏和关键字《interface》的矩形符号来表示（2）采用小圆圈和半圆圈来表示3.协作（Collaboration）4.用况（Use Case）5.主动类（Action Class）6.构件（Component）7.制品（Artifact）8.节点（Node）4.1.2 表达关系的术语1.关联（Association）（1）关联名（Name）（2）导航（3）角色（Role）（4）可见性（5）多重性（Multiplicity）（6）限定符（Qualifier）（7）聚合（Aggregation）（8）组合（Composition）（9）关联类（10）约束①有序（ordered）②无重复对象（set）③有重复对象（bag）④列表（list）或序列（sequence）⑤只读（readonly）2.泛化（Generalization）①完整（Complete）②不完整（Incomplete）③互斥（Disjoint）④重叠（Overlapping）3.细化（Realization）4.依赖①绑定（Bind）②导出（Derive）③允许（Permit）④实例（InstanceOf）⑤实例化（Instantiate）⑥幂类型（Powertype）⑦精化（Refine）⑧使用（Use）可模型化以下各种关系（1）结构关系1）以数据驱动2）以行为驱动（2）继承关系（3）精化关系（4）依赖关系4.1.3 表达组合信息的术语——包1）访问（Access）2）引入（Import）4.2 UML模型表达格式1.类图（Class Diagram）（1）模型化待建系统的概念（词汇）, 形成类图的基本元素（2）模型化待建系统的各种关系, 形成该系统的初始类图（3）模型化系统中的协作, 给出该系统的最终类图（4）模型化逻辑数据库模式2.用况图（Use Case Diagram）所包含的内容（1）主题（Subject）（2）用况（Use Case）（3）参与者（Actor）（4）关联、泛化与依赖模型化工作1）关于系统/业务语境的模型化①系统边界的确定②参与者与用况的交互③参与者的语义表达④参与者的结构化处理2）关于系统/业务需求的模型化①确定系统/业务的基本用况②用况的结构化处理③用况的语义表达3.状态图（1）状态1）名字2）进入/退出效应（Effect）①entry②exit③状态内部转移3）do动作或活动4）被延迟的事件（2）事件1）信号（Signal）事件2）调用（Call）事件3）时间事件4）变化事件（3）状态转移①源状态②转移触发器③监护（guard）条件④效应（effect）⑤目标状态实际应用中, 使用状态图的作用①创建一个系统的动态模型②创建一个场景的模型4.顺序图（1）术语解析1）消息2）对象生命线3）聚焦控制（the Focus of Control）（2）控制操作子1）选择执行操作子（Operator for Optional Execution）2）条件执行操作子（Operator for Conditional Execution）3）并发执行操作子（Operator for Parallel Execution）4）迭代执行操作子（Operator for Iterative Execution）4.3 本章小结第五章面向对象方法——RUP5.1 RUP特点1.以用况为驱动2.以体系结构为中心3.迭代增量式开发5.2 核心工作流5.2.1 需求获取1.列出候选需求2.理解系统语境（1）业务用况模型（2）业务对象模型3.捕获系统功能需求（1）活动1: 发现并描述参与者（2）活动2: 发现并描述用况（3）活动3: 确定用况的优先级（Priority）（4）活动4: 精化用况（5）活动5: 构造用户界面原型1）用户界面的逻辑设计2）物理用户界面的设计3）开发用户界面原型并演示为了执行该用况, 用户怎样使用该系统（6）活动6: 用况模型的结构化5.2.2 需求分析1.基本术语（1）分析类（Analysis Class）1）边界类（Boundary Classes）2）实体类（Entity Classes）3）控制类（Control Classes）（2）用况细化（Use Case Realization）（3）分析包（Analysis Package）2.分析模型的表达3.分析的主要活动（1）活动1: 体系结构分析（Architectural Analysis）1）任务1: 标识分析包2）任务2: 处理分析包之间的共性3）任务3: 标识服务包4）任务4: 定义分析包的依赖5）任务5: 标识重要的实体类6）任务6: 标识分析包和重要实体类的公共特性需求（2）活动2: 用况分析1）任务1: 标识分析类①标识实体类②标识边界类③标识控制类2）任务2: 描述分析（类）对象之间的交互（3）活动3: 类的分析1）任务1: 标识责任2）任务2: 标识属性①关于实体类属性的标识②关于边界类属性的标识③关于控制类属性的标识3）任务3: 标识关联和聚合①关于关联的标识②关于聚合的标识③关于泛化的标识（4）活动4: 包的分析4.小结（1）关于分析模型1）分析包2）分析类3）用况细化（2）关于分析模型视角下的体系结构描述（3）用况模型和分析模型比较（4）分析模型对以后工作的影响1）对设计中子系统的影响2）对设计类的影响3）对用况细化[设计]的影响5.2.3 设计1.设计层的术语（1）设计类（Design Class）（2）用况细化[设计]（3）设计子系统（4）接口（Interface）2.设计模型、部署模型以及相关视角下的体系结构描述（1）设计模型及其视角下的体系结构描述1）子系统结构2）对体系结构有意义的设计类3）对体系结构有意义的用况细化[设计]（2）部署模型及该模型视角下的体系结构描述3设计的主要活动（1）活动1: 体系结构的设计1）任务1: 标识节点和它们的网络配置2）任务2: 标识子系统和它们的接口①标识应用子系统②标识中间件和系统软件子系统③定义子系统依赖④标识子系统接口3）任务3: 标识在体系结构方面有意义的设计类和它们的接口4）任务4: 标识一般性的设计机制①标识处理透明对象分布的设计机制②标识事务管理的设计机制（2）活动2: 用况的设计1）标识参与用况细化的设计类2）标识参与用况细化的子系统和接口（3）活动3: 类的设计1）任务1: 概括描述设计类2）任务2: 标识操作3）任务3: 标识属性4）任务4: 标识关联和聚合5）任务5: 标识泛化6）任务6: 描述方法7）任务7: 描述状态（4）活动4: 子系统的设计1）任务1: 维护子系统依赖2）任务2: 维护子系统所提供的接口3）任务3: 维护子系统内容4.RUP设计小结1）RUP设计的突出特点2）关于RUP的设计方法①给出用于表达设计模型中基本成分的4个术语, 包括子系统, 设计类, 接口, 用况细化[设计]②规约了设计模型的语法, 指导模型的表达③给出了创建设计模型的过程以及相应的指导3）RUP的设计模型①设计子系统和服务子系统②设计类（其中包括一些主动类）, 以及他们具有的操作、属性、关系及其实现需求。
《需求工程》知识要点
~ 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章.需求获取概述
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)与目标软件系统之间一次典型的交 互作用，其效果就是执行者在软件系统的帮助下 完成了某项业务功能，或达成了某项业务目标。 从软件系统内部的视角出发，一个用例代表着系 统执行的一系列动作，动作执行的结果能够被外 部的执行者所察觉。
关于需求分析的总结报告
关于需求分析的总结报告在学习了第四章的需求获取之后做出以下总结这部分主要强调了在优秀的软件工程中抽象和建模的关键原则。
使用模型来从已有的需求中梳理出误解和遗漏的的细节并与他人沟通需求。
讨论了需求的不同资源和不同类型功能需求VS质量需求VS设计约束解释如何编写易测试的需求并描如何解决冲突。
讨论需求引出、需求文档、需求评审、需求质量及度量以及如何选择一个规格说明方法的示例。
为了开发出真正满足用户需求的软件产品首先必须知道用户的需求。
对软件需求的深入理解是软件开发工作获得成功的前提条件不论人们把设计和编码工作做得如何出色不能真正满足用户需求的程序任然是失败的程序。
那么这些工作需要在编码前进行细致的安排包括一需求分析任务的建立 1 确定对系统任务的综合要求○1功能需求指定系统必须提供的服务通过需求分析应该划分出系统必须完成的所有功能○2性能需求指定系统必须满足的定时约束和容量约束○3可靠性和可行性需求定量的指定系统的可靠性○4出错处理需求说明系统对于环境错误应该怎样响应○5接口需求描述应用系统与它的环境通信的格式○6约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件 2 分析系统的数据要求软件系统本质都是信息处理系统系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌对软件设计有深远影响 3 到处系统的逻辑模型 4 修正系统开发计划二与用户沟通获取需求的方法分析员提出一些事先准备好的具体问题例如询问客户公司销售的商品种类、雇佣的销售人员数目以及信息反馈时间应该多快等在非正式访谈中分析员提出一些用户可以自由回答的开性问题以鼓励被访问人员说出自己的想法例如询问用户对目前正在使用的系统有哪些不满意的地方。
在访问用户的过程中使用情景分析技术往往非常有效。
三分析建模与规格说明 1 分析建模 2 软件需求规格说明通常使用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
软件开发行业作业指导书
软件开发行业作业指导书第1章软件开发基础 (4)1.1 软件开发概述 (4)1.1.1 软件定义 (4)1.1.2 软件开发目的 (4)1.1.3 软件开发层次 (4)1.2 软件开发生命周期 (4)1.2.1 需求分析 (4)1.2.2 设计 (4)1.2.3 编码 (4)1.2.4 测试 (4)1.2.5 维护 (5)1.3 常用软件开发模型 (5)1.3.1 瀑布模型 (5)1.3.2 快速原型模型 (5)1.3.3 迭代模型 (5)1.3.4 敏捷开发模型 (5)1.3.5 喷泉模型 (5)1.3.6 智能化开发模型 (5)第2章需求分析 (5)2.1 需求获取 (5)2.1.1 用户访谈 (5)2.1.2 调查问卷 (6)2.1.3 竞品分析 (6)2.1.4 需求工作坊 (6)2.2 需求分析 (6)2.2.1 功能需求分析 (6)2.2.2 功能需求分析 (6)2.2.3 可用性需求分析 (6)2.2.4 安全性需求分析 (6)2.2.5 兼容性需求分析 (6)2.3 需求规格说明书 (6)2.3.1 引言 (6)2.3.2 总体描述 (7)2.3.3 功能需求 (7)2.3.4 功能需求 (7)2.3.5 可用性需求 (7)2.3.6 安全性需求 (7)2.3.7 兼容性需求 (7)2.3.8 界面需求 (7)2.3.9 系统约束 (7)2.3.10 附录 (7)第3章系统设计 (7)3.1 架构设计 (7)3.1.1 系统结构 (7)3.1.2 层次划分 (7)3.1.3 模块划分 (8)3.1.4 关键技术与选型 (8)3.2 模块设计 (8)3.2.1 用户模块 (8)3.2.2 业务模块 (8)3.2.3 系统管理模块 (8)3.3 数据库设计 (9)3.3.1 表结构设计 (9)3.3.2 索引设计 (9)3.3.3 存储过程设计 (9)第4章编码实现 (9)4.1 编程规范 (9)4.1.1 通用规范 (9)4.1.2 命名规范 (9)4.1.3 代码结构规范 (9)4.2 代码审查 (10)4.2.1 审查流程 (10)4.2.2 审查内容 (10)4.3 版本控制 (10)4.3.1 版本控制工具 (10)4.3.2 提交规范 (10)4.3.3 分支管理 (10)第5章软件测试 (10)5.1 测试策略 (11)5.1.1 目的与原则 (11)5.1.2 测试范围与对象 (11)5.1.3 测试方法与工具 (11)5.2 单元测试 (11)5.2.1 目的与原则 (11)5.2.2 测试内容 (11)5.2.3 测试方法与工具 (12)5.3 集成测试与系统测试 (12)5.3.1 集成测试 (12)5.3.2 系统测试 (12)第6章软件部署与维护 (12)6.1 软件部署 (12)6.1.1 部署前准备 (12)6.1.2 部署流程 (12)6.1.3 部署策略 (13)6.2 软件维护 (13)6.2.2 维护内容 (13)6.2.3 维护流程 (13)6.3 软件升级与更新 (13)6.3.1 升级策略 (13)6.3.2 更新流程 (13)第7章软件项目管理 (14)7.1 项目规划 (14)7.1.1 项目目标 (14)7.1.2 项目团队组织 (14)7.1.3 项目计划 (14)7.1.4 资源规划 (14)7.1.5 项目预算 (14)7.2 项目进度控制 (14)7.2.1 项目进度监控 (14)7.2.2 项目调整 (14)7.2.3 项目报告 (14)7.2.4 项目评审 (14)7.3 项目风险管理 (14)7.3.1 风险识别 (15)7.3.2 风险评估 (15)7.3.3 风险应对策略 (15)7.3.4 风险监控 (15)7.3.5 风险管理文档 (15)第8章软件开发团队协作 (15)8.1 团队组织与管理 (15)8.1.1 团队结构 (15)8.1.2 团队成员选择与配置 (15)8.1.3 团队管理 (15)8.2 沟通与协作 (15)8.2.1 沟通渠道 (15)8.2.2 协作规范 (16)8.3 知识分享与技能提升 (16)8.3.1 知识分享 (16)8.3.2 技能提升 (16)第9章软件开发工具与环境 (16)9.1 集成开发环境 (16)9.1.1 概述 (16)9.1.2 常用集成开发环境 (17)9.1.3 集成开发环境的选择 (17)9.2 代码管理工具 (17)9.2.1 概述 (17)9.2.2 常用代码管理工具 (17)9.2.3 代码管理工具的选择 (17)9.3.1 概述 (18)9.3.2 常用项目管理工具 (18)9.3.3 项目管理工具的选择 (18)第10章软件开发行业发展趋势 (18)10.1 新兴技术概述 (18)10.2 开源与闭源之争 (19)10.3 软件开发行业的未来挑战与机遇 (19)第1章软件开发基础1.1 软件开发概述1.1.1 软件定义软件是指在计算机硬件及系统环境下，为实现一定功能或多个功能，按照特定要求设计、开发、测试、维护的相关文档和程序代码的集合。
软件工程中的软件需求管理
需求与设计的关联
建立需求-设计映射
确保设计是基于准确需求的
需求验证
验证设计是否符合需求规格
持续跟踪需求变化
不断迭代确认需求和设计的一致性
需求跟踪工具
JIRA
强大的项目管理和 跟踪工具
VersionOne
适用于敏捷开发的 需求跟踪软件
Trello
简单直观的需求管 理工具
●05
第五章 需求管理工具
需求管理工具概述
需求管理工具是通过软件工具来支持需求管理活动的工 具，包括需求收集工具、需求建模工具、需求跟踪工具 等。这些工具可以帮助团队更好地管理和跟踪需求，提
高项目管理效率。
常用的需求管理工具
JIRA
功能强大，适用于大型团队
Trello
简单易用，适用于小型团队
Rational RequisitePro
软件需求的分类
功能性需求
指明系统应该做什么
非功能性需求
指明系统应该如何做
软件需求管理的重要性
按时交付
预算内完成
满足用户需求
有效的需求管理可以确保项目 按时交付
有效的需求管理可以确保项目 在预算内完成
有效的需求管理可以确保项目 满足用户需求
软件需求管理的挑战
需求不明确
需求可能存在不明 确、不完整、不一大型团队需要强大 的需求管理功能
预算
需求管理工具费用 也是考虑因素
项目需求
不同项目需要不同 的需求管理方法
易用性
工具易用性影响团 队使用效率
需求管理工具的使用
培训团队成员
建立统一流程
有效使用工具
团队沟通
对工具的培训可以提高团队使 用效率 定期更新培训内容以跟上工具
软件工程(习题及参考答案)
第1章概述（习题与参考答案）［判定题］1. 由于今天个人运算机不断进展壮大，人们再也不采纳软件团队的开发方式。
（×）2. 由于软件是产品，因此能够应用其他工程制品所用的技术进行生产。
（×）3. 购买大多数运算机系统所需的硬件比软件更昂贵。
（×）4. 大多数软件产品在其生命周期中不需要增强功能。
（×）5. 大多数软件系统是不容易转变的，除非它们在设计时考虑了转变。
（√）6. 一样来讲，软件只有在其行为与设计者的目标一致的情形下才能成功。
（×）［选择题］1. （）因素促使运算机系统愈来愈复杂。
（D）A. 运算机内存和存储容量上的庞大增加B. 外部输入／输出选项的加倍多样性C. 运算机体系结构方面的深刻转变D. 以上所有选项2. 下面的（）再也不是现代软件工程师关注的问题。
（A）A. 什么缘故运算机硬件的本钱这么高？B. 什么缘故软件需要很长时刻才能完成？C. 什么缘故开发一个软件的本钱这么高？D. 什么缘故不能在产品发布前去除软件错误？3. 软件会慢慢退化而可不能磨损，其缘故在于（）。
（C）A. 软件通常暴露在恶劣的环境下B. 软件错误通常发生在利用以后C. 不断的变更使组件接口之间引发错误D. 软件备件很难订购4. 大多数软件仍然是定制开发的，其缘故在于（）。
（C）A. 软件组件重用是十分普遍的B. 可重用的组件太昂贵而无法利用C. 软件在不利用其他组件的情形下很容易构造出来D. 商业组件在很多应用领域中能够取得5. 下面的（）说法是正确的。
（C）A. 软件危机在20世纪70年代末期全面暴发B. 当前先进的软件工程方式已经解决了软件危机的问题C. 软件危机是指在运算机软件的开发和保护进程中碰到的一系列严峻问题D. 软件危机是指在软件产品中存在一系列的质量问题6. 软件工程的大体目标是（）。
（B）A. 排除软件固有的复杂性B. 开发高质量的软件C. 尽力发挥开发人员的制造性潜能D. 更好地保护正在利用的软件产品7. （）是将系统化的、标准的、可定量的方式应用于软件的开发、运行和保护的进程，它包括方式、工具和进程三个要素。
四步搞定需求｜需求获取、需求分析
如上所述，需求获取这一步主要包括三个方面的内容：渠道、方式、记录。
一、需求获取渠道对产品经理而言，需求获取的渠道主要可分为两类：外部渠道和内部渠道。
1.外部渠道1）市场需求和产品常常会受到行业政策调整的影响。
如“净网行动”、“打车软件专车服务属非法营运”等。
2）用户产品设计的初衷就是为了满足用户需求。
3）竞品所谓的竞品，主要可分为两种。
一种是用同样的产品功能满足同样用户需求的产品，另一种是用不同的产品功能满足同样用户需求的产品。
竞品对用户需求的满足程度、满足方式既会对我们产生影响，也可以为我们的产品设计带来一定的启发。
4）合作伙伴合作伙伴在商业模式当中扮演着重要的角色，因此他们的需求亦不容忽视。
2.内部渠道1）产品用户在使用产品时会产生行为数据，这些客观的数据一定程度上会反映出用户的需求。
2）老板企业运转的根本目的在于盈利。
产品在满足用户需求的同时必须兼顾公司的战略需求。
而这方面需求通常是由老板或公司的高层来把握。
3）同事一款产品从诞生到投入市场，主要需要以下角色参与：产品、研发、设计、运营、市场、销售、客服。
其中，运营、市场、销售（解决合作伙伴对产品价值的质疑）、客服（解决用户遇到的问题）是距离用户最近的人，往往最能理解用户抱怨的点也最能提出产品建设性的意见。
4）自己产品经理应该成为自己产品的用户，而且是产品的目标用户，在使用产品的过程去发现用户需求，如此一来才能更好地帮助用户解决问题。
二、需求获取的方式需求获取的方式依来源渠道差异可分为外部和内部两大类：1.外部1）市场●政策调整关注行业相关的政策调整，并思考其对需求和产品的影响。
●动态资讯关注行业资讯，思考行业动向对需求和产品的影响。
●行业数据利用行业数据报告、行业数据统计工具获取需求。
CNNIC、199IT、易观智库、艾瑞咨询等机构会不定期发布行业的相关报告，这些机构的报告相对而言比较有权威性，具有一定的参考价值。
除了行业相关的数据报告，还有诸如百度指数、360指数等基于大量用户数据的数据统计工具。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 默认（Tacit）知识现象
• 利用有效的获取方法与技巧（角色扮演、观察等） 来发现并获取默认知识
（2）普通用户缺乏概括性、综合性的表述能力
– 普通用户的知识结构就相对局限于一些具体的业务细节 • 善于表达具体业务的细节问题
– 专家用户的知识结构因其渊博性而具有概括性和广泛性 • 能够回答概括性和综合性的问题 – 开发人员在与用户接触之前就先行确定获取的内容主题， 然后设计具体的应用环境和场景条件，由用户根据细节 业务的执行来描述问题、表达期望。
问题域特性
内容
记录结果
成果
涉众
特征
涉众分析
采样涉众
涉众特征
获取笔录
第3节 需求获取活动的要点
3.1 获取的内容
• 在项目的范围之内 • 所有为用户创建解决系统必须的信息
– 需求
• 通常体现为用户的观点、看法、目标或者问题
– 问题域特性
• 需要注意的是不要忽略系统的环境和约束
• 获取的内容不是一次得到的，而是逐步积累的
• 基于上下文的方法
– 观察、民族志（Ethnography）和话语分析（Conversation Analysis）
3.4 获取的过程 （1）注意事项 • 在整体上制定组织方案
– 确定系统的边界，建立上下文图或系统用例图
• • • •
维护项目的前景和范围 引导和控题域 业务数据资料 硬数据采样 样本数据 文档资料 系统环境
应用背景资料 对 问 题 解 决 的 期 望 采集范围
获取源
获取环境
问题分析
业务需求
目 定义项目前景 和范围 标
高层次解决方案 系统特性
项目前景和范 围文档
获取内容
选择获取方 法、执行获取
业务问题的期望 业务解释
用户需求 内容
业务范围 高层次问题 获取源
3.2 获取的来源
• 涉众
–用户 –客户 –领域专家 –市场人员、销售人员等其 他用户替代源
硬数据
• 相关产品
–原有系统 –竞争产品 –协作产品（和解系统存 在接口的其他软件系统）
登记表格、单据、报表等 定量文档 备忘录、日志等定性文档 重要文档 原有系统的规格说明 竞争产品的规格说明 协作产品的规格说明 客户的需求文档（委托开发 的规格说明、招标书） 相关技术标准和法规 相关法律、法规及规章制度 行业规范、行业标准
（3）用户存在认知困境
– 潜在（Latency）知识
• 需要利用各种有效的需求获取方法和技巧
（4）用户越俎代庖
– 用户提出的不是需求，而是解决方案
• 注意保持业务领域和解决方案的区分界限
– 用户固执的坚持某些特征和功能
• 分析用户的深层目的，找到隐藏在背后的需求
（5）缺乏用户参与
– – – – – 用户数量太多，选择困难 用户认识不足，不愿参与 用户情绪抵制，消极参与 没有明确的用户 对系统的用户以及用户的替代源等相关涉众 进行分析
（3）结束获取活动的判断条件
•用户想不出更多的用例； •用户想出的新用例都是导出用例（通过其他用例的 结合可以推导出该用例）； •用户只是在重复已经讨论过的问题； •新提出的特性、需求等都在项目范围之外； •新提出的需求优先级都很低； •用户提出的新功能都属于后继版本，而非当前版本 客户定制软件和市场驱动软件的不同交流途径倾向见 教材P74表4-3
第2节 需求获取的活动过程
2.1 需求获取的子活动 • • • • • 研究应用背景，建立初始的知识框架； 根据获取的需要，采用必要的获取方法和技巧； 先行确定获取的内容和主题，设定场景； 分析用户的高（深）层目标，理解用户的意图； 进行涉众分析，针对涉众的特点开展工作。
2.2 需求获取的活动过程
上下文图是一个简单的分析模型，显示了新的系统是如何适合 其环境，它定义了所开发的系统和系统外部实体（如使用人员、 硬件设备和其它信息系统）之间的边界和接口。
例1：上下文图（数据流图语法） 例2 ：上下文图（用例语法）
（2）防止需求遗漏
• 务必让所有的涉众都表达出自己的意见。 • 不要以抽象和模糊的需求作为结束。对抽象和模糊 的需求，要进行细化，让真正的需求显露出来。 • 使用多种方法表达需求信息。利用不同的分析技术 为相同的需求进行建模，通过分析不同的关注点， 考察需求是否完整。 • 注意检查边界值和布尔逻辑。
3.3 获取的方法
• 传统方法
– 问卷调查、面谈、硬数据分析、文档检查、需求剥离等
• 集体获取方法
– 头脑风暴（Brainstorming）、专题讨论会（Workshop）、 应用程序开发联系会议 (JAD)等
• 原型 • 认知方法
– 任务分析(Task Analysis)、协议分析(Protocol Analysis)等
3.5 获取的结果
• 肯定会产生获取笔录（Elicitation Notes）
– 用户需求、问题域知识和约束 – 可能具有组织差、冗余、遗漏、自相矛盾等诸 多问题 – 可以包括文字记录、录音、摄像等各种形式
• 可能会产生两份定义明确的正式文档
– 项目前景和范围文档 – 用例文档
第4章 需求获取概述
主要内容
第1节 第2节 第3节 第4节 需求获取的非平凡性 需求获取的活动过程 需求获取活动的要点 需求获取的实践调查情况
第1节
需求获取的非平凡性
（1）用户和开发人员的背景不同，立场不同
– 首先是知识理解的困难。
• 尽力去研究应用的背景，理解组织的状况，形成一 个能够和用户进行有效沟通的粗略的知识框架