第3章.需求工程过程
软件需求工程过程(SREP)
软件需求工程过程(SREP)一、开始：1. 项目经理根据项目特点，指定对过程表格的具体要求；2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类型)、TRS(需求类型)等，在过程表格中按标准引用。
二、计划：1. 计划经理估算需求开发时间；2. 计划经理完成：SPT(进度计划)、TPT(任务计划)，将计划数据录入PDS(项目计划摘要)。
三、需求获取：1. 软件需求工程师搜集系统概要信息，填写REQ(需求获取概貌)；2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA(需求获取/分析)、RES(需求获取情节)、UIR(用户交互需求)；3. 检查需求获取过程，并填写REC(需求获取检查)；4. 如果检查不通过，从1.重头开始过程；5. 软件需求工程师填写TRL(时间记录日志)、PIP(过程改进建议)；6. 计划经理整理本阶段数据，录入SPT、TPT。
四、需求分析：1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA （分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）；2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR；3. 检查需求分析，完成RAC(需求分析检查)；4. 如果检查不通过，从1重头开始过程；5. 软件需求工程师填写TRL、PIP；6. 计划经理整理数据，录入TPT、SPT。
五、协商：1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR；2. 软件需求工程师根据决议，修改REA等相关文档；3. 如果有新的需求引入，需要重新进行需求分析阶段；4. 软件需求工程师填写TRL、PIP；5. 计划经理整理数据，录入TPT、SPT。
六、需求评审：1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表；。
软件工程实践-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、 如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。
第3章.需求工程过程-1(1)
内容
技术、方法 问题分析 明确问题 发现业务需求 定义问题解决方案和系统特性 定义问题解决方案的边界 定义系统边界 涉众识别方法 涉众的描述特征 涉众的优先级评估 涉众的风险评估 涉众的共赢分析 代表采样 制定参与策略 使用用户替代源 用户参与 涉众分析的各种方法（如前述） 硬数据采样 建立合作关系，维护交流气氛 利用适当的交流途径、交流方式 面谈/调查问卷 群体会议面谈/头脑风暴原型 观察 文档分析/需求重用/需求剥离 面向目标的方法 基于场景的方法 基于用例的方法
差异性管理
获取
分析
确定可行性 形式化建模
规格
基于视图的文 档化 确保可跟踪性 文档化需求理 由 描述可度量、 可测试的需求 使用标准的文 档结构 原型
验证
获取非功能需 求
获取任务与业 务过程
GUI界面建模
用户行为建模
确定范围
获取目标
领域建模
数据建模
文档化客户需 求 文档化开发者 需求
形式化需求验 证
需求工程过程实例 RUP
商业建模：
1.评价组织的当前状态，包括支持新系统的能力； 2.探索当前业务的过程、角色和职责； 3.识别与评价业务过程改造的潜在策略； 4.开发反映业务内容的领域模型。
需求：
1.与项目涉众紧密接触，理解他们的需要； 2.定义项目的范围； 3.通过恰当的建模，探索功能、非功能、业务规 则、用户界面等需求； 4.识别项目中新的及变更的需求，并明确他们的 优先级。
2. 需求工程过程的活动
需求获取子活动
收集背景资料 定义项目前景和范围 选择信息的来源 选择获取方法，执行获取 记录获取结果
2. 需求工程过程的活动
需求工程总结
第1章. 需求工程导论本章小结⏹从20世纪60年代末期软件工程产生起，需求分析就一直是软件开发的重要主题⏹20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求”问题⏹应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程⏹需求工程是软件工程当中一项重要和复杂的活动，需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动第2章. 需求基础实例分析（系统A—招标书）⏹请说出下列需求的类型，是否存在问题？❑1、实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化；❑2、实现工作流程合理化、高效化，决策支持科学化、准确化；❑3、统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。
⏹请说出下列需求的类型，是否存在问题？❑先进性：软件系统采用三层B / S 系统结构，以“界面表示层－逻辑处理层－数据访问层”分层设计实现。
采用国际上先进成熟的、厂商广泛支持的计算机技术、网络技术与软件技术对系统进行规划，保证系统整体架构在未来几年内都处于国际领先的地位。
❑安全性：软件系统具有较高的安全要求，系统必须具备充分的安全措施，包括具备严格的权限控制机制和完备的日志记录，以确保信息安全。
❑可靠性：保证系统核心功能可以7×24小时连续运行；❑规范性：系统必须遵循国家有关法律法规要求，符合国家有关标准要求以及关于信息系统建设的各项标准和规范。
⏹请说出下列需求的类型，是否存在问题？❑收文管理应包括:⏹来文登记、拟办、领导审批、办理、归档、查询统计等功能。
附件支持WORD 、PDF 、EXCEL 、HTML 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。
⏹来文登记：完成来文登记功能。
登记来文基本信息（来文编号、来文标题、主题词、来文单位、来文时间），还要对原文进行扫描处理，引入到公文库中。
需求工程的基本过程
需求⼯程的基本过程需求⼯程的活动划分为以下5个独⽴的阶段：需求获取：通过与⽤户的交流，对现有系统的观察及对任务进⾏分析，从⽽开发、捕获和修订⽤户的需求；需求建模：为最终⽤户所看到的系统建⽴⼀个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；形成需求规格：⽣成需求模型构件的精确的形式化的描述，作为⽤户和开发者之间的⼀个协约；需求验证：以需求规格说明为输⼊，通过符号执⾏、模拟或快速原型等途径，分析需求规格的正确性和可⾏性，包含有效性检查，⼀致性检查，可⾏性检查和确认可验证性；需求管理：⽀持系统的需求演进，如需求变化和可跟踪性问题。
需求获取阶段需求获取⾸先需要的是技术的⽀持，其次，在需求获取⼯作中主要涉及了 3 个⾄关重要的因素：应搜集什么信息；从什么来源中搜集信息；⽤什么机制或技术搜集信息。
再次，需求获取的开始，代表着软件项⽬正式开始实施，正所谓万事开头难。
综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的⽅⾯。
在⼯作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进⾏沟通，挖掘系统最终⽤户的真正需求，把握需求的⽅向。
在需求获取调研会中⾸先对需求获取⽅法作了验证。
现⾏的需求获 取⽅法⼀般有基于调查的需求获取⽅法、基于⽤例的需求获取⽅法、原型法等⼏种⽅法。
各种需求获取⽅法各有利弊。
[7]需求分析阶段需求分析与需求获取是密切相关的，需求获取是需求分析的基础，需求分析是需求获取的直接表现，两者相互促进，相互制约。
需求分析与需求获取的不同主要在于需求分析是在已经了解承建⽅的实际的客观的较全⾯的业务及相关信息的基础上，结合软、硬件实现⽅案，并做出初步的系统原型给承建⽅做演⽰。
承建⽅则通过原型演⽰来体验业务流程的合理化、准确性、易⽤性。
同时，⽤户还要通过原型演⽰及时地发现并提出其中存在的问题和改进意见和⽅法。
需求⽂档编写阶段需求开发的最终成果是，在对所要开发的产品达成共识后，所编写的具体的⽂档。
软件工程- 需求分析 (1)
需求文档模板
编写需求文档 规范化后的潜在需求
产品开发计划
需求文档审核 通过的需求
未通过的需求
需求组件库
需求规格说明书
需求文档评估
分析/设计/实现
需求评估报告
需求过程中的角色
名称 描述
用户
直接操作软件的人员。他们通常具有不同的业务角色， 有不同的业务需求。例如一个图书管理系统的用户包 括：读者、图书管理员、仓库管理员、系统管理员、 馆长 指软件开发的委托方或软件市场的目标客户。例如， 某一设备制造商委托软件开发商进行设备控制软件开 发，那么该设备制造商是系统的客户
(8)
•
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
• 软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
• 需对访问系统或系统信息加以控制吗？ • 如何隔离用户之间的数据？ • 用户程序如何与其它程序和操作系统隔
•
离？ 系统备份要求？
(10) 软件成本消耗 与开发进度需求
• 开发有规定的时间表吗？
• 软硬件投资有无限制？
(11) 质量保证
• • • • • • •
系统的可靠性要求？
系统必须监测和隔离错误吗？ 规定系统平均出错时间？
出错后，重启系统允许的时间？
系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
软件需求的特性
(1) 可验证性 可验证性是软件需要的基本属性。软件需求必 须是可验证的，否则软件的评审和测试就没有相 应的依据。但在某些情况下，很难对某些软件需 求进行验证或需要的代价很高。软件需求人员和 测试人员应以合理的代价实现需求的验证。 (2) 优先级 软件需求应具有优先级，可以在有限的资源 情况下进行取舍。 (3) 唯一性 软件需求应唯一地标识出来，以便在软件配 置管理和整个软件生命周期中进行管理。
需求工程讲稿(第三讲)需求工程的方法
需求工程的方法过程、方法和技术描述的重要性建模的作用需求工程的维度♦表示维（代表需求的可维护、可验证的程度）⏹非形式的：自然语言⏹半形式的：图形语言（如：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)♦粗略的框架：每个人实际上都只属于一个家庭描述的语气问题♦描述的不同语气⏹直述：给出一个事实⏹询问：问一个问题⏹命令：传递一个命令⏹假设：陈述一种可能⏹希求：表达一种愿望需求是希求式的♦需求一定包含“应该做什么”♦对需求工程来说，一般应该有的语气：⏹领域特性：直述式语气⏹需求：希求式语气♦语气随开发进程不断变化需求描述需求的表示维坐标语言语言的形式化程度需求的内容维：模型♦现实中的三类模型⏹图示模型：一个雕塑，可视化⏹类比模型：一架模型飞机，使能测试经验的决策⏹分析模型：表示社会经济的一组数学方程，使能分析所描述的系统的可能行为需求中的模型分析模型类比模型理解问题，为问题世界的相关部分建模映射为实现，比如：用数据库存放信息模型的抽象性♦模型不仅仅是描述⏹它具有自己的现象，和它自己的关于这些现象之间的关系●只有当模型的现象按一种系统的方法对应到要被建模的领域的现象时，这个模型才是有用的。
需求工程(第二讲)需求工程过程33
前景与范围的关系
前景关系到整个产品。当产品的战略定位或
业务目标随时间发生改变时，前景也会变化。范
围则只与一个特定项目，或实现产品功能下一增 量的某次迭代相关。
产品前景包括了每一个计划产品版本的范围
产品目录
版本1.0的 项目范围
版本1.1的 项目范围
版本1.1的 项目范围
版本n的 项目范围
难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确 的；
– 存在默认的知识,如难以描述的常识问题；
– 存在多个知识源,且多知识源之间可能有冲突； – 客户可能的偏见，如不能提供或不想告知你所需要了解的事 情。
信息科学与技术学院
案例
3个月前，甲新加入一家公司。很快他进入到一个项目里， 这个项目是为某公司提供一个信息管理系统，主要是管理 供应商的情况。当时项目刚处于初期，主要是获取需求， 做DEMO，然后去为客户作演示。其中主要是甲做开发。 • 甲以前主要一直做系统的开发和设计工作，加入这个项目 后，公司希望他作为项目的PM，来推动这个项目往前走。 • 然而,甲对这个客户行业（某工程行业）非常不了解，因 此对获取需求毫无办法，虽然他也希望能参考一些类似的 系统，但一直没有找到。所以基本上就是公司有客户关系 的人零零碎碎的发过一些需求，然后他去照着做。最近， 客户终于认为甲做的系统并不适合他们。所以这个项目可 以说是失败了，于是，公司认为甲没有达到要求，解除了 合同。
信息科学与技术学院
通过业务需求定义前景
回顾：
业务需求（ business requirement）表示组织或客户高层次的目标。
来源：项目投资人、购买产品的客户、实际用户的管理者、市场
营销部门或产品策划部门。 内容：描述了组织为什么要开发一个系统，即组织希望达到的目
全套电子课件：软件工程-理论与实践(第3版)
程”，是软件开发和维护中的管理和
1.第一代软件工程 支—持传能力统，的逐软步件形工成程软件过程工程。
2.第二代软件工程 — 对象工程
3.第三代软件工程 — 过程工程
4.第四代软件工程 — 构件工程
90起年代，基于构件（Component）
螺旋模型将开发过程 分为几个螺旋周期，每 个螺旋周期可分为4个工 作步骤： 第一，确定目标、方案 和限制条件； 第二，评估方案、标识 风险和解决风险； 第三，开发确认产品； 第四，计划下一周期工 作。
6.智能模型(intelligent model)
也称为基于知识的软件开发模型，是知识工程 与软件工程相结合的软件开发模型。
软件工程是一门新兴的边缘学科,涉及的学科多， 研究的范围广，研究的主要内容有以下几方面：
软件开发方法、技术 软件开发工具及环境 软件管理技术 软件规范（国际规范）
} 软件开发技术 } 软件管理技术
１.２ 软件工程过程
为了克服软件危机，人们从其他产业的工业 化生产得到启示，于是在68年北大西洋公约的软 件可靠性会议（NATO）上，首次提出了“软件工 程”的概念。提出了在软件生产中采用工程化的 方法，采用一系列科学的、现代化的方法技术来 开发软件。这种工程化的思想贯穿到软件开发和 维护的全过程。
2. 增量模型(incremental model)
增量模型是一种非整体开发的模型。是一种进 化式的开发过程。
根据增量的方式和形式的不同，分为： 基于瀑布模型的渐增模型 基于原型的快速原型模型 该模型具有较大的灵活性，适合于软件需求不 明确、设计方案有一定风险的软件项目。
增量模型和瀑布模型之间的本质区别是什么？
软件工程第三章需求应用全面分析
结构化英语、判定树、判定表用于描述数据流 图中的处理逻辑说明。
• SA方法的实质*：是采用一组分层数据流图及数据
字典作为系统的模型，从总体来看，是一种依赖数
据流图的自顶向下的建模方法。
2020/11/25
5
数据流图：分层扩展的功能模
型
数据流图（DFD）是SA方法中用于建立系统逻辑模型 的一种工具，它以图形的方式描绘数据在系统中处理的流 动过程。由于它只反映系统需要完成的逻辑功能，所以它 是一种功能模型。*
配件库存
顾客
订货单 发货单
1
处理 业务Biblioteka 订货单 发货单供应 商
2020/11/25
15
数据流图： DFD绘制步骤（续）
* （2）再绘制二层DFD：是顶图的分解，表明子系统划分及其 边界。 • 系统划分几个子系统，一个子系统在二层图中只有一个处理逻辑（需
求来源是业务子系统或用例图中的用例）； • 每一子系统析取所有的外部项、输入输出数据流和主要数据存储； • 各子系统之间的依赖关系（数据流直接依赖，数据存储缓存依赖）。
软件工程 Software Engineering
第三章 需求应用全面分析
2020/11/25
1
本章主要内容
• 3.1 软件需求概念
-软件需求的问题、定义、层次、来源、依据、目标
• 3.2 需求工程过程
- 需求开发：需求获取、需求分析、规格说明、需求验证 - 需求管理：覆盖需求开发全过程
• 3.3 需求获取技术
数据存储可以是一个文件，也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的，也 可以是双向的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求规格说明子活动
2. 需求工程过程的活动
需求验证
确保需求规格说明文档能正确、准确的反映用户的 意图 确保文档的高质量
文档内每条需求都正确、准确的反映了用户的意图； 文档记录的需求集在整体上具有完整性和一致性； 文档的组织方式和需求的书写方式具有可读性和可修改性
需求验证子活动
执行验证 问题修正
2. 需求工程过程的活动
需求管理
保证需求作用在整个软件的产品生命周期中的持续、 稳定和有效发挥 建立和维护需求基线集 建立需求跟踪信息 进行变更控制
需求管理子活动
主要内容
1. 2. 3.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性
3.需求工程过程的并发和迭代性 ——需求开发中的分析模型复杂度
3.需求工程过程的并发和迭代性 ——迭代的需求开发过程模型
3.需求工程过程的并发和迭代性 ——需求开发活动的并发性
主要内容
1. 2. 3.
需求工程过程 需求工程过程的活动 需求Leabharlann 程过程的并发和迭代性本章小结
需求工程有着属于它自己的生命周期模型，存 在着针对需求开发的需求工程过程 需求工程过程拥有一些常见的需求工程活动： 需求获取、需求分析、需求规格说明、需求验 证和需求管理 需求开发活动是互相交织、并发、迭代和递增 的 需求工程过程的成功执行需要应用很多的有效 实践方法
需求获取子活动
收集背景资料 定义项目前景和范围 选择信息的来源 选择获取方法，执行获取 记录获取结果
2. 需求工程过程的活动
需求分析
建模来整合各种信息，以使得人们更好的理解问题 为问题定义出一个需求集合，这个集合能够为问题 界定一个有效的解决方案 检查需求当中存在的错误、遗漏、不一致等各种缺 陷，并加以修正
2. 需求工程过程的活动
需求分析子活动
背景分析 确定系统边界 需求建模 需求细化 确定优先级 需求协商
2. 需求工程过程的活动
需求规格说明
获取的需求需要被编写成文档，主要目的是为了在 系统涉众之间交流需求信息 业务需求被写入项目前景和范围文档 用户需求被写入用户需求文档（或者用例文档） 系统需求被写入需求规格说明 定制文档模版 编写文档
需求变化
变更控制
项目活动
系统开发
主要内容
1. 2. 3.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性
2. 需求工程过程的活动
需求获取
需求获取是从人、文档或者环境当中获取需求的过 程 需求工程师必须要利用各种方法和技术来“发现” 需求 需求获取和需求分析是交织在一起的
2. 需求工程过程的活动
1. 需求工程过程
需求获取
需求分析
需求规格说明
需求验证
成果文档： 用户需求 领域特性
项目前景和范围文档 用户需求文档 需求规格说明文档 一致的需求
1. 需求工程过程
系 统 环 境
涉众
硬
数
据
需求获取 需求分析 需求规格说明 需求验证
需求开发
需求基线 需求跟踪信息
需求管理
当前基线
修订的基 线
项目当 项目进 展 前状态
第3章.需求工程过程
主要内容
1. 2. 3.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性
1. 需求工程过程
过程是一组相关活动的集成，通过这些活动的执行，可以 完成一项任务或者达到一个目标。 需求工程过程是系统开发当中需求开发活动的集成，它的 目标是产生一个能够在用户环境下解决用户业务问题的系 统方案 需求工程过程可能会表现出极大的差异，但是除了少数情 况之外，主要的需求工程活动是比较固定的