软件需求分析

概述

夫风者生于地，起于青萍之末，止于草莽之间。捕风者弄潮儿一叶知秋乘风破浪。

需求分析就是分析软件用户的需求,解决”做什么”的问题。在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。

在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。

使用PowerPoint作原型设计

PowerPoint 原型制作 UML建模

1.为什么要需求分析

需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发forwindows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.

需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.

2.什么是需求分析

什么是需求分析,上面已经提过,简言之就是分析软件用户的需求,细致的进行调查,把用户”做什么”的要求最终转换为一个完全的,精细的软件逻辑模型,并些出软件的需求规格说明,准确地表达用户的要求.

3.需求分析的任务

简言之,需求分析的任务就是解决”做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.

4.需求分析的过程

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.

问题识别:就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.

分析与综合:逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).

制订规格说明书:即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.

评审:对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

5.需求分析的方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.

原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.

原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.

原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

在使用原型化方法是有两种不同的策略:废弃策略,追加策略.

废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。

追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

软工十天入门（2）–需求分析

http://www.clinux.org/forum/showthread.php?threadid=133

怎样做需求分析（一）

http://tech.ccidnet.com/pub/article/c291_a22188_p1.html

轻巧建模之需求篇

http://www.sawin.com.cn/doc/SA/Requirement/easyreq.htm

软件建模与分析

[[需求分析]]选种生根，[[UML建模]]，

* 建模基础

o 建模原则（如分解、抽象、泛化、投影／视图、明示、形式化方法的使用等）

o 前置与后置条件、不变量

o 数学模型和规格说明语言简介

o 建模语言的属性

o 语法和语义

o 明示（排除假设，或说明所有假设）

模型类型

o 信息建模（如实体关系图、类图等）

o 行为建模

+ 结构化分析

+ 状态图

+ 用例分析

+ 交互图

+ 故障模式和影响分析

+ 故障树分析

o 结构建模

o 领域建模

o 功能建模

o 企业建模

+ 业务流程

+ 组织结构

+ 目标

o 嵌入式系统建模

+ 时序分析

+ 外部接口分析

o 需求交互分析

+ 特征交互

+ 质量审议

+ 视点分析

o 分析模式

+ 问题框架

+ 规格说明复用

分析基础

o 完善性分析

+ 完整性

+ 一致性

+ 鲁棒性

o 正确性分析

+ 静态分析

+ 仿真分析

+ 模型检查

o 非功能性质量需求分析

+ 保险度

+ 安全性

+ 可用性

+ 性能

+ 根源分析

+ 可靠性

+ 可维护性

o 优先级确定、折衷分析、风险分析和效果分析

o 可追踪性

o 形式化分析

需求基础

o 需求定义

+ 产品

+ 项目

+ 限制

+ 系统边界

+ 外部

+ 内部

o 需求过程

o 需求的层／级

+ 需要

+ 目标

+ 用户需求

+ 系统需求

+ 软件需求

o 需求特性

+ 可测试性

+ 无二义性

+ 一致性

+ 正确性

+ 可理解性

+ 可追踪性

+ 优先级

o 管理需求变更

o 需求管理

+ 一致性管理

+ 发布计划

+ 复用

+ 可追踪性管理

o 需求和体系结构之间的交互

o 需求与系统工程、人性化设计等的关系

o 缺陷问题

+ 病态结构问题

+ 多重方案问题

o 作为限制的COTS

获取需求

o 获取来源

o 获取技术

+ 访谈

+ 问卷调查

+ 原型

+ 用例

+ 观察

+ 参与技术

o 高级技术

+ 人文

+ 知识获取

需求规格说明与文档

o 需求文档基础

+ 类型

+ 受众

+ 结构

+ 质量

+ 属性

+ 标准

o 软件需求规格说明

o 规格说明语言

+ 结构化描述

+ UML

需求验证

o 评审和检查

o 原型验证

o 确认测试设计

o 确认产品质量属性

o 形式化需求分析

How to create a RePast modelRepast3?.0发布了,现在支持Java Python DotNet?三种编程接口.

