-
需求分析与定义：做什么
可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么，不做什么”。
< br>即使可行性分析是客观的、
科学的，
但决策仍有可能是错
误的。
因为决策者是人，
人会冲动，有赌博心态。如果可行性分
析表明做某件事的成功率是
10%
，失败率
是
90%
，倘若该事情的意义非常大，决策者也许会一拍脑
袋：“豁出去，干！”
于是这世界就多了一份极喜与极悲。
4.
1
节讲述可行性分析的四大要素：经济、
技术、社会环境和人。
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通
< br>常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，
这在使用实例或方
案脚本中予以说明。
·功能需求——定义了开发人员必
须实现的软件功能，
使用户利用系统能够
完成他们的任务，从而
满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，
它包<
/p>
括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
·需求分析报告——
报告所说明的功能需求充分描述了软件系统所应具有
的外部行为。“需求分析报告”在开
发、测试、质量保证、项目管理以及相关项
目功能中起着重要作用。
下一层次需求——用户需求，
必须从使用产品的用户处收集。
因此，
这些用户
构成了另一种软件客户，
他们清楚要使用该产品完成什么任务和一些非功能性的
特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好
地接受具有该特点的软件产品。
软件需求包括三个不同的层次—业务需求、
用户需求和功能需求—也
包括非
功能需求。业务需求
( business requi
rement)
反映了组织机构或客户对系统、
产品高层次的目
标要求，
它们在项目视图与范围文档中予以说明。
用户需求
(user
requirement)
文档描述了用户使用产品必须要完成的任务，这在使用实例
(use
< br>case)
文档或方案脚本
(scenario)
说明中予以说明。功能需求
(functional
requirement)
定义了开发人员必须实现的软件功能，使得用户能完
成他们的任
务，从而满足了业务需求。所谓特性
(featur
e)
是指逻辑上相关的功能需求的集
合，给用户提供处理能力并
满足业务需求。
业务需求、用户需求、功能需求，这三者之间
，并不是完全并列的关系，而是在
逻辑上有着从外到内、从整体到细节的深入和细化的关
系。
比如：要设计一个系统
-
电视机，（这玩意儿大家都清楚是干么的吧，
8)
）
1
。
业务需求：
为用户提供看电视的服务
。请注意，是服务，是用从外部的眼
光，全局的性看这一需要实现的东东。
2
。
用户需求：
为了让用户能够看到电视
节目，需要提供：接受电视信号、显
示到屏幕、
可以换台等。<
/p>
这些内容都是为业务需求服务的，
也是为了能够看到电
视节目所必不可少的。即，用户需求，是业务需求的深入和细化。
3
。
功能需求：
对用户需求的内容进一步
细化：如何才能提供接受电视信号的
功能？
答：需要有信号接收器，并进行信号变化处理。
软件需求规格说明还应包括非功能需求，
它描述了系统展现给用户的行为和执
行
的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性
能要求；
设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产
品设计和构造上的限制。
质量
属性是通过多种角度对产品的特点进行描述，
从而
反映产品功能
。多角度描述产品对用户和开发人员都极为重要。
作为补充，
软件需求规格说明
还应包括非功能需求，
它描述了系统展现给用
户的行为和执行的
操作等。
它包括产品必须遵从的标准、
规范和合约；
外部界面
的具体细节；
性能要求；
设计或实现的约束条件及质量属性。
所谓约束是指对开
发人员在软件产品设计和构造上的限制。
质量属性是通过多种角度对产品的特点
进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
< br>
值得注意的一点是，
需求并未包括设计细节、
实现细节、
项目计划信息或测
试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
需求分析与定义
1.
软件需求：
软件需求分为三大部分：
I
．
功能需求：
指系统需要完成那些事情，
即向用户提供那些功
能。
II
．
非功能需求：指产品所具备的品质和属性，比如可靠性、扩展
性、响
应时间、性能等等。。。
III
．
设计约束：也称条件约束、补充规则。比如用户要安装该产品
他需要有
什么样的必备条件。（系统对操作系统的要求、硬件环境的要求等
等?..）
2.
需求调查与问题定义：
在做需求调查
时需要做到两
W
一
H
< br>即
What
、
Where
、
How
I.
应该收集什么信息
What-----
II.
从什么地方收集
Where----
III.
用什么机制或技术来收集
How-------
3.
需求分析
需求分析通常包括七个方面：
I
．
绘制系统上下文范围关系图：
主要用于定义系统与系统外部
实体间的界限和接口的简单模型，他可以为需求确定一个范围。其实就是
DFD
的
0
层图。
II
．
创建用户接口原型：
这里我们可以把他看成是用户操作的一个<
/p>
雏形，
什么意思呢就是我们通常所说的界面用户通过一系列的操作
完成他想达到
的效果的接口。
III
．
分析需求的可行性：这个需求我们应该用什么技术解决，他实
现后的性
能怎么样，
是否与其他需求相重合或是矛盾，
这里一定要注意不
要把系
统的这个需求怎么用代码实现想进去。
在需求分析时应多
注意需求本身是否有用
不必考虑怎么实现
IV
．
确定需求的优先级：可采用满意度
/
不满意度指
标来说明（满意
度
1-5
表示当需求被实现时用户的满意程度；不满意度取值同理）
V
．
为需求建立模型：
这里可以用
UML
创建用例图或是
E-R
图再加
上少量的文字描述。
VI
．
使用质量功能调配（
QFD
）：这里我的理解是
分析员根据需求的
理解发现隐藏需求而这些需求是用户也没有想到的需求，
系统实现后会给用户一
个惊喜，而没实现用户也不会有抱怨。
4.
需求分析方法
现在比较流行的软件需
求分析方法有
4
种，其中
3
种理论比较成熟
I
．
结构化分析方法（
Struetured
Analysis,SA
）：这个大家想
必很熟悉了不在复
述。
II
．
软系统方法：
这只是过度性的方法论他的出现只是证明结构化<
/p>
分析方法的一些不足。
因为结构化分析方法采用的相对形式化的模
型不仅与社会
观格格不入，而且在解决“不确定性”时显得十分无力。
< br>
III
．
面向对象分析方法（
Object
Oriented
Analysis
，
OOA
）：这也
是我下文想讲的分析
方法
IV
．
面向问题域的分析
（
Problem
Domain
Oriented
A
nalysis,PDOA
）
：
OOA
也存在着很多不足，但
PDOA
现在正
在研究中所以未被广泛应用
这里需要注意的是：
在软件开发中有很多需求分析方法他们没有好坏之分只要你
运用得当照样可以
做出一个很好的系统，
依据个人对某个方法的理解用自己最擅
长
的方法是最明智的选择。
5.
面向对象需求分析（
OOA
）
面向对象这个概念很简单但也很复杂我在这里不做深入探讨。
我
将从实际出发来
和大家一起探讨下在实际开发中我们应该怎么做。
OOA
的精髓在于世间万物均为对象采用
< br>OOA
方法在整个过程中包括
2
个工作任
务：
建立一个反应问题域静态关系的概念模型，
就是我们通常所说的类图；
另一
个反应系统行为的动态模型，即用例模型
那么我们在实际开发中到底怎么做呢？
1
）建立域模型
I
．
寻找类：在寻找类时有多种方法典型的是根据需求文档用
“名词
动词法”来寻找，
找出备选类后再从中寻找出真正的类。
（注意
在用此方
法时切记不要咬文嚼字专牛角尖在这里花费很长的时间）
II
．
确定类之间的关联：
这个过程是迭代的我们需要理清楚这些类<
/p>
之间的关系如关联、
继承、
聚合等然后通
过
UML
记录下来。
类之间的关系不是
一
下子就能确定下来的是要慢慢完善的
III
．
为类添加职责：这里就可以理解成为类添加所需要的属性和方
法。
IV
．
域模型的详细度：
这里不做太多要求可以写的很详细也可以写的
简单写，可以把握好一个原则：只要能有利于团队更好的开发就是好模型。
2
）建立用例模型
I
．什么是用例：
<
/p>
用例实例是在系统中执行的一系列动作，
这些动作将生成对特定参
与者可见的价
值结果。（用例实例就是常说的“使用场景“）一个用例定义一组用例实例
。
II
．识别参与者：
用例主要是为了
让客户直观的理解需求那么这里参与者是必不可少的这样才能
形象的勾画出系统某个特定
场景下的流程。
注意参与者不仅可以是人也可以是其他的事物
如
（其他系统、
硬件设备、
时钟等
等）
III.
合并需求获得的用例
IV
．绘制用例图（如果对用例图不清楚请参考
UML
相关文章）
V
．细化用例描述
用例描述可以包括以下几个部分：
u
用例名称
u
简要说明
u
事件流：是该用例要完成的工作步骤
u
非功能需求
u
前置条件
u
后置条件
u
扩展点
u
优先级别
3
）
要想做好需求分析光上面的用例是不够的还
有写建模技术也要有如：
协作图、
顺序图和状态图
u
协作图：
是一种用以显示对象如何被协调在一起执行用例的图，
用来识
别协作完成给定业务的对象。
u
顺序图：
是一种用以显示用例对象之间消息顺序的图，
他与协作图表达
的信息是一样的知识显示的方式有差别。顺序图以图形化的方式强调消
息的顺
序，而非协作对象间的顺序。他和协作图统称为交互图。
u
状态图：是一种用以显示对象在生命周期和转换期情况的图
什么是优秀的需求
讨论软件需求的文章有很多，
对于需求的标准也不尽相同，
这里我想用
NASA
的软件开发过程中的概念，软
件需求过程的标准是：清楚
(Clear)
、完整
(Complete)
、一致
(Consisten
t)
、可测试
(Testable)
，
此外还有其他的概念，如
可跟踪的、可修改的等等。
清楚：
目前大多数的需求分析
采用的仍然是自然语言
（因为如果采用形式化
语言的话，
和用户的沟通将成为一个大问题，
这意味着客户在开发软件之前必须<
/p>
先进行形式化语言培训，
这是不现实的）
。
自然语言对需求分析最大的弊病就是
它的二义性。
所以我们不得不对需求分析中采用的语言做某些限制。
例如尽量采
用主语＋动作的简单表达方式。
说白了，
需求分
析中的描述让人看上去像是刚学
习写作的小孩子就对了，千万不要采用疑问句、修饰这些
华丽的表达方式。
除了语
言的二义性之外，
主意不要使用行话，
就是计算机术语。
需求分析最
重要的是和用户沟通，
可是用户多
半不是计算机的专业人士，
如果在需求分析中
使用了行话，就会
造成用户理解上的困难。
打个比方，
如果你要做一个银行的信用卡系统，
你就可以这样描
述软件需求：
银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额
。一
张信用卡有多笔的交易记录。
完整：
再也没有什么比软件开发接近完成是发现遗漏了一项需求
更糟的事情
了。
需求的完整性是非常非常重要的，
想象一下遗漏需求而不得不返工，
这简直
就是恶梦。
可是令人遗憾的是，
需求的遗漏是很经常发生的事情，
不仅仅是你的
问题，
更多的问题发生在用户那里
，
他们不知道该做些什么。
要做到需求的完整
< br>性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，
从
最初的计划制定到最后的需求评审。
至于完整性的详细讨论，
我
们会在下面的
章节中讨论，
现在你只需要拼命的想象缺乏完整性
的坏处，
直到你出了一身的冷
汗。出了吗？好，那我们继续。<
/p>
一致：
一致性也是一个比较大的概念，
很难用几句话讲清楚。
还记
得我们在
开始的时候提到的需求的层次吗？简单的来说，
就是用
户需求必须和业务需求一
致，
功能需求必须和用户需求一致。<
/p>
严格的遵守不同层次间的一致性关系，
就可
以保证最后开发出来的软件系统不会偏离最初的实现目标。
在实现过程中，
我们
还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。
可测试：
大家觉得一个项目的测试
从什么时候开始呢？有人说从编码完成后
开始。
更清楚一点的说
是编码的时候同时进行单元测试，
编码完成后进行系统测
试。<
/p>
这些都没有错。
但是实际上测试是从需求分析过程就开始了。
需求分析是测
试计划的输入和参照。
这就要
求需求分析是可测试的。
什么是可测试呢？“我们
要用新的系统
完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不
是，
报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。
因此
这项需求是无法测试的，
就是不具有可测试性
。
说到这里，
大家可能就会明白之
前的
需求的几项标准都是为了保证需求的可测试性的。
事实就是这样，
只有系统
的所有需求是可以被测试的，
才能够保证软件始终围
绕着用户的需要，
保证软件
系统是成功的。
大家真正在应用一些科学的方法的时候也应该记住，
任何的方法
都是为了保证软件的成功，不要偏离这个目标，千万不要走火入魔了，呵呵，很
容易
的。
需求分析是对用户需求的真正明确，
< br>是对要解决的问题的彻底理解。
在解决问题
之前要理解问
题，
只有真正的理解问题才能更好的解决问题。
需求分析就是给
系
统分析、设计人员一个和用户交流来理解问题的机会—了解用户究竟需要什么。
需求分析也是一个建模的过程，
与在概要设计中建模不同在需求分析中建模是面
向用户的过程。
而在概要设计中的建模过程是面向开发人员的过程。
这样两种建
模的过程就会存在差异和不同，
从而使用自然语言进行描述也就不同。<
/p>
在传统的
软件工程中并不建议大量的使用自然语言对软件的需求进
行描述，
因为太多的自
然语言会引发出很多问题。
比如说，
二义性即不同的人对自然语言的描述会有不
同的理解，
就是再好的文档编写人员也不会保证他的文档不存在二义性。
毕竟我
们不是语言学家。
这样就引入了借用图示进行功
能的描述和建模的过程。
图示有
其自己的优势比如，
清晰，
明确给人直观的感觉。
无论是何种背景的人
群都可以
理解。
这样就大大减少需求分析中的二义性。
从而使系统设计人员和用户更加有
效的沟通。
这
样也增加了软件的正确性。
在传统的软件工程中提供了多种不同的
图示，
每一种都从不同的角度对同一个问题进行描述，
之所以
这样。
可以使系统
开发人员在不同的图示中挑出最适合他和他的
团队进行问题详尽描述的一个或
者一些图示。
比如数据流图，<
/p>
在需求分析中使用数据流图，
就充分体现了数据在
软件系统中移动时被变换的逻辑过程。所以就是一个建立功能模型的最好图示；
而实体关系图，
就是描述数据对象以及他们之间关系的图示，
所
以就是一个建立
数据模型的最好例子。
状态转换图通过事件的外
部作用从而对状态进行改变，
这
就是一个建立行为模型的例子。
在
做需求分析时，
< br>尽量做到问题阐述明确。
可是一直有一个问题困扰
，
就是应
该选择什么样的图例进行系统的描
述是，数据流图，状态转换图还是实体关系
图？其实不同系统设计人员给出的答案不会是
一样的。
这并不是一个哲学问题而
是一个应用问题。
从客户的角度出发使用实体关系图是最好的选择，
而数据流图
完全就是为系统设计人员量身定做的一样。
因为程序员更关心事物内部的逻辑
性
和相关性；
而用户只关心事物的外部表征和特性。
所以问题的答案只有每个人自
己去寻找，寻找一个最能体现用户需求和问题
解决方案的图示。
在按照模版进行需求分析撰写的时候，
发现有很多模版条目的要求是在需
求分析的最初阶段是无法给出确切的答案的。
有的条目要经过概要设计，
详细设
计之后才能
对文档内容进行修改和填充。同时
对其他同行撰写的需求分析
文档
进行研究发现，一个优秀的需求分析说明说并不是按照规定模版条目不变的照
搬。
其实有些冗余的项目完全可以不必关心。
毕竟撰写需求分析的真正目的，
是
让系统设计人员知道用户的需
求。其他的不必过多强求。
需求分析文档规范
A
、三种编写方法
1
、
用好的结构化和自然语言编写文本型文档；
2
、
建立图
形化模型，这些模型可以描绘转换过程、系统状态、和它们之间
的变化、数据关系、逻辑
流或对象类和他们的关系；
3
、
编写形
式化规格说明，
这可以通过使用数学上精确的形式化逻辑语言来
定义需求。
多种编写方法可在同一个文档使用，
根据需要选择，
或互为
补充，
以能够把
需求说明白为目的。
B
、应有成果
1
、
各业务手工办理流程文字说明；
2
、
各业务手工办理流程图；
3
、
各业务手工办理各环节输入输出表单、数据来源；
4
、
目标软件系统功能划分（示意图及文字说明）；
5
、
目标软件系统中各业务办理流程文字说明；
6
、
目标软件系统中各业务办理流程图（模型）；
7
、
目标软
件系统中各业务办理各环节数据、
数据采集方式、
数据间的内<
/p>
在联系分析。
8
、
目标软件系统用户界面图、各式系统逻辑模型图及说明
C
、文档工具推荐
1
、
调研结果《需求分析说明书》格式参照开发文档模板；
2
、
单位组
织结构图、功能模块分解图用
VISIO
绘制，或直接用
WORD
中
的画图工具；
3
、
业务流
程图用
VISIO
中的
FLOWCHA
RT
模板绘制；
4
、
系统逻
辑模型使用
ROSE
绘制活用
VISI
O
中的
UML
模板绘制；
5
、
软件用
户界面用
VISIO
中的
WIN95
USER INTERFACE
模板绘制；
6
、
数据物
理模型用
POWERDESINER
绘制；
D
、需求文档编写原则
1
、
句子简短完整，具有正确的语法、拼写和标点；
2
、
使用的术语与词汇表中所定义的一致；
3
、
需求陈
述应该有一致的样式，例如“系统必须..”或者“用户必
须..”，并紧跟一个行为动
作和可观察的结果。；
4
、
避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方
便”；
5
、
避免使用比较性词语，如“提高”，应定量说明提高程度
需求分析
一、需求分析的任务
需求分析是软件定义时期的最后一个阶段，
< br>它的基本任务是准确地回答“系
统必须做什么？”这个问题。
需求分析所要做的工作是深入描述软件的功能和性
能，
确定
软件设计的限制和软件同其它系统元素的接口细节，
定义软件的其它有
< br>效性需求。
通常软件开发项目是要实现目标系统的物理模型，
即确定待开发软件系统的<
/p>
系统元素，并将功能和数据结构分配到这些系统元素中。它是软件实现的基础。
需求分析的任务不
是确定系统如何完成它的工作，
而是确定系统必须完成哪
些工作
，也就是对目标系统提出完整、准确、清晰、具体的要求。在这个阶段结
束时交出的文档
中应该包括详细的数据流图（
DFD
），数据字典（
DD
）和一组简
明的算法描述。
< br>
需求分析阶段的任务包括下述几方面。
1
．确定对系统的综合需求
2
．分析系统的数据需求
分析系统的数据需求是由系统的信
息流归纳抽象出数据元素组成、
数据的逻
辑关系、数据字典格式
和数据模型。并以输入
/
处理
/
输出（
IPO
）的结构方式表
示。因此，必须分析系统的数据需求，这是软件需求分析的一个重要任务。
3
．导出系统的逻辑模型
就是在理解当前系统“怎样做”的
基础上，抽取其“做什么”的本质。
4
．修正系统开发计划
5
．开发原型系统
二、需求分析的步骤
结构化分析方法（简称
SA
方法）就是面向数据流自顶向下逐步求精进行需
求分析的方法。需求分析
的步骤如下。
1
．
调查研究
2
．分析与综合
应注意下述两条原则：
第一，
在分层细化时必须保持信息连续性，
也就是
说
细化前后对应功能的输入／输出数据必须相同；
第二，
当进一步细化将涉及如何
具体地实现一个功能时，
也就是当把一个功能进一步分解成子功能后，
并将考虑
为了
完成这些子功能而写出其程序代码时，就不应该再分解了。
3
．书写文档
在这个阶段应该完成下述四种文档资料：
（
1
）系统规格说明。
（
2
）数据
要求。
（
3
）用户系统描述。
（
4
）修正的开发计划。
4
．需求分析评审
三、需求分析的原则
1
．必须能够表达和理解问题的数据
域和功能域
2
．按自顶向下、逐层分解问题
3
．要给出系统的逻辑视图和物理视图
四、需求分析方法
大多数的需求分析方法是由数据驱动的，
数据域具有三种属性：
数据流、
数
据内容和数据结构。通常，一种需求分析方法总要利用一种或几种属性。
需求分析方法具有以下的共性。
1
．支持数据域分析的机制
2
．功能表示的方法
3
．接口的定义
4
．问题分解的机制以及对抽象的支持
5
．逻辑视图和物理视图
6
．系统抽象模型
五、面向数据流的需求分析方法
结构化分析方法是面向数据流进行需求分析的方法。
结构化分析方法使用数据流图
DFD
与数据字典
DD
来描述，面向数据流问题
的需求分析适合于数据处理类型软件的需求描述。其核心思
想是分解化简问题，
将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。
六、数据流图
数据流图是描述数据处理过程的工具。
1
．数据流图的含义
数据流图从数据传递和加工的角度
，
以图形的方式刻画数据流从输入到输出
的传输变换过程。
数据流图是结构化系统分析的主要工具，
它表示了系统内部信
息的流向，并表示了系统的逻辑处理的功能。
2
．数据流图的特性
（
1
）抽象性
（
2
）概括性
（
3
）层次性
3.
数据流图基本符号
（
1
）数据
流图中的主要图形元素
数据流图的基本图形元素有
4
种，
数据流图基本图形符号
（
2
）数据
流与加工之间的关系
其中星号“*”表示相邻的一对数据流同时出现，
?
则表示相邻的两数据流
只取其一。
（
3
）分层的数据流图
-
-
-
-
-
-
-
-
-
上一篇：品质分析工具5why
下一篇：Why do you like English