1 需求概述

需求问题的提出

讲述了在项目设计时，分析需求的重要性。

以及如果没有有效地分析需求，会造成怎样的结果。

在项目开发中，所有的干系人（涉众（Stakeholder）都对需求分析阶段感兴趣。

干系人是指所有能够影响软件系统的实现或者会被实现后的软件系统所影响的个人或团体。（如用户，客户，开发者，管理者，领域专家等）

未真正明白这些问题就开始编码，结果没有人对产品满意。

需求的定义

需求定义的不同观点

IEEE 的需求定义

用户解决问题或达到目标所需的条件或权能（Capability）。
系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
一种反映上面（1）或（2）所描述的条件或权能的文档说明。

IEEE 公布的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。关键的问题是一定要编写需求文档。

Jones 认为的需求

用户所需要的并能触发一个程序或系统开发工作的说明。

Sommerville 认为的需求

需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

优秀需求的特征

完整性:需求无遗漏，即需求变更中“新需求”所占量不大。
正确性：每一项需求都必须准确地陈述其要开发的功能。
无歧义性：对所有的需求说明的读者只能有一个明确统一的解释。
可行性：每一项需求都必须是在已经知道系统和环境的权能和限制范围内可以实现的。
有优先级
必要性
可验证性:检查每项需求是否能通过设计测试用例或其他的验证方法，如有演示、检测等来确定产品是否确实按需求实现了。

需求的层次与分类

业务需求：描述为什么要开发系统 why）开发系统的目标是什么，为什么要有这个系统。
用户需求：描述系统能够帮用户做什么（what）
系统需求：描述达到用户要求的具体流程（How）

业务需求

业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。

目标通常就是业务需求

业务需求的内容

业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？
客户：产品为谁服务？目标客户是谁？
特性：产品区别于其他竞争产品的特性是什么？
价值：产品的价值体现在什么方面？
优先级：产品功能特性的优先级次序是什么？

用户需求

用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。

系统需求

系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

软件需求

软件需求分为：功能需求，非功能需求和设计约束

功能需求

描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。

功能需求是需求的主体，是需求的本质。
功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
零散（需求项）-> 整理（特性、用例）
功能需求需要对用户需求进行分析、提炼、整理，因为用户需求具有零散、存在矛盾的特点。功能需求是需求分析与建模的产物，能生成指导开发的、更精确的软件需求。

非功能需求

描述了系统展现给用户的行为和执行的操作等。它包括外部界面的具体细节、性能要求及质量属性。
非功能需求是产品必须具备的品质，他们可以让产品有吸引力、易于使用、快速、可靠或者安全。
功能性需求是让产品工作的需求，非功能需求是为工作赋予特性的需求。

质量属性

质量是反映实体满足明确和隐含需要的能力的特性总和

设计约束

设计约束是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。

需求在总体方案中的位置

软件生存周期

软件生存周期就是从提出软件产品开始，直到该软件产品被淘汰的全过程。

瀑布模型(线形顺序模型)

特点：

从上一项活动接收该项活动的工作对象，作为输入；
利用这一输入实施该项活动应完成的内容；
给出该项活动的工作结果，作为输出传给下一项活动；
对该项活动实施的工作进行评审。若其工作得到确认，则继续进行下一项活动，否则返回前项，甚至更前项的活动进行返工。

缺点:

严格分级导致缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。凡前一阶段出现的问题需要通过后一阶段的重新确认来解决，所以这一点在开发过程完成后才有所察觉，因此,有时其代价十分高昂。
人员之间的通讯和软件工具之间的联系以及开发工作之间的并行和串行等都是必要的，但瀑布模型中并没有体现出这一点。
需要人员比较多；
瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

原型法

特点：

开发者和用户可充分通信，明确用户的需求；
可以给用户以机会更改心中原先设想的、不尽合理的最终系统；
可以低风险开发柔性较大的计算机系统；
使系统更易维护、对用户更友好的机会；
使总的开发费用降低，时间缩短。

