软件需求分析pdf 软件需求 pdf

发布日期：2020-11-11

软件需求分析的需求类型有哪些呢？

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。

因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。

针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。

我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。

本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1~2分钟左右的响应时间，让客户无法忍受。

（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。

在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。

注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Seve，客户端采用Windows 98，程序架构采用的是传统的CS结构。

鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得 （第1）步结果的基础上写出基本需求，交由客户评审补充，（3）在 （第2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。

下面按上述三步分别加以论述。

第一步是实施逆向工程，获取原有系统的基本需求 由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。

在这一阶段，我们采用的主要工具是PB自带的Powe Designe和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。

采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。

在使用Powe Designe分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。

这里指出，使用Powe Designe的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。

第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充 通过第一步的逆向工程，我们获得了系统的基本需求。

为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Po、Clea Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。

但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。

之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。

正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Po所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。

在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Po进行需求管理，...

软件需求分析 有那些有用的书可以学习一下呢？

软件需求（第2版） Karl E.Wiegers、刘伟琴、 刘洪涛 清华大学出版社 （2004-11出版） 软件需求最佳实践：SERU过程框架原理与应用 徐锋 电子工业出版社需求分析与系统设计（原书第3版） 麦斯阿塞克（Leszek A.Maciaszek）、马素霞、王素琴、 谢萍 机械工业出版社 （2009-09出版） 这几本书都很不错的，你可以先到图书馆比较一下再根据自己的实际选择，祝你学习顺利...

visio对软件需求分析有什么用？

软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。

（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。

实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。

需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。

这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。

需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。

。

（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。

它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。

这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。

在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。

需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。

制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。

2）进行需求变更影响分析。

评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。

通过这些分析将有助于需求变更控制部门做出更好的决策。

3）建立需求基准版本和需求控制版本文档。

确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。

每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

4）维护需求变更的历史记录。

将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。

为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

5）跟踪每项需求的状态。

可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

6）衡量需求稳定性。

可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。

过多的需求变更＂是一个报警信号＂，意味着问题并未真正弄清楚。

4.需求分析评价标准（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。

例如尽量采用主语+动作的简单表达方式。

需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。

除了语言的二义性之外，注意不要使用行话，就是计算机术语。

需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。

但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。

要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。

（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。

在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。

严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。

实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。

这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

关于软件需求分析师

再进行具体地描述。

简单来说软件需求分析师的工作会有三个过程 获取：将调研获取到的内容进行归纳整理：将业务的需求转换为功能设计，然后系统性地进行分析，了解每一个业务模块是如何运作的，会有哪些改进空间.不好说，能否通过系统实现，是否会存在风险等等. 不一定要从程序员做起，但了解程序如何实现还是非常有必要的。

软件需求分析主要还是要透彻地了解业务，能够用一些工具和方法对业务进行合理地抽象，可以是在某个行业或者领域做几年然后多用用相关的行业软件，比如分几个大模块，每个模块实现什么：需要调研业务相关的人员，具体有哪些功能点，每个功能点满足什么业务需求等职业规划嘛..，了解当前业务是如何运作地，希望软件能够如何改进业务 分析，就能在业务上比较熟悉的同时也知道软件的一些实现原理..设计，这样就可以入行了；也可以是做程序员，做具体项目时多学习和理解业务，然后再转到需求岗位，这样也可以入行。

反正无非是两点：熟悉业务 ...

软件开发中,需求分析阶段产生的主要文档是

第一个步骤是市场调研（可行性分析“做还是不做”）第二个步骤是需求分析（软件需求规格说明书“做什么，不做什么”。

）第三个步骤是概要设计（概要设计说明书）第四个步骤是详细设计（详细设计说明书）第五个步骤是编码第六个步骤是测试（集成测试计划）选B...

软件需求分析在软件工程中的作用,有哪些软件需求分析的方法。

软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。

在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。

软件开发，能否获得成功，最重要的是需求分析的工作。

因此，软件需求分析能力和水平，对软件项目至关重要。

一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。

⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。

⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。

⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。

由计算机完成的功能就是新系统应该实现的功能。

常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。

这种方法可以比较准确地理解用户的需求，但比较耗费时间。

⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。

座谈时，参加者之间可以相互启发。

⑶请专人介绍。

⑷询问 对某些调查中的问题，可以找专人询问。

⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。

⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。

分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。