软件需求工程2
软件工程实践-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. 加强项目管理：软件需求工程作为软件开发的基础，能够帮助项目经理对项目进展、人力资源和进度进行有效的管理。
通过对软件需求的追踪和管理，项目经理能够及时发现问题并做出相应的调整和决策。
三、软件需求工程的主要过程软件需求工程包含以下主要过程：1. 需求获取：通过与用户交流、访谈、需求调研等方式，获取用户的需求信息。
需求获取是软件需求工程的第一步，也是最关键的一步，它直接关系到后续工作的开展和软件开发质量。
2. 需求分析：在需求获取的基础上，进行需求分析工作，主要包括需求划分、需求描述、需求模型化等。
通过需求分析，将用户需求转化为开发团队所理解的形式，为后续的开发工作提供参考依据。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
软件工程课程设计-2-需求分析
新生入学管理信息系统需求分析说明书拟制人审核人______________________ 批准人______________________[XX年XX月XX日]目录1引言 (1)1.1编写的目的 (1)1.2背景 (1)1.3参考资料 (1)2任务概述 (2)2.1 目标 (2)2.2 用户的特点 (2)2.3 假定的约束 (2)3系统数据要求分析 (4)3.1 数据词典 (4)3.2ER图 (8)3.3 数据流模型 (10)4运行环境规定 (11)4.1 设备 (11)4.2 支持软件 (11)4.3 接口 (11)1 引言1.1编写的目的新学期伊始，各学校迎新生活动如火如荼的展开着。
随着时代的发展，信息化的进步，学校现有的新生接待工作显得较为繁琐和混乱，如何能更合理的安排好学校的迎新工作，已经成为一个学校是否能跟上时代和信息进步的体现。
在这种背景下该软件才得以开发。
新生入学管理是一个以3G网络或无线网络为平台，建立一个用电脑软件来实现流程一体并可视化的新生接待系统。
减少原有的新生接待流程人力资源浪费的现象，并且减少了餐饮开销；此外，该软件利用网络资源共享和信息同步技术，随时随地的查阅新生的各项信息，与现有的操作流程相比具实时性，准确性；而且，新生入学管理系统关于新生信息的安全性较传统的接待流程更为优秀。
因此开发该个软件。
希望该软件能够给使用者带来更多的益处。
最重要的是使用方法的方便、快捷、经济。
顺应时代的进步和信息的发展，采用更为先进的接待系统能够让新生感觉到学校的与时俱进，并产生良好的第一印象。
所以，使用者一个正确的选择往往能够取得事半功倍的效果。
该软件能够为学校的迎新工作带来新的气象。
1.2背景a.所建议开发软件系统名称：新生入学管理系统b.本显目的任务提出者：开发者：用户：学校招生处运行该软件的计算机网络与工作站：学校局域网，学校教务网c.该软件系统同其他系统或其他机构的基本相互来往关系：学校3G网络或无线网络，学校新生资源库，新生导师任信息。
软件需求工程
软件需求工程软件需求工程是软件开发过程中的重要环节，它涉及从需求收集、分析和规划到需求验证和确认的全过程。
作为软件工程的核心阶段之一，软件需求工程直接影响着最终软件产品的质量和用户满意度。
本文将重点介绍软件需求工程的概念、流程和方法，以及其在软件开发过程中的重要性。
一、软件需求工程的概念软件需求工程是指在软件开发过程中，对用户需求进行系统分析和定义，以明确软件功能、性能、用户界面等方面的要求，并将其规范化和文档化的过程。
它是软件工程的前期工作，旨在确保软件项目的成功与用户需求的一致性。
软件需求工程的主要任务包括需求收集、需求分析、需求规格说明和需求验证。
需求收集是通过与用户、利益相关者进行交流和对现有业务流程进行调研，获取相关需求信息。
需求分析是对收集到的需求进行整理、筛选和抽象，以明确软件系统的功能和性能特性。
需求规格说明是将需求信息进行形式化描述和文档化，为后续的软件设计和开发提供依据。
需求验证是通过与用户和开发团队的沟通和确认，确保需求规格的准确和完整。
二、软件需求工程的流程软件需求工程的流程可以分为五个主要阶段：需求识别、需求分析、需求规格、需求验证和需求管理。
1. 需求识别阶段：在这个阶段，软件工程师与用户、业务专家等进行沟通交流，明确软件开发的目标和范围，识别出相关需求和约束条件。
2. 需求分析阶段：在需求分析阶段，软件工程师对需求进行详细的分析和整理，识别出需求的优先级和复杂性，规划开发过程中的需求分解和优化策略。
3. 需求规格阶段：需求规格阶段是将需求进行形式化描述和文档化的过程。
软件工程师使用UML、数据流图等工具，以及规格文档进行需求描述和建模，明确功能模块、界面设计和数据结构等。
4. 需求验证阶段：需求验证是通过与用户和开发团队的沟通和确认，确保需求规格的准确和完整。
这个阶段通常包括需求评审、原型演示和用户反馈等活动，以验证需求是否满足用户期望。
5. 需求管理阶段：需求管理是软件开发过程中对需求的追踪和控制，确保软件开发的目标和需求的一致性。
第3章 需求分析-软件工程案例教程(第2版)-李军国-清华大学出版社
可行性研究的任务和目的
➢ 用最小的代价在尽可能短的时间内确 定问题是否能够解决。
➢ 确定问题是否能够解决和值得解决。 ➢ 分析可能的利弊关系。
➢ 对行动方针提出建议（是否可行）。
7
可行性研究的时间与成本
➢ 可行性研究实质上是在较高层次上以抽 象方式进行系统分析和设计的过程。
➢ 可行性研究需要的时间长短取决于工程 的规模。
仔细阅读和分析有关的材料，改正含糊或不正确的叙述， 清晰的描述目标系统。
➢ 识别用户的真正要求?（访问关键人员） ➢技术现状如何？ （系统调研） ➢系统配置如何？ （分析有关的材料） ➢系统维护能力如何？ （系统调研） ➢ 系统配置与外部环境的接口什么样？（限制和约束） ➢ 技术上的风险有哪些？ ➢ 是否具备技术资源？ ➢ 开发人员是否得到培训？ ➢ 是否存在法律责任和政治风险？
21
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解业务活动状况，特别是活动要点的分析。 ➢ 明确这些要点间什么在流动，如何流动。 ➢ 对物理流量进行分析。 ➢ 模型化，得到实际业务系统的物理模型。
22
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解系统应解决的问题是什么？ ➢ 这些问题是如何提出的？ ➢ 了解问题的结构。 ➢ 这些问题如何解决才能满足用户的要求？
17
案例： （库存管理）
找出问题
➢不能及时获得库存信息 ➢库存信息不够准确 ➢无法及时了解车间对库存商品的需求情况
18
系统分析过程
① 分析现实世界，充分理解当前系统，并用一个具体模 型描述，获得当前系统的物理模型。
软件工程中的软件需求分析方法(二)
软件工程中的软件需求分析方法导言在软件开发过程中，准确、清晰的软件需求分析是成功的关键。
软件需求分析方法的选择和运用，对于确保软件项目的顺利进行以及最终交付优质产品具有重要意义。
本文将探讨几种常见的软件需求分析方法，并介绍它们各自的优缺点。
1. 需求采集方法用户需求访谈用户需求访谈是一种常用的需求采集方法。
通过与终端用户直接交流，软件开发团队能够深入了解用户的需求、期望和挑战。
然而，这种方法的一个限制是，用户在开始的时候可能并不清楚自己具体需要什么，或者无法表达清晰的需求。
场景分析场景分析方法通过模拟真实的使用场景，帮助开发团队了解用户在实际情况下的需求。
开发团队可以通过观察用户在特定场景下的行为、交互等来推断出软件的需求。
然而，这种方法可能无法覆盖所有的使用场景，并且可能受到开发团队的主观因素的影响。
2. 需求建模方法用例图用例图是一种常见的需求建模方法，用于描述软件系统与其用户之间的交互。
它通过标识不同用户角色和系统功能，揭示系统的需求和行为。
用例图直观地展示了系统的功能和交互，有助于软件开发团队更好地理解用户需求。
然而，用例图不能提供详细的需求规范，无法满足复杂系统的需求分析。
数据流图数据流图是一种将系统视为一系列信息流动的图形表示方法。
它描述了软件系统中数据的流动路径和处理过程。
通过数据流图，开发团队可以更好地理解系统中不同模块的功能和相互关系，从而推导出详细需求。
然而，数据流图可能过于复杂，导致需求分析变得困难。
3. 需求验证方法原型验证原型验证方法通过制作出初步的系统原型，让用户提供反馈并验证软件需求的准确性。
原型验证可以帮助开发团队更好地理解用户需求，及时发现和修复问题。
然而，原型开发需要一定的时间和资源投入，并且可能导致需求变更频繁。
领域专家评审领域专家评审是一种常见的需求验证方法。
通过邀请相关领域的专家对需求规格文档进行评审，开发团队可以快速发现和纠正潜在的问题和风险。
然而，依赖专家的评审可能受到时间和资源的限制，评审结果也可能受到主观因素的影响。
需求工程(第二讲)需求工程过程33
前景与范围的关系
前景关系到整个产品。当产品的战略定位或
业务目标随时间发生改变时，前景也会变化。范
围则只与一个特定项目，或实现产品功能下一增 量的某次迭代相关。
产品前景包括了每一个计划产品版本的范围
产品目录
版本1.0的 项目范围
版本1.1的 项目范围
版本1.1的 项目范围
版本n的 项目范围
难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确 的；
– 存在默认的知识,如难以描述的常识问题；
– 存在多个知识源,且多知识源之间可能有冲突； – 客户可能的偏见，如不能提供或不想告知你所需要了解的事 情。
信息科学与技术学院
案例
3个月前，甲新加入一家公司。很快他进入到一个项目里， 这个项目是为某公司提供一个信息管理系统，主要是管理 供应商的情况。当时项目刚处于初期，主要是获取需求， 做DEMO，然后去为客户作演示。其中主要是甲做开发。 • 甲以前主要一直做系统的开发和设计工作，加入这个项目 后，公司希望他作为项目的PM，来推动这个项目往前走。 • 然而,甲对这个客户行业（某工程行业）非常不了解，因 此对获取需求毫无办法，虽然他也希望能参考一些类似的 系统，但一直没有找到。所以基本上就是公司有客户关系 的人零零碎碎的发过一些需求，然后他去照着做。最近， 客户终于认为甲做的系统并不适合他们。所以这个项目可 以说是失败了，于是，公司认为甲没有达到要求，解除了 合同。
信息科学与技术学院
通过业务需求定义前景
回顾：
业务需求（ business requirement）表示组织或客户高层次的目标。
来源：项目投资人、购买产品的客户、实际用户的管理者、市场
营销部门或产品策划部门。 内容：描述了组织为什么要开发一个系统，即组织希望达到的目
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件需求工程包括软件类产品中需求收集、评价、编写文档等所有活动建立并维护在软件工程中同客户达成的契约需求工程需求开发需求管理需求获取需求分析需求规约需求验证需求开发过程—需求获取•需求获取(Elicitation)是需求工程的核心任务，即确定软件系统涉众的需要及限制条件的过程。
•需求获取着重于发现用户需求。
用户需求包括用户要求系统完成什么任务和用户对性能、易用性和其他质量属性的期望。
需求开发过程—需求获取•需求获取发生在需求工程过程早期阶段,有时也称为需求收集(gathering)、需求捕获(capture),主要关注以下几个方面：•应当收集什么信息•了解问题域的特性，渐进地刻画需求的方向•有哪些信息来源•信息来源是多方面的，包括所有项目风险承担者(Stakeholders)，相似系统的类同分析等•可能通过什么机制或技术收集需求开发过程—需求获取1.确定需求开发过程2.编写项目视图和范围文档3.将用户群分类并归纳各自特点4.选择每类用户的产品代表5.建立起典型用户的核心队伍6.让用户代表确定用户使用实例7.召开应用程序开发联系会议(JAD)8.分析用户工作流程9.确定质量属性和其它非功能需求10.通过检查当前系统的问题报告来进一步完善需求11.跨项目重用需求需求开发过程—需求获取1.确定需求开发过程•确定如何组织需求的收集、分析、细化、核实的步骤并编写成文档。
•包括该活动的安排和进度计划。
需求开发过程—需求获取2.编写项目视图和范围文档•项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。
•项目视图说明使所有项目参与者对项目的目标能达成共识。
•范围则是作为评估需求或潜在特性的参考。
需求开发过程—需求获取3.将用户群分类并归纳各自特点•为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组。
•用户可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。
•详细描述用户的个性特点及任务状况将有助于产品设计。
需求开发过程—需求获取4.选择每类用户的产品代表•为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。
•对于内部信息系统的开发是最易实现的，因为用户就是身边的职员。
•对于商业系统开发，就得在主要客户或测试者中建立起良好的合作关系，并确定合适的产品代表。
他们必须一直参与项目的开发而且有权作出决策。
需求开发过程—需求获取5.建立起典型用户的核心队伍•把同类产品或其先前版本用户代表召集起来，从他们那里收集目前产品需求。
•这一团队对商业开发很有实际意义，因为你拥有庞大且多样的客户基础。
•与产品代表的区别在于，核心队伍成员通常不做决策。
需求开发过程—需求获取6.让用户代表确定用户使用实例•从用户代表处收集他们使用软件完成所需任务的描述（使用实例），讨论用户与系统间的交互方式和对话要求。
•在编写使用实例的文档时可使用标准模板，在使用实例基础上导出功能需求。
需求开发过程—需求获取7.召开应用程序开发联系会议(JAD)•JAD会议是范围广泛的、简便灵活的专题讨论会(workshop)，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。
•该会议通过紧密而集中的讨论将客户与开发人员间的合作关系付诸实践。
需求开发过程—需求获取8.分析用户工作流程•观察用户执行业务任务的过程。
•画一张简单的示意图，如数据流图，来描绘出用户什么时候获得什么数据，并怎样使用这些数据。
•编制业务过程流程文档将有助于明确产品的使用实例和功能需求。
•甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。
需求开发过程—需求获取9.确定质量属性和其它非功能需求•在功能需求之外再考虑非功能的质量特点，这才会使你的产品最终满足客户的期望。
•这些质量特点包括：性能、有效性、可靠性、可用性等。
•规范这些质量属性很大程度上决定于客户提供的信息。
需求开发过程—需求获取10.通过检查当前系统的问题报告来进一步完善需求•客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加新特性的想法。
•负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
需求开发过程—需求获取11.跨项目重用需求•如果客户要求的功能与已有的产品很相似，则可以查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
实验内容•第一阶段：项目启动•组建小组，确定项目•Eclipse•Mozilla•作为需求工程团队完成•项目的业务需求分析•项目视图和范围文档1.业务需求2.解决方案的视图3.范围和局限性4.业务环境5.产品成功的因素6.基于项目视图和范围的管理项目视图和范围文档1.业务需求–为什么开发该项目？新产品为客户和软件开发者带来的利益a)背景b)业务机遇c)业务目标d)客户需求e)业务风险项目视图和范围文档：业务需求a)背景•总结新产品的理论基础•产品开发的历史背景b)业务机遇•描述产品竞争的市场及运用的环境•现有产品评价及存在的问题•新产品的竞争优势项目视图和范围文档：业务需求c)业务目标•描述产品所带来的商业利润•客户获得的价值，如提高生产率、节省开支、符合产业标准、提高可用性等•产品预算和交付日期项目视图和范围文档：业务需求d)客户需求•描述典型客户的需求•客户对现有产品使用所遇到的问题•通过原型或举例阐述新产品的使用方法•确定新产品运行的软、硬平台•定义较高层次的关键接口•产品的性能要求项目视图和范围文档：业务需求e)业务风险•市场竞争带来的风险•产品预算和交付日期带来的风险•用户是否可以接受•实现技术的可行性•预测每一项风险的严重性•制定风险应对或减轻措施项目视图和范围文档2.项目视图解决方案–长远项目视图，业务目标，决策信息等a)项目视图陈述–开发新系统(产品)的目的简要陈述b)产品主要性能列表–强调区别于以往产品和竞争产品的特性c)主要假设和产品依赖的环境项目视图和范围文档3.范围和局限性–确定项目基本解决方案及适用范围，产品应包含和不应包含的性能a)Release 1.0 首次发行(开发)的范围，目的(争夺市场优先权？)b)Release 2.0 随后发行(开发)的范围c)Release 相关的产品局限性和专用性项目视图和范围文档4.业务环境–客户分类概述和项目管理优先级a)不同客户群的特征，包括客户能获得的益处，对新产品的态度，对产品哪些特性最感兴趣，使用该产品的可能性有多大，客户的限制b)项目优先级，通过对产品性能、质量、开发计划、开发成本、可用资源(主要为人力)的分析建立项目开发优先级项目视图和范围文档5.产品成功的因素a)产品成功的定义和测量b)影响产品成功的主要因素c)与所有关键风险承担者达成一致项目视图和范围文档6.基于项目视图和范围的管理a)新的需求或特性出现时确认是否在项目范围之内。
b)当不得不改变项目范围时，必须重新商定预算、资源和进度安排。
•为应对较小改变可能带来的麻烦，最初计划中留有余地，如25%，会是较现实的做法。
c)通常拒绝一个新的需求因缺乏根据难以做到，但基于项目视图和范围文档却可以合理地拒绝这些新的要求。
软件需求获取需求获取的三个主要方面:•应获取什么信息?•应使用何种信息来源?•应采用什么获取技术?软件需求获取：需求获取的信息•获取信息就是为了能够得到产生需求文档和规格说明所必需的信息：•问题域的描述•要求解决的问题列表(需求)•用户对解系统的行为或结构施加的任何约束软件需求获取：信息来源1)高层系统需求2)客户(实际的和潜在的)3)客户的“规格说明书”4)原有解系统(即运行在问题域中，执行与预期的新的解系统相似功能的系统)及其文档5)原有系统的用户6)竞争对手的产品7)应用领域专家8)定义了任何接口系统的特征和行为的文档9)相关的技术标准和法规第一次课堂分组讨论（1）•要求•选定项目，进行分组•课堂讨论+陈述•记录讨论内容•讨论内容•启动项目•获取项目的业务需求，确定项目视图和范围文档•业务需求•解决方案的视图•范围和局限性•业务环境第一次课堂分组讨论（2）•注意事项•对项目从问题域加以描述(关键点即可)•指明已有信息和待挖掘信息并分类•不确定的信息计划如何获取•确定信息来源可能的困难•将结果完整记录(记录关键点，课后整理)•每小组选一位代表加以陈述软件需求获取：需求获取技术一旦确定了可能的信息来源，接下来的工作是通过选择合适的获取技术来挖掘所需的信息。
软件需求获取：需求获取技术•面谈（Interviewing，是最直接的获得需求的方法）•结构化面谈，集中讨论一组事先计划好的问题；•非结构化面谈，面谈进行时通过临场发挥获得问题的答案；•对面谈主题做充分的准备可以大大提高面谈效率,例如对被咨询人的预先了解及期望获取的答案;•面谈进程控制•面谈信息记录软件需求获取：需求获取技术•调查表(Surveys)•当事先可以很好地确定问题时，调查表方法提供了一个高效的需求获取方法;•对问题列表预先作充分的准备，以便使问题易于理解，最小化二义性;•调查表可以认为是结构化面谈的最终表现形式，可作为面谈技术的补充方法。
软件需求获取：需求获取技术•用例(Use Case)和场景(Scenario)分析•一个精确定义的Use Case是面向解系统的而非问题域的。
•Use Case的观点和方法论对需求开发是极有帮助的，因为它可以描述用户使用系统所要完成的所有任务。
•Scenario描述了系统对用户特定的输入存在的可能的响应，可以和Use Case联合使用。
•经常和分析阶段一起使用。
软件需求获取：需求获取技术•头脑风暴Brainstorming•用于复杂、含糊不清的需求获取。
•通过一个短暂、集中式的讨论，使关键系统需求浮出水面。
•参加人员应包括各关键性领域代表，讨论将是自由式的，着重的是想法而不是辩论和批评。
软件需求获取：需求获取技术•需求裁剪Requirements Tailoring•当存在一份客户需求规格说明书，或者存在一份相似的已有产品需求规格说明书时，可使用这种技术。
•需求裁剪可以是手工的，也可以通过工具来完成。
软件需求获取：需求获取技术•关键点•在需求获取过程中，所有技术可以综合使用。
•与Stakeholders的交流(communication)与沟通(interaction)是需求获取过程中的关键能力体现。