多主体建模软件现在已经呈现百花齐放的兴盛局面,有人专门比较了16种多主体工具软件的使用,这种局面一方面说明这方面研究的兴旺,但另外一方面也让原初实现一个公共的统一的交流范式的希望越来越远,如何选择一个真正有前景的最终成为大众化的标准模型平台:Swarm?架构显得太重了点,且初学者也难以掌握,虽然现在仍然有许多人在支持,在发展.Ascape?看上去很好,逻辑很清晰,但现在却很缺少支持,而且很久没更新了,也不是开放原码. Starlogo?太简单了,不能完成实际的并行主体

Repast现在有越来越多的人使用和热心的团队支持,而且其提供的多种应用开发接口也满足不同技能的人的需求,从最简单可爱的Python,到大众流行的Java,到微软系统的忠实用户们喜欢的DotNet?(C++,ASP,C#)甚至Lisp.Prolog等用户,都可以选择自己熟悉喜爱的方式,以统一的逻辑来设计模型.因此,我看好Repast!

参见

《UMLChina讲座全集》2010[压缩包]|]] [[http://www.360doc.com/content/08/0517/10/64176_1265249.shtml|Rational Rose、PowerDesign、visio的比较|]] [[http://www.smashingmagazine.com/2011/02/25/why-wait-for-the-opportunity-create-your-own/|Why Wait For The Opportunity? Create Your Own!|]] [[http://linux.solidot.org/article.pl?sid=10/04/06/1510202&from=rss|Prefab让封闭软件看起来很开放|]] [[http://www.tianya8.net/2009/10/10.html|10款交互设计原型开发工具|]] [[http://www.tianya8.net/2009/09/blog-post_25.html|不要战斗，要协作|]] [[http://ued.taobao.com/blog/2009/10/20/tansuan15-2/|设计师挖掘用户需求浅谈【碳酸饮料会】|]] [[http://myhaha.net/?p=98|原型的使用]] [[http://www.seekui.com/xui/blog/article.asp?id=54|软件产品界面设计知识]] [[http://www.seekui.com/xui/blog/article.asp?id=34|软件产品界面不是艺术作品]] [[http://dev.csdn.net/article/72/72777.shtm|WEB交互界面易用性设计和验收的指导性原则]] [[http://www.seekui.com/xui/blog/article.asp?id=38|产品规划和设计文档示范:User Needs Docs 用户需求文档]] [[http://www.seekui.com/xui/blog/article.asp?id=47#1|用户体验研究人员需要掌握的研究方法]] [[http://www.adobe.com/devnet/fireworks/articles/demo_current_document_command.html|Exploring the Demo Current Document command in Fireworks CS3使用 Fireworks CS3 插件将设计稿变成可以全屏播放的 Flash 幻灯片 ]] 用FW做原型? [[http://www.seekui.com/xui/blog/article.asp?id=47|用户体验研究人员需要掌握的研究方法[转]

关于软件原型方法若干问题的讨论

进行 Web 界面原型设计的一种方法

左七右九的RUP2003文档迷宫口诀

2、去之前赵晨发给了我大致的讨论提纲。咣当了好几下~

说实话，我是硬着头皮去的，因为对于我这个非科班出身的人来说，提纲上的每个讨论话题都可以著书立传。

不过，实际的讨论中其实并没有那么学究。大概也是因为大家受了点我这种野里夜气的影响 :） 3、期间，赵晨介绍了IBM那边对于“可用性”、“UCD”、“用户体验”的定义：（大意）可用性是指标、用户体验是目标、UCD是思想和信仰。

这句话值得不少人记住。

4、研究的方法有很多种，也可以非常灵活和具备技巧性；但“设计”其实是难度最大也最重要的环节。

从一开始的概念讨论，就有人不断的忍不住问：“那么，如何设计用户体验呢？” 5、后面讨论到这个话题的时候，我介绍了我这边的互联网产品常见做法： 1》划分用户群。

什么样的人群我主要服务。什么样的人群我不服务。通常我没法去设计一个8到80岁都适应的产品。 2》做一个典型用户。