The Concept of Requirement Analysis and Related Technologies

2. 关于车网互联
北京车网互联科技有限公司
北京车网互联科技有限公司
定位于行业解决方案及服务提
供商，聚合无线通讯、移动互
联网、云计算、数据采集融合
等技术优势， 为车联网、北斗
建设提供开放式服务平台和全
面解决方案。2013年10月，证
监会审核通过公司与北京荣之
联科技股份有限公司的换股方
案，公司成为公众上市公司中
的一员。
未来，公司将致力于以物联
网技术创造用户新体验，不断
加强技术积累，聚合产业链资
源，引领和主导车联网、北斗
应用产业的创新发展。
通过与整个产业
链的紧密合作，
打造开放、共享、
可持续发展的车
辆信息服务平台。
聚合行业优质资
源，提供北斗民
用基础服务平台
和行业全面解决
方案。
车联网 北斗
诚邀您的加盟 http://www.carsmart.cn/job-bj.html
发送简历至hr@che08.com

3. 现任：
北京车网互联科技有限公司资深架构师
一个快乐孩子的父亲
历任：
卓望科技股份有限公司飞信系统架构师
诺基亚西门子科技股份有限公司工程师&TL
中国电信
专注于：
软件工程方法、系统架构、敏捷开发、
设计模式、领域驱动开发等
关于我

4. 需求和需求工程1
如果不知道自己将要去往何处，则必定行至他处。
-- Yogi Berra
 用户解决问题或达到目标所需条件或能力
 系统或系统部件要满足合同、规范或其它正式规定文档所需具有的条件或能
力
 一种反映上述所描述的条件和能力的文档说明，是以一种清晰、一致且无二
义性的方式对目标系统各个有意义方面陈述的一个集合

5. 需求和需求管理的目的
Requirements and Requirement management need to do two things:
1) Validate - Make sure you are building the right product:
Are we doing the right thing?
2) Verify - Make sure you built the product right:
Are we doing the thing right?

6. 需求的层次
 业务需求：
反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范
围文档中予以说明。
 用户需求：
描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案
脚本(scenario)说明中予以说明。
 软件/产品需求（功能需求）：
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足
了业务需求。
 非功能需求：
描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、
规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量
属性。

7. 需求的层次（2）
Level 1:
Why the project is being
undertaken
Level 2:
What users will be able
to do with the product
Level 3:
What the developers
need to build

8. “好”需求的特征
 无歧义：只能用一个方式来解释需求
 可测试（可验证）：测试人员能够验证需求是否正确的实现
 清晰（简洁，扼要，简单，精确）：需求中不要包含不必要的空话套话
 正确
 易懂：用规范一致的文法来书写，尽量使用通常的惯例或者习惯用法
 切实可行（真实，不空洞）：需求不会需要夸张的诸如时间、资金等资源
 独立：理解当前这个需求而不需要还要了解其他需求
 原子性（即不可分）：需求包含一个单一的可追踪元素，可修改可跟踪
 必需的
 自由实现（抽象）：需求不要包含不必要的设计和实现信息
 一致性：需求之间不要互相抵触，术语使用上要保持一致
 非冗余：每个需求只表述一次而不要在另一个需求中做相同陈述
 完整：

9. 需求工程
需求工程是指应用已证实是有效的技术、方法进行需求分析，确定客户
需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一
门科学。它通过合适的工具和记号系统地描述待开发系统及其行为
特征和相关约束，形成需求文档，并对用户不断变化的需求演进给
予支持。

10. 需求工程的复杂性
 领域知识的缺乏
 需求的描述问题
 需求的完备程度问题
 需求变更问题

11. 需求捕获2
需求捕获是软件项目的基础部分，对后继的分析设计及开发实施
有重大影响。如果做的好，会减少需求变更和返工。此外，需求
捕获过程的质量也将决定客户对需求的完整性、正确性的认可。
因为这个阶段的困难性和影响力，按一个理想的模式来完成需求
捕获过程就非常重要。
需求捕获可定义为：需求捕获是两个有关团体相互沟通，识别需
要的过程。两个团体通过这个过程提取、定义需求，来约束两个
团队。需求捕获既涉及技术问题，也涉及社会交往问题。
参考《需求捕获指南》

