浅论软件需求分析的论文

浅论软件需求分析的论文（精选10篇）

浅论软件需求分析的论文 篇1

摘要：软件需求分析中的关键就是展开分析，发现问题，解决问题。所有的一切都是为了能够将软件中的错误和漏洞在需求分析和需求工程阶段发现并解决，这样才能使软件开发的成本收益比达到最大，使得软件在其生命周期中的维护费用降到最低。本文主要探讨了软件需求分析方法，希望可以通过对软件需求分析的方法研究为为以后软件的开发打下一个良好。

关键词：软件需求分析；过程；原则；工具；方法

1.软件需求分析的过程

软件需求分析的具体过程可分为软件需求目标的认定、分析与综合、制定规格说明和最终评审。首先来看如何对软件需求目标进行认定，软件需求的目标是指系统分析工程师和程序开发工程师在软件需求分析过程中，确定目标软件工程的综合要求，并提出实现这些要求所需要的条件，以及需求应达到的标准。这些需求具体包括：

（1）功能需求：列举出所开发软件在功能上应做什么。

（2）性能需求：给出所开发软件的技术性能指标。

（3）环境需求：软件系统运行时所处环境的要求。例如硬件环境：主机类型、外围设备、数据通信接口；软件方面：系统软件平台（包括单机操作系统、网络操作系统及应用软件、数据库管理系统等等）；以及使用部门在操作人员方面应达到怎样的条件。

（4）可靠性需求：按照实际运行环境对所开发的软件提出要求，尽量在需求分析阶段将所有的问题进行暴露。对于运行实效后可能产生的后果要有充分估计，应对软件运行的可靠性提出较高的要求。

（5）安全保密要求：在软件的需求分析过程当中应当对所开发的软件的安全性进行特殊设计分析，使其在实际开发完成之后的运行过程中安全性能得到必要的保证。

（6）用户界面的需求：对于用户界面的细致性以及易用性进行需求分析使其达到客户要求。

（7）资源使用需求：通过需求分析使得所开发的软件在运行时所需的系统资源处于用户可接受范围。

（8）软件成本消耗与开发进度需求：通过需求分析对软件开发的进度和各步骤的费用提出大致要求，作为开发管理的依据。

（9）最后对于所开发系统得最终所能达到的目标进行分析，以便在开发过程中对系统进行必要的修改与补充。在我们的需求分析过程中这些问题都是必需要得出分析结果的，并且结果应当得到软件开发工程师的认可。

在实际的软件需求分析中，单单依靠上述过程是不够的，有时候我们还需要通过对所得结论的分析与综合来得出工程系统的详细逻辑模型。

例如，在面向对象的软件工程当中进行软件需求分析时，通过对整个工程的需求进行分析，我们得出的仅是该软件工程的综合项目需求。这时就需要整理逻辑模型。在这个过程中，分析与综合工作需要反复的进行。而常用的分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法（简称JSD法）、面向对象的分析方法（简称为OOA）等，以及用于建立动态模型的状态迁移图或Petri网等工具。

通过这一步之后，我们就可以将所得到的分析结果描述成软件需求规格说明书（简称SRS），并编写初步的标准格式用户手册。进行软件需求规格说明书以及标准格式用户手册时，不仅需要正确详实的需求分析数据，还需要较好的文字表达和组织能力。需求分析评审则是指在需求分析的最后阶段，对整个系统的需求分析工作给出其在正确性、完整性和清晰性等几个方面的最终评价。

2.软件需求分析的原则和工具

软件需求分析方法很多，其所使用的描述方法也各不相同，但他们都有着共同的基本准则。首先，他们都必须能够表达和理解问题所包含的数据域和功能域；其次，他们必须按照自顶向下、逐层分解的方式对问题进行分解和不断细化；最后，他们都要能够给出系统的逻辑视图和物理视图。这就说明在需求分析当中无论我们采取什么样的分析方法，都无一例外的会回归到对问题数据域与功能域的分析上来，并且对于问题的分析会自然而然的逐渐细化。

3.软件需求分析的方法

在软件需求分析中方法很多，不同的分析方法也都引入了不同的记号和分析策略。但与此同时，他们也具有着一些共同的性质，具体可以概括为：在支持数据域分析机制方面，所有的方法都直接或间接地涉及到数据流、数据内容或数据结构等数据域的属性。

多数情况下，数据流特征是用将输入转化为输出的变换过程来描述的，数据内容则用数据字典机制来明确表示，或者通过描述数据或数据对象的层次节后隐含地表示；在功能表示方法方面，功能一般用数据变换或加工来表示。还有在接口定义、问题分解的机制以及抽象的支持、逻辑视图和物理视图以及系统抽象模型方面都有着相同或相似的机制。在这里我们重点分析快速原型方法。在传统的软件工程方法学中，一贯强调的是自顶而下的分阶段开发，在每阶段实际开发之前必须对所开发项目进行严格要求的分析和定义。但实践表明，在系统建立起来之前很难仅仅依靠分析就确定出一套完整、有效的需求应用，并且这样预先定义的策略也无法适应用户需求的不断修正与变化。

由此，快速原型方法应运而生，他自顶向下的开发模式，是目前应用十分广泛的开发模式。快速原型方法是根据软件系统的需求快速产生出软件系统一个早期原形的过程。该原型能够表现出目标系统的功能和行为特征，但不一定符合其全部的实现需要。

通过这个方法，软件设计者可以利用原型得到系统可用性的反馈信息，未来用户也可以利用原型得到宝贵的早期经验。并且利用这样的一个快速原型尽早的获得更完整、更正确的需求与设计。

在软件的开发过程当中即使客户对于系统的要求发生了更改，也可以通过对原型就行改进而得到新的目标系统，不必再从头做起。而且在现实中存在的快速原型建造工具可以大大缩减创建系统的时间，可以在短期内迅速有效地建立起系统的原型，充分提高软件开发效率，提高软件质量、减少测试和调试的工作量，最终减少软件开发的总成本。

在快速原型法的实现过程中，由于建立原型的目的不同，实现原型的途径也有所区别，大致划分为以下三类：

（1）探索型。为研究探索而建立的原型。主要强调澄清目标系统的需求及所要求的特征。

（2）实验型。为实验而建立原型。主要强调在正式进行目标系统的大规模开发工作之前，通过建立原型来确定所提出的解决方法是否恰当。这种原型方法通常针对用户的问题的某个方案做出原型以供试验评估，该原型所实现的功能与最终产品的功能是有差别的。

（3）进化型原型。为演示而建立的原型。主要强调通过逐步的分析改进使系统适应变化了的需求。并最终生成一个演进式的系统开发模式。当采用进化型原型方法时，必须进行原型与产品间的变换，除了在开始阶段时采用单独的研究探索性原型方法及实验性原型方法外，圆形的生产环境必须与产品的生产环境集成在一起。

总而言之，快速原型法是具有相当大优势的。因为它可以为开发出较为有用的系统做出极大贡献，并且不会增加总的软件开发费用，开发原型所增加的投资可以因减少误解而节省下来。

参考文献：

[1]王继成,高珍.软件需求分析的研究[J].计算机工程与设计,2002,(8):18-21.

[2]卢梅,李明树.软件需求工程-方法及工具评述[J].计算机研究与发展.1999,(11):29.

浅论软件需求分析的论文 篇2

软件需求分析的具体过程可分为软件需求目标的认定、分析与综合、制定规格说明和最终评审.首先来看如何对软件需求目标进行认定, 软件需求的目标是指系统分析工程师和程序开发工程师在软件需求分析过程中, 确定目标软件工程的综合要求, 并提出实现这些要求所需要的条件, 以及需求应达到的标准.这些需求具体包括: (1) 功能需求:列举出所开发软件在功能上应做什么. (2) 性能需求:给出所开发软件的技术性能指标. (3) 环境需求:软件系统运行时所处环境的要求.例如硬件环境主机类型、外围设备、数据通信接口;软件方面:系统软件平台 (包括单机操作系统、网络操作系统及应用软件、数据库管理系统等等) ;以及使用部门在操作人员方面应达到怎样的条件. (4) 可靠性需求:按照实际运行环境对所开发的软件提出要求, 尽量在需求分析阶段将所有的问题进行暴露.对于运行实效后可能产生的后果要有充分估计, 应对软件运行的可靠性提出较高的要求. (5) 安全保密要求:在软件的需求分析过程当中应当对所开发的软件的安全性进行特殊设计分析, 使其在实际开发完

