1.1 需求问题的提出

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

  第1部分 原理、模型与误区  第1章 需求实践现状分析   1.1 软件项目失败的根源  

1.1 软件项目失败的根源

 1.1.1 chaos report 1994

1.不完整的需求                              
2、缺乏用户参与

3、资源不足                                 
4、不切实际的用户期望

5、缺乏执行层的支持                         
6、需求的变更频繁

7、规划不足                                 
8、提供了不再需要的

9
、缺乏IT管理                              10、技术能力缺乏

11、其他

 1.1.2 chaos report后续版本

  1.1.3 需求相关败因简要分析

败因

解决方案:

1 不完整的需求

采用业务导向让用户参与到完整性评价当中,在实际过程中利用树形层次结构将宏观信息与微观信息进行有效的剥离。

分析:

利用树形层次结构面向不同的层面:决策层,事务管理层,操作层,让合适的人验证相关的部分,这样可以有效的避免事不关己,高高挂起。让用户逃离无趣区和有效的启发用户的积极性,减少被专业人士排除在系统的完整性评价之外

2 缺乏用户参与

3不切实际的用户期望

由于软件的无形和成本的不透明,需要说明软件中不能完成的需求的原因

4 需求变更频繁

对变更进行分类,统计,有针对性的改进需求过程,提高设计的弹性

5提供不在需要的

找到用户经常使用到的功能,也即用户的需求,放弃用户很少使用的功能模块的开发

具体方案:在每个功能模块入口处,放置一个计数器

1.1.4 一幅漫画带来的思考

失败的原因

分析原因与解决方案

1 沟通失真

 

分析:

每个角色(如项目经理,商业顾问等)更加自己的特点和需求对信息(漫画)进行了不同程度的加工,从而导致信息内容有很大的变化

解决方案:

    1、
利用文档:防止信息在传递的过程中走样

    2、Reviews
(评审):在此审阅,需求人员在此用语言复述软件需求。

2、客户需求放大

分析:

1、客户希望支付的成本尽可能少,获得的效益尽可能多。

2、解决方案的选择权较给了不熟悉技术的客户。

解决方案1:

  1、需要提升软件估算实践的有效性

  2、提高产业成熟度

解决方案1:

   需求捕获的过程中多问为什么

3 项目经理的需求控制

分析:

需求捕获的过程中,导致需求产生了偏差,部分从技术的角度对需求进行了控制,造成无法对需求的有效理解

解决方案:

 
减少技术在需求提取过程中的不利影响

4分析人员的技术加工

分析:

   
分析人员对技术能力的追求高于业务能力的追求

 

解决方案:

    提高自己的业务分析能力

5 编码人员的断章取义

解决方案:业务场景是需求之魂

 

   
  

1.2 透过表象,分析本质

1.2.1 需求变更频繁

 1.2.2 上线阻力大

原因

解决方案

1 利益冲突

需求分析

2 工作量大

提高易用性、工作量价值化、将数据迁移,准备工作独立出来

 1.2.3 运行效果差

解决方案:从问题与机会入手,提高管理人员的推动力

         
从障碍和困难出发,解决操作人员的积极性