12. 需求捕获的常见问题
 范围的问题，需求陈述的信息过多或是过少。
 理解的问题：
用户不完全理解自己的需要
需求分析人员对于问题域缺乏足够的知识
忽略一些“明显”的信息。
不同用户的看法有冲突
语句含糊和无法测试的需求。例如“用户界面友好”或“高性能”
 需求不稳定的问题。例如需求本身的改变/拓展。

13. 需求捕获的基本方法
 查找需求源
识别需求的提出人或则称之为风险承担者，即产品涉及其利益的人。
 网络信息
收集各方面人员的对产品的要求，得到“期望列表”
 整合
反复分析“期望列表”直到前后一致，得到文档化，提炼后的“期望列表”

14. 需求捕获的内容
 组织机构
目标系统输入信息的提供人员
使用目标系统输出信息的用户
目标系统可能改变组织机构的业务流程。
 环境
目标系统的软，硬件限制。
目标系统问题域的成熟程度。
目标系统的界面与组织现有大部分系统界面风格一致。
目标系统与组织现有其他系统的关系。用户不完全理解自己的需要
 项目
不同风险承担人的特点，如管理风格，问题域/计算机经验。
其他约束条件，如资金，质量，时间期限。

15. 需求捕获的方法
 访谈
 小组会议
 问卷调查
 其它
现场观摩
文档考古（分析用户已有的业务、信息建设的文档）
原系统研究（现在的系统问题，改进要求）
分析同类软件产品特性（文档或试用软件分析）

16. 访谈
 一般在下列情况使用
需要与少数几个人，进行大量的知识交流
项目团队能够与他们会谈
无法一次性收集所有风险承担人的需求
 五个阶段
准备访谈
计划和安排访谈日程
访谈开始和结束
引导访谈
后继的访谈整理工作
 推荐工具
Mindjet MindManager
Micorsoft NoteNote

17. 问卷表
 一般在下列情况使用
需访谈的个体太多
需要回答容易确定的细节问题
当你希望有个详细的结果时

18. 小组会议
 一般在下列情况使用
信息平均的分布一小部分个人中
无法个别的会见所有的风险承担人
一系列的访谈已经结束，团队需要在同一平台下得到所有的回答
 推荐工具
会议记录：Mindjet Manager或录音笔
工作原型演示方法(最终确定需求时)

19. 小组会议
 一般在下列情况使用
信息平均的分布一小部分个人中
无法个别的会见所有的风险承担人
一系列的访谈已经结束，团队需要在同一平台下得到所有的回答
 推荐工具
会议记录：Mindjet Manager或录音笔
工作原型演示方法(最终确定需求时)

20. 需求分析方法3
如果需求文档质量强依赖于作者的经验，缺乏完善的工程方法来支
撑，则后续的开发、测试工作经常会发现需求分析得不准确、不
完善而使得工作产品需求变更、返工、修复，需求文档的指导作
用、参考价值变弱。

21.  如果需求文档质量强依赖于作者的经验，缺乏完善的工程方法来支撑，则后
续的开发、测试工作经常会发现需求分析得不准确、不完善而使得工作产品
需求变更、返工、修复，需求文档的指导作用、参考价值变弱。
 场景分析工程方法可以解决部分这样的问题。
场景分析法，又叫情景描述法、未来图景草拟法、脚本法。它是以
部分事实和逻辑推理为基础，用主观构思来预测事物的发展趋势，
描摹事物的图景全貌或若干细节的一种创造想象法。这种方法能
使研究人员较为容易地处理那些技术、经济以及其它社会事物交
织在一起的复杂体和不肯定的事物。
场景分析技术

22. 场景分析法的历史
 诞生
二战后，美国空军用场景技术想象对手会采取哪些措施，然后准备相应
的战略
 转变
196x年，兰德公司和曾供职于美国空军的赫尔曼.卡恩，将这种军事规划
方法提炼成一种商业预测工具
 成名
壳牌公司运用它成功预测了1973年的石油危机，而声名鹊起。（《福布
斯》杂志1970年还称壳牌公司为“丑美”，后来……）
 应用
据贝恩公司2004年对960家跨国公司经理的调查表明，场景技术应用超
过50%

