java技术文档

发者理解系统的预期行为， 它对于检查所要求的状态 和转换是否已全部正确地 写入功能需求中也是一种 好方法
项目的需求分析
好的<<产品需求规格说明书>>的特点
需求开发-需求定义
1. 完整性: 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得 设计和实现这些功能所需的所有必要信息。 2. 正确性: 每一项需求都必须准确地陈述其要开发的功能。做出正确判断
本章作业
1
2 3
交付物：《公司请假系统项目计划书》 交付形式：Word文档 提示：重点列出以下内容：
•项目的范围包括哪些？有哪些可交付的成果？ •简要描述项目的开发环境和工具 •为了开发这个项目，项目的组织结构方式是怎样的？
•简要说明项目的时间进度计划
•项目可能遇到哪些风险？风险的应对措施有哪些？ •项目开发过程中如何进行版本控制和问题追踪？
的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求
与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需 求的正确性，这就是一定要有用户的积极参与的原因。
项目的需求分析
需求开发-需求定义
好的<<产品需求规格说明书>>的特点
3. 可行性: 每一项需求都必须是在已知系统和环境的权能和限制范围内可 以实施的。为避免不可行的需求，最好在获取需求(收集需求)过程中始 终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起
员必须仔细审查所写的材料以确保记录的正确性
项目的需求分析
审查过程阶段
需求确认-需求评审
项目的需求分析
需求确认-需求承诺
需求承诺是指开发方和客户方的责任人对通过了正式评审的《产品需
求规格说明书》作出承诺，该承诺具有商业合同的效果。
开发方和客户方的责任人在作出承诺之前务必要认真阅读文档，一定
要明白签字意味着什么
项目的需求分析
需求工程-需求管理
需求管理的目的是在客户与开发方之间建立对需求的共同理解，
维护需求与其他工作成果的一致性，并控制需求的变更。
需求确认的目的是开发方和客户共同对需求文档进行评审，
双方对需求达成共识后做出书面承诺，使需求文档具有商业 合同效果。
需求跟踪的目的是通过比较需求文档与后续工作成果之间的
3. 两者之间可能并不存在一一影射关系，因为软件开发商会根据产品
发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分 配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》 来开发当前产品。
项目的需求分析
需求管理-小故事
需求工程-需求管理
-“我终于实现了库存报告中重排序的功能。” A在项目的每周例会上说。
参观与观察
组织会议
原型法
比较分析同类软件 从行业标准，规则提取
项目的需求分析
需求建模
需求开发-需求分析
单一来看需求并不能提供对需求的完全理解 可以增强你对系统需求的理解 在项目的参与者之间，对于某些类型的信息，图形化交互比
文本交互更高效
在不同的开发组成员之间扫清语言和词汇上的障碍 需求建模的方法
需求的重要性
项目的需求分析
需求的层次
业务需求 产品视图和项目范围
用户需求
质量属性
Use Case
非功能需求
功能需求
需求规格说明
项目的需求分析
需求工程
把所有与需求直接相关的活动通称为需求工程
项目的需求分析
• 需求开发
–需求调查 –需求分析 –需求定义
需求规格说明书
• 需求管理
– 需求确认 – 需求跟踪 – 需求变更控制 需求跟踪矩阵（RTM）
1. 实体联系图
2. 数据流程图
3. 状态转换图
Hale Waihona Puke Baidu
项目的需求分析
实体联系图:
有助于对业务或系统数据组成的理解和交互
需求开发-需求分析
项目的需求分析
需求开发-需求分析
数据流程图:
数据流程图以符合一定规则的图形来表达业务系统中信息
的变换和传递过程
项目的需求分析需求开发-需求分析
状态转换图:
有助于开
项目的需求分析
需求确认-需求评审
每个成员的角色
1. 作者—创建或维护正在被审查的产品。 2. 协调者(Moderator)—与作者一起为审查制订计划，协调各种活动， 并且推进审查会的进行。 3. 审查员—对于一份需求规格说明，审查员对需求给出注解或一个简 短评论。其它审查员可能有不同的解释，这将有利于发现二义性或可能 的错误。 4. 记录员—用标准化的形式记录在审查会中提出的问题和缺陷。记录
定义准确无误的产品需求，产生<<产品需求规格说明书>>， 以便开展系统设计工作。
项目的需求分析
确认需求调查的方式
需求开发-需求调查
说明 成本
需求调查方式 访谈
与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操作。也可以 把自己也当成一个用户，加入到用户的工作环境 中，最终去搞清楚用户到底在做什么，需要什么 样的系统来改善当前的操作。 将相关者组织起来开会讨论，由他们提出有关需 求的更多信息。以期收集全面的信息。 通过提供直观可视的系统使用户能从中找出哪些 信息需要，哪些信息不需要。 分析已经存在的同类软件产品，提取需求。 从系统相关的行业标准、规则中提取需求。
需求跟踪矩阵可以定义各种系统元素类型间的一对一，一对多，多对
多关系。允许在一个表单元中填入几个元素来实现这些特征。例如： 1. 一对一: 一个代码模块应用一个设计文档。 2. 一对多: 多个测试用例验证一个功能需求。 3. 多对多: 每个设计实例对应多个功能性需求
工作，由他负责检查技术可行性。
4. 划分优先级: 给每项需求、特性或使用实例分配一个实施优先级以指明它在
特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目
管理者在开发或节省预算或调度中就丧失控制自由度。
项目的需求分析
需求开发-需求定义
好的<<产品需求规格说明书>>的特点
5. 无二义性: 对所有需求说明的读者都只能有一个明确统一的解释，由于自 然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语 言表达出来。
-“噢，用户在两周前就取消这个功能了。”项目管理者说，“你没看改过的软件需
求规格说明吗？”
-“开发工作进展如何，
A ?”，在一次项目状态检查会上项目经理PM问道。
-“我没有按计划执行” A说，“我正在应B的要求添加一个销售分类查询功能，比 我原先预计的工作量超期多了。” -PM似乎有点迷惑，“好像在最近的变更控制委员会的会议中我们没有讨论过这个 功能。B是通过变更过程来提交要求的吗？” -“没有，她直接给了我这个建议，”A说，“本该请她通过正式渠道的，但这个功 能看上去较简单，所以当时我就答应她了。这个功能其实并不简单，每次当我认为该完 工了，但总能意识到在另一个文件中漏了一个变更，所以不得不修改它，再测试一遍。 原以为花4个小时就可以了，实际上花了4天时间，造成我没能按计划完成任务。我知 道延误了工期，那我应该加上这个功能还是放弃它呢？”
项目的需求分析
需求跟踪
需求跟踪矩阵(RTM-Requirements
Traceability Matrix)
代码 （版本，日期） 测试用例 （版本，日期） 测试用例名称，说 明 „
＃ 1 2
需求文档 （版本，日期） 标题或标识符，说 明 „
设计文档 （版本，日期）
标题或标识符，说 代码名称，说明 明 „ „
项目概述
• 阶段划分：
– 项目启动与计划 – 项目的需求分析 – 系统与测试设计 – 编码与测试执行 – 测试评估和系统部署
项目的启动和计划
• 项目的启动
– 可行性分析
• 项目的计划
– 系统项目计划书
• 项目实施的启动
– 项目启动会会议记录
项目的启动和计划
系统项目计划书
项目经过项目启动并确认立项后进入计划阶段。项目计 划的主要任务是根据客户对软件或系统的详细要求，对项目 的具体实施进行规划。主交付物《系统项目计划书》是对全 体项目参与人员对共同遵守的约定，也是项目取得成功的关 键文档。在这个文档中，要对软件开发的全部工作进行详细 安排。例如对每个技术文档的交付时间作出规定，确定技术 文档编写的工作目标等。
项目的需求分析
需求工程-需求开发
需求开发的目的是通过调查和分析，获取用户需求并定义产品
需求。
需求调查的目的是通过各种途径获取用户的需求信息(原始
材料)，产生<<用户需求说明书>>。
需求分析的目的是对各种需求信息进行分析，消除错误，刻
画细节等。
需求定义的目的是根据需求调查和需求分析的结果，进一步
项目概述
• 系统构架的初步设想
Web:html/AJA X/FLASH/Sive rlight JAVA:Spring,S truts ORM JAVA:Hibernate SQL Server Oracle
V(视图) 客户端
C（控制） 应用层
M（模型） 数据库
领域驱动开发（DDD）
测试驱动开发（TDD）
6. 可验证性:
检查一下每项需求是否能通过设计测试用例或其它的验证方法， 如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观
分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
项目的需求分析
需求开发-需求定义
<<用户需求说明书>>和<<产品需求规格说明书>>的主要区别和联系
1. 前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相 对于后者而言比较粗略，不够详细。 2. 后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求， 产品需求是软件系统设计的直接依据。
关系型数据 库设计范式
UI设计
数据结构-算法
项目概述
• 角色划分
项目实施方法
项目管理（PM）
软件开发（TW）
完成软件的需求分 析、设计、编码、 测试和系统部署等 工作。
软件测试（TEST）
完成测试策略和测 试计划的制定，测 试用例的设计和执 行、最终完成测试 评估工作。
技术文档写作（TW）
完成软件项目开发 过程中的技术文档 编写工作。
求的重要性：
开发软件系统最困难的部分就是准确说明开发什么。最困难的概念 性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件
系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后
对它修改也极为困难。
软件项目中百分之四十至百分之六十的问题都是在需求阶段埋下的
“祸根”
项目的需求分析
A
项目的启动和计划
• 系统计划制定的简单步骤：
– 收集和分析资料 – 提炼开发项目的背景，开发的目的和项目目前面临的问题。 – 确定本项目的可交付成果，以及为提交这些可交付成果必须展 开的工作。 – 确定项目开发所需要的环境、工具。 – 确定项目的验收标准。 – 确定项目实施的组织方案，包括参与人员的组织结构、协作和 沟通方法。 – 确定具体任务的先后顺序，所用资源和时间，并制定进度计划。 – 确定版本控制和问题追踪步骤 – 全体成员审批项目计划书，修改并定版。
项目的需求分析
用户的声音
什么是需求
用户的期望 宽泛地讲，需求来源于
用户的一些“需要”，
这些“需要”被分析、 确认后形成完整的文档，
用户的需求
该文档详细地说明了产
品“必须或应当”做什 么。
产品系统的需求
项目的需求分析
需求的重要性
Frederick
Brooks在他1987年经典文章“No Silver Bullet”中阐述了需
技术文档编写
L/O/G/O
天津中软卓越
主要内容
1
项目概述 项目的开发计划文档 项目的需求分析文档 详细设计文档
2
3
4
项目概述
了解项目
• 项目的名称
• 确定项目名称
• 项目的背景和目的
• 主要说明项目的来历，和一些需要项目团队成员知道的相关情 况。
• 基本需求的获取
• 确定系统应该具备的主要功能是什么？这里只需要总结出系统 的基本功能需求，更详细的需求要在需求分析阶段完成。
对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需 求文档进行开发。
需求变更控制的目的是指依据规定的流程处理需求的变更，
防止需求变更失去控制而导致项目发生混乱。
项目的需求分析
需求确认-需求评审
参与者
1. 正在评审的项目的规格说明编写者 2. 真正的用户—保证软件需求规格说明能正确并完整地描述了他们的 需求。 3. 要根据正在审查的文档来开展工作的人们—对于一个软件需求规格 说明，你可能需要包括一个开发人员、一个测试人员、一个项目经理和 一个用户文档编写人员，他们的工作基础都是软件需求规格说明。这些 审查人员将会发现不同类型的问题。一个测试人员很可能会发现一个不 明确的需求，而一个开发人员将会发现一个技术上不可实现的需求。