系统分析师考试论文案例集Word文件下载.docx
《系统分析师考试论文案例集Word文件下载.docx》由会员分享，可在线阅读，更多相关《系统分析师考试论文案例集Word文件下载.docx（31页珍藏版）》请在冰点文库上搜索。
表结构、评分方法以及能考虑继承等各方面的要素，这样就可以保证软件的通用
性，可配置性与可维护性。
在工具的选择过程中，我们选择了现在已十分流行的Rational系列，包括
RationalRose、RUP、SoDA等，为什么选取这个系列工具呢？
这是基于我们对
软件需求分析目标的看法，我们认为需求分析应当能正确地回答如下的几个关键
性问题：
（1）用户的需求是否已详尽地被考虑到了？
（2）用户能理解或明白我们所描述的内容吗？
（3）分析是否会和设计相脱节，
（4）程序员能明白我们的分析与设计要求吗？
等等。
以下对上述几个问题逐一简要地加以说明：
（1）详尽地获取用户的需求。
用户的需求可分为显式的需求与隐性的需求，用户的倾向往往只顾及到当前
的与明显的需求。
要达到对需求理解的全面性，不仅仅只是依靠有效的用户谈话
和调查，因为我们所面对的用户需求往往会有些片面的，采用RationalRose（基
于UML）提供的用例，以及多种图的联合使用，可以使我们发现其中的遗漏。
（2）使用户能充分地理解我们的表示方法，能够真正明白我们描述的内容。
软件需求分析规格说明书通常会是冗长而枯燥的，一般的用户不容易深入理
解，这样就削弱了分析的正确性。
通过支持面向对象及UML语言的RationalRose
可以更好地和用户交流，让用户了解系统的运作方式甚至细节的操作。
（3）使分析和设计两个阶段互相联系与贯通。
这是我们选择面向对象的方法及RationalRose工具的重要原因，系统分析
要向用户描述的不仅仅是用户的需求，而且包括解决方法，解决方法当然应包括
设计（程序）、数据库与系统配置，我们当然不希望用户得到的是一个与需求规
格说明不相同的软件，也不可能要求程序员完成一个不可胜任的任务。
然而我们
在以前的多项工作中经常发现这类情节，因为系统分析与设计相互脱节，导致一
头扎在分析中不顾设计有关的事宜。
分析与设计的脱节，还不利于设计现格说明的评估，因为分析往往会脱离现
实，导致缺乏评估的依据。
因为不可能成功地完成设计而使分析需要重来，就会造成巨大的浪费与损
失。
一个好的工具可以使分析与设计更紧密地连结起来，甚至于—一对应。
面向
对象的分析方法使对象之间相对而言有独立性，减少了任何影响到全局的改动，
能避免因需求变化而导致全盘皆动的被动局面。
（4）使程序员明白我们的设计。
一个好的设计应该让程序员感到清晰明白，更少疑问。
一个疑问很多的设计
加上沟通不畅，绝对会出现在应用环境下所不需要的另一个软件，所以设计规格
说明书务必清楚、形象与明确，当然，RationalRose具有足够的图形与其他形
式，能使程序员更加明确，甚至能细微到每一个语句（事实上如果使用VB，程
序架构都有可能直接生成了）。
（5）选择UML可能会有更多的理由。
比如用户文档的编写、数据库设计，我们都需要做到有延续性，有自动化支
持和具有质量上的保证。
所以，我们选用了以上的方法和工具。
在分析中，面对考勤班次的问题时，由于过去一直使用纸卡方式考勤，使用
户对班次形成了固定的概念，而现在的许多考勤软件也采用多次刷卡的方法来形
成一天的记录。
经过面向对象的分析可以发现，事实上每天的上班记录是由多个
时段所形成的，时段的多少在各个公司，各个工种与部门都不尽相同，每个时段
可能有不同的属性，时段与时段组合可形成为班次，这更适合于现实的情况，使
之能更加灵活与更有扩展性。
其实，在天与天之间也都有相互之间的关系。
在这
一点上，我们又发现必须在考勤与薪金工资中加入与MRP中相似的期段
（Periods）的基本概念，比如可以称之为考勤期段，允许为用户更加方便地设
置考勤期段，可能使之不一定与自然年月日相同等等。
RationalRose使我们更方便地把上面的想法在类上去实现，更进一步地设
计好我们的高效率的数据库。
当然，使用单一的一个工具去完成一个中大型的应用系统的需求分析，是不
可能成功的。
因为社会在发展，用户的需求也在改变，如何把握住用户的需求是
需要时间的，面向对象的方法有时也会忽略外在的与表层的要求，不仅仅是要获
得关键的需求，其他更多的需求往往要等到用户在使用后才知道，然而等到用户
使用是不现实的，作为原型开发模型中的原型也是收集用户需求，描述与解释需
求的一类相当有效的方法与工具。
在我们的开发过程中，为了更好地让用户了解我们的系统和我们的设计方
案，让用户在见面会上更有方向性与针对性，我们首先用Access开发出原型，
让用户先试用。
这样，我们在真正的分析与设计时就能更加符合用户的要求。
总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远
的，选用高效能的正确的方法与工具，可以使我们的软件更加正确地反映现实需
求，更加具有可用性、可扩展性和可维护性；
降低了软件项目的风险。
【评注】
（1）写得有些特色，观点鲜明。
（2）摘要写得不错，既反映了项目内容，也小结了本文的写作要点。
（3）文中所举的例子虽然简单，但很实际。
（4）多种方法与工具的使用，叙述得简明扼要。
（5）内容可更丰富一些，更深入的例子也可再增多一些，则会更有说服力。
（6）对需求分析的全过程的描述太少。
刘小波
本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信
息系统需求分析的整个过程，其重要特征是：
所涉及的项目是原有系统的一个升
级替换版本。
因此，需求分析过程不同于建立一个全新的系统，大体上可分为三
个阶段：
（）实施逆向工程获得对系统的初步了解；
（2）在第1步的基础上写
出基本需求，交由客户评审补充；
（3）在第2步的基础上开发原型，利用原型
与客户交流，最终获得基线需求。
针对上述三个阶段，本文论述了所使用的分析
方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工
具，谈一些自己的初步体会。
我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发
工作，该大型集团的业务主要涉及到IT类产品的进销存。
本人在项目中负责系
统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理
系统，但是该老系统存在两个主要的问题：
（一）系统运行速度非常慢，如商品
销售开单时，从确定开单到开单完成有时需要1～2分钟左右的响应时间，让客
户无法忍受。
（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹
配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，
只能采用人工录入方式补充进行。
在这种情况下，该集团的总经理决定参考原有
系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。
注；
原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，
客户端采用Windows98，程序架构采用的是传统的C/S结构。
鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间
短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的
结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切
实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经
验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为
三步：
（）分析原有系统的结构，主要是数据库结构和程序结构，
（2）在获得
第
（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第
（2）步
的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。
下
面按上述三步分别加以论述。
第一步是实施逆向工程，获取原有系统的基本需求。
由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发
中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯
路。
在这一阶段，我们采用的主要工具是PB自带的PowerDesigner和PB
Documents；
前者主要用来分析数据库结构，后者主要用来分析程序结构，便于
开发人员与高级用户理解程序。
采用这两个工具的原因是：
原系统过于庞大，模
块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整
的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的
设计文档，于是我们只能依靠工具辅助来进行。
在使用PowerDesigner分析数
据库，并且用PBDocuments分析原程序中的PBL以后，我们对原系统的结构有
了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并
在此基础上用人工录入方式，产生了初步需求的自然语言文档。
这里指出，使用
PowerDesigner的一个不足之处是：
如果一个表中的字段过多，而且又同时依
赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅
读及打印。
第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和
补充。
通过第一步的逆向工程，我们获得了系统的基本需求。
为了充分记录需求的
变化及需求之间的依赖关系，我们决定选用Rational公司的RequisitePRO作
为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非
常强大，包括RequisitePro、ClearQuest等等，这些需求分析工具可以对需
求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。
但是，
我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项
目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就
是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。
之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。
正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适
当补充，我们将经过补充整理后的需求作为正式需求记录入RequisitePro所维
护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可
以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先
考虑的，哪些是难度较大的等等。
在这个过程中，我们遇到了一些问题，譬如：
用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间
阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关
系；
另外是由于首次采用RequisitePro进行需求管理，在类型划分，属性值的
确定上，部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想
办法增加一些示意图，将大的流程分解为小流程，再与客户反复交流与沟通，最
终达到双方理解一致的目的。
对第二个问题，则参考了一些例子，再结合实际中
属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的
需求库，定出了基本需求规格说明。
第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交
流，通过交流修改相应的需求。
在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。
我们用
PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，
客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，
也在RequisitePro需求数据库中记录下修改的历史。
事实证明，这种记录历史
的作用是很有效的，如曾经有客户在两个不同的时间对同一需求提了相反的需
求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无需再作争
论，同时利用RequisitePro，我们还发现了一些需求相互之间有矛盾。
经过这
一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行
详细设计的基线需求。
在这个项目中，我们利用了PowerDesigner、PBDocuments等逆向工程分
析工具和RequisitePro需求管理工具，这些工具的使用，使我们提高了工作效
率，起到了一定的辅助作用。
但是，就需求分析工具方面而言。
我们觉得国内应
用得还是太少了，这一方面是因为对需求分析不够重视，另一方面是因为管理水
平还达不到相应的层次。
Rational公司的一整套需求分析工具，其功能是非常
产业也许会真正地腾飞了。
强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那些通过CMM二
级以上评审的单位，都必须使用工具对需求进行管理。
在本项目中，我们仅仅利
用了RequisitePro功能的一些小方面，已经体会到该工具对于项目管理的诸多
好处。
如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问
题会变得不再那么棘手了，项目的质量也会得到相应的提高。
目前国内由于CMM
热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜
的，当然，更希望在不久的将来，能用上国产的需求分析工具，那时我们的软件
采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。
写作有
条理，也很实际。
合理地界定了需求分析的现实水平。
所采用的需求分析的方法
与工具相对较合理科学。
能在对项目讨论的同时抒发议论、使用体会、爱国心和
事业心。
深度还可以提高，例子宜更加丰富一些。
魏福建
本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方
法的选用。
我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继
工程的进行以及最终的产品能否满足用户的需求，因此在整个工程中起着关键性
的作用。
采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需
求分析的质量和工作效率。
当然工具的选用应当与实际的项目相结合，充分地发
挥工具的作用。
本文结合我们工作的实际经历，简要讨论了开发系统时所选用的
工具及其应用，选用时所考虑的原则以及所碰到的问题。
在文中也结合多种开发
方法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法
的不足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生
的效果。
我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发
本公司的业务报表系统，我担任系统的需求分析、总体设计和部分代码的编写工
作。
我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，
各级公司之间都有数据报表的要求。
但是，每一个地市分公司因所处的地方不同，
经营环境不同，所面临的问题也不一样，因此形成了各具特色的数据报表（除地
市分公司向省公司汇报的之外）。
公司又分设了许多部门，这些部门也都会需要
数据，作为分析决策的依据。
因此，了解各个部门的需求就成了业务报表系统的
关键。
在调研的过程中，我选用了一种工具叫PlayCASE，可以从网上免费下载，
有很强的功能。
下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。
第一步，了解业务组织结构。
公司内部的数据实际上是在部门之间流动的。
业务部门需要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的
时空分布）。
财务部门需要知道本月各类用户的话费收入、预交款收入、与其他
电信运营商的网间结算等。
计划部门需要各部门的分析数据。
计费部门需要提供
本月的账革统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以
及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。
这些部门时常为了数据而产生了大量无谓的争议。
在使用PlayCASE工具时，先
要将这些部门录入到PlayCASE的“业务部门”中．构成了一个信息源的接收点
（或发送点）；
而PlayCASE通过图示表示了这些部门的关系，并转换成了相应
的软件结构。
实际上，这是一种系统建模的方法，即把业务系统中的各个组织转
变为软件功能中的各个结构。
这样，在需求分析阶段，明确哪些部门需要数据，
从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求
分析的不完整。
第二步，了解各个业务部门中的业务流程，使之通过PlayCASE转换成软件
的运行过程，这是一种动态建模的方法。
在上一步的基础上，追踪各个部门的行
为，录入到PlayCASE中，并以形式化的语言描述各过程。
对于复杂的过程，该
工具还提供了进一步细化的方法，并且形成了业务流程图和业务状态图。
根据这
些流程图、状态图与实际业务部门的业务相结合比较，还是较为吻合的。
在此步
的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软件的运行过
程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情
况，防止在后继的程序编写过程中，可能会经常发生的一类情况：
程序员因为没
有理解业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的
正确性。
第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所
需要的数据。
分析各部门需要的数据都有哪些；
以及数据是如何转换的，这可以
归入“功能建模”的范畴。
将这些相应数据录入到PlayCASE中，选定所属的部
门。
这时就自动地建立了DFD图（数据流程图），数据字典，省去了人工建立时
的很大麻烦。
第四步，将业务上的数据关系转变成软件中的数据关系。
这里采用了面向对
象的方法，把业务部门所需要的数据看作一个实体，部门间的数据关系就是实体
之间的关系。
比如：
经营部门所需要的用户资料、用户话费，实际上就是用户这
一实体与账单这一实体间的关系。
PlayCASE提供了构件（不过我觉得是部件更
为合适一些），来表示对应的数据，并提供了三种构件的表示关系即组装关系、
分类关系与相连关系。
这三类关系基本上反映出了现实世界中的业务数据之间的
关系。
例如现实世界中的用户资料与用户话费，在PlayCASE中，可将用户构件
析是很有帮助的。
与账单构件用相连关系表示。
这种方法，实际上是借鉴了OOA面向对象的分析方
法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；
同时，这
一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。
经历了上述四个步骤以后，利用PlayCASE工具自动生成了软件需求规格说
明书、初步的DFD图和业务流程图，为下一步的总体设计打好了基础。
使用PlayCASE工具，使需求分析既能继承传统的结构化分析方法，又能吸
收面向对象设计方法的优点。
比如能把业务流程转变成为运行过程，业务组织转
变成了软件的结构等都体现了这一点。
而在运行过程中，对复杂过程的细分以及
追踪则反映了传统方法中的自上到下分解的分析思想，这对于解决复杂系统的分
通过使用，我觉得这个工具还是很不错的。
因为它实际将以下四个方面的问
题结合起来了：
软件、业务、开发人员和用户。
对于用户而言，PlayCASE用图
形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来
验收软件时的依据。
对于开发人员来说，使开发人员能更清楚地了解业务流程，
不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来
的产品不符合用户需要”的现象。
因此，PlayCASE所自动提供的需求说明书能
够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。
使用PlayCASE工具后，使我们的需求分析取得了很好的效果，不但能自动
地提供许多结果，如需求说明书等；
还使需求的质量有了很大的提高，受到领导
的赞扬（领导不是学计算机的，但对公司的业务十分熟悉）；
在后继的设计与维
护工作中，我们感到工作似乎轻松了很多。
当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的
部门或者组织机构发生变化时，整个设计都要重新来过。
因此，在改进的过程中，
我们在第一步过程预留了好多个虚拟的部门，以备将来进一步的扩充或者变动。
（1）具体项目有些体会，完成情况似乎不错。
（2）条理较清晰，比较系统地描述了使用PlayCASE的过程和体会。
（3）偏重于工具的讨论，对需求分析的方法分析还嫌不够。
（4）项目相对较小，仅涉及报表系统，对更为复杂的业务流程应举例分析，
才能更充分地体现方法与工具的作用。
论文四IC行业内部的CAD应用
解亮
本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本
人所担任的工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及
选用的理由。
由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的
问题及解决方法；
在这个过程中给出了对选用的具体工具和方法的效果的描述。
接着本文讨论了对使用方法的改进的一些想法以及具体的实现过程。
最后提出了
我对需求分析的某些看法，强调了与客户沟通的重要性。
近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机
辅助电路设计的，包括了从上流设计到下流设计的所有流程，如用于可设计百万
门数量级的逻辑门电路。
有关方面把电路中路径的提取、过滤以及表示的某软件
开发任务交给我公司，我有幸担任了该部分的需求分析以及设计。
我所设计部分为一单独可
升级会员 