1.2.4 完全崩溃

  
分析:大多是由于忽略了非功能性需求(如:系统容量不足以支撑业务需求

  
解决方案:明确非功能性需求的特点,然后进行改进

1.3 方法论与需求工作

1.3.1 计算模式

如:C/S 与B/S

从用户的角度选取

1.3.2 软件工程方法论

 

方法论分两种:重方法和敏捷方法论

 

1.3.3 开发思想

1 成熟度

判断标准之一:见报率高,成熟度低

2 溯源

了解本质

3 了解局限性

了解局限性才不至于滥用,误用

1.4 小结

 

 

 

 

   

第2章 不同软件项目的需求视图

2.1 信息系统的需求视图

 

2.1.1 信息系统的本质与分类

信息系统的几个要素

1支持企业日常运作

 

2 支持解决问题

解决企业运作中存在问题的使命

3支撑决策

加工处理数据

信息系统的本质

 

1 数据信息化

通过对数据的有效处理,从而得出对人们更有价值的信息

2 信息系统的类别

联机事务处理系统(OLTP)—数据的生产者

管理信息系统(MIS)—数据的消费者(企业、组织中层管理者用于处理事务)

主管信息系统(EIS)–数据的高级消费者(企业中的高层管理者用于决策)

决策支持系统(DSS)—数据的高级消费者(中层管理者)

专家系统—-对个人知识的沉淀,同时也是数据的消费者

办公自动化系统(OA)—-对沟通和协作的支持

2.1.2 联机事务处理系统——流程电子化

电子化流程的好处

1、有利于流程的固化

2、对业务产生一定的约束

2.1.3 管理信息系统——数据信息化

1报表需求何时开始分析

(1)OLTP是数据的生产者,MIS是数据的消费者

报表的数据从OLTP中来,传统需求实战中,我们却经常先分析业务功能性需求,在分析报表类需求,此时我们根本不了解消费者需求是就确定了生产者的需求,显然是一种草率的态度。

解决方案:

 
从管理场景入手,从理解报表的目的着手就能更好地完成与用户的沟通,而且也更加的高效。

    报表需求的要点:

Why

目的

从管理场景出发,借助对管理控制点的理解来理解报表的目的

使用部门/职位

了解使用者

相关场景

如用户数量

What

关联实体

以类图或E-R图说明数据的来源

关键指标及计算规则

细化推导出关联字段,以及派生属性的基本方法

How

展现形式

以虚拟窗口等形式

输入输出需要

说明是否打印,格式等

2 解析报表的分类

1事务类

2 决策类

 

2.1.4 其他信息系统

1决策支持系统

 

1、结构化问题:

利用历史积累经验,如安全库存量,现金流预警。可以建立模型利用计算机直接计算出来。

2、非结构化问题;

如广告投放,产品定位等问题都没有现成的模式可以依赖

2 专家系统

个人知识转化为企业知识

3办公自动化

协同信息化

2.1.5 信息系统的多维视图

 

 

信息系统多维视图

人员角度

数据角度

过程角度

接口角度

系统所有者

业务实例和规则列表

 

业务知识

业务功能和事件列表

 

业务功能

业务地点和系统列表

 

业务地点

系统用户

E-R图

 

数据库需求

数据流图和业务流程图

 

过程需求

上下文范围图

 

接口需求

设计人员

逻辑视图

 

数据库模式

流程图、类图、活动图

 

过程需求

接口规范

 

接口说明

开发人员

数据库程序

应用程序

接口程序

 

 

 

 

 

 

 

 

 

2.2 嵌入式系统的需求视图

  2.2.1 面向直接用户的嵌入式系统

 

  2.2.2 面向特定设备的嵌入式系统

2.3 软件产品的需求视图

1 信息类

 

(1)、目标市场分析

1、目标客户分析

2、竞争对手分析

3、商业模式分析

(2)、产品体系设计

信息系统类软件产品的需求重点在于针对不同目标客户群体的不同商业模式分离变化点,经常需要减出通用性,在通过插接解决扩展性

工具软件类

对现实世界中某种工具的仿真,例如计算器,便签

  2.4 小结

 

 

 

 

 

 

 

 

 

 

第3章 软件需求与需求工程

 3.1 什么是软件需求

定义

业务知识+问题列表+其他因素

 3.1.1 需求的三个层次

1业务需求

定义:软件系统的建设目标。

需求定义的产物

也就是反映企业/组织对软件系统的高层次目标要求:

1、问题:解决企业运作过程中遇到的问题,如物资供应脱节、用户投诉量大

2、机会:抓住外部环境所带来的机会,以便为企业带来新的发展,如电子商务,网上银行

业务需求应该在项目立项的时候整理。

2用户需求

定义:用户使用软件需要完成什么任务,怎么完成的需求。

需求捕获的产物

通常在业务需求定义的基础上进行用户的访谈,调查,对用户使用的场景进行整理,从而建立用户角度的需求。

1、零散;用户提出不同角度,层面,粒度的需求

2、存在矛盾:用户在企业中的不同层面导致对系统的需求不同

3 软件需求

需求分析与建模的产物

 3.1.2 需求的三种类型

1功能需求

以系统→子系统→模块→子模块方式组织

2 非功能需求

常见的问题:是什么

保证信息的有效传递和注意局限性

1、信息传递的无效性,如高可靠性,扩展性

2、忽略了非功能需求的局部性,如查询时间<10s

3 设计约束

1非技术性因素决定的技术选型

如:采用VC++平台

2预期的软硬件环境和使用环境

实现技术受环境的影响如内存大小,海上使用

 3.1.3 优秀需求的标准

1完整性

定义:需求没有遗漏,也就是说在需求变更中新需求都是因为外部环境的变化而产生的且所占量小

(1)用户才是验证需求完整性的合适人选

为了保证需求的完整性,就必须从业务角度来组织各种需求项,让用户验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤、困难与障碍点是否完整,更具操作性。

步骤:验证主题域-》中层-》操作层

2不失真

1、正确性

2、无歧义性

3有优先级

1优先级有不同角度

 

2必要性是优先级评价的盲区

必要性只是对优先级的补充

分析:优先级常从充分性来考虑的,这样会导致忽略了需求的必要性。利用满意(反映需求的充分性)\不满意(反映需求的必要性)模型来防止需求的蔓延。

4有技术早期介入

1、可行性;就是指需要让开发团队早期介入,对需求中描述的解决方案进行评价。重点在需求项及复杂的解决方案

2、可验证性;说明需求规格说明书应该能够指导测试活动,也提供了验证所需的信息。

3.2 需求工程解析

 3.2.1 需求工程的范畴

1、需求开发:收集、分析、整理、编写、验证

2、需求管理:对需求的实现变化进行追踪的全过程,重点在于确保开发的软件满足这些需求

需求开发的三次循环

循环

工作任务

对应的

RUP阶段

初始循环

明确项目目标与范围,完成子系统划分及相关内容和接口

初始阶段

脉络循环

通过对每个 业务事件进行流程分析、业务实体分析,并表示出所有用例

细化阶段的第一迭代

细节循环

对每个用例的细节进行分析,包括事件流,用户界面原型

细化阶段的第二次迭代构建阶段

 

 

 

分析说明:

1需求获取

需求的捕获,它们都是主动词,而现实的需求实践中最大的问题是比较被动的。主要体现在:

1、捕获范围不足(对业务知识的不足)

2、缺乏计划性(预先对问题、时间、采访对象没有计划)

3、缺乏科学性(如宏观与微观问题混在一起)

4、捕获对象不明确(很少主动寻找合适的被访者)

5、捕获手段不足(对场景不同时需求的捕获缺乏)

2需求分析

1需求分析是什么

定义:

1、需求分析是业务分析

2、需求分析是一种分解活动

3、需求分析是一种提炼与整合活动

4、需求分析是一种规格化活动

 

2内容与形式

分析是任务,建模时手段,利用建模可以用图形代替文本,以更加可视化的方法表示信息,产生的结果并不一定非得是规范性很高的模型

建模的主要要点:

1、尽可能进行团队建模

2、大胆使用草图建模

 

3何时开始与结束

迭代式需求分析:

1、分析活动逐渐从本质需求过渡到边缘需求

2、RUP中的细化阶段是需求分析活动最密集的阶段

3、到了RUP中的构建阶段,需求分析活动将逐渐减少

3编写规约

良好的源代码和注释就是最好的文档

软件规格说明书应具有:

1、共享;可获得(软件开发团队可以在开发需要时获得最新版本的规格说明书),可获知(利用开发模板确保软件需求说明书的读者知道自己需要的信息在哪些章节)

2、更新;专人更新(按不同章节指定更新人),写作风格(确保一类信息只在一处描述)

4需求验证

需求验证的关键手段:评审

主要要点:分层次、分内容进行验证

 3.2.3 需求管理工作要点

需求管理项之间的关系

 

1统一、明确的需求项划分标准

成功的划分满足以下条件:

1、粒度均匀(如每个需求项的大小相当,即工时相当等)

2、大小合适(如每个需求项工作量以周为单位)

3、完整(最低一级的需求项应该涵盖所有的开发任务)

2 引入基线管理

 

 

每次迭代都是一个小型的瀑布型生命周期;通过这样的分解,整个开发工作就被划分成了多个小项目,这种模式更容易使开发人员保持良好的工作节奏。

在划分基线是,通常需要完成三个方面的事情:

1、确立优先级;确保高优先级,高风险的需求项在尽早的迭代中完成;

2、工作量估算;确保每次迭代的时间安排是紧凑的

3、未完成项的合并

3引入变更管理

客观存在的需求变更是引入变更管理成为必然

就需求管理而言主要完成:

1、业务影响分析:

从业务角度对变更的合理性、优先级以及对原有需求的影响进行分析,确定优先级

2、技术影响分析:

从技术角度对变更的影响范围、工作量进行分析,并决定是拒绝、在后续还是在本次的迭代中进行响应

3、项目影响分析:

基于前面的工作量分析,考虑是否对整个项目的时间、进度、成本产生较大影响

4引入需求跟踪

引入需求跟踪能精确地评价在变更的影响分析过程中变更将影响的哪些需求项、哪些设计元素

 3.2.4 需求分析人员的技能组成

1需求分析人员的来源

1、开发人员;2、用户;3、领域专家

2各种能力培养的要点

 

 3.2.5 seru模型概述

 

 3.3 小结

 

 

 

 

 

 

 

 

五个与需求有关的败因描述:(1)不完整的需求(2)缺乏用户参与(3)不切实际的用户期望(4)需求变更频繁(5)提供了不再需要的需求

 

1.2 不同项目的需求视图

软件需求分析的任务是:深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素的接口细节,定义软件的其他有效性需求,借助于当前系统的逻辑模型导出目标系统逻辑模型,解决目标系统“做什么”的问题。

不同的软件项目具有不同的特点,这对需求也带来了影响,在此主要从信息系统、嵌入式系统、软件产品等不同角度说明如何进行相关的需求工作

 

(1)信息系统的需求试图(2)嵌入式系统的需求试图(3)软件产品的需求试图

需求分析可分为需求提出、需求描述及需求评审三个阶段。

1.3 需求的定义

 

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。经过与客户的多次交流,并且收集、协商、修改产品需求后,软件开发人员将用户提出的要求变成软件需求,软件开发人员将在此基础上成功的开发软件系统,使其与用户最终的要求相适应

需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域,并定义一个描述该问题的系统。这样的定义称作系统规格说明,并且它在用户和开发人员之间充当合同。

1.3.1几种主要的需求定义

 

1.3.2需求定义的一些基本原则

在问题分析阶段分析人员的主要任务是:对用户的需求进行鉴别、综合和建模,清除用户需求的模糊性、歧义性和不一致性,分析系统的数据要求,为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来,以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求,哪些是用户尚未提出但具有真正价值的潜在需求。

(1)并没有一个清晰、毫无歧义的“需求”术语的存在,真正的“需求”实际上在人们的脑海中(2)定义问题,而不是解决问题(3)定义系统,而不是项目(4)区分正式和非正式部分(5)避免重置(6)保持每个需求定义的大小在合适的范围是良好的做法

 

1.3.3优秀需求的特征

在需求评审阶段,分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核,以确保软件需求的完整、准确、清晰、具体,并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点,必须尽快更正,再行检查。

(1)完整性(2)正确性(3)无歧义性(4)可行性(5)有优先级(6)必要性(7)可验证性

 

1.4 需求定义的实践

软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解,
使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:
1 引言
1.1编写目的
  说明编写这份软件需求说明书的目的,指出预期的读者。
1.2背景 
  说明: 
  a.待开发的软件系统的名称;
  b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
  C.该软件系统同其他系统或其他机构的基本的相互来往关系。 
1.3定义
  列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料 
  列出用得着的参考资料,如:
  a.本项目的经核准的计划任务书或合同、上级机关的批文;
  b.属于本项目的其他已发表的文件;
  c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2 任务概述
2.1目标 
  叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2.2用户的特点 
  列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2.3假定和约束
  列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
3 需求规定
3.1对功能的规定
  用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。 
3.2对性能的规定
3.2.1精度 
  说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
3.2.2时间特性要求 
  说明对于该软件的时间特性要求,如对:
  a.响应时间;
  b.更新处理时间;
  c.数据的转换和传送时间;
  d.解题时间; 等的要求。
3.2.3灵活性 
  说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
  a.操作方式上的变化;
  b.运行环境的变化; 
  c.同其他软件的接口的变化;
  d.精度和有效时限的变化; 
  e.计划的变化或改进。 
  对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求
  解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.4数据管理能力要求 
  说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。 
3.5故障处理要求
  列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
  如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。 
4 运行环境规定
4.1设备 
  列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
  a.处理器型号及内存容量;
  b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
  c.输入及输出设备的型号和数量,联机或脱机; 
  d.数据通信设备的型号和数量;
  e.功能键及其他专用硬件
4.2支持软件 
  列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。
4.3 接口
  说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制 
  说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源

1.4.1 需求定义任务概述

要想建立起清晰的项目目标,需要注意一下两个方面:(1)内部寻根(2)外部溯源

1.4.2问题分析五步法

(1)在问题定义上达成共识(2)分析问题背后的问题(3)确定相关人员和用户(4)定义解决方案的界限(5)确定加在解决方案上的约束

1.4.3需求定义的要素

问题定义的要素包括:目标、范围、相关人员与用户、相关事实与假定

1.4.4需求定义的范围

1.5需求的层次和分类

软件需求的层次:业务需求、用户需求、功能需求

(1)业务需求:代表了需求链中的最高的抽象,它为软件系统定义了项目视图和范围,反映了企业/组织对软件系统的最高层次目标要求

(2)用户需求:用户使用软件需要完成什么任务,怎么完成的需求

(3)功能需求:对用户需求进行分析,提炼,整理,因为用户需求具有林三、存在矛盾的特点。功能需求必须根据用户要求来考虑,且要与业务需求所设定的目标相一致

1.5.2 软件需求的分类:功能需求 非功能需求 设计约束

(1)功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求

(2)非功能需求:作为功能需求补充的非功能需求,它描述了系统展现给用户的行为和执行的操作。包括外部界面的具体细节、性能及质量属性。

(3)指对开发人员在软件产品设计和构造上的限制,产品必须遵从的标准、规范、合约。包括:非技术因素的技术选项,预期的软硬件环境和预期的使用环境。

1.6需求分析与其他软件项目过程的关系

1.6.1 软件的生命周期

软件开发的共有阶段:(1)问题定义和可行性研究(2)制定开发计划(3)需求捕获(4)分析(5)设计(6)规范(7)实现(8)测试(9)部署(10)维护

1.6.2需求与其他软件项目过程的关系

需求分析在系统开发的整个生命周期中处于基础、最重要的位置。需求分析用于软件项目的初始阶段,他的结果接着用于开发的下一阶段即设计阶段。

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注