缺点：

“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。
原型迭代不收敛于开发者预先的目标。为了消除错误，每次更改，次要部分越来越大，“ 淹没”了主要部分。
原型过快收敛于需求集合，而忽略了一些基本点。
资源规划和管理较为困难，随时更新文档也带来麻烦。

螺旋模型

特点：

螺旋模型加入了风险分析，是一种风险驱动的方法体系；
“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。可以先定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到满意的最终产品。因此，迭代过程这种模式使适应需求的变化会更容易些；
加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率；
使用面向对象的语言或统一建模语言

缺点：

这个模型的使用需要具有相当丰富的风险评估经验和专门知识，具有高素质的项目管理者和软件研发团队。

增量模型

特点：

这种模型融合了线性顺序模型的基本成份和原型实现模型的迭代特征。
人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。
当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。

缺点：

始至终开发者和客户纠缠在一起，直到完全版本出来。

敏捷模型（SCRUM）

特点：

从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；
从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。敏捷方法强调适应性而非预见性，相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

2 需求工程

需求工程的提出

简述了需求工程是怎么提出，如何提出，在什么时间提出的。

需求工程的定义

需求工程(RE)的概念

是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有
外部特征的一门学科。
RE 通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化
的需求演进给予支持。
需求分析专家 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”

需求工程 RE 可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。

传统的需求处理是软件工程的需求阶段，系统化的需求工程则将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到重要的作用。

软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。

需求工程的内容

需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需求和软件能力之间的桥梁。

需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理

三阶段周期的说法：获取、表示和验证

需求开发

需求开发的任务是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

需求获取

从项目的规划开始建立最初的原始需求。

需求获取是需求工程的主体,非常困难，主要原因有：

缺乏领域知识,应用领域的问题常常是模糊的、不精确的；
存在默认的知识,如难以描述的常识问题；
存在多个知识源,且多知识源之间可能有冲突；
客户可能的偏见，如不能提供或不想告知你所需要了解的事情。

需求分析、协商与建模

需求分析阶段主要对收集到的需求进行提炼、分析和认真审查，进行需求建模、对模型或原型进行分析。确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立完整的分析模型。

需求规约

采用原始模板，在你的组织中要为编写软件需求文档定义一种标准模板
指明需求的来源
为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号
记录业务规范

需求验证

需求验证目的是要检验需求是否能够反映用户的意愿

有效性检查—指功能需求是否符合用户所提出的需求。
一致性检查—系统功能描述及约束是否一致。
完备性检查—是否包含所有系统用户的需求和约束。
可检验性检查—是否能设计出一组验证方法。

需求管理

需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。

有效的需求管理在于维护清晰明确的需求阐述，每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。

其活动包括：定义需求基线，建立跟踪信息，进行变更控制。

需求工程优秀实践

需求分析师

职责

需求分析师是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。

工作

需求分析师是客户与开发人员交流的中间人，负责将客户对产品的初步想法转化为明确的需求说明，用来指导开发工作。
定义业务需求
- 需求分析师的第一项工作是帮助业务或出资方、产品经理或市场经理定义项目的业务需求。
规划需求方法
- 确定项目干系人和用户类别
获取需求
- 需求分析师可能要用到各类信息收集技巧，帮助用户阐明自己需要那些系统功能，满足业务目标。
分析需求
- 需求分析师还要对收集到的需求进行分析，找出那些客户没有明确说明的需求。
记录需求
沟通需求
主导需求的验证
引导对需求的优先级排序
- 需求分析师要负责对各类干系人和开发人员进行合作与协商，以保证他们进行合理的优先级划分。
管理需求
- 需求分析师参与了软件开发的整个生命周期，因此，他应该帮助制订、检查和执行项目的需求管理计划。

必备技能

