03需求工程的推荐方法教案
软件工程实践-3-需求工程(2用例)
用例的可视化描述
系统边界
藏书室
登录 用户管理 图书管理 通信
统计 参与者 藏宝者 晒书计划
规则制定 系统管理员 系统设置
借阅 关系 还书 资料管 理员 上报图书信息
<<actor>> 院图书管理 系统
计算机系统 参与者表示法
用例
2.用例之间的关系 用例之间的联系
预定游船 <<communicate>> <<include>> 收集支付信息 <<include>> <<communicate>> 预定航班 单向 代理人 用登录验证代理 人 用指纹扫描验证 代理人 <<extend>> 为飞行常客 预定航班
响应 编辑新书，并保存在系统中 告知藏书者要借阅的信息并进行记录 告知藏书者要借阅的信息并进行记录 产生图书统计清单 产生图书推荐清单 编辑资料，并保存在系统中 完成要求 完成要求 记录收藏信息 修改图书借阅状态 记录评语 编辑推荐信息并保存在系统中 产生到期催还通知单 产生图书统计表
将MSMS项目事件表进行分组
非正式形式的样例项目用例
用例UC2：藏书管理 对个人拥有图书信息的管理。 用例UC2.1：添加藏书 基本流程： •藏书者登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动 给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5 级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方 便管理，可自己设定归类名称）。 •系统进行输入信息的有效性检查 •系统根据图书名称进行重复图书检查 •存储图书信息，并提示存储成功。 •系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。 分支流程： 1.a、如果藏书者录入信息有误 1、系统提示藏书者此信息 2、返回添加藏书界面，界面保持原来填写数据 3.a、如果图书名称发生重复，系统将提示此信息，并给出相应图书列表，用户可以查阅图 书的详细信息，同时要求用户对此情况进行处理。 1、 如果确认图书录入重复，则系统放弃对当前图书信息的存储 2、 如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。
软件需求工程教学设计
软件需求工程教学设计一、教学目标本课程旨在培养学生软件需求工程方面的理论和实际应用能力，让学生掌握软件需求工程的基本概念、需求开发、需求管理、需求变更、需求跟踪等知识和技能，使学生能够在软件的需求获取、分析、设计、实施及验证等各个阶段中运用所学的知识和方法，以满足各种软件系统不断增长的需求，具备独立完成软件需求工程工作的能力。
二、教学内容1. 软件需求工程概述•软件需求的概念、定义和分类。
•软件需求工程的基本过程、模型和方法。
•软件需求工程的目标、价值和挑战。
2. 需求获取和分析•需求获取和描述的方法、技巧和工具。
•需求分析的基本方法、技巧和工具。
•需求获取和分析中的问题及解决方案。
3. 需求规格说明和管理•需求规格描述和编写的方法、标准和工具。
•需求验证和确认的方法、标准和技术。
•需求变更和跟踪的方法、工具和技术。
4. 需求实现和验证•需求实现、测试和验证的主要方法和技术。
•需求的追踪和管理工具的使用。
•需求工程和软件开发中的问题及解决方案。
三、教学方法本课程采用面授、案例分析、实际操作和课堂讨论相结合的教学方法，着重培养学生的实践能力和创新思维，提高学生的学习成效和工作能力。
教学中将注重学生的自主学习和团队协作，开展实际项目及案例分析，引导学生积极参与课程讨论和课程设计。
四、考核方式本课程的教学成绩包括平时成绩和期末考试成绩。
平时成绩占总成绩的40%，主要包括课堂讨论、课程作业和小组项目设计等。
期末考试占总成绩的60%，主要考察学生对软件需求工程的理论知识和实践技能掌握情况。
五、教材参考1.软件需求工程（第3版），中国铁道出版社，卫东、田久龙等著，2016年。
2.软件需求工程：原理与实践（美），Pressman 和 Widrig 著，宋宝华等译，电子工业出版社，2014年。
3.软件工程：实践者的研究方法（第8版），Pearson 出版社，RogerS.Pressman 著，2014年。
以上是软件需求工程教学设计文档，将采用面授、案例分析、实际操作和课堂讨论等方式传授相关知识和技能。
03需求工程推荐的方法
SQE-WRL
12/16
第 3 章 需求工程的推荐方法
3.8 方法使用原则
P38
从低到高，先易再难的使用原则。 （参见表3－2） 方法有效性判定原则。
SQE-WRL
13/16
第 3 章 需求工程的推荐方法
3.9 需求开发过程
重新评估
P39
获取
证实
分析
更正
编写
重写
验证
图3－2 需求开发迭代示意图
6/16
第 3 章 需求工程的推荐方法
3.2 需求获取的方法
P30
确定需求的收集、分析、细化和 前景说明所有涉众对产品目标的达 1. 定义需求开发过程 核实的步骤、方法、模板。 成的共识； 将可能使用产品的用户组，以 2. 定义项目前景与范围 范围定义了需求是否属于某个特定 为每类用户至少选择一位 避免出现某一用户群的需求被 版本的界线。 3. 确定用户群 能代表他们需求的、有时 忽略的情况。 把同类产品或产品前版本 间、有热情、有权利参与 的用户代表召集起来，从 从用户代表处收集他们使用 4. 选择产品代表 列出系统可能发生的外部 需求工作的用户代表。 软件完成所需任务的描述— 他们那里收集目前产品的 5. 建立核心队伍 事件以及对每个事件所期 功能需求和非功能需求。 —用例，讨论用户与系统间 专门的需求获取讨论会可 6. 确定用例 待的响应时间。 的交互方式和对话要求。 以方便分析员和客户进行 观察用户执行业务的过程。 7. 确定系统事件和响应 合作。 画一张简单的数据流程图 如果客户要求的功能与已 客户对当前系统的问题 8. 举行进一步需求获取的讨论 或业务流程图，描绘出用 有的某产品很相似，则可 报告及补充需求为新产 9.观察用户如何工作 户什么时候获得什么数据， 查看需求是否有足够的灵 品或新版本提供了大量 10. 检查问题报告 并怎样使用这些数据进行 活性以允许重用一些已有 丰富的改进及增加特性 业务处理。 11. 需求重用 的软件组件。 的想法。
软件工程中的需求工程方法与实践技巧
软件工程中的需求工程方法与实践技巧需求工程是软件开发过程中至关重要的一环，它确定了软件系统需要满足的功能和性能要求。
在软件工程中，需求工程师负责收集、分析和定义用户需求，为开发团队提供清晰、具体的指导。
本文将介绍一些常用的需求工程方法和实践技巧，以帮助开发团队更好地理解和应对需求工程的挑战。
1. 需求收集需求收集是需求工程的第一步，它的目的是获取用户的需求和期望。
需求工程师可以通过以下几种方式进行需求收集：- 面对面交流：与用户进行面对面的会议和访谈，了解他们的需求和期望。
这种交流方式可以更好地把握用户的真实需求，并及时解答用户的疑问。
- 文档分析：分析现有的需求文档、项目计划和用户手册等，了解系统已有的需求和规范。
- 调查问卷：设计调查问卷，广泛收集用户的需求，以获取更全面和客观的数据。
- 观察和模拟：观察用户的工作环境和方式，模拟他们的操作过程，以更好地理解他们的需求和使用习惯。
2. 需求分析与建模需求分析是将收集到的需求进行分析和整理的过程，它的目的是确定需求的优先级和相关的约束条件。
需求建模是需求分析的一种重要工具，它可以帮助将需求转化为易于理解和验证的形式。
- 用例图：用例图是一种常用的需求建模工具，它描述了系统和外部参与者之间的交互关系，帮助开发团队更好地理解系统的功能和用户的行为。
- 领域模型：领域模型是对系统所涉及的相关领域和实体进行建模的过程，以确定系统的边界和相关概念之间的关系。
- 数据流图：数据流图描述了系统中数据的流动和处理过程，帮助开发团队更好地理解系统的数据需求和处理逻辑。
3. 需求验证和确认需求验证和确认是确保需求的正确性和可行性的过程，它有助于避免开发过程中的返工和变更。
- 需求审查：通过团队内部和用户参与的需求审查会议，确认需求的正确性和一致性。
- 原型演示：根据收集到的需求，开发简化的原型系统，与用户共同验证需求的实现效果。
- 用户验收测试：在软件开发结束后，邀请用户进行验收测试，并与其确认是否满足其需求和期望。
03第三章需求工程
2019/12/7
13
什么是“软件需求”
• 软件需求(Software Requirements)：
– 用户解决问题以达到特定目标所需的能力；
– 系统或系统构件要满足的合同、标准、规范或其他正式文档所需具
备的能力；
——IEEE, 1997
– 指用户对软件的功能与性能需求,就是用户希望软件能够做什么事情,
– 学生希望能够在学期开始之前查询所有开设课程的详细信息，并能 够通过校园网进行选课。
– 学生希望在选课期间系统能够24小时使用，系统使用方便快捷。
2019/12/7
21
3. 功能需求
• 功能需求(Functional Requirements, FR)：系统应该提供的功 能或服务，通常涉及用户或外部系统与该系统之间的交互， 不考虑系统内部的实现细节；
2019/12/7
25
一个例子：拼写检查器
• 业务需求：“用户能有效地纠正文档中的拼写错误” ；
• 用户需求：“找出文档中的拼写错误并通过一个提供的 替换项列表来供选择替换拼错的词”；
• 功能性需求：
– 找到拼写错误的单词并以高亮度提示 – 显示提供替换词的对话框 – 实现整个文档范围的替换
• 非功能性需求：
Maria 一个同事想把自己名字改为Sparkle Starlight，但系统不允许，能帮忙吗？ Phil 她嫁给了一个姓Starlight的人吗？
Maria 不，她并没有结婚，她只是想改名字而已； Phil 系统只支持在改变婚姻状况时才可以改名字。
Maria 可是每个人只要愿意就可以随时改变自己的名字啊。 Phil 这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
《需求工程》课件
06 需求变更处理
需求变更请求
提出变更
当项目干系人提出需求变更时，应详细记录变更请求的 内容、原因和影响。
确认变更
对变更请求进行评估，确认是否需要进行变更，并通知 相关干系人。
变更影响分析
影响范围
分析变更对项目范围、进度、成本和质量等方面的影响。
资源需求
评估实施变更所需的资源，包括人力、物力和财力等。
需求工程
目录
• 需求工程概述 • 需求获取 • 需求分析 • 需求规格说明 • 需求验证与确认 • 需求变更处理 • 需求工程工具与技术
01 需求工程概述
定义与特点
定义
需求工程是一种系统的方法，用于确 定、捕获和验证系统或产品需求，以 满足用户、客户和其他利益相关者的 期望和要求。
特点
需求工程强调与利益相关者的沟通、 需求分析和验证，以确保需求的正确 性、完整性和一致性。它还涉及到需 求管理，以确保需求在整个产品开发 生命周期中得到满足。
需求工程的重要性
A
减少开发时间和成本
准确的需求可以避免开发过程中的返工和变更 ，从而缩短开发时间和降低成本。
提高产品质量
明确和经过验证的需求有助于提高产品的 质量和性能，满足用户和客户的需求。
B
C
增强用户满意度
通过了解和满足用户需求，可以提高用户对 产品的满意度和忠诚度。
降低维护成本
明确的需求有助于降低产品维护和升级的成 本，因为变更可以在开发阶段进行充分的考 虑和规划。
分析文档中的需求
对审查的文档进行分析，提取其中的需求信 息，以便更好地理解项目的需求背景和要求
。
03
需求分析
需求分类与优先级排序
需求分类是将收集到的原始需求按照一定的标准进行分类的过程，优先级排序则 是根据需求的紧急程度、重要性等因素对需求进行排序。
需求工程讲稿(第三讲)需求工程的方法
需求工程的方法过程、方法和技术描述的重要性建模的作用需求工程的维度♦表示维（代表需求的可维护、可验证的程度）⏹非形式的：自然语言⏹半形式的：图形语言（如：UML，DFD，等）⏹形式的：数学或逻辑语言（如：Z，等）♦内容维（代表需求工程的进行程度）⏹模糊的客观世界现象⏹明确的需求规格说明♦一致性维⏹代表某个投资者的观点得到全部投资者的认可需求工程的三维视图非形式非形式形式规格说明表示一致的程度模糊一般完全个人观点公共的观点表示维内容维接受度维再论描述的重要性♦软件开发：获取描述+逐步精化♦需求：是过程的起点需求代码设计系统需求问题描述什么、怎样、相互转化♦传统地，需求应该说明‘什么’而不说明‘怎样’⏹但是这不很容易区分：●一辆小汽车做什么？●一个WEB浏览器做什么？⏹在某个抽象层次上的‘怎样’形成下一个层次上的‘什么’♦Jackson&Zave的工作提供了一个区分：⏹‘什么’涉及系统的目的●对系统来说是外部的●是应用领域的特性⏹‘怎样’涉及系统的结构和行为●对系统是内部的●是机器领域的特性需求需求需求设计设计设计系统子系统单元什么什么什么怎样怎样怎样关注于问题♦问题先于解决方案⏹硬件和软件都能正常运行，但它起的作用却不是所想要的⏹对提早发现潜在的困难有帮助，困难越后发现越难解决♦计算机系统和现实世界的关系计算机系统计算机系统以外的世界解决方案在此问题在此世界和计算机之间的连接需求处于环境之中♦机器⏹我们称要被开发出来的软件系统为机器⏹硬件是为了运行软件而存在的，因此是机器的一部分♦应用领域⏹机器将与它所处的环境发生交互⏹建立机器为了实现现实世界中的某个目的⏹定义机器的环境，就是定义应用领域⏹应用领域常常是人类活动的系统♦实现的决策是出于那些在应用领域中没有基础的需求⏹例子：字典要存放在Hash表中；病人记录要存放在一个面向对象数据库中需求的环境零售企业系统客户银行帐户部门仓库供应商订购，付款帐单信用状态帐单，查询订购财务报告发货通知运送报告需求的环境借书还书续借需求就是描述♦指代：⏹环境中的实体：为它规定一个名字⏹观察到的现象：告诉你怎样识别它，并为它规定一个名字⏹指代通常是非形式的，但它将一个模糊的现象映射到一个形式的（或者说可表达的）语言上♦定义⏹为一个术语给出形式的定义，使这个术语能在其它描述中使用⏹定义或多或少是有用的，但它却是没有对错的需求就是描述♦可反驳的描述：领域的特性⏹陈述领域的某种特性，这种特性在原理上是可反驳的●可能实际上并不会去反驳它，但应该有这样的意识⏹可反驳性依赖于对我们正在描述的领域中的这个被指代的现象的一种询问♦一个粗略的框架⏹是要被开发出来系统描述的一个尝试性描述●允许包含未定义的术语例子♦指代：MOTHER(X,M)：表示M是X的母亲♦定义：CHILD(X,Y) ::= MOTHER(Y,X)∨FATHER(Y,X)♦可反驳的描述：对所有M和X有，MOTHER(X,M) →⌝MOTHER(M,X)♦粗略的框架：每个人实际上都只属于一个家庭描述的语气问题♦描述的不同语气⏹直述：给出一个事实⏹询问：问一个问题⏹命令：传递一个命令⏹假设：陈述一种可能⏹希求：表达一种愿望需求是希求式的♦需求一定包含“应该做什么”♦对需求工程来说，一般应该有的语气：⏹领域特性：直述式语气⏹需求：希求式语气♦语气随开发进程不断变化需求描述需求的表示维坐标语言语言的形式化程度需求的内容维：模型♦现实中的三类模型⏹图示模型：一个雕塑，可视化⏹类比模型：一架模型飞机，使能测试经验的决策⏹分析模型：表示社会经济的一组数学方程，使能分析所描述的系统的可能行为需求中的模型分析模型类比模型理解问题，为问题世界的相关部分建模映射为实现，比如：用数据库存放信息模型的抽象性♦模型不仅仅是描述⏹它具有自己的现象，和它自己的关于这些现象之间的关系●只有当模型的现象按一种系统的方法对应到要被建模的领域的现象时，这个模型才是有用的。
《需求工程》课件
需求工程是一项关键的软件工程领域，旨在有效地获取、分析和管理软件系 统的需求。本课件将介绍需求工程的核心概念、方法和实践，并探讨其在软 件开发和项目管理中的重要性。
什么是需求工程？
需求工程是一个跨学科的领域，涉及到识别、分析、规范和验证软件系统的需求。它旨在确保开发的软件满足 用户和利益相关者的期望和需求。
2 非功能需求
描述系统应具备的性能、可靠性、安全性等方面的特性。
3 用户故事
以用户的视角叙述需求，具有用户愿望和期望的特点。
用户需求的获取方法
访谈
与用户和利益相关者进行面对面 的谈话和讨论，获取需求信息。
调查问卷
通过编制问卷并广泛分发，获取 大量用户的意见和需求。
情境分析观察用户在实际环源自中使用系统 的行为和需求。需求分析的步骤和技术
1
需求分类
将需求按照功能、优先级等进行分类和组织。
2
需求建模
使用UML、用户故事地图等工具，建立需求模型和关系。
3
需求验证
借助原型、模拟和验证工具，检查需求的正确性和可行性。
需求规格说明的编写
需求规格说明是一份详尽而准确的文档，描述了软件系统的功能、性能和约 束条件，为开发人员提供指导和参考。
需求工程的发展历程
1
1970s
早期需求工程方法的诞生，主要关注需求获取和需求分析的基本概念。
2
1980s
需求工程方法逐渐成熟，开始关注需求规格说明和需求验证的方法和工具。
3
1990s
需求工程的方法论得到进一步发展，加强了与软件开发和项目管理的整合。
需求工程的流程与方法
需求获取
通过与利益相关者沟通和访谈，收集并理解用 户的需求。
需求分析与解决方案设计ch03
9.创建需求跟踪矩阵
建立一个表，把每项功能需求和实现它的设计和代码部分、验证它 的测试部分联系起来。
10
3.7 项 目 管 理
软件项目管理方法和项目的需求过程密 切相关。应根据需要实现的需求来规划项 目资源、进度和承诺。 1.选择合适的软件开发生命周期
4.管理与需求相关的风险以及编写风险文档
确定与需求相关的风险并将它们编写成文档是项目 风险管理活动的一部分。
5.跟踪需求工程的投入
记录下你的团队在需求开发和管理活动上投入的工 作量。
6.从其他项目的需求工程中积累经验
组建一个学术研究组织专门管理项目回顾(也称为 项目的审阅)以收集有价值的信息。 12
9
3.6 需 求 管 理
5.维护需求变更的历史记录
记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。
6.跟踪每项需求的状态
建立一个数据库，为每一项功能需求保存一条记录。
7.衡量需求的稳定性
记录已设为基线的需求数，以及每周提议和批准的需求的变更(增 加，修改，删除)数。
8.使用需求管理工具
可定义一种约定，用于为SRS中的每项需求提供一个惟一的识别 标号。
4. 记录业务规则
业务规则包括公司章程、政府法规和计算机算法。
5. 定义质量属性
在功能需求之外还应考虑非功能的质量属性这些属性包括性能、 效率、可靠性、可用性等。
7
3.5 需 求 验 证
需求验证可确保需求声明是正确的、具备了所需的质量 属性，而且能够满足客户的需要。 1. 审查需求文档 对需求文档进行正式审查是保证软件质量的有效手段之一。 2. 测试需求 根据用户需求推导出功能测试用例，以便记录产品在特定 条件下应有的行为。 3. 定义合格标准 让用户描述决定产品是否满足他们的需求并适合使用的标 准。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
·第3章
·第5章
●第6章
●第7章
●第8章
●第22章
定义需求开发过程
将你的组织如何获取和分析需求、编写规格说明和验证需求的步骤编写成文档。提供如何完成主要步骤的指导可以帮助分析员做好工作，还能够使规划项目的需卒尹发任务、进度和所需的资源变得更为容易。
编写前景和范围文档
前景和范园（vision and scope）文档包含了产品的业务需求。前景说明使所有涉众可以对产品的目标达成共识。范围则定义了需求是否属于某个特定版本的界线。前景和范围一起为如何评估提出的需求提供了参考。项目前景应该在不同版本之间保持相对稳定，但是每个版本需要有自己的项目范围声明。
·第4章
●第10章
培训需求分析员
所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。需求分析专家需要几天时间来进行这样的培训。熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。
对用户代表和管理者进行软件需求培训
参与软件开发的用户应该接受一到两天的需求工程方面的培训。开发经理和客户经趸也会发现这些内容很有用。培训可使用他们明白重视需求的意义；需求工作包括哪些活动，要提交什么样的结果；忽略需求过程会导致什么风险。一些参加过我的需求研讨课程的用户说他们从此更加体谅软件开发人员。
●创建需求跟踪矩阵
●选择合适的开发周期
●根据需求制订项目计划
●重新协商权利或义务
●管理需求风险
●跟踪需求耗费的人力物力
●回顾以往的教训
需求获取
需求分析
编写规格说明
需求验证
●定义需求开发过程
●定义项目前景和范围
●确定用户群
●选择用户代言人
●建立核心队伍
●确定用例
●确定系统事件和响应
ቤተ መጻሕፍቲ ባይዱ●举行进一步需求获取的讨论
●观察用户如何工作
●检查问题报告
●重用需求
●绘制关联图
●创建原型
●分析可行性
●确定需求优先级
●为需求建模
●创建数据字典
●将需求分配至各子系统
●应用质量功能调度
●采用SRS模板
●确定需求来源
●惟一标识每项需求
●记录业务规范
●定义质量属性
●审查需求文档
●测试需求
●确定合格标准
3.1
软件开发人员大都未曾接受过需求工程的正规培训。然而，许多开发人员在他们职业生涯的某些时刻都会担任需求分析员的角色，与用户打交道，获取、分析需求，并将它们编写成文档。期望所有开发人员天生就都胜任需求工程中需要进行大量沟通的工作是不合理的。培训可以提高分析员的熟练程度，使他们工作起来更得心应手，却无法弥补人际关系能力的不足或兴趣的缺乏。
最佳方法是一个有争议的说法：谁能决定什么是“最佳”，他有什么依据？一种决定方法是召集一群行业专家或研究员来分析来自不同组织的项目。这些专家在其中寻找一些方法，它们的有效性能是和成功的项目联系在一起，而失败的项目则往往没有很好地实施这些方法，或者根本就没有实施。通过这些手段，专家们就那些一直产生良好结果的活动达成了一致。这些活动就被称为最佳方法。对于专业软件人员来说，这些活动代表了十分高效的方法，能够提高特定类型或特定条件下项目的成功几率。
对开发人员进行应用领域的相关培训
为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。这样可以减少开发过程中的混淆、误解、和返工。还可以在项目开发过程中为每位开发人员配备一位“用户伙伴”，负责向他解释行话和业务概念。用户代言人可以担当这个角色。
创建项目术语表
《软件需求（第2版）》，教案
3
十多年前，我曾是一个软件开发方法集的爱好者。软件开发方法集（methodology）指包装好的整套模型和技术方法，用于为项目提供整体解决方案。但现在我更愿意寻找和应用行业的最佳方法（best practice）。最佳方法的做法是：在你的软件工具包中储存各种技术方法，用于解决不同的问题，而不是试图设计或购买整体解决方案。即便采用商业开发方法集，也可以对其进行改造，使它最大程度地满足你的需求。还可以从工具包中选出其他有效方法补充该方法集。
由于需求过程是必不可少的，因此项目的所有涉众都应该理解需求工程的概念和方法。将各方涉众召集起来利用一天的时间进行软件需求培训，这是打造团队的一种有效方法。各方可以更好地理解合作伙伴所面临的挑战，明白为了整个团队的成功参与者们需要对方做些什么。同样，开发者也应该了解产品应用领域中的基本概念和术语。关于这些主题可以在以下章节中找到更详细的内容：
表3-1需求工程推荐方法
知识
需求管理
项目管理
●培训需求分析员
●对用户代表和管理者进行需求培训
●对开发者进行应用领域相关的培训
●创建术语表
●定义需求变更控制进程
●成立变更控制委员会
●分析需求变更的影响
●控制需求版本并为其建立基线
●维护需求变更的历史记录
●跟踪每项需求的状态
●衡量需求稳定性
●使用需求管理工具
定义应用领域专业名称的术语表可以碱少误解。术语表中包括同义词、有多种含义的术语、以及既有特定领域的含义又有日常含义的术语。既可以是名词又可以是动词的单词，如“process”和“order”，尤其容易产生混淆。
3.2
第1章讨论了3个不同层次的需求：业务需求、用户需求和功能需求。这些需求在项目不同阶段的来源不同，有着不同的受众和目的，需要用不同的方式写入文档。项目范围内的业务需求不能排斥任何必要的用户需求，而且每项功能需求都应该可以追溯到对应的用户需求。您还需要收集非功能需求，如对质量和性能的要求。在以下章节中介绍了有关这些主题的内容：