23. 场景分析6项步骤
1. 明确决策焦点
2. 识别关键因素
3. 分析外在驱动力量
4. 选择不确定的轴向
5. 发展情景逻辑
6. 分析情景的内容，通过角色试演的方法检验情景的一致性

24. 用例驱动的需求分析技术
 基于用例驱动分析技术的软件需求获取是以任务和用户为中心的，迭代的增
量式的需求开发方法，是当前国际流行的软件开发过程之一，软件开发所有
阶段的活动都是以用例为核心。
 用例驱动分析技术不同于传统的功能分解法，是一个面向对象而不是面向实
现的过程，它完全从外部来定义系统的功能，把需求和设计分离开来。
 用例驱动分析的基本概念是参与者和用例，通过识别用例和参与者，可以了
解系统的每一类用户的需求和愿望，而不会沉溺于细节。
 一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结，用例
场景是用来描述用例在实际执行的时候发生的各种不同情况，在用例规约中，
场景可以由基本流和备选流的组合来表示。
 场景既可以帮助需求获取人员防止需求的遗漏，同时也对后续的开发工作能
起到很大的帮助，开发人员必须实现所有的场景，测试人员可以根据用例场
景来设计测试用例。

25. 用例驱动的需求分析技术的优缺点
 优点：
用例比模棱两可的功能点描述要清晰，也更直白于系统的价值
用例是用户和开发人员之间的桥梁
采用简单的图形元素表示系统的活动者、用例以及它们之间的联系，以半形
式化的图形方式对需求描述进行规范化，避免了表达的歧义性
用例方法被综合到UML规范之中，成为一种标准化的需求表达体系
 缺点：
用例驱动技术在功能性需求分析方面比较成熟，但在非功能性需求方面却比
较薄弱
用例驱动技术对用例的获取是零散的，没有说明用例的来源问题，缺乏系统
化的获取过程，不能保证获取到的需求的完整性
在实际应用开发中，用例粒度问题很难把握

26. 基于目标的需求分析技术
 将目标作为判断需求完整性的依据：当需求能够满足当前的目标时，则说明
需求是完整的；如果需求不能满足当前的目标，则说明需求是不完整的。
 目标建模
“与”求精链使一个父目标与一系列子目标相关联，意指满足父目标的充分
条件是必须满足所有与之相关联的子目标。“或”求精链连接一个子目标与可
供选择的一系列子目标，意指满足父目标的充分条件是只需满足一个可供选择
的子目标。“与”和“或”求精链用来捕获求精目标和证明目标求精的正确性。

27. 基于目标的需求分析技术优缺点
 优点：
在细化目标过程中，分析人员不断回答“What”,“How”和“Why”，常
常会发现和揭露一些用户的需求，能帮助需求分析人员获取完整的需求。
方便非功能性需求分析
目标提供了一种有用的方式来消除冲突，方便冲突处理
 缺点：
处理目标并不是一个简单的任务，在实践中存在着许多困难。领域专家很难
处理那些具有模糊概念的目标，并且由系统的组织给定的目标有时并不是实际
的目标，而是企业理想化的视图，从这些目标出发会导致无效的需求。因此系
统的目标来源和目标发掘工作就显得非常重要。
应该把目标和场景的技术进行结合来进行需求分析。因为场景描述的是现实
情况或具体行为，所以场景捕获的是现实需求，通过捕获具体的实例，成精可
以帮助人们弄清复杂系统的原因，抓住系统真正的需求。

28. 目标发掘与场景设置过程
1. 由相关的组织和系统利益相关者给出待建系统的业务层目标（只能有一个）
2. 对业务层目标精化，形成服务层目标（业务层子目标，可以是一个或多
个），服务层目标通过服务层场景实现
3. 从服务层场景中发掘比服务层更为小粒度的目标，即交互层目标，关注代
理（可以是人、机器或系统）之间的交互，交互层目标由交互层场景实现
4. 通过对交互层场景的设置，可以发掘出内部层目标，关注待建系统内部操
作的实现，内部层目标由内部层场景实现