倾听的技巧
- 要善于双向交流，就必须知道如何有效地倾听。
访谈谈和提问的技巧
- 大部分需求是通过讨论得到的，因此，需求分析师必须能够与不同的个人或小组就需求展开讨论。
才思敏捷
分析技巧
系统思考的技巧
学习技巧
引导技巧
观察能力
领导力技巧
观察技巧
- 观察力敏锐的需求分析师能够从不经意的闲谈中发现重要的信息。
沟通技巧
组织技巧
- 需求分析师需要处理获取和分析过程中收集到的大量杂乱的信息。
建模技巧
人际交往能力
- 需求分析师应具备让彼此利益竞争的人们进行合作的能力。
创造性
- 需求分析师不能像抄录员那样只记下客户说过的每句话。
需求分析师还需具备从实践经验中积累的广博知识。
- 其中最基本的是对当代需求管理技术的深刻理解，以及在各种不同的软件开发生命周期环境中应用这些技术的能力。
需求分析师需要将需求开发与管理活动贯穿于整个产品生命期中。
掌握应用领域的知识、最大限度地减少与客户间的误解。

3 需求获取

需求获取为涉众团体之间的相互沟通、识别需求的过程。涉众团体通过这个过程提取、定义需求。需求获取不但涉及技术问题，而且涉及社会交往问题。

需求获取的一个必不可少的结果是对项目描述的客户需求的理解。

问题域

问题域是指与问题相关的部分现实世界

问题域是定义用户需求的前提条件。用户需求与所处的客观世界是紧密联系的，依赖可运行程序的计算机本身难以产生预期的效果。

需求工程的本质在于从待求解问题加以解决，与问题相对应的是问题的解决方案。

软件需求的相关描述应包括三个方面的内容

问题所处问题域知识的描述，用 K 表示。

用户最终期望在问题域中产生的效果，称为用户需求，用 R 表示。

为实现用户期望的效果，运行待开发软件系统的计算机必须与问题所处的问题域进行交互，对这种交互的描述也与软件需求直接相关，成为规格说明。用 S 表示。

K，S→R,即在三者各自的描述均正确的前提下，S 所定义的行为能在 K 所描述的问题域中产生所期望的效果 R

需求获取方法与技术

需求获取的方法

面向对象的方法
基于场景的方法
- 场景（Scenario)这一概念在需求工程领域取得了广泛的应用。一般来说，它基于对应用环境的某一特定情境的描述来阐述用户的需求。对于这一类方法，目前应用最广泛的是基于用例的方法。用例是从用户的观点，以交互的方式对与系统的行为特征进行的描述，而场景一般认为是用例的一个实例。
面向方面的方法
面向视点的方法

需求获取的技术

面谈法
问卷法调查法
需求专题讨论会
观察用户的工作流程
原型化方法
基于用例的方法
需求重用

建立业务需求

业务需求指的是一组信息，描述的是需要，在此需要的指导下，一个或对多个项目交付一个解决方案和符合预期的最终业务成果。业务机会、业务目标、成功标准和一个愿景声明共同构成业务需求。

业务需求的冲突

业务需求收集自多个来源，可能有冲突。

协商是解决办法

产品愿景和范围

产品愿景(product vision)将所有涉众统一到一个方向上。描述了产品用来干什么，它最终会是什么样子。
愿景关系到整个产品。当产品的战略定位或信息系统的业务目标随时间发生改变时，愿景也会随之变化，但这种变化相对缓慢。
范围明确当前项目或开发迭代应强调最终产品愿景的那些部分，范围声明的是项目内外的边界。

愿景与范围文档

业务需求
1. 背景总结新产品或对现有产品进行变更的依据和环境。描述产品开发的历史背景或形式。
2. 业务机遇
3. 业务目标
4. 成功指标
5. 愿景申明
6. 业务风险
7. 业务假设和依赖
范围与限制项目的范围定义了所提出的解决方案的概念和范围
1. 主要特征
2. 首发版本的范围概述计划在产品的第一个版本中实现的主要特性。
3. 各后续版本的范围要采用阶段性的开发方式，需要决定推迟实现哪些特性，并为后续的版本做出时间安排。
4. 限制与排除定义项目包含的需求与不包含的需求之间的界线。
业务背景这一部分概述一些项目的业务问题，包括简要描述主要的干系人类别，以及说明项目的管理优先级。
1. 干系人简介对每类涉众的说明都应提供如下信息：
  1. 从产品得到的主要价值或利益，产品如何才能产生较高的客户满意度。
  2. 可能对产品采取的态度。
  3. 感兴趣的主要功能和特点。
  4. 必须加解决的任何已知约束。
