需求分析(一)概念、方法、实践步骤

上传人:夏** 文档编号:563498438 上传时间:2022-08-23 格式:DOCX 页数:13 大小:314.81KB
返回 下载 相关 举报
需求分析(一)概念、方法、实践步骤_第1页
第1页 / 共13页
需求分析(一)概念、方法、实践步骤_第2页
第2页 / 共13页
需求分析(一)概念、方法、实践步骤_第3页
第3页 / 共13页
需求分析(一)概念、方法、实践步骤_第4页
第4页 / 共13页
需求分析(一)概念、方法、实践步骤_第5页
第5页 / 共13页
点击查看更多>>
资源描述

《需求分析(一)概念、方法、实践步骤》由会员分享,可在线阅读,更多相关《需求分析(一)概念、方法、实践步骤(13页珍藏版)》请在金锄头文库上搜索。

1、需求分析(一)概念、方法、实践步骤1。概念、方法、实践步骤需求分析阶段主要通过收集、分析、导出的方法,将客户、业务、用户的需求转换为 对应的(软件)系统需求的过程。典型的工作产品:软件需求说明(Software Requirements Specifications,以下简称SRS)其主要包括系统基本概要、业务功能、系 统功能(性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求)、接口功能要求 等内容。11需求分析阶段的主要活动需求分析阶段的主要活动可以分为需求开发、需求管理2类:皑检讹VI需求开发通过对客户、业务、用户、原系统等调查获取原始的需求,经过需求分析逐 步识别并使业务具体化,

2、通过形成制作规格说明书(或SRS)使业务系统化,项目团队同客 户、用户逐步达成共识对需求得以最终确认,其间可以通过系统建模、P0C等方式评估需 求的可实现性.需求管理在需求开发过程中,通过需求范围认定、需求形式化记录、需求数据库建 立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动,通过使用需求管理工 具等手段,实现对系统需求按基线进行控制和管理。其核心内容变更管理、版本管理以及 需求跟踪。1。2需求开发的主要概念以及核心步骤业务需求反映了企业或组织对(软件)系统的业务要求,通常也包含问题或机会的定 义。问题是指企业或组织运作过程中遇到的问题,例如物资供应脱节、用户投诉量大、客 户流

3、失率较高等。机会是指抓住外部环境变化所带来的机会,以便为企业带来新的发展例 如电子商务、网上银行、基于即时通信的工作协同系统等。业务需求通常由管理人员提出, 业务需求的解决往往要结合制度、(人员)能力、系统功能等多方面综合解决。另外,业务 需求也反映了企业或组织对(软件)系统的高层次目标要求,就是系统的建设的目的以及目 标。用户需求是指描述用户使用(软件)系统需要完成什么任务,怎么完成的需求,通常是 在问题定义(业务需求)的基础上进用户访谈、调查,对用户使用的场景进行整理从而建 立用户角度的需求解决如何使用(软件)系统完成具体工作.软件系统需求是在业务需求的指导下,对用户需求进行整理、分析、提

4、炼从而指导开 发的、更精确的、规格化的需求一般来说,软件需求可以作为软件验收依据与合同契约。 软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。业务功能需求:(软件)系统必须完成的业务功能,即为了向它的用户提供有用的功 能,产品必须执行的动作这部分工作将分散的用户零散的需求采用结构化的方法 去定义,以便支撑后续的设计、开发、测试。系统功能需求:(软件)系统必须具备的功能、性能、属性。包括系统性能(功能速 度、响应时间、恢复时间等等)、可靠性、易用性、安全性、移植、部署等方面 的内容需求.设计约束的需求:影响系统实现的各种设计约束,包括开发语言、数据完整性方 针、资源的限制、

5、运行的环境的要求等等.2主要流程需求分析阶段的主要活动围绕需求开发进行,包括制定及修改需求开发计划、开展需 求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。1. 制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS 进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容其目的是保证 各项活动有序、可控的进行。2. 需求调查以及分析的过程,主要活动通过沟通、收集项目中的各级关系人的需求, 形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计 调查表并调查、收集查阅记录等方式获取客户、用户各级组织对(软件)系统需求,分析并