成之后的运行过程中安全性能得到必要的保证. (6) 用户界面的需求:对于用户界面的细致性以及易用性进行需求分析使其达到客户要求. (7) 资源使用需求:通过需求分析使得所开发的软件在运行时所需的系统资源处于用户可接受范围. (8) 软件成本消耗与开发进度需求:通过需求分析对软件开发的进度和各步骤的费用提出大致要求, 作为开发管理的依据. (9) 最后对于所开发系统得最终所能达到的目标进行分析, 以便在开发过程中对系统进行必要的修改与补充。在我们的需求分析过程中这些问题都是必需要得出分析结果的, 并且结果应当得到软件开发工程师的认可.

在实际的软件需求分析中, 单单依靠上述过程是不够的, 有时候我们还需要通过对所得结论的分析与综合来得出工程系统的详细逻辑模型。例如, 在面向对象的软件工程当中进行软件需求分析时, 通过对整个工程的需求进行分析, 我们得出的仅是该软件工程的综合项目需求.这时就需要整理逻辑模型。在这个过程中, 分析与综合工作需要反复的进行.而常用的分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法 (简称JSD法) 、面向对象的分析方法 (简称为OOA) 等, 以及用于建立动态模型的状态迁移图或Petri网等工具.

通过这一步之后, 我们就可以将所得到的分析结果描述成软件需求规格说明书 (简称SRS) , 并编写初步的标准格式用户手册.进行软件需求规格说明书以及标准格式用户手册时, 不仅需要正确详实的需求分析数据, 还需要较好的文字表达和组织能力.需求分析评审则是指在需求分析的最后阶段, 对整个系统的需求分析工作给出其在正确性、完整性和清晰性等几个方面的最终评价.

2. 软件需求分析的原则和工具

软件需求分析方法很多, 其所使用的描述方法也各不相同, 但他们都有着共同的基本准则.首先, 他们都必须能够表达和理解问题所包含的数据域和功能域;其次, 他们必须按照自顶向下、逐层分解的方式对问题进行分解和不断细化;最后, 他们都要能够给出系统的逻辑视图和物理视图.这就说明在需求分析当中无论我们采取什么样的分析方法, 都无一例外的会回归到对问题数据域与功能域的分析上来, 并且对于问题的分析会自然而然的逐渐细化.

3. 软件需求分析的方法

在软件需求分析中方法很多, 不同的分析方法也都引入了不同的记号和分析策略.但与此同时, 他们也具有着一些共同的性质, 具体可以概括为:在支持数据域分析机制方面, 所有的方法都直接或间接地涉及到数据流、数据内容或数据结构等数据域的属性.多数情况下, 数据流特征是用将输入转化为输出的变换过程来描述的, 数据内容则用数据字典机制来明确表示, 或者通过描述数据或数据对象的层次节后隐含地表示;在功能表示方法方面, 功能一般用数据变换或加工来表示.还有在接口定义、问题分解的机制以及抽象的支持、逻辑视图和物理视图以及系统抽象模型方面都有着相同或相似的机制.在这里我们重点分析快速原型方法.在传统的软件工程方法学中, 一贯强调的是自顶而下的分阶段开发, 在每阶段实际开发之前必须对所开发项目进行严格要求的分析和定义.但实践表明, 在系统建立起来之前很难仅仅依靠分析就确定出一套完整、有效的需求应用, 并且这样预先定义的策略也无法适应用户需求的不断修正与变化.由此, 快速原型方法应运而生, 他自顶向下的开发模式, 是目前应用十分广泛的开发模式.快速原型方法是根据软件系统的需求快速产生出软件系统一个早期原形的过程.该原型能够表现出目标系统的功能和行为特征, 但不一定符合其全部的实现需要.通过这个方法, 软件设计者可以利用原型得到系统可用性的反馈信息, 未来用户也可以利用原型得到宝贵的早期经验.并且利用这样的一个快速原型尽早的获得更完整、更正确的需求与设计.在软件的开发过程当中即使客户对于系统的要求发生了更改, 也可以通过对原型就行改进而得到新的目标系统, 不必再从头做起.而且在现实中存在的快速原型建造工具可以大大缩减创建系统的时间, 可以在短期内迅速有效地建立起系统的原型, 充分提高软件开发效率, 提高软件质量、减少测试和调试的工作量, 最终减少软件开发的总成本.

在快速原型法的实现过程中, 由于建立原型的目的不同, 实现原型的途径也有所区别, 大致划分为以下三类: (1) 探索型.为研究探索而建立的原型.主要强调澄清目标系统的需求及所要求的特征. (2) 实验型.为实验而建立原型.主要强调在正式进行目标系统的大规模开发工作之前, 通过建立原型来确定所提出的解决方法是否恰当.这种原型方法通常针对用户的问题的某个方案做出原型以供试验评估, 该原型所实现的功能与最终产品的功能是有差别的. (3) 进化型原型.为演示而建立的原型.主要强调通过逐步的分析改进使系统适应变化了的需求.并最终生成一个演进式的系统开发模式.当采用进化型原型方法时, 必须进行原型与产品间的变换, 除了在开始阶段时采用单独的研究探索性原型方法及实验性原型方法外, 圆形的生产环境必须与产品的生产环境集成在一起.

总而言之, 快速原型法是具有相当大优势的.因为它可以为开发出较为有用的系统做出极大贡献, 并且不会增加总的软件开发费用, 开发原型所增加的投资可以因减少误解而节省下来.

摘要：软件需求分析中的关键就是展开分析, 发现问题, 解决问题.所有的一切都是为了能够将软件中的错误和漏洞在需求分析和需求工程阶段发现并解决, 这样才能使软件开发的成本收益比达到最大, 使得软件在其生命周期中的维护费用降到最低.本文主要探讨了软件需求分析方法, 希望可以通过对软件需求分析的方法研究为为以后软件的开发打下一个良好的基础.

关键词：软件需求分析,过程,原则,工具,方法

参考文献

[1]王继成, 高珍.软件需求分析的研究[J].计算机工程与设计, 2002, (8) :18-21.

软件工程中的需求分析 篇3

关键词：软件工程；CMM；需求管理；需求分析

中图分类号：TP311 文献标识码：A 文章编号：1674-7712 （2012） 18-0039-01

“软件工程”这个名词是1968年美国和西欧的一些科学家在NATO（北大西洋公约组织）会议上第一次提出的，是利用工程学的方法开发和维护计算机软件的一门学科。本篇论文粗浅分析的是软件工程中的需求分析。

软件开发由需求分析、概要设计、详细设计、编码、软件测试、项目维护和软件集成几部分内容组成。英文中有个全称为CapabilityMaturityModelforSoftware，缩写为SW-CMM，简称为CMM，用汉语表达出的意思就是——“能力成熟度模型”，也就是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。软件开发被CMM的核心视为一个过程，并根据这一核心原则对其进行过程监控与研究，目的是更加科学化、标准化，在监督过程中发现影响项目的关键问题并予以解决，使企业能够更好地实现商业目标。软件开发人员开发和维护软件及相关产品的一套行为、方法、实践及变换过程被定义为软件过程，它包括软件开发过程和软件管理过程。CMM把软件开发机构按照不同开发水平划分为5个级别，每个等级被分解为几个KPA（关键过程域），KPA是指在某个成熟度等级应重点关注的区域，也是达到此成熟度等级必须解决的关键点。在CMM中成熟度第二等级有6个关键过程域，主要涉及建立软件项目管理控制方面的内容。即：需求管理（RM）、软件项目计划（SPP）、软件项目跟踪与监控（SPTO）、软件子合同管理（SSM）、软件质量保证（SQA）、软件配置管理（SCM）。

软件项目管理中还有一个非常关键的步骤——需求管理。对于计算机系统的认识，很多用户有很多盲区，对于系统的具体需求往往也比较模糊，经常出现疏漏或者是错误的问题，随着项目的进展，凸现的会愈发明显。对于开发人员来说，软件产品的部分内容必须重新开发，这就意味着需求的变更。而对于整個软件项目管理而言，势必要重新分配资源、调整计划、估算成本等等。需求分析的完整与否可以控制软件质量、决定项目周期、增减项目成本。故而：需求管理工程越来越成为热点。

