软件工程4.ppt
《软件工程4.ppt》由会员分享,可在线阅读,更多相关《软件工程4.ppt(192页珍藏版)》请在三一文库上搜索。
1、第四章 软件需求工程 软件工程课件 1 第四章 软件需求工程 4.1 软件需求工程基础 4.2 软件需求获取 4.3 传统的需求分析方法 4.4 面向对象的需求分析 4.5 快速原型化方法 4.6 软件需求规格说明 4.7 软件需求评审 4.8 软件需求管理 2 4.1 软件需求工程基础 软件需求工程的基本任务是准确地回答“软件系统 必须做什么?”这个问题。它在系统工程和软件设 计之间起到桥梁的作用。 软件需求工程是软件生存周期中重要的一步,也 是决定性的一步。只有通过软件需求工程的活动 才能把软件功能和性能的总体概念描述为具体的 软件需求规格说明,从而奠定软件开发的基础。 系统工程软件需求工
2、程软件设计工程 3 软件需求的定义和层次 n1997年IEEE在软件工程标准词汇表对需求 (requirement)所作出的定义为: 用户为解决某一问题或为达到某个目标所需要 的条件或能力。(需方) 系统或系统部件为满足合同、标准、规格说明 或其他正式的强制性文档所必须具有的条件或 能力。(供方) 对在a) 和b) 中所描述的条件或能力的文档化说 明。 4 nGBT 114572006信息技术 软件工程术语 等同采用了这个定义。它从两个方面阐述了需求 的含义: u从用户角度要求系统应具有的外部行为 u从开发者角度要求系统应具有的内部特性 n最后强调了需求一定要文档化。 n软件需求包括 3 个不
3、同的层次:业务需求、用户 需求、功能需求和非功能需求。 n不同层次是从不同角度与不同程度反映着细节问 题。 5 业务需求(Business Requirement) n业务需求反映了组织或客户高层次的目标要求 。 n业务需求主要来自于项目的投资人、购买产品 的客户、实际用户的管理者、市场营销部门或 产品策划部门。 n业务需求描述了组织的愿景,即为什么要开发 一个系统;系统的业务范围、业务对象、客户 、特性、价值和各种特性的优先级别等。 6 n用户需求描述了要求系统必须完成的任务,即 用户对系统的目标要求。 n用户需求通常只涉及系统的外部可见行为,不 涉及系统的内部特性。 n用户需要是用户真正需
4、要的东西,用户需求是 用户对其需要的一种陈述,但这种陈述可能与 它们的需要不一致。 n用户需求一般采用自然语言和直观图形相结合 的方式描述,例如采用用例(Use Case)文档 或场景(Scenario)等方式说明。 用户需求(user Requirement) 7 功能需求和非功能需求 n功能需求定义了开发者应提供的软件功能或服务 ,但不涉及这些功能或服务的实现。 n非功能需求则是对功能需求的补充,包括了对系 统的各种限制和用户对系统的质量要求。 n特性是指逻辑上相关的功能需求的集合以满足业 务需求。 n功能需求记录在软件需求规格说明(SRS)中。 n非功能需求的描述如下: 8 产 品 需
5、求 性能实时性; 其他时间限制,包括响应时间、处理时间、包 传送时间等; 资源配置需求,包括内存容量、磁盘容量、缓 存容量、硬软件支持等; 处理精度、单位时间处理量、网络流通量等。 接口相关硬件接口、软件接口、人机接口 可靠性 可用性(系统无故障运行时间所占总运行时间 的百分比) 完整性(系统的行为遵从用户需求所期望行为 的百分比) 安全性 系统一旦发生故障降低损失防止严重危害的能 力 保密性 防止非法访问保证信息不泄露的能力 9 产 品 需 求 运行限制 使用频度、运行期限; 控制方式(如本地控制还是远程控制); 对操作员的需求; 物理限制 对系统的规模等限制。 过 程 需 求 开发类型(实
6、用型开发还是试验型开发?是有机型、嵌入型 还是半独立型项目?) 开发工作量估计 对资源、开发时间及交付的安排 开发方法 应遵循的规范和标准(如开发规范、文档规范、 专业标准等) 里程碑和评审(如对阶段制品设置检查点和评审 内容) 质量控制标准及验收标准(如质量检验指标) 10 n系统需求来自于系统分析和结构设计。 n例如,有一个电信计费系统,它包括许多业务规 则,这些业务规则与企业方针、政府条例、会计 准则、计算方法有关,它们本身并非软件需求, 因为它们不属于任何特定的软件系统的范围,它 们属于系统需求。 过程 需求 建立可理解性、可修改性、可移植性、可测试性、效 率等质量需求并设置优先级 可
7、维护性 系统需求 11 功能需求非功能需求 系统需求 软件需求规格说明 质量属性 外部接口 约束 业务需求 愿景和范围文档 用户需求 用例文档 功能需求 业务需求 12 n所有的用户需求必须与业务需求一致。 n功能需求必须从用户需求中提取,以满足用户对 产品的要求从而完成其任务。 n开发人员应根据功能需求来设计软件以实现必须 的功能。功能需求从外部(用户角度)描述了软 件系统所应具有的行为。 n对一个复杂产品来说,软件功能需求也许只是系 统需求的一个子集。 各种需求的关系 13 n非功能需求作为功能需求的补充,包括 u产品必须遵从的标准、规范和合约; u外部接口的具体细节; u性能要求; u设
8、计或实现的约束条件及质量属性。 n约束是指在软件产品设计和构造上的限制。 n质量属性是通过多种角度对产品的特点进行描述 ,从而反映产品功能。 n多角度描述产品对用户和开发者都极为重要。 14 软件需求工程过程 n软件需求工程阶段研究的对象是软件项目的用 户需要。需要注意的是, u必须全面地理解用户的各种需求 u分析和澄清模糊的用户需求 u准确地表达被接受的用户需求 n只有经过确切描述的软件需求才能成为软件设 计的基础。 n软件需求工程需要执行的活动包括: 15 1)确定目标系统将要面对的各类用户; 2)从各类用户的代表那里收集需求; 3)了解用户的任务和目标,以及这些任务要实 现的业务目标;
9、4)分析从用户那里得到的信息,将用户的任务 和目标与软件的功能需求、非功能需求、业务 规则、解决方案建议及其他无关信息区分开来 ; 5)将顶层的需求分配到软件系统构架内定义好 的软件成分中; 6)了解各个质量属性的相对重要性; 16 8)协商需求的实现优先级; 9)将收集的用户需求表述为书面的需求规格说 明和模型; 10)审阅需求文档,以确保在认识上与用户 需求相一致。应在开发组接受需求之前解决所 有分岐。 n软件开发的目标是实现目标系统的物理模型,即 确定待开发系统的各种软件成分,并将功能和信 息结构分配到这些软件成分中。但是目标系统的 具体物理模型是由当前系统的具体物理模型经过 一系列的转
10、换得到的。 17 n软件需求工程的任务就是借助于当前系统的逻 辑模型导出目标系统的逻辑模型,解决目标系 统 “做什么” 的问题。 目标系统 当前系统 物理模型逻辑模型 模型化抽象化 物理模型 逻辑模型 具体化实例化 理 解 需 求 导 出 怎么做做什么 18 Abran和Moore的软件需求工程过程模型( 未包括需求管理) 用户需求和 系统需求 需求规格 说明 用户需求 草稿 分析模型 可行性 研究 分析建模 需求获取 需求描述 需求有效 性验证 19 n 需求获取 1) 定义需求开发过程 2) 定义项目愿景和范围 3) 确定用户群 4) 选择用户代理人 5) 确定用例 6) 确定系统事件和响
11、应 7) 描述软件的功能和性能 8) 指明软件与其他系统元素的接口 9) 建立软件必须满足的约束 20 n 分析建模 分析可行性 确定需求优先级 为需求建模 创建数据字典 将需求分配至各子系统 应用质量功能进行调整 分析模型为日后软件设计提供了可被翻译成数据 、体系结构、接口和处理过程设计的模型。 21 需求描述 需求规格说明为开发人员和用户提供软件开 发完成时质量评价的依据。 采用SRS模板 确定需求来源 唯一标识每项需求 记录业务规范 定义质量属性 需求有效性验证 审查需求文档,确定合格标准 22 4.2 软件需求获取 n需求获取的目标是确定用户“需要”什么样的软 件产品,即新的软件必须能
12、够做什么。 n没有专业的系统分析人员,用户很难了解到需 要开发什么相关信息和功能;另一方面,没有 与用户的交流,系统分析人员也很难弄清客户 真正需要什么。 n发现用户需求的过程称为需求获取。一旦提出 了最初的需求,进一步推敲、细化和扩充的过 程称为分析建模。 23 需求获取过程 n需求获取包括以下活动: v发现和分析问题 发现问题症结,并分析问 题的原因/结果关系。 v获取需求 根据对问题的理解定义需求。 v使用调查研究方法收集信息; v遵循需求获取框架,按照三个成分观察: 即数据、过程和接口。 v需求归档 以草稿形式归档调查结果。形式 有用例、决策表、需求表等。 24 需求获取技术的基本特征
13、 n好的需求获取技术,对于规范需求获取活动, 高效准确地获取需求定义,是十分重要的。 n好的需求获取技术,应具有如下基本特征: u提供便于沟通的工具,如易于理解的语言和 直观的图表; u提供定义系统边界(交互)的方法; u提供支持抽象的机制,如“分解”、“映射”等 ; 25 u鼓励分析员使用面向问题的术语思考问题, 编写文档; u为分析员提供多种可供选择的解决方案; u适应需求的变化。 n适于以上特征的需求获取方法: u基于数据流图的结构化分析方法; u基于用例(use case)的建模方法。 n需求获取技术的关键点在于: 深入浅出 需求获取要尽可能全面、细致。 26 获取的需求是个全集,系统
14、真正实现的是 个子集。分析时的调研内容并不都纳入到 新系统中,目的在于以后的扩充。 以流程为主线 在与用户交流的过程中,应该用流程将所 有的内容串起来。如信息、组织结构、处 理规则等。这样便于交流沟通。 流程描述有宏观,也有微观。既要强调总 体的业务流程、全生存周期的业务流程, 又要对流程细化,有分支的业务流程。 27 需求获取的主要步骤 n 开发高层的业务模型 u理解应用领域,即目标软件的应用环境。如 银行、电信公司、书店等。 u一旦系统分析人员对该领域有了充分了解, 就可以建立一个业务模型,描述用户的业务 过程,确定用户的初始需求。 u分析出企业的业务实体,开发或选取必需的 构件,建立稳定
15、的软件体系结构。 u通过迭代,更深入了解应用领域,再回过头 来推敲业务模型。 28 n 定义项目的视图和范围 u在项目开始之前,在所有干系人中竖立一个 共同的愿景,明确供需各方的权利和义务, 并发布得到共识的、对项目目标的理解。 u在共同愿景的确立过程中要做两件事情: u定义项目范围:项目范围描述项目该做什 么,不该做什么,可通过陈述和图表(如 用例图或数据流图)来表达; u定义高层需求:高层需求不涉及过多的细 节,主要通过它表示系统的概貌,从而建 立需求模型。 29 n 寻求需求的来源 u软件需求的来源取决于目标系统的性质和开 发环境。典型的需求来源是: n与潜在用户进行交谈和讨论 n描述现
16、有产品或竞争产品的文档 n系统需求规格说明 n当前系统的问题报告和改进要求 n市场调查和用户问卷调查 n观察用户如何工作 n用户工作的场景分析 n事件和响应 30 n根据所受限制不同,不同类型的应用系统能够从 用户那里获取需求的比例也不同。 n所谓限制,是指受客观物理规律的限制。 相对低的 相对高的从人群获取需求的大概百分比 应 用 的 类 型 高度受限的 不受限制的 导弹制导系统 航班控制系统 公司财务系统增强版 制造控制系统 公司财务系统 视频游戏 军事战略决策支持系统 31 u如导弹制导系统更多地受物理运动定律的限制 ,而非人的决策。视频游戏的大部分需求依赖 人,因为它是一个想象出来的产
17、品。 u应用受到的限制越少,能从人们那里获得的需 求比例越大。 n 识别用户类和用户代表 u确定目标系统的不同用户类型; u挑选出每一类用户和其他项目相关者的代表并 与他们一起工作; u商定谁是项目需求的决策者。 32 u不同用户类可能还有不同的非功能需求。 u不同用户类的需求甚至可能发生冲突,导致 需求不一致。 u即使所有利益相关者的需求一致,也可能由 于实现代价高昂,需求不能得到完全满足。 u用户类可以是人,也可以是与系统打交道的 其他应用程序或硬件部件。 u分析员必须在项目初期便确定产品有哪些不 同的用户类,并描述它们的特点,这样就能 从每个重要用户类的代表那里获取用户需求 。 33 u
18、每一个项目,包括企业信息系统、商业应用 软件、数据包、集成系统、嵌入式系统、互 联网Internet应用程序等,都需要有合适的用 户来提供用户需求。 u确定目标系统的业务工作流 u具体到当前待开发的应用系统,确定系统的 业务工作流和主要的业务规则。 u例如,针对信息系统的需求调研方法如下: 1)调研用户组织结构、岗位设置、职责定义, 从功能上区分子系统,明确系统范围和目标 。 34 调研每个子系统的处理流程、功能与处理规 则,收集原始信息资料,用数据流来表示物 流、资金流、信息流三者的关系。 对调研内容事先准备,针对不同管理层次的 用户询问不同的问题,列出问题清单。将操 作层、管理层、决策层的
19、需求既联系又区分 开来,形成一个需求的层次。 对与用户沟通的情况及时总结归纳,整理调 研结果,初步构成需求基线。 需求调研的形式可根据需求的来源来确定。 35 n 访谈和文档记录 u大部分需求获取是人与人沟通的活动,这些 活动经过精心组织,以准确获得最好的效果 。 u准备和访谈客户的过程如下: 访谈之前 u策划访谈的目标和内容: u通过查阅组织的组织结构图,搞清业务部门 的各种角色,选择访谈的主要对象 u预约访谈时间 u准备访谈内容,拟定一些具体问题 36 访谈过程中 u引导访谈对象。发现业务流程背后的用户需求 : nWhat:系统要处理的业务内容是什么。 nWhen:系统业务过程的主要活动什
20、么时候 发生,持续时间有多长。 nWho:系统业务过程的各个活动中会有哪 些相关的人、物、事(系统)。 nWhy:为什么会出现这样的问题。 nHow:为完成系统的业务目标所采用的方 法。 37 u不管用户说什么,分析员首先要分析,然后 置疑,从而引导用户说出他们真正的需求所 在。 访谈之后 u根据标准模版撰写软件需求规格说明SRS, 打客户需求草稿 u通过电子邮件征求客户意见 n 需求的整理与描述 u开发反映主要业务规则的用例(或数据流图 或状态图),与用户沟通。 38 u收集用户的质量属性信息和其他非功能需求 ,将性能、安全性、可靠性等需求和其他设 计约束结合业务规则,形成功能需求。 u分类
21、在用例(或数据流图)中涉及的数据, 包括数据的组成和数据之间的关系。 u详细拟订用例(或数据流图)的规格说明, 建立功能模型,并进行审查。 u开发并评估界面原型,建立接口规范和信息 流传输规则。 u从功能描述中开发概念测试用例,验证用例 (或数据流图)、功能需求和原型。 39 描述用户需求 n需求可以看成是应用与应用的外部代理(如用户 )之间的交互。可利用用例作为表达工具。 n用例描述了系统外的参与者(Actor)与应用之间 的交互情况。主要注重用户对系统的看法。 n描述客户需求的过程如下: 1) 标识参与者 标识目标系统将支持的不同类型 的用户,可以是人、事件或其他系统。 2) 标识场景 用
22、场景描述目标系统典型功能的活 动细节,并与用户沟通,加深开发人员对应用 领域的理解。 40 3) 标识用例 当双方确定了一组场景后,开发人 员从该场景抽象出一组用例,描述所有可能的情 况。用例表达了系统的范围。 4) 求精用例 细化每一个用例。引入带有出错处 理或带有异常处理的用例,描述系统的行为,保 证需求的描述是完全的。 5) 标识用例之间的关系 描述用例之间的依赖关 系,提取相同功能,建立用例模型。 6) 标识非功能需求 包括系统性能上的约束、文 档、使用资源、安全性和质量等需求。 41 n需求获取期间,开发人员需要访问一些不同的信 息资源: 客户提供的与应用领域相关的文档和手册。 将被
23、目标系统替代的遗留系统的技术文档。 最终用户和客户本人。 n以“图书管理系统”为例,首先标识参与者: Librarian 图书管理员:创建、修改、删除读者 信息;添加、编辑、删除书目信息;添加、编 辑、删除图书信息。 Borrower 读者:借阅、预约、归还图书,以及 取消书目预约。 42 n图书(Book)是指某种书目(Title)的某一流通 中的复本。例如“数学分析教程第二册”的 5 本馆 藏复本中的第 3 本。 n识别用例: BorrowBook:借阅图书 ReturnBook:返还图书 RecerveTitle:预约某种书目 CancelReservation:取消预约 Maintai
24、nBorrowerInfo:维护读者信息,包括 创建、修改、取消读者账户 MaintainTitleInfo:维护书目信息,包括添加 43 修改、删除书目信息 MaintainBookInfo:维护图书信息,包括添加 、修改、删除图书信息 Login:登录 n识别参与者与用例之间的关系(场景) Borrower执行BorrowBook、ReturnBook、 ReserveTitle、CancelReservation等用例。 Borrower是通过Librarian完成上述用例的工作 。则Borrower与Librarian存在依赖关系。 Librarian还与MaintainBorrowe
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程
链接地址:https://www.31doc.com/p-3301837.html