6、识别客户以及用户的需要、期望、业务要求,归纳整理后形成需求调查报告。3. 需求验证环节主要通过原型(Prototype)、POC (Proof of Concept)、用例(Use Case)或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软 件系统需求. 原型(Prototype)模拟最终软件的屏幕显示,这样用户可以看到最终软件将是 什么样,有些原型可以模拟实际的操作,对关键的输入输出数据也可以一定程 度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 POC(Proof Of Concep t)原意是“为观点提供证据”。对于关键的技术或者 业务模型,论证需求、设

7、计的可实施性,评估和确认概念设计方案,POC的 评价可能引起需求和设计的调整。一般来说,进行POC的条件:1.论证业 务中涉及到的模型或者算法的可行性.2.论证技术模型实现的可行性、成本 用例(Use Case):对(软件)系统如何反应外界请求的描述,是一种通过用 户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景 说明了系统是如何同最终用户或其它系统交互(in terac t)的,也就是谁可以 用系统做什么,从而获得一个明确的业务目标.4。需求规则说明(SRS)制作:通过需求调查和初步的需求验证后,可以建立需求制 作的准则,包括确认需求规则说明(SRS)的内容、制作方法、制作

8、工具、质量标准等等. 根据需求制作的准则制作需求规格说明(SRS),好的需求规格说明(SRS)应该遵循正 确、无歧义、完备、一致、分级(重要性或稳定性)、可验证、可修改、可追踪的原则。5。需求确认:通过组织各级评审对需求分析阶段的产物,尤其最重要的结果产物需 求规格说明(SRS)进行确认,以确保相关人员理解一致.从评审方法来说,可以根据情况分 为需求开发组组内评审、客户外部评审、关键关系人评审等等。需求分析的流程往往因项目规模、作业人员、系统类型差异很大因此必须根据实际的 情况合理的裁减,以下举例几种不同情况下的具体流程:例:简明的需求开发的流程第1步:确定实现的目的、目标,基本业务需求、业务

9、定义以及相关的评审。从达到目的、目标的角度,重新评审业务定义,总结业务需求(确认客户实施的业务要 求)第2步:使业务具体化,进行软件系统的定义(系统需求定义)。从目的的角度,进行业务定义(功能,步骤),对系统结构进行讨论、对所要进行系统化 或计算机化的功能、流程进行定义。第3步:一边定义业务需求、系统需求、一边对运行上的相关要求(非功能需求)进 行总结运行时间,安全应对、访问权限等系统需求以及设计约束在业务需求的基础之上、考 虑系统上的限制条件之后逐步形成。例:软件工程类的典型流程主要特征:强调客户协同、提高运作效率、屏蔽技术风险、加强边界管控强调同客户协同,比如确定各种约定,包括截至时间、交

10、流方式、成果物;强调计划管控,起目的确保进度和成本,人力资源合理使用;采用问题回答管理票的方式加强需求团队以及客户的协同作业,提高生产效率,确 保质量;加强需求边界管理,控制项目整体成本;提前对技术关键环节(技术解决方案、技术构架)进行论证,控制技术风险减少技术 带来的成本损失;强调需求最终确认;案例3:软件产品类的典型流程主要特征:缩减开发周期、支撑跨部门运作、提高创造性、强调用户体验设计。强调计划性以加快研发进程,缩减产品开发周期。强调跨部门协调组织,建立统一的需求团队.强调行业学习、创新以及交流。分版本制作以适应产品的创造、快速变化、市场需求的适应性、进程以及成本控制。强调交互原型的重要