29. 分析需求场景对产品设计的意义
1. 产品经理知道这个新开发的功能是为了帮助用户解决什么问题。
2. 交互设计师可以从中获知这种需求场景的细节：“发生频率，需求强度，
用户有什么样的能力和辅助工具”
3. 其他合作伙伴更容易了解到这个功能的价值，更能够及时表达意见，否决
不靠谱的功能，并对有价值的功能产生更强烈的共鸣。
“在某某时间（when），某某地点（where），周围出现了某些
事物时（with what），特定类型的用户（who）萌发了某种欲望
（desire），会想到通过某种手段（method）来满足欲望”

30. 需求建模4
需求分析包括将高层需求分解为低层需求、构建图形化的需求模型、
以及构建产品原型等工作。
分析模型和产品原型提供了理解需求的可选视图，通过这些视图可
以揭示一些通过文本很难描述的概念，从而避免需求错误或需求冲
突。
此外，需求分析另一个重要的活动是…对优先级进行排序。

31. 需求分析建模方法和工具
 产品需求列表：Product Requirements Backlog
 用户故事和用例建模：User Stories & Use Case
 业务流程建模：BPMN & Activity Diagram
 业务概念定义
 实体及实体关系建模：ER Diagram
 用户交互设计：原型法

32. 产品需求列表
 The Product Requirements Document
定义了项目的全部目标和范围
项目最终交付的规范
由产品负责人(Product Owner)创建和维护
产品设计的起始点（高层需求）
QA验收测试标准的基线
 为什么需要PRD
定义了项目范围
提供了项目回顾和过程审计的历史记录

33. 产品需求列表
 Excel表格示例
 也可以用JIRA进行产品需求列表的维护

34. 用户故事和用例建模
 用户故事
As a [User Role], I want to [Goal] so I can/because [Reason]
Example: As a registered user, I want to log in so I can access
subscriber-only content

35. 用户故事和用例建模
 用例建模
用例图 + 用例描述

36. 用户故事和用例建模
 User Story 和 Use Case的区别和联系
相同点：两者都是需求组织的具体方法
不同点：
- Use Case：描述业务层/用户层需求 (High Level)
- User Story：描述产品层/交互层需求 (Detailed Level)

37. 业务流程建模
 业务流程管理
以规范地构造端到端的业务流程为中心，以持续地提高组织业务绩效为目的的
系统化管理方法。
BPM活动的五个阶段：设计、建模、执行、监控和优化

38. 业务流程建模
 BPM相关概念
• Business Process - A set of one or more linked procedures or activities
which collectively realize a business objective or policy goal, normally
within the context of an organizational structure defining functional roles
and relationships.
• Workflow - The automation of a business process, in whole or part,
during which documents, information or tasks are passed from one
participant to another for action, according to a set of procedural rules.
• Process Definition - The representation of a business process in a form
which supports automated manipulation, such as modeling, or
enactment by a workflow management system. The process definition
consists of a network of activities and their relationships, criteria to
indicate the start and termination of the process, and information about
the individual activities, such as participants, associated IT applications
and data, etc.

39. 业务流程建模
 Enterprise Process Framework
WHAT
HOW

40. 业务流程建模
 BPMN建模语言
Business Process Model and Notation (业务流程模型与符号)
是一套流程建模的标准，主要目标是提供一套被所有业务用户容易理解的符号，
支持从创建流程轮廓的业务分析到这些流程的最终实现，直到最终用户的管理
监控
提供了清晰而精准的执行语义来描述元素的操作
确保设计为业务流程执行的XML语言（如WS-BPEL），能够用这套以业务为中
心的符号所可视化表示

41. 业务流程建模
 BPMN示例 （协作图）
Pool
Lane
Start
Event
End
Event
Activity
Gateway
Sequence
FlowMessage
Flow
Event

42. 业务流程建模
 BPMN 与 UML Activity Diagram
相同点：都用于流程建模
不同点：
BPMN设计初衷更强调易于业务人员使用
UML Activity Diagram 设计初衷是为系统开发人员建模使用(在后续版本中持
续优化)

43. 业务概念定义
 从用例或流程描述中抽取名词，发现业务实体
 对业务实体进行定义
 业务实体概念可能因业务领域不同而有不同含义，应注意业务上下文

44. 实体及实体关系建模
 Class Diagram
 概念数据模型

45. 用户交互设计
 用户交互设计实际上是讲用户故事（用户用例）的过程
 讲故事的方法