2. 项目优先级要想更有效地进行决策，涉众必须就项目的优先级达成一致。
3. 部署注意事项

获取用户需求

要获得用户的需求，应采取以下步骤：

确定产品的不同用户类型。
挑选出每一类用户和其他涉众的代表并与他们一起工作。
对谁是项目需求的决策者达成共识。

寻找用户代表

每个项目都有几位用户类的关键成员负责提供需求。我们称他们为产品代言人(product champion)或用户代言人或项目协调人。
设置用户代言人为构造客户和开发人员之间的伙伴关系提供了有效途径。
每位用户代言人都是他所属用户类的成员与项目的需求分析员之间的主要联系人。
如果每位用户代言人都被赋予足够的权力，能够为他代表的用户类做出具有约束力的决定，他们就能发挥最大效应。

陷阱

用户代言人模型在很多情况下都获得了成功。其成功需要具备以下条件：
- 用户代言人理解并履行他的职责。
- 被赋予用户需求级别的决策权，有足够的工作时间。
引入用户代言人时应小心下列可能出现的问题：
- 一个合格的用户代言人根据授权做出的决定却被经理推翻。
- 用户代言人如果忘了自己应代表其他客户，而只表达出自己的需求，那么他的工作肯定做不好。
- 用户代言人如果缺乏对新系统的充分了解，就可能在重要问题上听从需求分析员的决定。
- 资深用户可能因为自己没有时间而推荐缺少经验的用户担任代言人。
- 谨防用户试图代表他们不属于的用户类发表意见。

用户需求的冲突处理

如果是个别用户之间的分歧，则由用户代言人来裁决。
如果不同的用户类或客户群提出的需求发生冲突时，应支持最重要的用户类或对产品的商业前景影响最大的客户群提出的需求。
不同的企业客户都可能要求按他们自己的喜好设计产品。解决办法还是依据项目的业务目标来确定哪些客户对项目的成败影响最大。
用户经理表述的需求有时会和其部门中实际用户的需求相矛盾。尽管用户需求必须服从业务需求，但不属于用户类的经理应该服从于用户代言人，因为后者是用户的代表。
当开发人员对产品的想法与客户的要求不一致时，通常应由客户做出决定。

理解需求

用例法

用例描述了系统与外部角色之间的一系列交互。
角色(actor)指与系统交互以实现某种目的的人、软件系统或硬件设备。
用例源于面向对象的开发方法,用例转变了需求开发的角度，用例更接近目标。
用例图(user-case diagram)提供了对用户需求的概要性可视化表示。

流程：

找出系统边界和参与者
建立场景
捕获用例
定义关系和建立用例图

基于用例的需求获取

需求获取的步骤

识别项目远景
1. 系统改进点不等同于软件需求
  1. 用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进
  2. 这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标
2. 业务模型描述了“现实是什么”，远景则描述“希望的改进”
  1. 远景表达了“为什么要开发这个系统”
  2. 在业务现状(业务模型)下，开发系统是为了达到什么目标？
识别业务参与者客户、供应商、合作伙伴、潜在客户、政府等
识别用例
1. 业务为业务参与者提供的价值
2. 体现企业业务本质，是有意义的目标
详述用例业务用例是对业务流程的封装，在业务建模过程中需要逐一描述其内部细节，即详述业务用例
1. 详细说明业务用例的工作流程
2. 说明业务用例的工作流程，以便于客户、用户和涉众理解
重构用例利用用例建模高级技术重构用例模型
1. 用例关系
  1. 通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型
    的结构更合理
