? 2008 BUPT TSEG
软件工程模型与方法
Models & Methods of SE
第四章 软件需求分析肖丁 dxiao@bupt.edu.cn
2? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心引言
为何要进行软件的需求分析？
软件的需求分析处于软件生命周期的那个阶段？
起到什么作用？
怎样才能做好软件需求分析？
软件需求分析的过程和步骤是什么？
软件需求分析的最终结果是什么？
3? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.1 需求的定义
需求来源于用户的一些“需要”，这些“需要”
被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 。
Boehm 给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受
，并能够把“需求”严格地、形式地表达出来。
,需求、设计、编程、测试四者究竟哪个环节最重要？”
首先，每个环节都是很重要，任何一个环节出现问题
，都会导致软件的质量问题。
但是，从管理的角度来看，需求是软件产品的起源，
因而是最重要的一个环节
4? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
某大型的电信设备供应商，案例中涉及 6个部门 A,B,C,D,E和 F，它们之间的关系如下图所示：
F
客户
E：网管软件承包商
D
销售机构
A：增值业务研发机构 C：项目管理机构
B：核心平台研发机构一年前,B研制了一种数据接入服务器的原型。 B对 A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”
D对 B和 A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”
5? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
A觉得机会难得，于是向 C申请立项。
立项后,A把项目外包给专业做网管软件的公司 E，期望半年内完成。
由于接入服务器是 B的，于是 A和 E就派开发人员到 B处搞需求分析。
B的接入服务器并不成熟，老在变，三方折腾了好久，最终 E用了一年时间把接入服务器的网管软件做出来了。
E把网管软件交付给 A,A付清了 E的开发费用，再把网管软件交付给
D,D再卖给客户 F（某地电信局）。
F对 D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”
D赶紧对 A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”
A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”
6? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
祸不单行的是,C来找 A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。”
A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策，设法把事情搞定。
大家挖空心思只想出一个馊主意：既然套子是 B下的，那么就把套子还给 B。要设法把“那么好”的网管产品转让给 B，只要 B能给我们成本费，以后就跟 B拜拜。
这个案例的问题根源在于进行软件开发之前没有搞清楚网管软件的需求，这都是 B,A,E闭门造车惹的祸。
最可悲的是，相关责任人关心的是如何把事情“完成”，
而不是深刻了解用户的具体需求。
这种类似的事情在软件开发行业中经常发生而且还会继续发生，最主要的是每发生一次就损失大量的人力和物力。
7? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.3 需求分析的必要性
需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：
它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，
建立软件必须满足的约束条件。
它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
它能准确表达用户对系统的各项要求。
8? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.4 需求分析的对象、任务和目标
软件需求分析的对象是用户要求。
其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。
作为目标系统的参考，需求分析的任务就是借助于（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
9? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.5 需求分析建模的原则
需求分析方法的一组 操作性原则 是：
1,问题的信息域必须被表示和理解。
2,软件将完成的功能必须被定义。
3,软件的行为 （作为外部事件的结果） 必须被表示。
4,描述信息、功能和行为的模型必须被划分，使得可以用层次的方式揭示细节。
5,分析过程应该遵从自顶向下，逐层细化的原则。
一组三元模型：第 1条原则表示需要建立数据模型，第 2条和第 3条原则表示需要建立功能和行为模型。
10? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6需求工程的指导性原则
首先要正确地理解问题，再建立分析模型。
记录每个需求的起源及原因，保证需求的可回溯性。
开发一个能使用户能够了解人机交互过程的原型。因为对软件质量的感觉经常基于对界面“友好性”的感觉。
使用多个需求视图。建立数据模型、功能模型和行为模型，为软件工程师提供三种不同的视图，增加识别不一致性的基础。
给需求赋予优先级。紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
努力删除歧义性。因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。
11? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.1 数据建模
需求分析的第 1条操作性分析原则表明需要对信息域进行检查并创建数据模型。
信息域包含三个不同的数据和控制视图：
信息内容和关系；
信息流；
信息结构。
信息流表示了数据和控制在系统中流动时变化的方式信息内容表示了个体数据和控制对象；
数据和控制对象可和其他的数据和控制对象关联信息结构表示了各种数据和控制项的内部组织
12? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.2 功能及行为建模
功能模型,对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出。
行为模型,大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。
功能模型和行为模型的作用如下：
模型能够帮助软件开发人员快速准确的理解系统所涉及的信息
、功能和动态行为；
模型可成为后期软件设计的基础，为软件设计人员提供了设计软件功能的视图化表示；
模型能够成为软件测试和软件评审的重要依据
13? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.3 问题划分
需求问题域涉及面广泛而且复杂，以至于难以进行整体理解。为此，需要将这样的问题划分为易于理解的子问题，并建立各子问题间的关系以使得可以完成整个功能。
第 4条和第 5条操作性分析原则建议软件的信息、
功能和行为域可以被划分。
在本质上，划分将问题分解为其构成成分。在概念上，建立信息或功能的层次结构表示，通过进行自顶向下的分析，进而暴露更多的细节问题，
并在各层次上进行各功能元素的分配。
14? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7 需求工程
软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，
人们把所有与需求直接相关的活动通称为需求工程。
需求工程需求开发需求变更控制需求管理需求确认需求跟踪需求获取需求分析需求定义用户需求说明书软件需求规格说明书需求跟踪矩阵需求评审报告
15? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.1 需求获取
需求获取的目的是清楚地理解所要解决的问题
，完整地获得用户的需求。并提出这些需求实现条件，以及需求应达到的标准。
需求获取的对象
用户：使用软件的人员
客户：购买软件的人员
需求获取的难点
用户无法清楚地表达需求
需求的理解问题
用户经常变更需求
16? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.2 需求获取流程目的 获取用户（客户与最终用户）的需求信息，经过分析后产生,用户需求说明书,。
角色与职责 需求分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。
启动准则 需求分析员已经确定输入 任何与用户需求相关的材料主要步骤第一步：准备调查第二步：调查与记录第三步：分析需求信息第四步：撰写,用户需求说明书,
第五步：需求确认输出,用户需求说明书,
结束准则需求分析员已经撰写完成,用户需求说明书,,确保无拼写、排版等错误。并确保
,用户需求说明书,的内容无二义性，且涵盖了所有的用户需求。
度量 需求分析员统计工作量和上述文档的规模，汇报给项目经理。
17? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.3 需求获取的准备
需求获取的准备工作围绕三项展开：
调查什么？
通过什么方式去调查？
,何人”在“何时”调查？
首先，应起草需求调查问题表，将重点锁定在该问题表内
，否则调查工作将变得漫无边际。
其次，应当确定需求调查的方式，比如：
与用户交谈，向用户提问题。
参观用户的工作流程，观察用户的操作。
向用户群体发调查问卷。
与同行、专家交谈，听取他们的意见。
18? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.4 需求获取的记录
准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如下图：
需求标题 1
调查方式调查人调查对象时间、地点需求信息记录 基本要素如“是什么”、“为什么”等
19? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.5 撰写用户需求说明书
最后对收集到的所有需求信息进行分析，
消除错误，归纳与总结共性的用户需求。
然后按照规定的文档模板撰写,用户需求说明书,,调查过程中获取的需求信息可以作为,用户需求说明书,的附件。
之后应当邀请同行专家和用户一起评审,
用户需求说明书,,尽最大努力使,用户需求说明书,能够正确无误地反映用户的真实意愿。
20? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.6 用户需求说明书与软件需求规格说明书的区别
前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。
两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整软件需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据,软件需求规格说明书,来开发当前产品。
21? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
功能需求,列举出所开发软件在功能上应做什么，这是最主要的需求。
性能需求,给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、
消息传送时间等；资源配置要求，精确度，数据处理量等要求。
环境需求,是对软件系统运行时所处环境的要求。
在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。
在软件方面，采用什么支持系统运行的系统软件（指操作系统
、网络软件、数据库管理系统等）。
在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。
22? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
可靠性需求：指软件的有效性和数据完整性。各种软件在运行时失效的影响各不相同。在需求分桥时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求。
安全保密要求：工作在不同环境的软件对其安全
、保密的要求显然是不同的，应当把这方面的需求恰当地做出规定。
用户界面需求：软件与用户界面的友好性是用户能够方便有效愉快地使用该软件的关键之一。
23? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
资源使用需求,指所开发软件运行时所需的数据
、软件、内存空间等各项资源，以及软件开发时所需的人力、支撑软件、开发设备等。
软件成本消耗与开发进度需求,在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。
预先估计以后系统可能达到的目标,在开发过程中，可对系统将来可能的扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。
24? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9 需求的分析与综合
需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，
分析它们是否满足功能要求，是否合理。
依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
分析和综合工作需要反复地进行，其过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。
25? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9.1 需求的定义目的 定义准确无误的软件产品需求，产生,软件需求规格说明书,。
角色与职责 需求分析员定义软件需求。客户与最终用户确认软件需求。
启动准则,用户需求说明书,已经撰写完成。
输入,用户需求说明书,
主要步骤第一步：细化并分析用户需求第二步：撰写软件需求规格说明书第三步：软件需求确认输出,软件需求规格说明书,
结束准则,软件需求规格说明书,已经撰写完成。开发方和客户方已经对产品需求进行了确认。
度量 需求分析员统计工作量和上述文档的规模，汇报给项目经理。
26? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9.2 需求建模
软件开发人员还需要构造系统的分析模型，着重于描述系统必须做什么、而不是如何去做系统。
给出系统的逻辑视图，以及系统的物理视图。
逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。
物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。
常用的建模分析方法有：
面向数据流的结构化分析方法（简称 SA）
面向数据结构的 Jackson方法（简称 JSD）
面向对象的分析方法（简称 OOA）等
以及用于建立动态模型的状态迁移图或 Petri网等
27? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.10 编制需求分析文档
把描述需求的文档称为软件需求规格说明书。
为了确切表达用户对软件的输入输出要求，还需制定数据词典及初步的用户手册，反映软件的用户界面和用户使用的具体要求。
从现实中分离功能，即描述要“做什么”而不是“
怎样实现”；
要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。
如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；
规格说明必须包括系统运行环境，等；
28? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.10.1 需求文档的特点
正确性：不仅要正确书写，最主要的是正确地表达用户的需求。
清晰性：需求地表达是否清晰易懂？
文档的结构、段落是否乱七八糟？上下文是否不连贯？
文档的语句是否含糊其词、啰里啰唆？
看了半天是否还不明白需求究竟是什么？
无二义性：需求的表达内容只有唯一的含义。
一致性：在上下中，需求之间不存在矛盾。
必要性：所需表达的内容一定是必须的，注意避免“画蛇添足”
完备性：需求所对应的功能是完整的，不能缺少某个部分。
可实现：所列举的需求，在技术上一定是可实现的。
可验证：所列需求在进行软件验收时，要被用户所理解和测试。
确定优先级：根据项目计划制定需求实现的先后次序。
29? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.11 需求确认
需求确认是指开发方和客户方共同对需求文档
,用户需求说明书,和,软件需求规格说明书
,进行评审，对需求达成共识后作出承诺。
目的 开发方和客户对需求文档进行评审，并作书面承诺。
角色与职责 开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。
启动准则 需求文档如,用户需求说明书,和,软件需求规格说明书,已经完成。
输入 需求文档如,用户需求说明书,和,软件需求规格说明书,
主要步骤 第一步：非正式需求评审第二步：正式需求评审第三步：获取需求承诺输出,需求评审报告,和书面的需求承诺结束准则 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。
度量 项目经理统计工作量和上述文档的规模。
30? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.12 需求评审
在需求分析的最后一步，应对功能的正确性、完整性和清晰性，以及其他需求给予评价。主要内容是：
系统定义的目标是否与用户的要求一致；
文档资料是否齐全，内容是否完整、清晰、准确？
与所有其他系统成分的重要接口是否都已经描述；
所开发项目的数据流与数据结构是否足够，确定；
所有图表是否清楚，在不补充说明时能否理解；
系统的约束条件或限制条件是否符合实际；
是否考虑过软件需求的其他方案；
是否考虑过将来可能会提出的软件需求；
是否详细制定了检验标准？
软件开发计划中的估算是否受到了影响？
软件工程模型与方法
Models & Methods of SE
第四章 软件需求分析肖丁 dxiao@bupt.edu.cn
2? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心引言
为何要进行软件的需求分析？
软件的需求分析处于软件生命周期的那个阶段？
起到什么作用？
怎样才能做好软件需求分析？
软件需求分析的过程和步骤是什么？
软件需求分析的最终结果是什么？
3? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.1 需求的定义
需求来源于用户的一些“需要”，这些“需要”
被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 。
Boehm 给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受
，并能够把“需求”严格地、形式地表达出来。
,需求、设计、编程、测试四者究竟哪个环节最重要？”
首先，每个环节都是很重要，任何一个环节出现问题
，都会导致软件的质量问题。
但是，从管理的角度来看，需求是软件产品的起源，
因而是最重要的一个环节
4? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
某大型的电信设备供应商，案例中涉及 6个部门 A,B,C,D,E和 F，它们之间的关系如下图所示：
F
客户
E：网管软件承包商
D
销售机构
A：增值业务研发机构 C：项目管理机构
B：核心平台研发机构一年前,B研制了一种数据接入服务器的原型。 B对 A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”
D对 B和 A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”
5? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
A觉得机会难得，于是向 C申请立项。
立项后,A把项目外包给专业做网管软件的公司 E，期望半年内完成。
由于接入服务器是 B的，于是 A和 E就派开发人员到 B处搞需求分析。
B的接入服务器并不成熟，老在变，三方折腾了好久，最终 E用了一年时间把接入服务器的网管软件做出来了。
E把网管软件交付给 A,A付清了 E的开发费用，再把网管软件交付给
D,D再卖给客户 F（某地电信局）。
F对 D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”
D赶紧对 A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”
A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”
6? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.2 一个需求分析的案例
祸不单行的是,C来找 A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。”
A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策，设法把事情搞定。
大家挖空心思只想出一个馊主意：既然套子是 B下的，那么就把套子还给 B。要设法把“那么好”的网管产品转让给 B，只要 B能给我们成本费，以后就跟 B拜拜。
这个案例的问题根源在于进行软件开发之前没有搞清楚网管软件的需求，这都是 B,A,E闭门造车惹的祸。
最可悲的是，相关责任人关心的是如何把事情“完成”，
而不是深刻了解用户的具体需求。
这种类似的事情在软件开发行业中经常发生而且还会继续发生，最主要的是每发生一次就损失大量的人力和物力。
7? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.3 需求分析的必要性
需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：
它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，
建立软件必须满足的约束条件。
它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
它能准确表达用户对系统的各项要求。
8? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.4 需求分析的对象、任务和目标
软件需求分析的对象是用户要求。
其任务是要准确地定义新系统的目标。回答系统必须“做什么”的问题并编制需求规格说明书。
作为目标系统的参考，需求分析的任务就是借助于（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
9? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.5 需求分析建模的原则
需求分析方法的一组 操作性原则 是：
1,问题的信息域必须被表示和理解。
2,软件将完成的功能必须被定义。
3,软件的行为 （作为外部事件的结果） 必须被表示。
4,描述信息、功能和行为的模型必须被划分，使得可以用层次的方式揭示细节。
5,分析过程应该遵从自顶向下，逐层细化的原则。
一组三元模型：第 1条原则表示需要建立数据模型，第 2条和第 3条原则表示需要建立功能和行为模型。
10? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6需求工程的指导性原则
首先要正确地理解问题，再建立分析模型。
记录每个需求的起源及原因，保证需求的可回溯性。
开发一个能使用户能够了解人机交互过程的原型。因为对软件质量的感觉经常基于对界面“友好性”的感觉。
使用多个需求视图。建立数据模型、功能模型和行为模型，为软件工程师提供三种不同的视图，增加识别不一致性的基础。
给需求赋予优先级。紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
努力删除歧义性。因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。
11? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.1 数据建模
需求分析的第 1条操作性分析原则表明需要对信息域进行检查并创建数据模型。
信息域包含三个不同的数据和控制视图：
信息内容和关系；
信息流；
信息结构。
信息流表示了数据和控制在系统中流动时变化的方式信息内容表示了个体数据和控制对象；
数据和控制对象可和其他的数据和控制对象关联信息结构表示了各种数据和控制项的内部组织
12? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.2 功能及行为建模
功能模型,对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出。
行为模型,大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。
功能模型和行为模型的作用如下：
模型能够帮助软件开发人员快速准确的理解系统所涉及的信息
、功能和动态行为；
模型可成为后期软件设计的基础，为软件设计人员提供了设计软件功能的视图化表示；
模型能够成为软件测试和软件评审的重要依据
13? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.6.3 问题划分
需求问题域涉及面广泛而且复杂，以至于难以进行整体理解。为此，需要将这样的问题划分为易于理解的子问题，并建立各子问题间的关系以使得可以完成整个功能。
第 4条和第 5条操作性分析原则建议软件的信息、
功能和行为域可以被划分。
在本质上，划分将问题分解为其构成成分。在概念上，建立信息或功能的层次结构表示，通过进行自顶向下的分析，进而暴露更多的细节问题，
并在各层次上进行各功能元素的分配。
14? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7 需求工程
软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，
人们把所有与需求直接相关的活动通称为需求工程。
需求工程需求开发需求变更控制需求管理需求确认需求跟踪需求获取需求分析需求定义用户需求说明书软件需求规格说明书需求跟踪矩阵需求评审报告
15? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.1 需求获取
需求获取的目的是清楚地理解所要解决的问题
，完整地获得用户的需求。并提出这些需求实现条件，以及需求应达到的标准。
需求获取的对象
用户：使用软件的人员
客户：购买软件的人员
需求获取的难点
用户无法清楚地表达需求
需求的理解问题
用户经常变更需求
16? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.2 需求获取流程目的 获取用户（客户与最终用户）的需求信息，经过分析后产生,用户需求说明书,。
角色与职责 需求分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。
启动准则 需求分析员已经确定输入 任何与用户需求相关的材料主要步骤第一步：准备调查第二步：调查与记录第三步：分析需求信息第四步：撰写,用户需求说明书,
第五步：需求确认输出,用户需求说明书,
结束准则需求分析员已经撰写完成,用户需求说明书,,确保无拼写、排版等错误。并确保
,用户需求说明书,的内容无二义性，且涵盖了所有的用户需求。
度量 需求分析员统计工作量和上述文档的规模，汇报给项目经理。
17? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.3 需求获取的准备
需求获取的准备工作围绕三项展开：
调查什么？
通过什么方式去调查？
,何人”在“何时”调查？
首先，应起草需求调查问题表，将重点锁定在该问题表内
，否则调查工作将变得漫无边际。
其次，应当确定需求调查的方式，比如：
与用户交谈，向用户提问题。
参观用户的工作流程，观察用户的操作。
向用户群体发调查问卷。
与同行、专家交谈，听取他们的意见。
18? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.4 需求获取的记录
准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如下图：
需求标题 1
调查方式调查人调查对象时间、地点需求信息记录 基本要素如“是什么”、“为什么”等
19? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.5 撰写用户需求说明书
最后对收集到的所有需求信息进行分析，
消除错误，归纳与总结共性的用户需求。
然后按照规定的文档模板撰写,用户需求说明书,,调查过程中获取的需求信息可以作为,用户需求说明书,的附件。
之后应当邀请同行专家和用户一起评审,
用户需求说明书,,尽最大努力使,用户需求说明书,能够正确无误地反映用户的真实意愿。
20? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.7.6 用户需求说明书与软件需求规格说明书的区别
前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。
两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整软件需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据,软件需求规格说明书,来开发当前产品。
21? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
功能需求,列举出所开发软件在功能上应做什么，这是最主要的需求。
性能需求,给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、
消息传送时间等；资源配置要求，精确度，数据处理量等要求。
环境需求,是对软件系统运行时所处环境的要求。
在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。
在软件方面，采用什么支持系统运行的系统软件（指操作系统
、网络软件、数据库管理系统等）。
在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等。
22? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
可靠性需求：指软件的有效性和数据完整性。各种软件在运行时失效的影响各不相同。在需求分桥时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求。
安全保密要求：工作在不同环境的软件对其安全
、保密的要求显然是不同的，应当把这方面的需求恰当地做出规定。
用户界面需求：软件与用户界面的友好性是用户能够方便有效愉快地使用该软件的关键之一。
23? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.8 需求类别
资源使用需求,指所开发软件运行时所需的数据
、软件、内存空间等各项资源，以及软件开发时所需的人力、支撑软件、开发设备等。
软件成本消耗与开发进度需求,在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。
预先估计以后系统可能达到的目标,在开发过程中，可对系统将来可能的扩充与修改做准备。一旦需要时，就比较容易进行补充和修改。
24? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9 需求的分析与综合
需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，
分析它们是否满足功能要求，是否合理。
依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
分析和综合工作需要反复地进行，其过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。
25? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9.1 需求的定义目的 定义准确无误的软件产品需求，产生,软件需求规格说明书,。
角色与职责 需求分析员定义软件需求。客户与最终用户确认软件需求。
启动准则,用户需求说明书,已经撰写完成。
输入,用户需求说明书,
主要步骤第一步：细化并分析用户需求第二步：撰写软件需求规格说明书第三步：软件需求确认输出,软件需求规格说明书,
结束准则,软件需求规格说明书,已经撰写完成。开发方和客户方已经对产品需求进行了确认。
度量 需求分析员统计工作量和上述文档的规模，汇报给项目经理。
26? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.9.2 需求建模
软件开发人员还需要构造系统的分析模型，着重于描述系统必须做什么、而不是如何去做系统。
给出系统的逻辑视图，以及系统的物理视图。
逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。
物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。
常用的建模分析方法有：
面向数据流的结构化分析方法（简称 SA）
面向数据结构的 Jackson方法（简称 JSD）
面向对象的分析方法（简称 OOA）等
以及用于建立动态模型的状态迁移图或 Petri网等
27? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.10 编制需求分析文档
把描述需求的文档称为软件需求规格说明书。
为了确切表达用户对软件的输入输出要求，还需制定数据词典及初步的用户手册，反映软件的用户界面和用户使用的具体要求。
从现实中分离功能，即描述要“做什么”而不是“
怎样实现”；
要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。
如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；
规格说明必须包括系统运行环境，等；
28? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.10.1 需求文档的特点
正确性：不仅要正确书写，最主要的是正确地表达用户的需求。
清晰性：需求地表达是否清晰易懂？
文档的结构、段落是否乱七八糟？上下文是否不连贯？
文档的语句是否含糊其词、啰里啰唆？
看了半天是否还不明白需求究竟是什么？
无二义性：需求的表达内容只有唯一的含义。
一致性：在上下中，需求之间不存在矛盾。
必要性：所需表达的内容一定是必须的，注意避免“画蛇添足”
完备性：需求所对应的功能是完整的，不能缺少某个部分。
可实现：所列举的需求，在技术上一定是可实现的。
可验证：所列需求在进行软件验收时，要被用户所理解和测试。
确定优先级：根据项目计划制定需求实现的先后次序。
29? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.11 需求确认
需求确认是指开发方和客户方共同对需求文档
,用户需求说明书,和,软件需求规格说明书
,进行评审，对需求达成共识后作出承诺。
目的 开发方和客户对需求文档进行评审，并作书面承诺。
角色与职责 开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。
启动准则 需求文档如,用户需求说明书,和,软件需求规格说明书,已经完成。
输入 需求文档如,用户需求说明书,和,软件需求规格说明书,
主要步骤 第一步：非正式需求评审第二步：正式需求评审第三步：获取需求承诺输出,需求评审报告,和书面的需求承诺结束准则 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。
度量 项目经理统计工作量和上述文档的规模。
30? 2008 BUPT TSEG 北京邮电大学 通信软件工程中心
4.12 需求评审
在需求分析的最后一步，应对功能的正确性、完整性和清晰性，以及其他需求给予评价。主要内容是：
系统定义的目标是否与用户的要求一致；
文档资料是否齐全，内容是否完整、清晰、准确？
与所有其他系统成分的重要接口是否都已经描述；
所开发项目的数据流与数据结构是否足够，确定；
所有图表是否清楚，在不补充说明时能否理解；
系统的约束条件或限制条件是否符合实际；
是否考虑过软件需求的其他方案；
是否考虑过将来可能会提出的软件需求；
是否详细制定了检验标准？
软件开发计划中的估算是否受到了影响？