文字描述
图形化描述 (线框图)
DIFFERENT WAYS TO TELL A STORY
frame by frame, drawings
key frames, textual descriptions
key frames, spoken narrative

46. 用户交互设计
 线框图 (Wireframes)
Wireframes are a static representation
of a dynamic non-linear flow of activity

47. 用户交互设计
 设计过程 (迭代)
准备阶段
-理解问题
工作会议
- 和相关人员
合作在会议中
画出第一批线
框图
工具：白板
用户
测试
替代方案
- 在工作会议
中检查可优化
系统的替代方
案
工具：纸/Axure
用户
测试
检查第一稿
- 若此前没有
征询过开发人
员意见，请一
定明确询问
工具：纸/Axure
….

48. 需求规范文档的编写5
需求的编写是一项艺术，需要很高的技巧。
不要期望需求100%正确。

49. 需求编写的技巧
1: Use the simplest words appropriate to state a complete requirement.
– An eloquently written requirement is probably not a good one.
– A requirement must be written so many different people can
understand it.

50. 需求编写的技巧
2: Use requirement imperatives correctly.
– Use company/program defined list.
– If requirements are from a non-company source, make sure you know the
meaning of these words. (Definitions should be included in Section 1 of the
specification)
Common imperative definitions;
“Shall” Definition
“Shall” denotes a mandatory and contractual requirement. “Shall” requires metrics to quantify
and requires a verification process.
“Will” Definition
“Will” denotes a mandatory and contractual requirement. It is similar to “shall” but does not
require metrics or verification.
“Should” Definition
“Should” denote a design goal, an objective the system tries to meet.

51. 需求编写的技巧
 Adequate
 As Appropriate
 Bad
 Better
 But not limited to
 Correct
 Easy
 Effective
 Ideal
 Large
 Maximize
 Minimize
 Most
 Must
 Necessary
 Normal
 Quick
 Rapid
 Readily
 Relevant
 Satisfactory
 Shall not
 Small
 Sufficient
 Suitable
 Timely
 Typical
 User friendly
 Was
3: Do not use weak phrases and subjective words.
Following are words and phases not to use when writing a requirement:

52. 需求编写的技巧
4: Use continuations carefully, they make traceability and verification
difficult. Use when all items are to be verified by the same method at the
same time.
Example:
– The system shall report software status to the host interface under the following conditions:
• At system initialization.
• When the status of an external interface has changed.
• When a report has been requested.
5: Use examples, tables, figures etc., they are a great source of
information and clarification.
– Make sure examples and notes are clearly marked as such (not part of requirement).
– For tables; specify if all, some or none of the cells are requirements.
– Clearly indicate if a figure or part of the figure, is part of the requirement, or is information.

53. 需求编写的技巧
6: Be consistent with names; always call the same entity by the same name.
– Example: If in some requirements the subject is called “the System,” and in others “ the URQ-65”, the
names are not consistent.
– Always use the correct name for the level of specification. You can not verify a sub capability at a
systems level.
7: If you use a TBD or TBR, have a plan. You must state who is responsible for
the information, and when the it will be completed.

54. 需求编写的技巧
8: Make sure a requirement contains all the qualities of a good requirements
– Concise: Minimal, easily understood, a complete expression of a single thought, non-ambiguous; only
one possible interpretation.
– Correct: An absence of errors of fact.
– Consistent: No conflicts between individual requirements, parts of a single requirement complement
each other. Connectivity exists between the requirements; consistent words and terms
– Traceable: Know source of requirement and be able to allocate it, Uniquely identified for life. Never re-
used identification on Project.
– Verifiable: Method (Test, Inspection, Demonstration, Analysis, Certification) Understand how
requirement can be verified, and determine criteria for acceptance.
– Necessary: Can the system be complete without this requirement?
– Attainable: Is this requirement technically feasible within given time and cost?
– Modular: Will a change to this requirement have a big impact on the system? Can this requirement be
easily used and monitored by other programs if needed?
– Restrictive – The requirement should written in such a way as to not limit implementation. Make sure the
requirement states what needs to be done not how.

