您的位置：首页 > 其它

软件需求分析学习笔记

2011-01-06 10:02 183 查看

第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 小结

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航