计算机系统分析员论文12篇

系分论文3

论软件需求分析方法和工具的选用——论文3：通信行业的应用

【摘要】

    本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程的进行以及最终的产品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了开发系统时所选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多种开发方法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法的不足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】
    我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发本公司的业务报表系统，我担任系统的需求分析、总体设计和部分代码的编写工作。

    我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级公司之间都有数据报表的要求。但是，每一个地市分公司因所处的地方不同，经营环境不同，所面临的问题也不一样，因此形成了各具特色的数据报表（除地市分公司向省公司汇报的之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。

    在调研的过程中，我选用了一种工具叫Play CASE，可以从网上免费下载，有很强的功能。下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

    第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账革统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中．构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建模的方法，即把业务系统中的各个组织转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。

    第二步，了解各个业务部门中的业务流程，使之通过Play CASE转换成软件的运行过程，这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到Play CASE中，并以形式化的语言描述各过程。对于复杂的过程，该工具还提供了进一步细化的方法，并且形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。

    第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。分析各部门需要的数据都有哪些；以及数据是如何转换的，这可以归入“功能建模”的范畴。将这些相应数据录入到Play CASE中，选定所属的部门。这时就自动地建立了DFD图（数据流程图），数据字典，省去了人工建立时的很大麻烦。

    第四步，将业务上的数据关系转变成软件中的数据关系。这里采用了面向对象的方法，把业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营部门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系。Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将用户构件与账单构件用相连关系表示。这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。

    经历了上述四个步骤以后，利用Play CASE工具自动生成了软件需求规格说明书、初步的DFD图和业务流程图，为下一步的总体设计打好了基础。

    使用Play CASE工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。

    通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

    使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多结果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学计算机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轻松了很多。

    当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的部门或者组织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预留了好多个虚拟的部门，以备将来进一步的扩充或者变动。

评注：（1）具体项目有些体会，完成情况似乎不错。（2）条理较清晰，比较系统地描述了使用Play CASE的过程和体会。（3）偏重于工具的讨论，对需求分析的方法分析还嫌不够。（4）项目相对较小，仅涉及报表系统，对更为复杂的业务流程应举例分析，才能更充分地体现方法与工具的作用。（本文主要参考了广东魏福建等人的论文）

系分论文4

论软件需求分析方法和工具的选用——论文4：IC行业内部的CAD应用

【摘要】

    本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。

    由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方法；在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对使用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性。

【正文】

    近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计到下流设计的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计。

    我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

    委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需求分析时的工作主要有两点：第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。

    在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件，对专业领域要求相当高，所以准备把此项目分成两部分：

   （1）界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动可能是最大的。

   （2）功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面的简单需求，相应来说只是完成深化。对界面，我采用了部分RUP的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。

    首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt（由于要支持Windows和Unix双平台，所以控件库采用Qt）的类库中选择相应的控件。在提取和抽象逻辑模型时，我采用了Rose 2000中的用例图，即以 USE-CASE图来描述与外部的关系。之所以采用Rose，我是基于以下的原因：第一，在已开发的部分中，委托方统一要求我们使用Rose进行类和顺序图等的设计和代码生成。第二，Rose提供了标准的图来描述系统与外部的关系，在全球范围已是一种标准结构。第三，使用上的方便性。我用Rose的USE-CASE图，理清了我们的软件窗口与委托方主窗口以及外部角色（操作者）之间的相互关系。

    在确定了界面元素后，考虑到文档的可理解性不是很强，我采用Visio 2000把界面的外观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，委托方基本批准了我的方案。

    下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose，我用了状态图和时序图，把重要的控件状态变化及相应顺序进行了描述，随后的几天把相应的DOC文档建好写明，基本上界面设计就完成了。

    下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的了解，这样在设计中自己始终是层层推进的，不至于一于碰到无法逾越的专业障碍。

    在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的E-Mail系统，所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段，它起到了一个与客户的交流沟通和客户需求的提取作用。所以，我认为在这一阶段，E-Mail系统是对我帮助最大的工具，其次是Excel，我用它建立了问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果（可分为已清楚、仍不太清楚、不清楚、尚未回答）均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效率。

    每进行一层的细化，我都把结果交付委托方审核，由他们进行提出何时能终止细化，大约在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需求分析基本成功了。

    在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。

    通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用。我认为在需求分析中工具的作用不外乎两个：一是实际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是Rose，第二类的代表是Word，WPS，Visio等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-Mail服务系统。

    最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因素还是—一“与客户的沟通”。

    评注；
   （1）较实际地讨论了方法与工具。（2）两类需求的讨论有点特色，解决需求问题的方法较成功，有说服力。（3）能发表自己的观点和意见，体会较实在。（4）本例似乎有些特殊性，还是要鼓励对自己熟悉的业务领域做项目，否则的话，有时会事倍功半。（5）最好再列举更多的项目或例子，使方法与工具的讨论更全面一些。（本文主要参考了上海解亮等人的论文）