55. 需求编写的技巧
9: Conjunctions. There should be only one requirement per statement.
– A requirement should not contain “and” or “or”.
– Requirement which contain “and”, “or” or “and/or” probably contain more than one requirements. These
hard to trace and completely verify.
10: Make sure that if a requirement references another document, that it does
so correctly.
– State if reference is information or part of the requirement.
– Make sure references are listed in applicable document section and state what part of reference applies

56. 需求编写的技巧
11: Make sure Acronyms are used correctly.
– Place the acronym in the acronym list in the specification.
– Spell out the complete phrase followed by the acronym in parenthesis the first time used.
– The next time just use the acronym.
– Example: first use: “The SATCOM Antenna Interface Unit (SAIU) shall…”, second use “The SAIU
shall…”
12: Overspecification leads to unfunded requirements, and can add duplicate
requirements.
– The length of a requirement should not be excessive.

57. 需求编写的技巧
13: Use the requirement template
There are four major parts to a requirement:
– Entities –
• Subject of the requirements (noun)
• Object of action (noun)
– Actions – What the subject does, contains imperative (verb)
– Conditions – What must be in place in order for this action to take place
– Constraints– Qualifies the action, performance
The following is the structure of a basic requirement:
 [Conditions] [Subject] [Action] [Object] [Constraint]
Example:
 When signal x is received [Conditions] , the system [Subject] shall set
[Action] the signal x received bit [Object] within 2 seconds [Constraint].

58. 功能性需求描述方法
 用例模型和用例描述最能够说明系统的功能性需求

59. 功能性需求描述方法
Use-Case Description Template
1. Use Case: The use-case name as it appears on system use-case diagrams
Perspective: Business use case/system use case
Type: Base use case/included/extending/generalized/specialized
1.1 Brief Description: Describe the use case in approximately one paragraph.
1.2 Business Goals and Benefits: Briefly describe the business rationale for the
use case.
1.3 Actors
1.3.1 Primary Actors: Identify the users or systems that initiate the use case.
1.3.2 Secondary Actors: List the users or systems that receive messages from
the use case. Include users who receive reports or online messages.
1.3.3 Off-Stage Stakeholders: Identify non-participating stakeholders
who have interests in this use case.
1.4 Rules of Precedence
1.4.1 Triggers: Describe the event or condition that “kick-starts” the use
case (for example, “User calls Call Center; inventory low”). If the
trigger is time-driven, describe the temporal condition, such as
“end-of-month.”
1.4.2 Pre-Conditions: List conditions that must be true before the use
case begins. (If a condition forces the use case to occur whenever it
becomes true, do not list it here; list it as a trigger.)

60. 功能性需求描述方法
1.5 Post-Conditions
1.5.1 Post-Conditions on Success: Describe the status of the system after
the use case ends successfully. Any condition listed here is guaranteed
to be true on successful completion.
1.5.2 Post-Conditions on Failure: Describe the status of the system after
the use case ends in failure. Any condition listed here is guaranteed
to be true when the use case fails as described in the exception flows.
1.6 Extension Points: Name and describe points at which extension use cases
may extend this use case.
1.6.1 Example of Extension Point Declaration: “Preferred Customer:
2.5–2.9.”
1.7 Priority
1.8 Status: Your status report might resemble the following:
Use-case brief complete: 2005/06/01.
Basic flow + risky alternatives complete: 2005/06/15
All flows complete: 2005/07/15
Coded: 2005/07/20
Tested: 2005/08/10
Internally released: 2005/09/15
Deployed: 2005/09/30

61. 功能性需求描述方法
1.9 Expected Implementation Date
1.10 Actual Implementation Date
1.11 Context Diagram: Include a system use-case diagram showing this use
case, all its relationships (includes, extends, and generalizes) with other use
cases, and its associations with actors.
2. Flow of Events
Basic Flow
2.1 (Insert basic flow steps.)
Alternate Flows
2.X.a (Insert the Alternate Flow Name): The alternate flow name should
describe the condition that triggers the alternate flow. “2.X” is the step
number within the basic flow where the interruption occurs. Describe the
steps in paragraph or point form.
Exception Flows
2.Xa (Insert the Exception Flow Name): The exception flow name should describe
the condition that triggers the exception flow. An exception flow is one
that causes the use case to end in failure and for which “post-conditions
on failure” apply. “2.X” is the step number within basic flow where the
interruption occurs. Describe the steps in paragraph or point form.

