注重需求分析做好数据库应用系统的设计
注重需求分析做好数据库应用系统的设计
（广西广播电视大学理工学院　　广西南宁　　530022）
　　[摘要]在数据库应用系统的设计中，需求分析是整个设计的基础。本文针对大专院校学生在进行数据库应用系统的设计中出现的问题，强调需求分析的重要性，并理论联系实际地对需求分析的各项工作做了具体的阐述，对学生今后的设计有一定的指导意义。
　　[关键词]需求分析；数据库；数据流图；毕业设计
[中图分类号]G434[文献标识码]A[文章编号]1008－－0026－03
数据库应用系统是在计算机软硬件系统和某一种数据库管理系统的支持下，针对某一方面应用的信息管理系统。在现实生活中，大到在互联网或专用网支持下的全球或全国系统，小到某个单位、某个部门，甚至某项工作的计算机管理，数据库应用系统无处不在。
　　在大专院校的计算机教学中，毕业设计是完成教学计划达到专业培养目标的一个重要的教学环节，也是教学计划中综合性最强的实践性教学环节，而数据库应用系统的设计往往被作为毕业设计的选题之一。许多同学直观地认为数据库应用系统的设计就是编制程序，他们过早地将注意力放在系统的编程设计上，不注重对系统进行需求分析，导致在后期的系统测试工作中发现这样或那样的错误，造成大量的返工。
　　其实，要编制出真正适用的程序，在编程之前，还需要做许多艰苦细微的工作，需求分析就是为今后工作的顺利开展创造条件的。实践证明，在一个数据库应用系统的开发过程中，要非常重视早期的分析工作，决不能草率行事，否则一旦出现错误，将造成人力物力的极大浪费。
　　一个数据库应用系统的开发过程大致包括六个阶段：需求分析阶段、概念设计阶段、逻辑设计阶段、物理设计阶段、机器实现阶段、运行维护阶段。
　　需求分析是整个开发过程的第一个阶段，也是最重要的一步。其主要任务是：了解和掌握数据库应用系统开发对象（用户）的工作业务流程和每个岗位、每个环节的职责，了解和掌握信息从开始产生或建立，到最后输出、存档或消亡所经过的传递和转换过程，了解和掌握各种人员在整个系统活动过程中的作用；通过同用户充分地交流和沟通，决定哪些工作应由计算机来做，哪些工作仍由手工来做，决定各种人员对信息和处理各有什么要求，对视屏操作界面和报表输出格式各有什么要求，对数据（信息）的安全性（保密性）和完整性各有什么要求，等等。它是开发人员弄清实际情况，制定合理方案，开发系统的基础，对此，必须加以高度的重视。
　　下面，就需求分析阶段的具体工作进行如下归纳的描述：
　　1调查、分析系统功能需求和用户活动，确定系统边界
　　系统功能需求调查分析的目的是确定系统应具有哪些功能，完成哪些任务。调查分析工作通常是从用户对数据处理要求的提出开始的，通过设计人员和用户充分地讨论和协商，提出实施方案和需求，最后把系统功能确定下来。
　　调查和分析用户活动是为了了解用户的各种业务活动，具体工作包括：调查各部门输入和输出的数据与格式，所需的表格和卡片，数据的加工，输入输出的部门等。调查时应特别注意了解这些报表之间的关系，各数据项的含义等，以确保建立的数据库应用系统能符合客观管理规律，满足用户的需求。
调查分析的结果要用系统功能结构图、业务流图等一系列图表表示出来。以图书管理系统为例，根据用户的处理要求划分功能模块，可以设计出功能模块调用图如图1所示
　　2收集、分析、整理数据
　　数据是处理的对象，是建立数据库的基础。因此收集和分析数据是需求分析阶段最重要的内容，同时也是最难完成的任务。在设计工作中遇到的最大的困难往往是由于设计人员对业务的不熟悉而无法深入全面地了解系统的数据情况，以及这些数据如何在数据库中表示，在处理模块中如何处理它们。
　　2.1收集资料
　　收集资料的工作是数据库设计人员和用户共同完成的任务。因为熟悉应用业务的用户最了解系统的需求，尽管他们不一定知道如何设计或实现系统，但他们对系统应当提供的处理功能最有发言权。强调各级用户的参与是数据库应用系统设计的特点之一。
　　首先确定企业组织的目标，从这些目标导出对数据库的总体要求。这些要求一般应该从组织中的高层决策机构获得，因为他们熟悉企业的发展规划。通过对中层管理人员的调查访问可以获得日常控制管理的信息需求、各个部门之间的信息交流接口。通过对基层业务人员的访谈可以了解具体的业务操作流程，从而便于确定新系统的人机界限。确定哪些功能由计算机完成，哪些事情留给手工去做。具体调研的形式很多，例如通过发放信息需求调查表、当面交谈、开讨论会等多种形式。广泛收集各个部门的需求和约束条件等，在调研过程中要做详细记录，回来及时进行分析整理。
　　用户需求主要包括以下三方面：
　　（1）信息需求，即用户要从数据库获得的信息内容。信息需求定义了新系统应该提供的所有信息，应描述清楚系统中数据的性质及其联系。
　　（2）处理需求，即完成什么处理功能及处理的方式。处理需求定义了新系统数据处理的操作，应描述操作执行的场合、频率、操作对数据的影响等等。
　　（3）安全性和完整性要求。在定义信息需求和处理需求的同时必须相应确定安全性、完整性约束。
　　尽管收集资料阶段的工作非常繁琐，但必须耐心细致地了解现行业务处理流程、对新系统的要求、收集全部数据资料，如报表、合同、档案、单据、计划等等。
　　2.2分析整理资料
　　分析的过程是对所收集到的数据进行抽象的过程。抽象是对实际事物或事件的人为处理，抽取共同的本质特性，忽略细微末节，并用各种概念精确地加以描述，这些概念组成某种模型。
　　数据分析与抽象是数据库设计的基础，数据分析和抽象可以同时进行，并往往从局部入手。例如，在图书库存清单中图书的总价可通过下式求得：总价=单价＊数量。此时就要考虑不必将总价作为图书表中的存储数据项，以免造成数据的冗余和产生数据的不一致性。
　　2.3绘制数据流图（DFD）
　　数据的收集和分析，最终应以数据流程图的形式表示出来。数据流图用来描述系统的数据流向和数据的处理功能，它以图形的方式来表达数据处理系统中信息的变换和传递过程。数据流图有三个重要特点：一是可以表示任何一个系统中信息流程；二是每个处理符号根据需要可进一步分解，以求得对问题的全面理解；三是强调的是数据流程而不是控制流程。
　　数据流图的基本符号有以下几种：1）数据流，用标有名字的箭头表示有名字有流向的数据；2）数据处理，用标有名字的圆圈表示对数据进行加工和变换。指向处理的数据流是该处理的输入数据，离开处理的数据流是该处理的输出数据；3）数据文件，用标有名字的双直线段表示数据暂存的处所。对数据文件进行必要的存取，可用指向或离开文件的箭头表示；4）数据源及数据终点，用命名的方框表示数据处理过程的数据来源或数据去向。
在数据流程图中，应把数据来源、进行的处理以及处理的去向等表示清楚。对稍为复杂的系统，只用一个数据流图是不够的，应按自顶向下的分解方法逐层分解为多个数据流图。图2、图3给出了图书管理系统的顶层和0层数据流图。
　　2.4数据字典（DD）
　　数据字典是对各类数据描述的集合，它对数据流图中出现的所有数据元素给出逻辑定义。它在需求分析阶段建立，在整个数据库设计的各个阶段将不断修改、充实和完善。数据字典包括的主要条目有：
　　1）数据项条目：包括数据项的名称、类型、字节长度、取值范围、别名等。
　　2）数据流条目：包括数据流的名称，组成该数据流的所有数据项名，数据流的来源、去向及流量等。
　　3）事务条目：包括事务名称、事务逻辑功能、事务处理逻辑、事务处理所涉及的部门名、数据项名、数据流名、事务处理频率、激发条件等。
　　4）数据文件条目：包括数据文件名称、组成该数据文件的所有数据项名、数据存取频度、存取方式等。
　　5）报表条目：包括报表名、报表所涉及的处理名、所需的数据项名、报表产生频率等。
　　2.5用户确认
　　设计者将需求分析产生的数据流图、数据字典、功能结构图等返回给用户，并与用户一起检查、补充、修改，最终获得用户的认可。
　　3编写需求分析报告
　　需求分析阶段的最后结果是编写需求分析报告。
　　需求分析报告也称作系统需求说明书，它是系统的总体设计方案，内容包括：
　　①系统的概况、系统的目标、范围、背景、历史和现状。
　　②系统的原理和技术，系统适宜采用的计算机系统和数据库管理系统及相应配置情况。
　　③系统预算的开发费用和时间、工作量等。
　　④系统边界，即哪些数据和处理由计算机完成，哪些数据和处理仍由手工完成。
　　⑤系统开发人员的组成。
　　⑥用户使用系统的要求。
　　随系统分析报告应提供的附件有：组织结构图、功能模块图、业务流图、数据流图和数据字典等。
　　需求说明书是开发单位与用户单位共同协商达成的文档，一般要经过有关方面的专家进行评审和通过。它是以后各阶段进行开发和设计的主要依据，是以后所有工作的基础和凭证，也是最终进行系统鉴定和评价的依据。
　　需求分析是数据库应用系统开发工作中一项重要的、繁杂的、工作量大的工作，它是数据库设计的基础，而数据库建造得是否合理，直接影响到系统的优劣，所以，要合理地设计好数据库，需求分析是关键，必须引起高度重视。只有需求分析工作做好了，才有可能设计出满足用户应用需求的数据库应用系统。在教学实践中，由于我们注重了这方面的工作，取得了良好的教学效果。
　　[参考文献]
　　[1]赵杰，杨丽丽，陈雷.数据库原理与应用[M].人民邮电出版社，2002.
　　[2]施伯乐等.数据库技术[M].科学出版社，2002.
　　[3]张健沛.数据库原理及应用系统开发[M].中国水利水电出版社，1999.
　　[作者简介]叶嘉（1965－），女，讲师，研究方向：数据库，管理信息系统，操作系统。
　　[责任编辑　　张宜]二次元同好交流新大陆
扫码下载App
汇聚2000万达人的兴趣社区下载即送20张免费照片冲印
扫码下载App
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
近年来，由于Android平板成本不断降低，以及Android系统更新带来的更多完善功能，酒店或者餐馆配置数字餐饮治理系统，以电子菜单模块为核心内容，产品提倡绿色健康消费观念，将会极大进步餐馆档次、形象和顾客消费体验。
对于一般的酒店或餐馆，现在一个普通菜谱的成本为每本400-1000元，每年得更换2-4次，每年一个房间的菜谱成本就是800-4000元，而一个android平板的成本为元，因此成本要低很多的。假如点餐系统可以提供除一般餐饮列表和特色推荐外，还能根据餐馆风格定制界面，提供菜品做法，将会极大提高餐馆的吸引力。
电子菜谱与传统菜谱对比：
个性化制作封面
个性化制作封面
每次制作新菜谱时才能更换
贴条或服务器提醒
随时设置不可见可不可点
菜品、价格及简单介绍
菜名、价格、做法介绍，可以嵌入大量图文甚至视频
健康提示、卡路里含量、配餐等
制作菜谱时设定
基本上没有
可对自已或合作伙伴的产品进行演示推广
客人点餐可以形成菜单确认后提交服务员
使用久了会出现磨损、脱页等
更换封面，贴膜后保持常新
不更换不可以变换
根据酒店风格定制界面，春节、中秋、圣诞、情人节等可以更换不同皮肤，增强节日气氛。也可以根据婚宴、寿宴等不同需求个性化定制，彰显时尚品味
500-200元/本,2本/年，需要不间段地印刷，累计成本高
首次投资成本略高，累计成本低
本《业务需求分析说明书》是描述Android Ordering Food客户自助订餐系统（以下简称“AOF”）的功能需求和性能需求的一份基础文档。它阐明“AOF”各功能模块的建设要求，此外还说明“AOF”项目的非功能性需求。
“AOF”项目《业务需求分析说明书》的编制是为了让用户和开发方对本系统有一个共同的理解，是用户与开发方双向沟通的桥梁，是把业务需求计算机化的关键步骤，使之成为整个项目开发及测试工作的基础，是用来规范项目的工作内容、工作范围、工作目标和检验项目是否成功完成的标准。
编写本《业务需求分析说明书》的目的是：
1)是用户方与开发方关于项目功能和要求达成的协议。
2)为项目的评测与验收提供依据。
3)为开发人员进行系统设计和程序设计提供依据。
本《业务需求分析说明书》的预期读者有：
?酒店、餐馆使用业务人员
?甲、乙方的项目管理人员
?需求分析人员
?软件设计人员
?软件开发人员
?软件测试人员
?软件维护人员
“AOF”订餐系统由以下功能构成：
1)菜谱管理：系统支持多个菜谱，可随时对菜谱菜单进行添加、修改、更换模板，可实现对菜品的图片、库存和相关介绍信息更新。
2)订单管理：包括用户下单、下单确认、订单状态查询和资金结算。用户可以通过终端实时跟踪订单状态。
3)界面主题管理：系统初始化默认包含几种主题，后续可以通过导入模板添加到订餐系统中，另外支持自定义主题属性。
4)餐桌管理：管理餐馆的餐桌，标记餐桌的被预订信息以及使用状况。客户可实行预定餐桌、转台和合台。
5)用户权限管理：实现用户登录、登出功能，不同用户能够操作对应的权限页面。
6)客户评分：提供客户对于餐馆菜品的评分、留言功能。
7)广告管理：餐馆附近旅游设施、购物休闲可附加广告于功能界面。
8)分析报表：分析客户点餐习惯，以及销售业绩情况，生成分析报表。
9)国际化标准
AOF平台的主要功能，
用户访问方式如下图：
系统管理员：餐馆订单系统管理员，可通过角色权限定义修改用户权限菜单。
下图描述了系统管理员可以使用的主要功能模块：
内容管理员：可进行菜谱管理，定时更新菜品信息，跟踪客户订单，界面主题订制维护，餐桌管理。
下图描述了内容管理员可以使用的主要功能模块：
服务员：可对菜品库存信息和当日销售信息进行更新，更新餐桌占用资讯，实行转台、合台操作，跟踪客户订单，资金结算。
下图描述了互联网用户可以使用的主要功能模块：
顾客包含游客和个人注册用户。
顾客：可以浏览餐馆的菜谱和菜品，下订单，对服务和菜品进行评分
下图描述了顾客可以使用的主要功能模块：
厨师：可浏览客户订单，根据客户订单情况选择较优的做菜任务。
下图描述了厨师可以使用的主要功能模块：&&
业务销售员：获取系统订餐数据，生成销售分析报表。
下图描述了业务销售员可以使用的主要功能模块：
要求保证功能的正常使用，界面操作方便，界面逻辑合理，页面最大响应时间不可以超过10秒。
要求系统可以根据系统的负载情况和容量增长，比较方便地实现系统扩容。
a.要求系统前端与后端均提供一定级别的密码安全保护。
b.确保系统及信息的安全性，防止被恶意访问。
c.程序能防范各种基本漏洞攻击，如跨站脚本攻击、重复提交攻击等。
d.系统用户的登录密码采用Md5不可逆加密。
e.用户注册时要求提供密码强度效验，长度最少6位，并不允许重复的数字或字符。
f.系统每隔30天提示互联网注册用户修改登录密码。
要求系统能够负荷几百万注册用户。
要求系统能够方便地在不同应用服务器间可移植。
要求系统有完整的备份策略，有良好的日志记录。
n技术的成熟性
要求产品架构有比较高的可伸缩性，已经有成功案例证明其可用性、成熟性。
内部用户数据可导出为excel。（本期暂不实现）
阅读(3732)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Android Ordering Food
客户自助订餐系统需求分析说明书（上）',
blogAbstract:'
最近发现Android很火，于是跟风也学一下Android，感觉入手不容易，所以就收集网上一部分需求，然后自己着手写了份需求分析，估计还要半个月时间才能完善这部分需求。&& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &',
blogTag:'',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:7,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:2,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}我对软件开发需求分析的认识和理解 - 中国研发管理网（）
我对软件开发需求分析的认识和理解
发布者：佚名
来源：互联网 点击： 发表日期：<font color="#4b-03-21 【
　　应用软件开发中的需求分析及方法 软件工程一般具有以下基本活动：软件描述：软件的功能以及软件操作上的约束定义;软件设计和实现：软件要按照描述来设计;软件有效性验证：软件要被确定是有效的，能完成预期的应用;软件进化：软件按应用需要的变更来进化。其中，软件描述的目标是，确定软件系统需要哪些服务以及开发和运行期间受到哪些约束，对服务和约束的发现、分析、建立文档、验证活动，现在常称为需求工程。为此，笔者谈谈如何进行需求分析及方法。
　　一、 需求的过程
　　需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上(各种相关模型至少在一定程度上可以衍生导出)，而需求工程阶段的成果却是靠创建而来的。
　　需求工程本身就是一个过程，这个过程将产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户需要高层次的需求描述;而系统开发人员需要比较详细的系统描述。
　　(一)需求过程的四个主要阶段
　　1、可行性研究：指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是初步的，结果就是要得出结论，该系统是否值得进行更细致的分析。
　　2、需求的导出和分析：这是一个通过对现有系统分析、与潜在用户讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。
　　3、需求描述：需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从最终用户对系统需求的抽象描述;系统需求是对系统要提供的功能的详尽描述。
　　4、需求有效性验证：这个活动检查需求实现、一致和完备。在这个过程中，可发现需求文档中的错误，并加以修正。
　　当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。
　　(二)需求的进一步认识
　　1、软件系统需求 常常分为功能需求、非功能需求和领域需求。 功能需求：包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。
　　非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求源于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互操作，还包括如安全规章、隐私权利保护等外部因素。
　　领域需求：这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。
　　2、软件需求文档 也称软件需求描述(SRS)，是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言(目的、范围、缩略词等)，一般描述(产品透视、功能、用户特征、约束等)，专门需求(功能、非功能、接口)，附录，索引。
　　二、方法
　　(一)问题域(应用领域)
　　是指问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。例如，对一个电梯控制系统来说，它将包含任何现存的硬件(电梯、指示器、传感器、按钮等)、建筑物特征(楼层和电梯井的数目)、预期的使用模式、用户特征、使用约束(如限制短途搭乘)等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。 到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么;从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述(即需求);确定新系统所需的行为，以便让它在问题域内产生所需要的效果。
　　(二)需求分析
　　通过对问题域的研究，获得对该领域特性及存在于其中(需要解决)的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统(问题域)的结构，而内部设计则是要创建出一个尚未存在的软件系统(解系统)的结构。对于这一重要任务其特性如下： 分析关注问题域及对其建立的模型，而不是解系统; 主要目标是要获得对问题域及存在于其中的问题本质的理解; 分析在本质上先于解系统行为的规格说明(尽管有重叠和反复的过程)。
　　(三)方法论
　　方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面： 问题域的结构，根据其子域及其相互间的关系; 问题域数据，语法和语义方面 问题子域的内在属性和行为; 问题域中的重要事件及现象; 需求，解系统在问题域中应产生的效果。 具体有以下三个方法： 1、结构化分析(SA) 结构化分析(SA)是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型(DFD)，数据字典(DD)，实体关系图(ERD)。 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。
　　2、 面向对象分析(OOA)
　　面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。面向对象分析基本思想是：如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。
　　OOA(面向对象分析)算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计(如果是OOD开发的话)。
　　OOA的大致方法是：标识出问题域中的对象类;定义这些类的属性和方法;定义这些类的行为;对这些类间的关系建模。
　　3、 面向问题域分析(PDOA)
　　面向问题域的分析(PDOA)是一种新技术。PDOA更多的强调描述，而较少的强调建模。描述大致划分为两个部分：一部分关注于问题域，而另一部分关注于解系统的待求行为。一般建议同时有两个单独文档：第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表(即需求);第二文档(规格说明书)包含的是对解系统的待求行为的描述以解决需求。其中第一文档才是通过做分析产生的;第二文档推迟到后续的规格说明任务中。
　　PDOA整个方法过程的基本步骤： 搜集基本的信息并开发问题框架(一种模型)，以建立问题域的类型 在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述 基于以上两点，收集并用文档说明新系统的需求问题框架。问题框架是将问题域建模成一系列互相关联的子域。一个子域可以是那些可能算是精选出来的问题域的任一部分。问题框架的目标就是大量地捕获更多有关问题域的信息。基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类为： 工件系统——系统必须完成针对只存在于系统中的这些对象的直接操作。
　　控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。 信息系统——系统将提供有关的问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供。 转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。 连接系统——系统必须维持那些相互没有直接连接的子域间的通信。 问题框架法在应用时，建议采用直截了当的策略： 抽象问题域：标识子域;标识子域间的交互;刻画每个子域的特征;生成一个上下文图识别出相关的标准框架;调整框架，尽可能使之适用于问题;使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。 问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。
　　4、方法的对比
　　结构化分析(SA)及其相应的派生方法，曾一度风行了许多年。它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。 面向对象分析(OOA)是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。它也继承了很多结构化分析的思想体系。OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。 SA和OOA还有几点相同特性：主要模型是结构模型;通常焦点集中在对解系统的建模上;两中方法都较少地应用于需求获取领域;分析与内部设计之间没有明显差异。 面向问题域分析(PDOA)被认为是一种较为理想的方法。PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还有一定距离。 因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。
　　总结 在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的进一步进行，我们越来越清晰的认识了软件系统的需求。
　　虽然应用方法使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。
发 表 评 论
相 关 信 息
共创国际项目管理顾问旗下网站： |
Copyright & 2005- 研发管理网 All rights reserved. 京ICP证060517号