2. 用例分级
  1. 可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑
3. 用例分包
  1. 将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模

4 需求分析与建模

分析与需求的关系

分析建立在需求获取的基础上

用户视角理解用户问题过渡到开发团队视角分析用户问题
- 与需求一样，它还是在问题域中
- 从用户视角跨入开发团队视角
分析与需求捕获在很大程度上重叠，这两个活动常常相辅相成，为了澄清和找出任何遗漏或歪曲的需求，常常需要在需求之上作一些分析

需求分析的模型和方法

提出目标系统的数据模型、功能模型和行为模型是需求分析的核心任务。

所谓模型就是系统的一种书面描述，通过抽象、概括和一般化，把研究的对象或问题转化为本质相同的另一对象或问题，以便解决的方法。

数据模型
1. 描述对象系统的本质属性及其关系。常用的建模工具有实体-联系图、类图等。
功能模型
1. 描述对象系统所能实现的所有功能。而不考虑每个功能实现的次序。常用的建模工具有数据流图、活动图等
  。
行为模型
1. 描述对象系统为实现某项功能而发生的动态行为。常用的建模工具有控制流图、状态转换图和顺序图等。

需求分析方法

需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成;

常见的有：

面向数据流的结构化分析方法 (SA)
面向对象的分析方法 (OOA)

结构化需求分析与建模

实体关系图(Entity-Relationship Diagram,E-R 图)来创建数据模型，描述系统中所有重要的数据对象；
数据流图（Data Flow Diagram,DFD）：用来创建功能模型，描述了信息流和数据转换。
状态转换图（State-Transition Diagram,STD）用来创建行为模型，描述系统状态如何响应外部事件，而进行转换。

数据流图

数据字典

数据词典(Data Dictionary，简称 DD)和数据流图密切配合，能清楚地表达数据处理的要求。

数据词典用于对数据流图中出现的所有成分给出定义，它使数据流图上的数据流名字、加工名字和数据存贮名字具有确切的解释。每一条解释就是一条词条，按一定的顺序将所有词条排列起来，就构成了数据词典，就象日常使用的英汉词典、新华词典一样。

通常，数据字典应该包含下列 5 类元素的定义：数据流；数据元素；数据存储；变换处理；源点及终点（汇点）。

E-R 图

用 E-R 模型描述现实世界，不必考虑信息的存储结构、存储路径及存取效率如何在计算机中实现。
该模型面向现实世界，便于直接描述现实世界，且有直观、自然、语义丰富、易于向其它数据模型转换等优点。

状态转换图

活动表语法：事件名（参数表）／动作表达式常用事件名： Entry、Exit、Do
动作表达式：应做的具体动作
事件表达式：触发状态转换的事件。
语法：事件说明 [守卫条件]／动作表达式。
其中，事件说明的语法：事件名（参数表）。

分析系统的需求说明，找出可能的状态
找出每个状态下的动作
在状态之间画事件
分析系统标注开始与终止状态

面向对象需求分析与建模

面向对象方法学概述

了解基本概念：对象、类、消息、封装性、继承性、多态性、优点、抽象、封装。

面向对象=对象+类+继承+通信

面向对象方法学的特点

符合人们习惯的思维方式
- 面向对象方法学将问题域的理念直接映射到对象，以及对象之间的接口，这种映射的方法符合人们习惯的思维方式。
稳定性好
- 当系统的功能需要变化时，并不会引起软件结构的整体变化，仅需要作一些局部性的修改；
可重用性好
容易开发大型软件产品
可维护性好
易于测试和调试

OOA 的基本原则和任务

为建立分析模型，要运用如下的 5 个基本原则：

建立信息域模型；
描述功能；
表达行为；
划分功能、数据、行为模型，揭示更多的细节；
用早期的模型描述问题的实质，用后期的模型给出实现的细节。

OOA

包含三项内容：