62. 功能性需求描述方法
3. Special Requirements: List any special requirements or constraints that apply
specifically to this use case.
3.1 Non-Functional Requirements: List requirements not visible to the user
during the use case—security, performance, reliability, and so on.
3.2 Constraints: List technological, architectural, and other constraints on
the use case.
4. Activity Diagram: If it is helpful, include an activity diagram showing
workflow for this use case or for select parts of the use case.
5. User Interface: Initially, include description/storyboard/prototype only to
help the reader visualize the interface, not to constrain the design. Later,
provide links to screen-design artifacts.
6. Class Diagram: Include a class diagram depicting business classes, relationships,
and multiplicities of all objects participating in this use case.
7. Assumptions: List any assumptions you made when writing the use case.
Verify all assumptions with stakeholders before sign-off.
8. Information Items: Include a link or reference to documentation describing
rules for data items that relate to this use case. Documentation of this sort is
often found in a data dictionary. The purpose of this section and the following
sections is to keep the details out of the use case proper so that you do not
need to amend it every time you change a rule.

63. 功能性需求描述方法
9. Prompts and Messages: Any prompts and messages that appear in the use
case proper should be identified by name only, as in “Invalid Card Message.”
The “Prompts and Messages” section should contain the actual text of the
messages or direct the reader to the documentation that contains text.
10. Business Rules: The “Business Rules” section of the use-case documentation
should provide links or references to the specific business rules that are active
during the use case. An example of a business rule for an airline package is
“Airplane weight must never exceed the maximum allowed for its aircraft
type.” Organizations often keep such rules in an automated business rules
engine or manually in a binder.
11. External Interfaces: List interfaces to external systems.
12. Related Artifacts: The purpose of this section is to provide a point of reference
for other details that relate to this use case, but would distract from the overall
flow. Include references to artifacts such as decision tables, complex algorithms,
and so on.

64. 功能性需求描述方法
有哪些模型
可以辅助事
件流建模？
A. 时序图
B. 活动图
C. 交互原型

65. 非功能性需求描述方法

66. 敏捷需求4
敏捷开发的核心是…迭代开发、SCRUM管理方式、还是Time-boxed
Delivery？
敏捷开发关注的核心应该是用户价值！

67. 传统瀑布式软件研发过程的问题
 需求不明
 需求变更
 项目周期过长
 没时间测试
 在无用的功能上花费大力气
 项目进度不可视

68. 敏捷开发实践 - SCRUM

69. Product backlog
 用场景描述的用户需求（User Story）列表
 经过优先级排序和工作量评估的
 优先级越高，User Story描述粒度越细
 是一个业务计划
ID STORY / FEATURE / REQUEST CATEGORY TYPE
Relative
Benefit
Relative
Penalty
TotalValue
Value%
Estimate
Cost%
***Priority
1 As the system I want to be able to capture image files from disk Imaging Feature 9 9 18 22.2 10 10.4 2.13
7 As a user when I enter a non alphanumeric character when logging in an error occurs Login Bug 2 1 3 3.7 2 2.1 1.78
2 As a user I want to be able to view the metadata for an image Index Feature 7 3 10 12.3 8 8.3 1.48
3 As the system when an image appears on disk I want to automatically capture it Imaging Feature 8 9 17 21.0 15 15.6 1.34
4 As a user I want to be able to login to the system Login Feature 3 5 8 9.9 8 8.3 1.19
5 As a user when I have logged in I want to view my inbox Desktop Feature 9 2 11 13.6 21 21.9 0.62
6 As a user I want to be able to view a scanned document Imaging Feature 8 6 14 17.3 32 33.3 0.52
TOTALS 46 35 81 100 96 100
PRODUCT BACKLOG

70. User Story描述
As a <USER ROLE>,
I want a <FUNCTIONALITY>
So that I can get
<BUSINESS VALUE>.对比基于目标和场景驱
动的用例需求分析方法，
是否似曾相识呢？

71. User Story的描述粒度

72. 需求的优先级排序方法
 Kano analysis
 Expert opinion
 Theme screening
 Theme scoring
 Relative weighting
 Financial analysis

73. Kano分析法

74. Any Questions？