需求获取的正确性和有效性要求很高：角色的专业化、业务创新的复杂、交付速度等等。有时缺少特定需求的某些信息。在解决这个不确定性之前，可能必须与客户商议，检查与另一个系统的接口或者定义另一个需求。使用“待确定”符号作为标准指示器来强调软件需求规格说明中的这些需求的缺陷。

设计一个软件应用系统的起点与基本依据是需求分析。对用户来讲最重要的是有效性，高效性，灵活性，完整性，互操作性，可靠性，健壮性，可用性。对开发者来说最重要的是可维护性，可移植性，可重用性，可测试性。在属性取舍方面，用户和开发者必须确定属性优先级，做决策时始终遵照优先级，为了达到产品特性的最佳平衡，必须在需求获取阶段识别，确定相关的质量属性并为之确定优先级。当为项目定义重要属性时利用属性间正负关系图可防止发生与目标冲突的行为。通常一个软件项目合同的签订，体现的可能是整个系统的目标需求，面向用户的需求往往被忽略，对于这种情况一定要注意需求更改的可控性。任何一个需求分析因客观原因可能存在着需求更改的现象，要使受需求变化影响的产品与需求变更一致，就要建立需求的基准版本和更改版本，真正了解用户想要解决的实际问题，即使需求的变更比较频繁，也要注重需求的稳定性。直接影响到软件过程的改进因素离不开需求分析的完整性和变更可控性，它不仅可以决定软件的质量、开发成本的高低、甚至是导致项目成败的关键。

需求管理员是软件工程组（SEG）中要明确定义的一个角色。具体操作步骤有几点：

第一：多角度全方位的对项目进行分析并且对项目的可行性进行论证；

第二：对客户进行需求调研，整理客户需求，负责编写用户需求说明书；

第三：负责将完成的项目模块给客户做演示，并收集完成模块的意见；

第四：协助系统架构师、系统分析师对需求进行理解。

有了上述铺垫，毋庸置疑的一个角色也要出场了，那就是——需求工程师。再好的软件如果没有做好需求分析也将失去市场意义，失去生存活力。需求工程师是沟通用户与开发人员的桥梁，做好需求分析是一个产品是否能够适应用户要求的关键所在。需求工程师们在了解用户又了解技术的基础上掌控项目发展的风向标。

计算机软件工程中的需求分析要解决的任务是"做什么"的问题，全面地理解用户和开发人员的各项要求，准确表达所接受的需求。之所以重要，是因为它具有决策性、方向性、策略性的作用，从某种程度上说，它的作用可能并不小于程序设计，而且是提高软件质量的基础，也是决定一个软件项目成败的关键。

参考文献：

[1]孙琦龙.一种加强软件项目管理的实践模式[J].科技信息，2008.

[作者简介]王一帆，大连交通大学09级日语和软件工程二班。

软件需求分析师的职位职责 篇4

1. 负责公司软件需求的调研、收集、整理工作;

2. 参与项目需求调研、需求讨论、需求梳理、需求分析等;

3. 输出产品或项目需求规格说明书、系统初版原型;

4. 向开发工程师提供咨询、指导、以及业务解释，提供需求澄清工作;

5.负责需求的开发与跟踪、完成需求变更的控制与管理;

6.参与需求验收，与开发测试团队一起保证最终产品满足用户需求和市场需要。

岗位职责：

1. 熟练掌握相关需求分析工具，能熟练撰写需求分析、规格文档;

2. 了解需求分析的基本方法和工作流程，负责过具体产品或项目的需求分析已经规格文档的撰写工作;

3. 能熟练使用常用的原型设计工具，如Axure RP Pro等;

4. 善于发现产品中的创新点，并能够根据业务需求进行创新转化;

5. 乐观进取、高度的工作热情，有良好的团队合作精神;

6. 良好的沟通技巧和说服力，能承受较大的工作压力;

软件项目需求分析总结 篇5

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。

浅论软件需求分析的论文 篇6

关键词:面向对象;软件工程;软件需求分析

本文主要阐述软件需求分析在关键工程中的必要性，并描述了面向对象的软件工程中软件需求分析的任务、过程和方法。

1软件工程

软件工程涉及程序涉及语言、数据库、开发工具、以及设计模式等等，是研究并维护软件的一门学科。在目前的社会中，软件在各个方面都被广泛的应用，如办公套件、操作系统以及游戏。其中计算机软件的应用在银行、工农业、、企业中的应用更为广泛，有了这种软件工程的加入，让人们的生活和工作的质量更高，同时也加强了工作效率，推动社会经济的发展。开发软件的职业是软件工程师，也能够根据所负责的工作不同进行划分为系统分析员、软件设计师、系统架构师和程序员等。软件工程在学界中并没有专一的概念，比较被大部分人认可的定义为：软件工程是针对软件出现的各种问题而出现的一门学科，同时也是对软件进行一系列研究的方法。软件工程的目标在于研发质量较高的软件产品，使软件在功能、可靠、使用、效率、维护、移植等方面都具有良好的标准。软件工程的表现为以下几点：首先，软件并不是指实际产品，它是指逻辑上存在的产品，费用的使用也主要是在研制过程中，软件的问题并不存在像实物中一些用坏或者损坏情况，而是存在过时问题；其次，软件的功能体现是靠用户的使用和软硬件的运行状态，而且其功能的复杂性也高于一般产品；最后，软件设计在功能和实现上有很大的多样性，提升软件的质量和开发效率就是推动软件工程发展的关键。

2软件需求分析具体过程

软件需求分析的过程主要有四个阶段，分别为确定软件需求目标、进行分析并整合、规格的相关说明规定、以及最终评审。确定软件需求目标在涵义上是指系统分析师和程序开发工程师在进行工作中，找出目标软件工程所需的要求，从而讲述出能够达到要求所需要的条件。一般来说，这些要求主要体现在功能、性能、环境、可靠性、安全性以及用户界面、资源使用、软件成本消耗与开发进度等。

（1）功能是指将软件的功能开发；

（2）性能则在于软件技术性能标准；

