软件工程的需求模型

Ⅰ 什么是需求分析，其目标是什么《软件工程》

需求分析，也叫软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统功能的过程。

需求分析的目标是把用户对待开发软件提出的要求或需要进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现的功能，完成的工作。此外，软件的一些非功能性需求、软件设计的约束条件、运行时与其他软件的关系等也是软件需求分析的目标。

(1)软件工程的需求模型扩展阅读：

需求分析阶段分为四个方面：问题识别、分析与综合、制订规格说明、评审。

1、问题识别：从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求。

2、分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

3、制订规格说明书： 编制文档，描述需求。需求分析阶段的成果是需求规格说明书，向下一阶段提交。

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

Ⅱ 在软件工程中什么是需求分析

一。 确定对系统的综合要求
1. 功能需求
这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。
2. 性能需求
性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求
可靠性需求定量地指定系统的可靠性。
可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。
5. 接口需求
接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
6. 约束
设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
7. 逆向需求
逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。
注意：举例让学生理解：这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。
二 。分析系统的数据要求
任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。
分析系统的数据要求通常采用建立数据模型的方法（举例）。

三。 导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
四。 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

Ⅲ 如何将需求模型转变为软件分析模型

软件工程范围内，这个问题几句话也说不清楚，推荐搜一篇文档：将分析模型转换为软件设计。

Ⅳ 软件工程导论 什么是需求分析在需求分析阶段,建立目标系统的逻辑模型的具体做法

所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的“需求分析”就是确定要计算机“做什么”。
具体做法:首先确定目标系统与当前系统的逻辑差别；然后将变化部分看作是新的处理步骤，对功能图及对象图进行调整；最后由外及里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型

Ⅳ 软工建模九张图 瀑布模型 软件生命周期 需求工程中的分析模型 将分析模型转化为软件设计 谈对其的理解

第九章设计工程软件设计是软件工程过程的技术核心，它开始于需求分析和需求建模完成.

Ⅵ 软件工程需求分析的模板

需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的
基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细
节。
1)采用软件需求规格说明模版:
采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注
意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准
830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。

1
2
3
4
5
6

A引言
目的
文档约定
预期的读者和阅读建议
产品的范围
参考文献

B综合描述
产品的前景
产品的功能
用户类和特征
运行环境
设计和实现上的限制
假设和依赖附录

C外部接口需求附录
用户界面附录
硬件接口
软件接口
通信接口

D系统特性
说明和优先级
激励/响应序列
功能需求

E 其它非功能需求
性能需求
安全设施需求
安全性需求
软件质量属性
业务规则
用户文档

F其它需求

G附件
词汇表
分析模型
待确定问题的列表


表2 需求规格说明模板

a. 引言

引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。

a . 1 目的

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

a.2 文档约定

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

a.3 预期的读者和阅读建议

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

a.4 产品的范围

提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。

Ⅶ 总结归纳主要的软件工程模型，并任意选定其中的一种过程模式，介绍其特点及你对该模型的理解。

主要的软件过程模型有：瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式方法模型等。
瀑布模型（waterfall model）是1970年有W.Royce提出的，它给出了软件生存周期活动的固定顺序，上一阶段的活动完成后向下一阶段过渡，最终得到所开发的软件产品。瀑布模型如下图所示，有时也称为软件生存周期模型。

瀑布模型中，上一阶段的活动完成并经过评审后才能开始下一阶段的活动，其特征是：
（1）接受上一阶段的结果作为本阶段活动的输入。
（2）依据上一阶段活动的结果实施本阶段应完成的活动。
（3）对本阶段的活动进行评审。
（4）将本阶段活动的结果作为输出，传递给下一阶段。
瀑布模型是最早出现的也是应用最广泛的过程模型，对确保软件开发的顺利进行、提高软件项目的质量和开发效率起到重要作用。
在大量的实践过程中，瀑布模型也逐渐暴露出它的不足。首先，客户常常难以清楚地描述所有的要求，而且在开发过程中，用户的需求也常常会有所变化，使得不少软件的需求存在着不确定性；在某个活动中发现的错误常常是由前一阶段活动的错误引起的，为了改正这一错误必须回到前一阶段，这就导致了瀑布的倒流，也就是说，实际的软件开发很少能按瀑布模型的顺序没有回流地顺流而下。其次，瀑布模型使得客户在测试完成以后才能看到真正可运行的软件，此时，如果发现不满足客户需求的问题（由于需求不确定性），那么修改软件的代价是巨大的。
不是任何软件都可采用瀑布模型的，瀑布模型适合于结构化方法，也就是面向过程的软件开发方法。软件项目或产品选择瀑布模型必须满足下列条件：在开发时间内需求没有或很少变化；分析设计人员应对应用领域很熟悉；低风险项目（对目标、环境很熟悉）；用户使用环境很稳定；用户除提出需求以外，很少参与开发工作。

Ⅷ 软件工程中需求分析的任务是什么（具体点）

软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。

除此之外，每个系统还有各种非功能需求。

业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。

用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。

然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

功能需求记录在软件需求说明书（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；

或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。

除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

约束（constraint）限制了开发人员设计和构建系统时的选择范围。

行业需求：企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。

(8)软件工程的需求模型扩展阅读：

工程与科学：

软件的开发到底是一门科学还是一门工程，这是一个被争论了很久的问题。实际上，软件开发兼有两者的特点。但是这并不意味着它们可以被互相混淆。很多人认为软件工程基于计算机科学和信息科学就如传统意义上的工程学之于物理和化学一样。

在美国，大约40%的软件工程师具有计算机科学的学位。在世界其他地方，这个比例也差不多。他们并不一定会每天使用计算机科学方面的知识，但是他们每天都会使用软件工程方面的知识。

Ⅸ 软件工程的模型都有那些

都忘光了,只记得有个螺旋型的比较好