11、性,加强用户体验性设计。需求分析(二)内容需求分析阶段产物可以包括需求调查报告、需求规格说明、可行性报告等多方面的内容, 但是一般来说需求规格说明(硬件、软件)是最终的产物。过程中的关键产物还包括需求调 查报告.3。1需求调查报告通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅 记录等方式获取客户、用户各级组织对(软件)系统需求分析并识别客户以及用户的需 要、期望、业务要求,归纳整理后形成需求调查报告。需求调查常作为一个中间过程成 果,主要强调对业务、系统的现状进行归纳整理,同时对业务中的问题、各类期望以及优 化方案进行记录和整理,通过初步分析形成结构化描述。一般需求

12、调查报告包含目的、目 标、范围、业务域概述、组织机构以及对应的岗位权限、业务现状、业务优化的期望、业 务规则(算法、逻辑)、输入输出数据、其他系统的交互(如果有)等内容。1。业务领域业务领域主要梳理并整理项目的作业范围,同时在业务上进行梳理了解并描述各领域 间的关联。例 业务领域以及关联关系2。业务现状业务现状主要描述当前业务工作中的各种处理,可以通过业务流程描述(常见可以用泳道 图描述)、逐个业务场景描述、对系统功能需求描述、相关输入输出信息以及优化分析的 期望等几个方面进行描述如果原业务有对应的(软件)系统,也可以收集原系统的对应的 资料进行整理。1)业务场景描述:对业务工作中的每个处理进

13、行对应的描述,并通过记录和整理形成结构化的场景描述。场景描述一般包括定义场景的名称、场景相关的角色、场景 的详细描述、结果产出以及当前的存在的问题以及对应的期望。需要注意的是任何 系统的引入都会一定程度地改变当前的工作模式和工作方法,所以对当前的存在的 问题以及对应的期望的支撑程度往往决定了系统的价值,也必然是今后(软件)系 统的焦点。当然这些问题以及期望可以采用多种方式解决,比如通过管理制度的建 设、人员能力的加强、计算模型的优化、系统化(计算机化)等等。其实需求分析阶 段的主要工作就是识别、分析那些工作是可以系统化或计算机化的工作,并辅助制 度化管理流程、提高人员能力等工作提高作业的效率和

14、质量。例,一个移动终端希望 提高购物的便利性,哪些是可以系统化的呢?比如支付可以系统化做到移动支付, 同时第3方支付还需要法律的支撑等等.2)业务功能需求描述:结合业务场景对系统的业务功能进行描述。一般包括前置条 件、输入、输出、业务规则、典型动作等。业务功能需求描述着眼于使业务具体化, 进行(软件)系统的需求调查或定义,描述方法也更加的结构化这一步骤中,业务规 则是重要的核心,是业务场景中具体处理的细节要求,一般包括处理的详细流程、 关键数据的计算方法、样式要求等等内容。3)业务数据描述:对业务场景、业务功能需求中的输入和输出数据进行结构化整理的 过程多数新建系统,业务数据往往是分散和凌乱的

15、,通过这个过程需要对相关的数 据进行结构化的整理,并为后续的规格定义提供基础.4)其他:对业务现状整理过程,对一些过程性的资料比如原始的单据、表单通过扫描 等方式进行收集汇总。对原系统可以通过收集设计资料、屏幕截图等方式汇集整理3.2软件规格说明书(SRS)通过需求调查以及分析、需求验证环节等步骤,需求规格说明书使业务具体化,最终对 软件以及硬件系统的功能进行明确定义。需求规格说明(SRS)对功能进行结构化的描述, 以指导后续设计、开发、测试工作的开展。需求规格说明定义系统愿景、系统范围、业务 功能、系统功能、约束条件等方面的需求。主要描述系统“What to do”,而后续的设计要 描述系统

16、“How to do”。1。项目目标&系统范围项目目标&系统范围描述项目发起的背景、希望解决的问题、系统的目的和目标以及 核定项目的范围。一般可以包含以下内容项目背景(Project Background)、现状(Current Situation )、当前面临的问题(The issues we are facing now)、项目目的以及目标 (Objectives & Goals)、项目范围(Project Scope)、业务流程/功能范围(Business Process/Function Scope)、涉及组织范围(Organization Scope)。1) 项目目的以及目标(O bjectives & Goals)应着眼于(系统)未来的

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号