（3）环境是指如硬件和软件方面在软件系统运行时的`要求，另外还包括对使用此软件的工作人员的技术要求；

（4）可靠性是通过软件在开发过程中对实际环境的要求，并满足在进行需求分析时显露出所有存在的问题，估计运行后会产生的后果，提出更高的可靠性；

（5）安全性是指安全保密，在进行开发时特别针对安全性能严格要求，保证在日后的使用过程中能够拥有强大的安全性能；

（6）用户界面要根据客户的要求进行需求分析；

（7）资源使用是要保证用户能够接受在软件的使用中的资源需求；

浅论软件需求分析的论文 篇7

本文将以软件需求工程为侧重点、从软件需求变更的原因、影响、原则及管理方案为研究领域进行分析和讨论。

一、软件需求变更的主要原因分析

1、客户需求因素。

在软件的开发过程中, 客户会随着项目开发的进程逐渐达成对软件系统的深入了解和认识, 在不断的思考过后形成了新的需求信息或改进的需求信息, 进而会提出满足其新需要的软件变更条款。2、系统内部因素。在软件开发过程中, 计算机外部硬件设备、系统软件、系统数据等内部系统之间的相互适应要求都会引起软件需求的变更。这种需求变更将会以硬件设备、操作系统、系统软件等原始系统因素为基础进行更新、升级、换代, 以此确定软件设计的安全性、兼容性和准确性。3、业务环境因素。在软件开发过程中, 与软件开发相关联的制度、规范、政策等的重新改写与设定, 或是软件开发业务要求的不断改变都将会引起软件需求变更。例如, 软件的需求会随着保险制度的变化而变更, 会随着交通制度的变化而变更等等。4、需求开发缺陷因素。在软件需求开发过程中, 需求信息调查研究、需求文档的编写及评审等工作的不足都是影响软件需求变更的主要原因。

二、软件需求变更的主要影响分析

1、影响软件开发的实际进度。

频繁的需求变更不仅需要大量项目人员的支持, 还需要投入大量的经费, 如果投入的力度过大, 将会导致软件开发项目超过预期甚至导致失败。

2、影响软件开发质量的优良。

在软件开发过程中, 需求的不断变更将会导致原有的需求链断裂, 对原定需求的部分环节造成影响, 而这些影响又将导致软件开发项目设计的改变, 最终导致系统质量的下降, 开发效率的降低。

3、影响客户与开发者之间的相互合作。

软件开发是客户与开发者之间的一种相互信任、相互合作的过程。如果二者之间在软件需求变更上产生不同意见, 而且没有得到妥善的处理, 将会导致二者之间的合作关系破裂, 甚至造成软件开发中断等严重后果。

三、软件需求变更的处理原则

1、完整性原则。

完整性是软件安全的基本要点。在软件开发过程中, 要保证需求变更信息的采纳收集、汇总整理、评判审核、监视追踪等环节的完整性, 保证软件需求变更能够按照规范的流程进行操作。

2、合理性原则。

在软件开发过程中, 客户与需求分析人员将会以不同的视角、不同的态度评估需求变更条件, 要想达成软件开发的精确性, 就需要在用户需求、软件技术和整体开发能力的基础上, 达成需求变更的合理性, 实际性。

四、软件需求变更的有效管理方案

1、达成开发者与客户之间的有效沟通。

在发生软件需求变更时, 需求分析人员要与客户进行及时有效的沟通和反复的确认, 向客户说明开发建议和解决方案并制定相应的合同规范, 以此来达成对客户的承诺和软件修改后的满意度。2、制定软件需求变更信息的整理报告。在软件需求变更过程中, 要对客户需求的规范、变更后的功能、软件质量目标、变更解决方案等信息进行整理、分析和记录, 制定明确的需求分析整理报告, 以此来确保需求变更的准确性、实际性与科学性。3、进行明确、合理的人员分工。在需求变更达成协议后, 就需要对开发人员进行合理的安排和组织, 对操作人员和测试人员进行明确的分工;利用合理的需求变更管理工具, 达成整体软件项目开发的高效和优质。4、做好需求和产品特性的评审和测试工作。做好需求变更相关信息的记录后, 需求分析人员要组织开发、测试与客户等相关人员对更改后的需求进行评审和测试, 筛出掉不符合实际的变更需求, 确保需求变更流程的顺利进行。在软件变更实施的最后阶段, 要对软件产品系统进行测试, 以检验其是否满足客户的原定需求、是否达到了预期的效果和期望, 以保证更改后产品系统的基准性和安全性。

总之, 在出现软件需求变更状况时, 首要的就是与客户做好沟通和协商, 其次要做好需求变更信息的详细记录, 最后做好软件需求变更后的测试。只要做好这关键的三部, 就能够充分确保软件开发的规范化和优质化。

参考文献

[1]李厚明.软件项目需求变更风险管理[D].山东大学2012

浅论软件需求分析的论文 篇8

关键词：原型法；软件项目；需求分析

中图分类号：TP311.52 文献标识码：A文章编号：1007-9599(2011)07-0000-01

How to Carry Out the Needs Analysis of Software Projects Using Prototyping

Tang Hao (Huazhong University Of Scince and Technology Wenhua College,Wuhan430074,China)

Abstract:Carried out using prototype software project needs analysis,requirements analysis can greatly increase the work efficiency.In this paper,the project needs analysis,based on the analysis of the advantages and disadvantages of the prototype and how to use the prototype to carry out needs analysis of software projects put forward their constructive comments.

Keywords:Prototype;Software project;Needs analysis

一、软件项目需求分析的背景

软件需求分析是一个项目的开端，也是项目最重要的关键。由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，一旦需求分析做错了，不但会给系统功能带来极大的损害，不断的修改也会浪费资源。曾有调查报告显示，现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因就是由于需求分析不透彻或错误，结果软件产品存在不完整、不正确的问题等。

二、原型法及其优缺点

（一）什么是原型法。原型法是一种将系统调查、系统分析和系统设计合而为一的工作方法[1]。原型法强调开发人员与用户之间的相互作用：用户通过在计算机上实际运行和试用原型系统得到亲身感受并受到启发向开发者提供真实的反馈意见；鼓励开发者改进和创造，通过不断交流来提高需求实现的质量和软件产品的质量。原型需求分析法是目的是为了双方能更及时、准确、真实地反馈信息，增加系统的可靠性和适用性，更好地提高客户满意度。（二）原型法的优缺点。1.优点：原型法克服了传统软件生命周期法的一些弊端，具有快速灵活、交互式等特点，因而更容易被人们掌握和接受。主要体现在：（1）通过软件开发者和用户及时的沟通交流，使主要功能性的需求明确化，可以容易地确定需求，使潜在问题能尽早发现并及时解决；（2）大大降低原型开发工作量，修改和补充方便，提高了开发人员的工作效率；（3）提前考虑了系统的设计与实现，大大降低了减系统开发的风险，这一效果在项目需求分析难以一次完成思维大型项目的开发中体现得较为明显项目管理论坛；（4）用户由于参与了开发的过程将有利于系统的移交、运行和维护。同时，提高了用户参与开发的积极性。2.缺点：（1）适用范围有限。它的局限性是对于大型、复杂、处理过程较为繁琐、需要大量的运算、逻辑性较强的系统不太适合；因为原型法对用户需求的了解缺乏彻底和全面的认识，很难提出一个合适的模型，供用户评价和提出修改建议。（2）由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得用户盲目纠错，通过原型构造、试用运行、评价反馈、分析修改的多次反复要花费人力、物力，导致成本增加也拖延了开发过程。

三、使用原型法进行需求分析的流程

（一）快速分析、弄清需用户的基本信息需求。需求分析原型法的第一步是在分析人员和用户进行交流后，把所要体现的特性用交互、快速建立起来的原型取代不太明确的需求规格说明体现出来[2]。需要满足用户的需求主要有功能需求、性能需求、环境需求可靠性需求、安全保密工作需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求预先估计以后系统可能达到的目标。在诸多的功能性需求和非功能性需求中关键是要选取核心需求来描述，先放弃一些次要的功能和性能。这样才能集中力量确定核心需求说明，双方讨论和确定初始需求的可用性，从而能尽快开始构造原型。（二）构造系统原型。需求分析原型法的第二步是在快速分析的基础上，根据用户的基本信息需求尽快建立一个能运行的交互式应用系统。在这一步骤的实现主要由开发人员去负责建立一个初始原型。先考虑原型系统应必备的待评价特性，暂时可忽略安全性、健壮性、异常处理等一切次要的内容。节省时间和后期的修改工作量。（三）运行、评审系统原型。这个阶段是开发人员与用户沟通最为频繁的阶段，是发现问题和消除误解的重要阶段。用户在开发人员的指导下试用原型，在试用的过程中考核和原型是否完成、功能是否需要细化、规格说明书是否需要确定、评价原型系统的正确性、可行性、必要性、具有优先级属性、可验证性和无二义性。得出效果是否满意的结论。

四、利用原型法开展软件项目的需求分析的建议

（一）重视需求分析，明确需求分析的任务。需求分析如同建一座房子需要图纸，在软件需求分析中也需要有一份客户和开发人员对所开发的产品达成共识详细的文档，软件开发者要根据用户的需求使用相应的软件系统来帮助用户解决实际问题。这要求在所有涉及需求细节方面的问题都要重视，这个基石没打好，后面的设计和开发工作便会功亏一篑。（二）为了减少系统的开发成本，要减少需求变更，保证需求分析的稳定性。要减少需求就要做到以下方面：在需求分析的初始阶段要对开发人员进行相关知识的培训；加强开发方与用户间协作和交流；通过签订有法律依据的合同约束不合理的要求；对适当的需求变更可增加相关合同条款；需求评审后设置需求基线将变更引起的麻烦减至最小。（三）简化作为需求分析工具的系统原型。简化系统原型第一个阶段就是要解决“有什么”的问题，由项目开发经理与用户进行协商，确定系统的技术协议。以合同的形式经开发人员与用户签字盖章后正式生效。技术协议的主要内容有：系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。第二个阶段解决“做什么”的问题。主要工作有需求调查准备、到用户单位进行需求调查分析和进行需求评审。这就简化了程序，采用此方法，开发同类项目越多，需求分析工作的效率越高。

五、结束语

需求分析阶段是管理信息系统开发最重要的阶段。原型法由于能较好了解和澄清用户的需求，改变了系统的分析、设计和实现三个顺序阶段的观点和传统的自顶向下的开发模式，降低了软件需求的风险，因此得到了广泛的应用。原型法还需进一步更好地修改和完善提升软件项目的需求分析的开展。

参考文献：

[1]毋国庆,朱立松等.嵌入式实时系统的软件需求检测.软件学报,2002.5(13)

需求分析在软件开发中的重要性 篇9

摘要：

“需求分析”,就是对需要解决的问题进行详细分析,弄清楚需要解决的问题。开发人员需要了解顾客的需求,然后体现在软件中。如果说软件开发过程中,开发人员需要了解自己做什么,顾客需要告诉开发人员自己需要什么,而需求分析就是连接开发人员和顾客之间的重要纽带。只有真正理解顾客的需求,才能设计出顾客所需要的软件。

在过去很长一段时间,开发人员的认为需求分析是整个开发过程中最简单的一个环节。然后越来越多的开发人员认识到它才是整个开发过程中的核心部分。正所谓“磨刀不误砍柴工”。只有真正理解了顾客的需求,才能顺利开发出顾客真正需要的软件。如果一味追求进度,而忽略需求分析,很可能南辕北辙,开发变得毫无意义。

关键字：需求分析，详细分析，开发过程，进度，开发人员。

一、绪论

随着计算机在日常工作中的普及，软件开发行业作为其必不可少的组成部分，被人们所认可。在我国，软件行业日渐成熟，小作坊式的开发形式，已经不能满足我国对于软件规范化、实用性的要求，软件开发流程化及各个职能部门工作的有效划分和正确协作，是现在软件行业面临的一个较大的问题。软件需求分析是软件开发的出发点，为设计起到指导性作用，所以需求分析在软件行业及开发流程中起着非常重要的作用。

“需求分析”,就是对需要解决的问题进行详细分析,弄清楚需要解决的问题。开发人员需要了解顾客的需求,然后体现在软件中。如果说软件开发过程中,开发人员需要了解自己做什么,顾客需要告诉开发人员自己需要什么,而需求分析就是连接开发人员和顾客之间的重要纽带。只有真正理解顾客的需求,才能设计出顾客所需要的软件。

在过去很长一段时间,开发人员的认为需求分析是整个开发过程中最简单的一个环节。然后越来越多的开发人员认识到它才是整个开发过程中的核心部分。正所谓“磨刀不误砍柴工”。只有真正理解了顾客的需求,才能顺利开发出顾客真正需要的软件。如果一味追求进度,而忽略需求分析,很可能南辕北辙,开发变得毫无意义。

一、什么是软件需求分析

通俗地说，软件需求分析是解决做什么，怎么做的问题。告诉客户及开发人

员，需要实现哪些功能，以何种方式，在什么平台去进行操作，开发结束后，应交付哪些东西。

需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.(这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.)

二、需求分析的任务

简言之,需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.(一)了解顾客的要求

这是需求分析的重点任务,也是最基本的任务。只有正确了解、理解顾客的要求,才能顺利完成需求分析。

(二)分析系统的数据要求

软件产品是指软件开发商根据市场需要开发的、具有一定适用性和潜在客户的、可销售的软件成品。它区别于应特定客户需求或根据订单开发的软件商品，通常应具有更高的通用性和适应性。但它的通用性和适应性不是轻而易举就能达到的。要实现软件的产品化，就必须在软件产品的设计上下一番功夫。

本文结合一个“多媒体远程教学系统”实例，探讨软件产品设计中的一些经验与看法。

三、需求分析的过程

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.（一）、问题识别

就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.（二）、分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).（三）、制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.（四）、评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

四、需求分析的方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。

追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.五、总结

浅论软件需求分析的论文 篇10

本章介绍需求分析的意义概念和方法了解结构化分析方法和需求管理的关键活动要求学会运用实体关系图数据流图和状态控制图进行结构化分析建模能够编写软件需求规格说明 学习方法

正确理解需求工程涉及的基本概念结合具体实例运用结构化分析技术从而达到理论学习及在实际项目中应用的目的 难重点

本章的学习重点在于理解软件需求的概念和重要性熟悉需求开发和需求管理的基本思想和主要活动掌握结构化的分析方法难点是怎样在实际的软件项目中灵活运用这些思想和方法 课前思考 软件需求存在什么问题 什么是软件需求 什么是需求工程 常见的需求分析方法是什么 需求分析的结果可以验证吗 需求规格说明有什么质量要求

本节知识点 软件需求的定义 需求的层次 导致需求缺陷的原因

随着计算机技术的飞速发展软件已经成为人们生活中不可缺少的一部分人们在使用软件的过程中常常会抱怨它无法执行某些基本操作但对于软件开发人员而言用户不断提出新的要求是一件多么烦人的事

其实在软件开发过程中遇到的许多问题都是由于收集编写协商修改软件需求过程中的失误带来的诸如信息收集不全功能不明确交流不充分文档不完善需求发生变化等可以这样说软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”

开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写详细的技术需求包括所有面向用户面向机器和其它软件系统的接口

IEEE软件工程标准词汇表将需求定义为

1用户解决问题或达到目标所需的条件或能力

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

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

下面列出其他几种关于需求的定义 需求是用户所需要的并能触发一个程序或系统开发工作的说明 需求是从系统外部能发现系统所具有的满足于用户的特点功能及属性等 需求是指明必须实现什么的规格说明它描述了系统的行为特性或属性是在开发过程中对系统的约束

软件需求包括四个不同的层次即业务需求用户需求和功能需求另外还有非功能需求

软件需求各组成部分之间的关系如下图所示

业务需求 反映了组织机构或客户对系统或产品高层次的目标要求它们在项目视图与范围文档中予以说明

用户需求

描述了用户使用产品必须要完成的任务可以在用例模型或方案脚本中予以说明

功能需求

定义了开发人员必须实现的软件功能使得用户能完成他们的任务从而满足了业务需求 非功能需求

是从各个角度对系统的约束和限制反映了应用对软件系统质量和特性的额外要求

非功能需求包括过程需求产品需求和外部需求三类其中过程需求有交付实现方法和标准等需求产品需求包含性能可用性实用性可靠性可移植性安全保密性容错性等方面的需求外部需求有法规成本操作性等需求

需求工程中的缺陷将给项目的成功带来极大风险导致缺陷的原因主要包括以下方面 缺乏足够的用户参与

客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫开发人员可能也不重视用户的参与究其原因一是因为与用户合作不如编写代码有意思二是因为开发人员觉得已经明白用户的需求了在某些情况下与实际使用产品的用户直接接触很困难而客户也不太明白自己的真正需求然而在项目的早期让具有代表性的用户直接参与到开发队伍中并一同经历整个开发过程很重要

用户需求不断增加

在开发过程中用户需求经常发生变化但是不断的变更会使其整体结构越来越乱整个程序也难以理解和维护如果要减少需求变更的影响范围就必须在项目的开始对项目视图范围目标约束限制和成功标准给予明确说明并将此说明作为评价需求变更和新特性的参照框架

需求模棱两可

模棱两可是需求规格说明中最严重的问题它意味着不同的人对需求说明产生了不同的理解或者是同一个人能用不止一个方式来解释某项需求说明模棱两可的需求带来的后果便是返工--重做一些你认为已做好的事情返工会耗费开发总费用的40而70～85的重做是由于需求方面的错误引起的添加不必要的特性

有时候开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能然而常常是用户并不认为这些功能性很有用开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡

规格说明过于简单

客户往往不明白需求分析的重要性只是提供一份十分简略的规格说明仅涉及产品概念上的内容然后让开发人员在项目进展中去完善从而导致开发人员先建立产品结构再完成需求说明

忽略了用户分类

大多数产品是由不同的人使用其不同的特性使用频繁程度也有所差异使用者受教育程度和经验水平也不尽相同如果你不能在项目早期就针对所有这些主要用户进行分类的话必然导致有的用户对产品感到失望

总体来说导致需求缺陷的原因主要体现在三个方面 需求的沟通与理解 需求的变化与控制 需求说明的明确与完整 需求工程中的缺陷将给项目成功带来极大风险如产品的成本过高产品的功能和质量无法完全满足用户的期望等等即使一个项目团队的人员和配备都很不错但不重视需求过程也会付出惨痛的代价

本节知识点 需求工程的内容 需求获取 需求分析 编写需求文档 需求验证

需求工程是指应用已证实有效的原理和方法系统地描述出待开发系统及其行为特征和相关约束

通常需求工程由一些过程组成可分为需求开发和需求管理两部分

需求开发的主要活动 确定产品所期望的用户类 获取每个用户类的需求 了解实际用户任务和目标以及这些任务所支持的业务需求 分析源于用户的信息以区别用户任务需求功能需求业务规则质量属性建议解决方法和附加信息

将系统级的需求分为几个子系统并将需求中的一部份分配给软件组件 了解相关质量属性的重要性 商讨实施优先级的划分 将所收集的用户需求编写成规格说明和模型 评审需求规格说明确保对用户需求达到共同的理解与认识并在整个开发小组接受说明之前将问题都弄清楚

需求管理的主要活动 定义需求基线 评审提出的需求变更评估每项变更的可能影响从而决定是否实施它 以一种可控制的方式将需求变更融入到项目中 使当前的项目计划与需求一致 估计变更需求所产生影响并在此基础上协商新的承诺 让每项需求都能与其对应的设计源代码和测试用例联系起来以实现跟踪 在整个项目过程中跟踪需求状态及其变更情况

今天我们引入“需求工程”的概念强调用工程化的方法进行需求开发和需求管理其中需求开发是采用有效方法获得高质量需求的过程而需求管理则是在需求说明形成之后有效地控制其变更的过程二者缺一不可

一工作内容 聆听用户的需求 分析和整理所获取的信息 形成文档化的描述 二基于用例的方法

随着面向对象技术的发展基于用例的方法在需求获取和建模方面应用得越来越普遍这种方法是以任务为中心和以用户为中心的比起使用以功能为中心的方法它可以使用户更清楚地认识到新系统允许他们做什么

用例模型以用户和任务为中心将整个工作的焦点集中在从用户的角度说明系统能够干什么完全不考虑具体的实现细节从而达到准确地理解客户需求的目的在用例模型中角色和用例是两个基本概念分别代表着系统外部的执行者和系统应包含的功能因此建立用例模型的主要工作是确定角色确定用例和描述用例 A确定角色

角色代表着与系统交互的人或事通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等可以有效地识别出系统角色 B确定用例

一个完整的系统包含若干个用例每个用例具体说明应完成的功能识别用例首先要确定系统所能反映的外部事件并把这些事件与参与的执行者和特定的使用实例联系起来最终绘制出用例图 C描述用例

单纯地使用用例图不能提供用例所具有的全部信息因此需要使用文字描述那些不能反映在图形上的信息用例描述实际上是关于角色与系统如何交互的规格说明要求清晰明确没有二义性

建立用例模型是一种需求获取的有效方法其简洁清晰的描述方式容易被软件人员和用户共同理解和接受这种方法已经在许多大型系统的开发中取得成效实践证明它能有效地解决用户参与的问题

需求分析主要是对收集到的需求进行提炼分析和仔细审查以确保所有的风险承担者都明白其含义并找出其中的错误遗漏或其它不足的地方形成完整的分析模型分析的目的在于开发出高质量的和具体的需求从而支持项目的估算和软件的设计开发和测试

需求分析的主要活动包括 绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求的优先级别 创建数据字典 为需求建立模型

绘制系统关联图

这种关联图用于定义系统与系统外部实体间的界限和接口的简单模型

创建用户接口原型

当开发人员或用户不能确定需求时开发一个用户接口原型可以使许多概念和可能发生的事更为直观明了用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题同时找出需求文档与原型之间所有的冲突之处 分析需求可行性

在允许的成本和性能要求下分析每项需求实施的可行性明确与每项需求实现相联系的风险包括与其它需求的冲突对外界因素的依赖和技术障碍

确定需求的优先级别

应用分析方法来确定用例产品特性或单项需求实现的优先级别以优先级为基础确定产品版本将包括哪些特性或哪类需求当允许需求变更时在特定的版本中加入每一项变更并在那个版本计划中作出需要的变更 为需求建立模型

需求的图形分析模型是软件需求规格说明极好的补充说明它们能提供不同的信息与关系以帮助找到不正确的不一致的遗漏的和冗余的需求这些模型包括数据流图实体关系图状态变换图对话框图对象类及交互作用图等 创建数据字典

数据字典是对系统用到的所有数据项和结构的定义以确保开发人员使用统一的数据定义在需求阶段数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语

分析建模的方法有很多其中最重要的两种方法是结构化分析和面向对象分析 结构化分析方法提供实体关系图数据流图和状态转换图三种图形模型分别进行数据建模功能建模和动态建模

人们习惯于用自然语言来描述软件需求但这会产生许多意想不到的问题如不精确二义性等因此需要采用适当的方法形成一致的完备的和无二义性的软件需求规格说明

通常编写软件需求规格说明有三种方法 将结构化语言与自然语言结合编写文本型文档 建立可视化的模型 采用形式化的方法进行需求规格说明

软件需求规格说明是需求开发的最终结果它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件软件需求规格说明不仅是系统测试和用户文档的基础也是所有子系列项目规划设计和编码的基础

软件需求规格说明是用户分析人员和设计人员之间进行理解和交流的手段 测试人员可以根据软件需求规格说明中对产品行为的描述制定测试计划测试用例和测试过程 文档人员根据软件需求规格说明和用户界面设计编写用户手册等 软件需求规格说明指导着整个系统的开发过程评审过的需求规格说明需要进行变更控制

a 引言

概要叙述软件需求规格说明便于读者理解文档如何编写以及如何阅读和解释

在软件项目中开发组织应该采用一种标准的软件需求规格说明的模板现在有许多软件需求规格说明模板可以使用这里介绍其中的一种 a1 目的

对产品进行定义在该文档中详尽说明了这个产品的软件需求包括修正或发行版本号如果这个软件需求规格说明只与整个系统的一部分有关系那么就只定义文档中说明的部分或子系统 a2 文档约定

描述编写文档时所采用的标准或排版约定包括正文风格提示区或重要符号

a3 预期的读者和阅读建议

列举了软件需求规格说明所针对的不同读者例如开发人员项目经理营销人员用户测试人员或文档的编写人员描述了文档中剩余部分的内容及其组织结构提出了最适合于每一类型读者阅读文档的建议 a4 产品范围

提供了对指定的软件及其目的的简短描述包括利益和目标 a5 参考文献

列举了编写软件需求规格说明时所参考的资料或其它资源可能包括用户界面风格指导合同标准系统需求规格说明使用实例文档或相关产品的软件需求规格说明在这里应该给出详细的信息包括标题名称作者版本号日期出版单位或资料来源以方便读者查阅这些文献 b 综合描述

这一部分概述了正在定义的产品以及它所运行的环境使用产品的用户和已知的限制假设和依赖 b1 产品的前景

描述了软件需求规格说明中所定义的产品的背景和起源说明了该产品是否是产品系列中的下一成员是否是成熟产品所改进的下一代产品是否是现有应用程序的替代品或者是否是一个新型的自含型产品如果软件需求规格说明定义了大系统的一个组成部分那么就要说明这部分软件是怎样与整个系统相关联的并且要定义出两者之间的接口 b2 产品的功能

概述了产品所具有的主要功能其详细内容将在d中描述所以在此只需要概略地总结例如用列表的方法给出很好地组织产品的功能使每个读者都易于理解用图形表示主要的需求分组以及它们之间的联系例如数据流程图的顶层图或类图都是有用的 b3 用户类和特征

确定你觉得可能使用该产品的不同用户类并描述它们相关的特征有一些需求可能只与特定的用户类相关将该产品的重要用户类与那些不太重要的用户类区分开 b4 运行环境

描述了软件的运行环境包括硬件平台操作系统和版本还有其它的软件组件或与其共存的应用程序 b5 设计和实现上的限制

确定影响开发人员自由选择的问题并说明这些问题为什么成为一种限制可能的限制包括如下内容

必须使用或者避免的特定技术工具编程语言和数据库 所要求的开发规范或标准 企业策略政府法规或工业标准 硬件限制例如定时需求或存储器限制 数据转换格式标准 b6 假设和依赖

列举出在对软件需求规格说明中影响需求陈述的假设因素以及项目对外部因素存在的依赖 c 外部接口需求

利用本节来确定可以保证新产品与外部组件正确连接的需求 c1 用户界面

陈述所需要的用户界面的软件组件描述每个用户界面的逻辑特征以下是可能要包括的一些特征

将要采用的图形用户界面 G U I标准或产品系列的风格 屏幕布局或解决方案的限制 将出现在每个屏幕的标准按钮功能或导航链接例如一个帮助按钮 快捷键 错误信息显示标准

c2 硬件接口

描述系统中软件和硬件每一接口的特征这种描述可能包括支持的硬件类型软硬件之间交流的数据和控制信息的性质以及所使用的通信协议 c3 软件接口

描述该产品与其它外部组件由名字和版本识别的连接包括数据库操作系统工具库和集成的商业组件明确并描述在软件组件之间交换数据或消息的目的描述所需要的服务及内部组件通信的性质确定将在组件之间共享的数据 c4 通信接口

描述与产品所使用的通信功能相关的需求包括电子邮件Web浏览器网络通信标准或协议及电子表格等等定义了相关的消息格式规定通信安全或加密问题数据传输速率和同步通信机制 d 系统特性 d1 说明和优先级

简短说明该系统的特性并指出该特性的优先级是高中还是低另外还可以包括对特定优先级部分的评价例如利益损失费用和风险 d2 激励响应序列

列出输入激励用户动作来自外部设备的信号或其它触发器和定义这一特性行为的系统响应序列 d3 功能需求

详列出与该特性相关的详细功能需求这些是必须提交给用户的软件功能使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务 e 其他非功能需求 e1 性能需求

阐述了不同的应用领域对产品性能的需求并解释它们的原理以帮助开发人员作出合理的设计选择确定相互合作的用户数或者所支持的操作响应时间以及与实时系统的时间关系 e2 安全设施需求

详尽陈述与产品使用过程中可能发生的损失破坏或危害相关的需求定义必须采取的安全保护或动作还有那些预防的潜在的危险动作明确产品必须遵从的安全标准策略或规则 e3 安全性需求

详尽陈述与系统安全性完整性或私人问题相关的需求这些问题将会影响到产品的使用和产品所创建或使用的数据的保护定义用户身份确认或授权需求明确产品必须满足的安全性或保密性策略 e4 软件质量属性

详尽陈述与客户或开发人员至关重要的其它产品质量特性这些特性必须是确定定量的并在可能时是可验证的 e5 业务规则

列举出有关产品的所有操作规则例如什么人在特定环境下可以进行何种操作这些本身不是功能需求但它们可以暗示某些功能需求执行这些规则 e6 用户文档

列举出将与软件一同发行的用户文档部分例如用户手册在线帮助和教程明确所有已知的用户文档的交付格式或标准 f 其他需求

定义在软件需求规格说明的其它部分未出现的需求例如国际化需求或法律上的需求你还可以增加有关操作管理和维护部分来完善产品安装配置启动和关闭修复和容错以及登录和监控操作等方面的需求这一部分可以省略

需求验证是为了确保需求说明准确完整地表达必要的质量特点当你阅读软件需求规格说明时可能觉得需求是对的但实现时却很可能会出现问题当以需求说明为依据编写测试用例时你可能会发现说明中的二义性而所有这些都必须改善因为需求说明要作为设计和最终系统验证的依据

正确性 完整性 可验证性 无二义性 可修改性 可跟踪性 一致性

审查需求文档

对需求文档进行正式审查是保证软件质量的有效方法组织一个由不同代表如分析人员客户设计人员测试人员组成的小组对SRS及相关模型进行仔细的检查

以需求为依据编写测试用例

根据用户需求所要求的产品特性写出黑盒功能测试用例客户通过使用测试用例以确认是否达到了期望的要求从测试用例追溯回功能需求以确保没有需求被疏忽并且确保所有测试结果与测试用例相一致同时要使用测试用例来验证需求模型的正确性如对话框图和原型等

编写用户手册

在需求开发早期即可起草一份用户手册用它作为需求规格说明的参考并辅助需求分析 确定合格的标准

让用户描述什么样的产品才算满足他们的要求和适合他们使用的将合格的测试建立在使用情景描述或用例的基础之上

需求验证包括需求评审和需求测试两个部分需求评审又包括正式的和非正式的两种形式

需求评审是一种有效的需求验证手段通常以用例模型为基础编写测试用例进行检验虽然没有在运行系统上执行测试用例但是设计测试用例的过程可以解释需求的许多问题

本节知识点 分析模型--实体关系图数据流图状态转换图 数据字典 结构化分析过程

多年来人们提出了许多分析建模的方法其中占主导地位的两种方法是传统的“结构化分析”方法和当今流行的“面向对象的分析”方法本节重点介绍结构化分析方法面向对象的分析方法在后面章节介绍

需求分析产生的模型使人们可以更好地理解将要建造的系统它有助于系统分析员理解系统的信息功能和行为成为确定需求规格说明完整性一致性和精确性的重要依据奠定了软件设计的基础

结构化分析导出的分析模型包括数据模型功能模型和行为模型该模型以数据字典为核心描述了软件使用的所有数据对象围绕这个核心的是实体关系图数据流图和状态转换图具体形式如下图所示 实体关系图ER数据建模的基础描述数据对象及其关系 数据流图DF功能建模的基础描述数据怎样转换以及转换的功能 状态转换图ST行为建模的基础表示系统的各种行为状态以及状态间的转换方式 数据模型包括三种基本元素 数据对象 属性 关系 它们对理解问题的信息域提供了基础

两个数据对象之间有以下三种关联ER在数据对象之间的连线上用数字或字母表示

一对一11对象 A的一个实例只能关联到对象B的一个实例对象 B的一个实例也只能关联到对象A的一个实例如一个丈夫只能有一个妻子一个妻子也只能有一个丈夫

一对多1N对象 A的一个实例可以关联到对象B的一个或多哥实例而对象 B的一个实例只能关联到对象A的一个实例如一个母亲可以有多个孩子而一个孩子只能有一个母亲

多对多MN对象 A的一个实例可以关联到对象B的一个或多个实例同时对象 B的一个实例也可以关联到对象A的一个或多个实例如一个叔叔可以有多个侄子一个侄子也可以有多个叔叔

数据建模的其他图形工具层次方框图

层次方框图通过树型结构的一系列多层次的矩形框描述复杂数据的层次结构树型结构顶端的矩形框只有一个用于代表完整的数据结构下面各层的矩形框是对完整数据结构的逐步分解和细化得到的数据子集底层的矩形框代表组成该数据结构的基本元素是数据的最小单位不可再分割

数据建模的其他图形工具层次方框图 层次方框图非常适合描述自顶向下的需求分析方法中数据的层次关系系统分析员可以从对顶层信息的分类开始沿着层次图中的每条路径逐步细化直到确定了数据结构的全部细节为止

例如某单位职工的实发工资由应发工资和扣款两部分组成每部分又可进一步细分如应发工资又可分为基本工资和奖金基本工资又可分为国家工资津贴补贴奖金也可分为出勤奖和业绩奖津贴和补贴还可以再进一步地细分 实发工资的层次方框图如下图所示

数据流图是结构化分析的基本工具它描述了信息流和数据转换通过对加工进行分解可以得到数据流图

DF有四种元素其基本符号如下图所示

外部实体与系统进行交互但系统不对其进行加工和处理的实体用带标记的矩形表示 加工对数据进行的变换和处理用带标记的圆圈表示 数据流在数据加工之间或数据存储和数据加工之间进行流动的数据用带标记的箭头表示 数据存储在系统中需要存储的实体用带标记的双实线表示

第0层DF称为基本系统模型可以将整个软件系统表示为一个具有输入和输出的黑匣子用一个圆圈表示上一层DF中的每一个圆圈可以进一步扩展成一个独立的数据流图以揭示系统中程序的细节部分

这种循序渐进的细化过程可以继续进行直到最低层的图仅描述原子过程操作为止每一层数据流图必须与它上一层数据流图保持平衡和一致因此子图的所有输入输出流要与其父图相匹配

状态转换图通过描述状态以及导致系统改变状态的事件来表示系统的行为它没有表示出系统所执行的处理只表示了处理结果可能的状态转换

ST用带标记的圆圈或矩形表示状态用箭头表示从一种状态到另一种状态的变换箭头上的文本标记表示引起变换的条件 例如在操作系统中当存在多个申请占用CPU运行的进程 进程是分配CPU的最小处理单位 时系统将按照某种调度策略为各个进程分配CPU此时进程的状态可能有三种就绪运行和等待 就绪等待分配CPU 运行占用CPU进行相应的处理 挂起

name=baidusnap1>放弃CPU的使用

数据流图是结构化分析的基本工具体现了自顶向下逐步求精的分析过程确定了系统的任务流和数据流 实体关系图描述了系统的数据关系从而帮助开发人员分析和理解系统数据的组成并为系统设计阶段定义系统数据库的物理结构打下基础 状态转换图描述了系统状态之间的变化过程它对于实时系统和控制系统尤为重要

数据字典描述数据流图的数据存储数据加工 最底层加工和数据流它记录的主要内容有 基本信息名字别名描述 定义数据长度数据类型数据结构 使用特点取值范围使用频率使用方式等 控制信息来源用户引用程序读写权限等 其他说明

在数据字典中数据元素的定义可以是基本元素及其组合数据进行自顶向下地分解直到不需要进一步解释且参与人员都清楚其含义为止

数据组合有三种方式

顺序以确定的次序连接多个数据项

选择从多个数据项中选取一个

重复将某个数据项重复多次 为了能够对数据流中的各组成成分进行准确的定义在数据字典中使用了多种具有特定意义的符号如下

结构化分析过程实质上就是创建数据模型功能模型和行为模型其中数据建模的工具是实体关系图功能建模的工具是数据流图行为建模的工具是状态转换图另外使用数据字典定义系统的所有数据项

为了理解和学会使用这些建模工具我们结合一个学生成绩管理系统的实例讲解整个分析过程并给出部分实体关系图数据流图状态转换图和数据字典

下面列出用户对学生成绩管理系统的要求 教务人员录入学生信息课程信息和成绩信息 学生可以随时查询自己所选课程的成绩 由于学生成绩属于敏感信息系统必须提供必要的安全措施以防非法存取

在需求收集的过程中要求客户列出应用软件或业务过程涉及到的“事物”将其演化成数据对象 一次考虑一个对象分析员和客户定义这个对象和其他对象之间是否存在连接 如果存在连接应创建一个或多个关系

对每一个关系确定其关联类型

重复步骤2到步骤4直到定义了所有关系

定义每个实体的属性

形式化并复审实体关系图 重复步骤1到7直到数据建模完成

实例分析 学生成绩管理系统 实体学生课程成绩 实体属性定义

学生学号姓名性别出生日期入学年月

课程课程编号课程名称课程学分课程描述

成绩学号课程编号分数考核日期

显然学生课程和成绩都是系统的实体并且可以初步定义它们的属性

教务人员虽然是系统的用户但其信息与系统处理无关因此不用作为实体 由于成绩信息包含了选课信息因此选课信息不用单独记录

因此系统的实体是学生课程和成绩

我们分析这些实体之间的关联关系从实际情况得知一个学生可以选多门课程一门课程也可以有多个学生选修但每个学生选一门课程必须有一个成绩根据上述分析我们得到如图所示的实体关系图

实体关系图

通常数据流图是分层绘制的整个过程反映了自顶向下进行功能分解和细化的分析过程 顶层也称第0层DF用于表示系统的开发范围以及该系统与周围环境的数据交换关系 最底层DF代表了那些不可进一步分解的原子加工 中间层DF是对上一层父图的细化其中的每一个加工可以继续细化中间层次的多少由系统的复杂程度决定

第0层DF将整个系统表示成一个加工 2 确定并标记主要的输入和输出 分离出下一层中的加工数据对象和存储 并对其进行细化一次细化一个加工 4 标记所有加工和箭头 重复步骤3和4直到所有的加工 只执行一个简单的操作可以很容易地用 程序实现

绘制第0层DF的时候将整个系统看成一个加工然后找出作用于该加工的外部实体以及相应的数据输入和输出

绘制下一层数据流图时细化第0层的加工从而描述系统的主要功能 继续进行分解直到所有的加工只执行一个简单的操作为止

实例分析 学生成绩管理系统 第0层DF图

1教务人员维护学生信息和课程信息并登录学生的选课成绩 2学生查询自己的成绩单

对于学生成绩管理系统而言整个系统就是一个加工学生成绩管理

教务人员是数据的源点学生是数据的终点 教务人员需要录入学生信息课程信息和成绩说明学生信息课程信息和成绩是数据流同样查询请求和查询结果也是数据流 根据上述分析得到如图所示的第0层DF图

第1层DF图

对第0层DF图中的加工学生成绩管理 展开得知学生信息是教务人员需要录入的一个信息因此加入一个加工录入学生信息同样得到录入课程信息登记成绩两个加工另外数据流查询请求和查询结果应该由加工查询成绩来完成

这样我们用录入学生信息录入课程信息登记学生成绩和查询学生成绩四个加工代替第0层的学生成绩管理同时增加这些数据流对应的数据存储即学生课程和成绩最后得到如图所示的第1层DF图

第2层DF图

为了继续进行分解我们分析第1层DF中的加工查询学生成绩

学生查询成绩时需要提供合法性检查因此查询学生成绩可以分解为合法性检查和查询成绩两个处理步骤从而形成第2层DF如下图所示

根据以上实例和经验绘制数据流图应当遵循以下原则 1 分层时子图的输入输出数据流必须和父图中相应加工的输入输出数据流一致 加工的编号应该唯一且具有层次性 加工不应该只有输入或只有输出通常既有输入又有输出 4 数据流图不应反映处理的顺序 加工之间应通过数据存储进行通信避免从一个加工直接流到另一个加工 数据应通过加工进行流动避免从一个数据存储直接流到另一个数据存储 数据流图中所有元素的命名应当对客户有意义且与业务相关 8 不要在一个图中绘制7个以上的加工否则难于绘制和理解

数据字典

以下列出“学生成绩管理系统”的部分数据字典条目

4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4331 创建实体关系图 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加定义项 其他说明 随时但经常在新生入学时期 峰值 10000左右 数据量 学号 姓名 性别 出生日期 入学年月 定义 无 别名 包括学生的主要信息 描述 学生 数据项名 4332 创建数据流模型 第四章 软件需求分析与建模 学号不能重复 其他说明 6位字符 长度 字符串 类型 无 别名 唯一标识学生的编号 描述 学号 数据流名 4332 创建数据流模型 第四章 软件需求分析与建模 在系统功能扩充时可能增加种类 其他说明 随时但经常在学期开学 峰值 10000次左右 频率 无 别名 系统处理的一个命令 描述 学生成绩查询 数据流名 4333 创建行为模型 第四章 软件需求分析与建模

通常来说行为建模用于实时系统 实时系统中可能存在许多脚本很多实体需要进行状态划分和描述状态转换图 在事务系统中系统行为相对简单只有某些行为较复杂的实体才需要建立其状态转换图 4333 创建行为模型 第四章 软件需求分析与建模 1 分析外部事件所谓外部事件是指外部实体与系统的一次交互 分析事件的响应者该响应者为了响应该事件要进行怎样的活动这种活动又会激发哪些事件等 根据事件和活动划分实体的状态考虑发生怎样的事件使该实体进入这个状态怎样的事件使该实体从这个状态转换到另一状态等 4333 创建行为模型 第四章 软件需求分析与建模 实例分析学生成绩管理系统

在学生成绩管理系统中学生成绩信息必须采取安全措施我们采取登录方法避免非法使用系统这样该系统存在登录正常和出错等状态的转换如下图所示 4333 创建行为模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 431 分析模型 第四章 软件需求分析与建模 4311 实体关系图 第四章 软件需求分析与建模