软件需求分析和建模

2.3 分析和精化
• 开发一个精确的技术模型，用以说明软件的功能、特征和约束。 • 精化是一个分析建模动作，由一系列建模和求精任务构成 • 定义了问题的信息域，功能域和行为域
2.4 可行性研究
• 可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问题是否能够解决 • 可行性研究的输入是系统的一个框架描述和高层逻辑模型 • 输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的具体建议和意见 • 三个问题：
• 2.1.2 扩展流程：......
系统需求
• 系统需求是比用户需求更详细的需求描述，是系统实现的基本依据 • 系统需求描述可能包括许多不同的模型，如对象模型和数据流模型
软件需求各组成部分之间的关系
软件需求规格说明的原则
从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的规格说明语言 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描
• 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标 系统的 “做什么” 的问题。
需求分析模型
当前系统 模型化
怎 物理模型 么 做 物理模型 具体化
目标系统
系统实现模型
需求分析的 主要工作
做什么
理
解
抽象化 逻辑模型
需 求
导
Байду номын сангаас
系统流程图 或高层DFD图
实例化 逻辑模型
出
表 达
在着相互作用关系
非功能需求举例
• 一个POS系统所需的存储因为成本原因有所限制，而商品的描述和价目表的信息量很大。 • 如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要
网络技术。 • 当POS机数量多时必然引起服务器处理瓶颈问题。
领域需求
• 领域需求反映应用领域的基本问题，直接影响到系统的可用性。
软件需求分析过程
软件需求分析过程
• 什么是软件需求？ • 软件需求分析有哪些过程？ • 如何启动分析过程？ • 需求规格文档有哪些内容？ • 需求分析有哪些技术？
1 什么是软件需求
一般把需求定义为“（正在构建的）系统必须符合的条件或 具备的功能或能力”。电气和电子工程师学会使用的定义与此 类似。
• 可行性研究最根本的任务是对以后的行动方针提出建议。
2.5 协商与沟通
• 调节冲突和问题 • 需求排序 • 识别和分析与每项需求相关的风险、开发工作量、成本和交付时间
2.6 软件需求规格
• 一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、 一组使用场景、一个原型或以上各项的任意组合。
软件工程方法与实践
软件需求分析与建模
主要问题
• 什么是软件需求？ • 软件需求分析有哪些过程？ • 如何启动分析过程？ • 什么是面向数据的建模？ • 什么是面向数据流的建模？ • 什么是非形式化建模、半形式化建模和形式化建模？ • 什么是统一建模语言（UML）？ • 什么是用例建模？ • 什么是领域模型？
需求分析的重要性
• 需求的重要性： • 需求是产品的根源，需求工作的优劣对产品影响最大。 • 是系统开发的基础，质量和成败的关键 • 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一 直忙碌不停地开发。
• 需求分析是通过问题识别、分析与综合、制订规格说明和评 审等阶段，达到为系统设计提供依据的目标。因此，需求分 析过程包括： • 确定对系统的综合要求 • 分析系统的数据要求 • 抽象出并确立目标系统的逻辑模型 • 编写需求规格说明书
• 完整性意味着用户所需的所有的服务应该全部给出描述 • 一致性意味着需求描述不能前后矛盾 • 准确性是指需求不能出现模糊和二义性的地方
功能需求描述：出卷系统
• 教师能够根据自己的要求手动或自动出一份试卷； • 教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷； • 教师可以对试题中的题目进行更新。
4 功能需求 4.1 功能划分
4.2 功能描述
5 性能需求 5.1 数据精确度 5.2 时间特性 5.3 适应性
• 软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产 品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。
• 软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以 及其他与需求相关的信息。
• 分为：用户需求和系统需求
用户需求描述示例
• 2.1 处理销售：完成一次销售过程。
• 2.1.1 基本流程：（1）顾客携带所购商品或服务到收 银台通过POS机付款；（2）收银员开始一次新的销售 交易；（3）收银员输入商品条码；（4）系统逐条记 录销售的商品，并显示该商品的描述、价格和累计额； 重复（3）—（4），直到输入结束；（5）系统显示 总额；（6）收银员告知顾客总额，并请求付款；（7） 顾客付款，系统处理支付；（8）系统记录完整的销 售信息，并将销售金和支持信息发送到外部的帐务系 统和库存系统；（9）系统打印票据；（10）顾客携 带商品和票据离开。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件：
1、软件需求可定义为： 用户需解决某一问题或达到某一目 标所需的软件功能。 2、系统或系统构件为了满足合同、规约、标准或其他正式实 行的文档而必须满足或具备的软件功能。
非功能需求
• 非功能需求主要与系统的总体特征相关，是一些限制 性要求，是对实际使用环境所做的要求 • 性能要求 • 可靠性要求 • 安全性要求 • 可用性要求 • 移植性要求
• 非功能需求关心的是系统整体特征而不是个别的系统 的特征，比功能需求对系统更关键。
• 非功能需求却很难检验 • 非功能需求与功能需求有时会发生冲突，它们之间存
2.2 导出需求
• 导出需求应理解问题： • 范围问题：系统的边界，是客户和开发者共同关心的部分 • 理解问题：确定业务需求、需求冲突、说明有歧义和不可测试的需求 • 易变问题：分清需求稳定部分和易变部分
• 收集活动： • 识别真正的客户/用户 • 正确理解客户的需求 • 耐心听取客户意见和思考 • 尽量使用符合客户语言习惯的表达
• 三种方式来发送和接收SMS信息： • Block Mode • Text Mode：纯文本方式，可使用不同的字符集，也可 用于发送中文短消息，主要用于欧美地区。 • PDU Mode：PDU Mode被所有手机支持，可以使用任何 字符集，这也是手机默认的编码方式
2 需求分析过程
• 需求分析过程主要是理解客户需要什么、分析要求、评 价可行性、协商合理的方案、无歧义地详细说明方案、 确认规格说明、管理需求以至将这些需求转化为可行系 统
需求分析阶段的目标是用计算机的（而不再是用户）眼光 和语言，分解需求、定义需求。但是，这个眼光不是程序 设计员的眼光，是系统分析师的眼光
经过需求处理后，达到需求规范要求 分析的方法是一套“建模”技术
软件需求的分类
• 功能需求：描述系统预期提供的功能或服务 • 对系统应提供的服务 • 如何对输入做出反应 • 系统在特定条件下的行为
需求分析的成果
需求分析就是为了实现系统需求，并使最后交付成果与需求 所要求的目标不产生：含糊性、不完整性、不可检验性、不 一致性、不可追踪性和不可用性。
需求分析面向下阶段——系统概要设计 需求分析采用自己的特定方法，达到相应的阶段要求
采用的方法是尽量地让用户和开发团队都能理解并认同系 统目标和范围界定的方法——业务/系统模型、用例和USE CASE图
• 系统是否符合机构的总体要求？ • 系统是否可以在现有的技术条件、预算和时间限制内完成？ • 系统能否把已存在的其他系统集成？
可行性研究的任务
• 可行性研究的目的就是用最小的代价在尽可能短的时间内 确定问题是否能够解决。必须记住，可行性研究的目的不 是解决问题，而是确定问题是否值得去解决。
• 一般来说，至少应该从下述四个方面去研究每种解法的可 行性： • 技术可行性：使用现有的技术能实现这个系统吗？ • 经济可行性：这个系统的经济效益能超过它的开发成 本吗？ • 操作可行性：系统的操作方式在这个用户组织内行得 通吗？ • 时间可行性：能在预定时间内完成吗？
述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充
需求规格文档标准
1 引言
1.1 编写目的 1.2 项目背景（单位和与其他 系统的关系） 1.3 定义（专门术语和缩写词） 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件限制 3 数据描述 3.1 静态数据 3.2 动态数据 3.3 数据库描述 3.4 数据字典 3.5 数据采集
• 例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络 打印机上，但因为版权限制，这些文档打印之后应立即删除。
领域需求示例：短信系统
• 如果短信经过终端无线模块发送之前必须经过短消息协议 标准编码才能发送出去。
• 要对短信编码，必须要对由ESTI制订的SMS规范有所了解 • 技术实现(含编码方式)GSM 03.38、GSM 03.40 • SMS的DTE-DCE接口标准(AT命令集)：GSM 07.05
• 非功能需求：指那些不直接与系统具体功能相关的一类需求 • 产品需求 • 机构需求 • 外部需求
• 领域需求：源于系统的应用领域需求
功能需求
• 软件系统的功能需求描述可以有许多方式： • 文字描述 • 图表表示
• 功能需求可以以不同的详细程度反复编写和细化 • 功能需求描述应该完整而且一致和准确
需
求 DFD图、STD图、
E-R图、用例图、
类图、顺序图等
需求分析模型
逻辑模型
物理模型
(本质模型、概念模型) (实施模型、技术模型)
现 行 系 统
描述重要的业务功能， 无论系统是如何实施的 。
描述现实系统是如何在 物理上实现的。
目
描述新系统的主要业务功 描述新系统是如何实施
标
能和用户新的需求，无论 的（包括技术）。
需求工程基本任务
需求工程
需求开发
需求管理
需求获取
需求分析
需求验证
需求规格说明
变更管理
需求分析的基本任务
• 需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工 作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结 束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。
系
系统应如何实施。
统
软件需求曾经让我们如此狼狈
软件开发的问题分类
ESPITI(欧洲软件
过程改进培训倡议） 所作的一个调查， 3800个被调查者认 为，软件开发的主
60 50 40 30
要问题、次要问题 20
和不是问题的问题 10
如图。
0
一半以上的人认为，
123456
主要问题 次要问题 不是问题
软件的二个最大问
• 过程包括： • 初步沟通 • 导出需求 • 分析和精化 • 可行性研究 • 协商与沟通 • 规格说明 • 需求验证 • 变更管理
2.1 初步沟通
• 业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用 例
• 确定市场的范围 • 初略地可行性分析 • 确定项目范围的工作说明
需求变化
合理范围内的变化： • 用户不了解自己的需求 • 需求本身易变，市场、技术、竞争因素
不合理的变化： • 需求文档质量不高 • 需求分析技能、技术和管理上的缺陷
需求变化的原因： • 未受控制的需求变更 • 遗漏需求 • 用户交流不够 • 需求规约质量差 • 低效的需求分析
谨记一点，需求是经常变动的， 只有先做好需求的分析，了解 业务以后的发展趋势，做好具 有拓展性的系统设计，才会给 系统更大的扩展空间，从而在 需求发生变化的时候可以更从 容的修改。
题是： 1、需求规格说明 2、管理客户需求 相对而言，编码不 是问题
1、需求规格说明 4、软件和测试
2、管理客户需求 5、项目管理
3、建档
6、编码
问题的重要性依次降低
需求错误的代价
0.1-0.2
需求阶段
0.5
设计
1
编码
2
单元测试
5
验收测试
20
维护
修复的相对成本
“ 需求开发可能是软件开发中最困难、最关键、最易出错以及 最需要沟通的方面 ”