第5章_需求工程与需求分析

另外，每个学期有一段时间让学生更改课程表。学 生可在该时段内访问系统并添加/删除课程。
某个学生的选课一旦结束，选课系统即将此学生本 学期的账单信息送到财务系统。 如果在选课时某门课已经人满，学生在提交信息前 必须被告知。
学期结束，学生可进入系统查看自己的成绩。成绩 属于隐秘信息，系统必须提供额外的安全措施阻止未 授权的访问。 教授必须能访问系统查询他们主讲课程。他们也需 要知道是哪些学生选择了自己的课程。另外，教授也 能登记学生的成绩。
• 选课系统用例图
查看报告 课程目录系统 注册课程 学生 登录 注册员
选择所教的课程
维护教授信息
维护学生信息
关闭注册
教授 提交成绩
财务系统
选课用例规约
1．简要说明 本用例允许学生选本学期提供的课程。在学期开始的添加/删除时期，学生 可以修改或删除选择的课程。课程目录系统提供了当前学期开设的所有课 程的列表。 2．事件流 2.1基本事件流 用例开始于学生选择选课，或修改已存在的课程表。 1）系统要求学生指出要执行的操作（创建，修改或删除课程表） 2）一旦学生提供了所需要的信息，以下的一条子事件流将被执行 如果选择的是“创建课程表”，创建课程表子事件流将被执行 如果选择的是“修改课程表”，修改课程表子事件流将被执行 如果选择的是“删除课程表”，删除课程表子事件流将被执行 2.2备选事件流 3．特殊需求 : 无 4．前置条件 本用例开始前学生必须已经登录进系统。 5．后置条件 如果用例成功，学生的课程表被创建，修改，删除。否则系统状态不变。
用例模型
用例模型
• 用例规约 • 补充规约 • 术语表
5.5 软件需求描述
• 软件需求规格说明书 • Software Requirement Specification – 引言 – 信息描述 – 功能描述 – 行为描述 – 质量保证 – 接口描述 – 其他
5.6 需求管理
需求应具有弹性的结构，能适应可能
用例建模示例
“学生选课系统”问题陈述
开发一个学生选课系统。通过这个系统，学生可以选课和 查看成绩报告单，教授可以选择所教的课和记录学生的成绩。
学校保留原有的“课程目录”数据库系统来维护课程信息， 但该系统的性能是有限的。所以新系统必须确保能及时访问旧 系统上的数据。但新系统只能读取旧系统的课程信息，不能更 新。 每学期开始时，学生请求查看本学期开设的课程目录。有关 课程的信息，包括教授名和所开设的系等，将帮助学生做出决 定。 系统允许学生每学期选择4门课，如果学生没有选到主要的 课程，还有两门备选课程可选。每门课的学生人数限3到10人。 不满3人的课程将被取消。
需求变更状态列表 （1）新增变更请求 （2）拒绝变更 （3）接受变更 （4）变更关闭
PM
拒绝 变更 （2）
接受 变更 （3）
变更 关闭 （4）
5.6.3 需求管理工具
• IBM Rational RequisitePro • Telelogic DOORSreg • Borland CaliberRM
5.3 需求获取的常用方法
5.3.1 常规的需求获取方法
– 联合分析小组 • 用户代表、领域专家和系统分析员 – 客户访谈 • 充分准备，寻找共同语言 • 循序渐进、逐步逼近 – 问题分析与确认 • 多个来回
5.3.2 用快速原型法获取需求
利用各种分析技术和方法，生成一个简化的 需求规格说明； 对需求规格说明进行必要的检查和修改后， 确定原型的软件结构、用户界面和数据结构 等； 在现有的工具和环境的帮助下快速生成可运 行的软件原型并进行测试、改进； 将原型提交给用户评估并征求用户的修改意 见； 重复上述过程，直到原型得到用户的认可。
③ 功能需求：定义软件开发人员必须实现的软 件功能，以及为了有效实现这些功能而必须达 到的非功能性需求、约束条件等，从而使用户 能完成他们的任务，满足业务需求。
软件需求的层次关系
业务需求
项目愿景与范围
用户需求
质量属性 非功能需求和 约束条件
用例模型文档
功能需求
软件需求规格说明
5.1.2 软件需求的特性
第5章 需求工程与需求分析 Requirement Engineering & Requirement Analysis
软件需求过程 需求分析与建模 需求获取的常用方法 需求模型 软件需求描述 需求管理 需求建模示例
5.1 软件需求工程
5.1.1 软件需求的定义
一个软件系统必须遵循的条件或具备的能力 。
1. 功能性----普通功能和全局性功能。 2. 可用性----使最终用户方便使用软件的相关 需求。 3. 可靠性----正常运行率、平均无故障时间、 最高错误或缺陷率。
4. 性能----对事物的响应时间、吞吐量等。
5. 可支持性----可维护、支持的相关需求-编码 标准、命名约定、类库。 6. 设计约束----必须遵循的设计决定。
•本示例作为WEB 应用，主要为普通购物 用户和管理员服务。 必须先注册账号。在注册页面中填写个人
•普通购物用户在使用本系统的购物功能前， 信息，如使用本系统的账号名和密码,联系
地址等。在提交表单、完成注册后，系统
将保存信息，以方便管理员管理用户信息、
联系用户。
• 进入系统后，用户也可选择维护自己的信 息，比如修改账号名，密码，联系地址等。 • 如果直接进行购物，系统可让用户首先浏 览商品信息，使之对商品的数量、种类有 一个大概的了解。如果用户对某件商品感 兴趣，就可以选择特定商品查看其详细信 息，接着选择将商品加入购物车，或继续 查看其他商品。 • 当购物结束时，用户首先要浏览一下已经 存在于购物车中的商品项目，包括数量、 单价及总价。这时用户可以更改任何已存 在购物车中的商品数量。
原始用户的要求
抛弃原型法
初始原型快速生成 评价/确认 实验性原型进化
展示/理解/构造
演化原型法
补充/确认/优先
最终确认
目标系统的实现 目标系统的测试 系统交付
5.4 需求模型
5.4.1 需求模型概述
– 结构化需求模型 – 面向对象需求模型
1. 结构化需求模型
功能模型
数据流图
数据模型
数据定义...... 数据字典
的变更。
一种获取、组织并记录系统需求的系
统化方案
一个使客户与项目团队对不断变更的
系统需求达成并保持一致的过程。
需求管理的特定实践
1.获得对需 求的理解
需求管理
5.标志项目工 作与需求的不 一致性
2.获取需 求承诺
3.管理需 求变更
4.维护对需求的 双向可追溯性
双向溯源矩阵
需求管理的流程
– 需求确认 – 需求跟踪 – 需求变更控制
开始
软 件 需 求 变 更 流 程 图
提交变更申请书 书面化变更的需求
《需求变更审请书》 《需求分析说明书》 《项目估算表》 《项目计划书》 《项目进度表》
评估需求变更的影响
变更审批
审批通过？
Yes
根据变更修改 相关工作产品 变更验证 需求评审结束
No
需求变更状态转化图
PM
新增变 更需求 （1）
管理员进入系统时，首先要输入口令。如 果检查通过，就可以对系统中的信息进行 维护和管理，包括：⑴ 管理用户信息。当 有些用户有不正常操作时，如填写订单时 使用不存在的信用卡号，可以将此用户账 号冻结，也可以启用用户账号。但管理员 无权修改客户信息；⑵ 管理系统中的商品 信息，例如有新的商品时，管理员可向系 统中添加此商品。当商品的价格或规格发 生浮动时，管理员也可以对它们作修改， 使用户及时了解商品的最新情况。
• 确定参与者
学生要注册课程； 教授要选择课程来教； 注册管理人员要维护关于教授和学生的所有信息； 财务系统要从注册系统获得学生的费用情况； 课程目录系统维护课程信息。
• 确定用例
无论是学生，教授还是注册员都需要登陆到系统； 学生需要使用系统来选课，也能查看自己的成绩； 教授需要使用系统来选择课程，也能记录学生的成绩； 注册员必须维护学生、教授的所有信息，并在适当时候 关闭注册系统； 当选择课程的过程完成后，收费系统必须获得收费信息； 学生和教授选择课程，需要启动课程目录系统。
(3) 绘制和检查用例图
– 按UML标准画用例图 – 检查用例图 • 细化每个用例的用例规约 – 内容包括： • 简要说明 • 事件流 • 特殊需求 • 前置条件和后置条件 • 用例模型的检查 – 功能需求的完备性 – 模型是否易于理解 – 是否存在不一致性 – 避免二义性语义
5.6.7 需求建模示例—网上购物系统
若某件商品没有存货或不再出售时，管理 员可删除系统中的此项商品记录。 ⑶ 管理客户订单。及时获得客户的资料 （资料中有电子邮件地址），以便与客户 联系。 • 要求系统对数据库的存取速度要尽量快， 并保证系统在配置完成以后一天24小时 都可用。还要求系统有较高的安全性， 当生成订单时，用户的信用卡号码要在 网上传输，所以必须提供额外的安全措 施。
5.1.3 需求工程的由来
• 代码编写---〉生存周期----〉需求工程 • 软件需求工程:可以定义为应用有效的 技术和方法，合适的工具和符号，来 确定、管理和描述目标系统及其外部 行为特征的学科 。
5.2 需求分析与建模
5.2.1 需求分析的步骤
需求获取
需求建模
需求验证
规格说明
5.2.2 需求分析是迭代过程
小结
• 需求分析由需求获取、需求建模、规格说明 和需求验证四个步骤组成 • 建立需求模型是需求分析的核心，它通过各 种图形及符号，可视化地从各个侧面描述系 统需求 • 需求规格说明书以各方共同认可的文档形式 表述出来，是软件设计、系统验收的可靠依 据 • 面向对象的用例模型，由用例模型、补充规 约和术语表一起组成 • 随着人们对需求重要性的认识逐渐深入，软 件需求管理应运而生