软件需求分析.pptx

软件需求分析;

教学内容

软件需求概述

架构师与需求

软件需求面临的主要困难

需求工程

需求获取技术

需求分类和结构化

需求建模

编写软件需求规格说明书;

需求确认

需求跟踪技术

需求变更控制;

软件需求概述

u经典的“四拍”

决策时拍脑袋——就这么定了

指挥时拍胸脯——保证没问题

失误时拍大腿——我怎么木想到

追查时拍屁股——老子不干了;

软件需求概述

u需求分析的重要性;

软件需求概述

u根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出;

软件需求概述

原因：需求不明确

FACT:软件项目中40%-60%的问题都是在需求分析阶段埋下的祸根，需求错误消耗整个项目预算的30%-50%

不充分的计划和过于乐观的评估

盲目采用新技术

管理方法缺乏或不恰当

团队组织不当

人际关系因素;

软件需求概述

错误的架构;;

软件需求概述 ;;

谁需要什么样的东西？

需求的内容;

软件需求概述

马斯洛人类需求层次理论;

需求的基本概念

IEEE(1997)

(1)用户解决问题或达到目标所需的条件或能力

(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力

(3)一种反映上面（1）或（2）所描述的条件或能力的文档说明

SommervilleandSawyer(1997)

需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。;

客户、最终用户间接用户

客户：客户是掏钱买软件的人，所以他是“上帝”。与客户打交道的主要目的是：一是获取需求，二是签订合同

最终用户：即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得

间接用户：重视“间接用户”，千万别“大意失荆州”;

需求的重要性

FrederickBrooks在他1987年经典文章《没有银弹》(NoSilverBullet)中阐述了需求的重要性：

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求。;

软件需求概述;

软件需求概述 ;

软件需求概述

需求分类;

义本身就是业务需求

背景描述：XX保险公司希望充分利用日益完善通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与同时，还要实现企部的即时通信。

业务需求/目标：通过该系统的实施，人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使业内部沟通效率

善，以帮助企业运转效率得以提高。;

描述用户使用产品要完成什么任务、如何完成的需求

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

用户有不同类型：;

软件需求概述

系统需求

从系统的角度来说明软件的需求;

功能需求

系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作

需求的主体，需求的本质

零散（需求项）整理（特性、用例）;

非功能需求

指产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。

设计约束

也称为“限制条件”或“补充规约”，通常是对解决方案的一些约束说明。例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。;;

架构师与需求;

架构师与需求 ;

架构师是客户需求和开发者之间的桥梁

架构师的工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划和文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划

架构师需要参与项目开发的全部过程，负责在整个项目中对技术活动和技术说明进行指导和协调

架构师的主要任务不是从事具体的项目程序的编写，而是从事更高层次的开发架构工作

架构师必须对开发技术非常了解，并且需要有良好的组织管理能力;

架构师与需求 ;

一线架构师的六个经典困惑

将系统划分模块，如何更合理？

大系统架构设计，如何起步？

总觉得需求很糟糕，影响了架构设计？

非功能需求是重要，但要如何设计？

架构新手：缺乏指导，架构设计不知所措。

架构老手：缺乏总结，仍“怕”下一个项目。;

把握需求特点，确定架构驱动力;

知识技能问题