理解：由用户与系统分析员、基本领域的专家充分交流，达到充分理解用户的要求和本领域的知识。
表达：将所理解的知识用面向对象方法进行表达。
验证：将所表达的知识用面向对象方法进行验证。

过程：

从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例之间的关系，生成用例图，建立功能模型。
从业务需求描述和用例描述中提取“关键概念”，形成领域概念。
依据领域概念和功能模型，研究系统中主要的类之间的关系，生成类图，建立对象模型。
从用例出发，将系统看成“黑盒子”，识别出参与者和系统交互的系统事件，在系统（顺序图、状态图等）中进行描述，并进一步识别出系统操作，建立动态模型。
依据系统动态模型和对象模型，建立操作契约，描述响应系统操作执行后对系统状态的影响，从而回答“做什么“的问题。

对象模型

类图

序列图

状态图

活动图

5 需求文档

需求文档的作用

作用：

（1）规范的文档可以拓展人脑的知识记忆能力。（2）编制需求文档的过程，可以帮助需求工作人员更好的理解问题域，使文档表达的知识更准确、更清晰。（3）定义清晰、正确、规范的需求文档为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。（4）通过编制需求文档，可以尽早发现需求错误，提高项目开发效率。（5）需求文档能够促进软件开发过程的规范化，也为开发团队建立了经验模型和可利用知识库。（6）需求文档可以作为项目开发方和软件客户之间的有关软件系统的协议基准，可以使用它作为合同协议的重要组成部分。使开发方和软件客户对系统目标达成一致。（7）需求文档还可以作为软件成本估算和项目开发进度安排的重要依据，从而使整个项目开发计划的制订更为合理。

原则：

（1）在可能的情况下，需求文档应该由软件开发方和软件客户联合起草。（2）文档编写应适应文档的读者。（3）文档的表达方式依赖于内容。（4）文档编写应该有必要的重复（强化）。（5）文档编写应有一定灵活性。（详细程度上，可以扩展与合并，能对需求变更进行有效的管理和控制）（6）采用原型法，渐进式开发需求文档
。

常见文档：

文档分类：

项目视图与范围文档（愿景和范围文档）包含了业务需求
用户需求通常形成用例文档
在得到用户需求之后，需求工程师需要对其进行建模和分析，细化为系统需求并建立能够满足系统需求的解决方案。
系统需求规格说明可细化为软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档及人机交互文档。

软件需求规格说明

需求获取收集了需求信息，需求分析活动深入理解了需求信息并建立了能够满足用户需求的软件解决方案。需求规格说明（需求描述）是将需求获取、需求分析的结果进行文档化的过程。在软件开发过程中，将分析的结果文档化是不可或缺的任务，也称为编写规约活动。

主要活动：

首先寻找一个标准模版，然后根据模版的结构对模版进行选择与裁剪转变为需求规格说明文档模版。

然后将根据系统模型、系统需求和需求规格说明文档进行文档写作，然后形成软件需求规格说明文档。

各种写作风格：

自然语言：就是使用结构合理的自然语言来描述需求，该表示不管对于写的人还是看的人都是一个非常容易接受的方法。以前的项目很多都是采用此方法。优点：易于编写、易于阅读，不需要掌握特定的技巧；缺点：不够严谨，歧义性强，表达能力弱（特别是对于复杂问题的描述）

图形化模型：图形化模型在表述时能够给读者提供更强的视觉效果，同时能够使问题更加聚焦。在日常交流中，我们经常会绘制一些非标准的示意图，以便更好地进行沟通。优点：可视化、聚焦性，易于理解。缺点：编写和阅读的人都需要能够正确地理解模型，所以一般 SRS 不可能完全采用复杂模型。

形式化描述：如果说图形化模型比自然语言表达的精确度更高的话，则形式化描述比图形化模型更高一些。对于逻辑性很强，精度要求很高的场合，形式化规格描述是一种不错的选择。优点：严谨、精确。缺点：编写和阅读的人都会感到很困难。