软件需求分类有哪些

从猴子说起 有这样一个笑话：一个旅客走进硅谷的一家宠物店，浏览展示的宠物。

这时，走进一个顾客，对店主说：＂我要买一只C猴。

＂店主点了点头，走到商店一头的兽笼边，抓出一只猴，递给顾客说：＂总共5000美元。

＂顾客付完款，然后带走了他的猴子。

这位旅客非常惊讶，走到店主跟前说：＂那只猴子也太贵了！＂店主说：＂那只猴子能用C编程，非常快，代码紧凑高效，所以值那么多钱。

＂这时，旅客看到了笼子中的另一只猴子，它标价10000美元。

于是又问：＂那只更贵了！它能做什么？＂店主回答：＂哦，那是一只C++猴；它会面向对象的编程，会用Visual C++，还懂得一点Java，是非常有用的。

＂旅客又逛了一会儿，发现了第三只猴子，它独占一个笼子，脖子上的标价是50000美元。

旅客倒抽一口气，问道：＂那只猴子比其他所有猴子加起来都贵！它究竟能做什么？＂店主说：＂我们也不知道它究竟能做什么，不过它是做项目顾问出身的。

＂ 虽然这只是一个笑话，但是有一点是可以肯定的，项目管理是非常重要的，而项目管理的人才又是极为缺乏的。

在软件工业发达的国家，大家多少都知道点软件工程规划的重要性。

在我们身边的台湾、印度、日本，都不乏因实施软件工程而成功的软件团体，更不用说身为软件大国的美国，已经从较低级的软件实现摆脱出来，进入了设计和营销的境界。

软件首先是一种产品（软件是服务还是产品的问题，向来未有定论），看看世界上制造业的发展历程，就会发现一些很有意思的现象。

在本世纪早些的年代，西方国家的制造业经历了规模生产、提高质量等等促进生产力提高的过程。

可是由于西方国家的人力资源成本不断的攀升，越来越难降低产品成本，所以西方国家又不可避免的经历了一次将制造业外移的过程（制造业外移的结果是成本大幅下降、国际贸易频繁、接受制造业的国家发展了自身的制造业），而西方国家只留下营销和设计的能力，掌握了产品生产的重点。

同样，IT行业也在经历这种过程：美国将软件外包给印度，硬件外包给台湾。

而中国的硬件也在崛起，但是在软件行业，中国和其他国家的差距还是太大了，且不说在软件行业中处于核心地位的操作系统、数据库。

即便是应用软件，中国的软件水平也实在低的可怜。

在国外制造业刚刚迁移进中国的时候（改革开放），中国的小企业家同样没有任何管理经验、质量意识。

但是随着制造业的发展和国外先进思想的进入，中国也诞生了极为出色的全球制造业巨头。

而中国的软件行业现在正是处于刚刚有了一点管理思想，但还没有成熟的地步。

我们有理由相信，在不久的将来中国也会诞生出出色的全球性软件企业。

憧憬归憧憬，现实的问题还是必须要考虑的。

软件这个产品很奇特，软件企业的管理思想同样很奇特。

不同于现在企业推崇的各种管理思想，软件企业的管理思想主要是针对项目的管理，确保项目的成功。

项目和需求 笑话里的猴子对应到项目就是指项目管理人员，这里要引入一个角色的概念（同样的人可以担任多种的角色），通常的项目管理角色包括：项目经理、项目复审员、变更控制经理、企业流程分析师、业务模型设计师、需求分析员、需求复审员、系统分析员…在一个成功的项目里，多种角色职责明确，分工合作，共同完成项目的设计实施。

那么这？quot；猴子＂在项目中都做了些什么呢？RUP(Rational Unified Process 瑞理统一过程，本文采用了众多的RUP的思想)把一个项目分成10个核心工作流程（Core Workflows）和4个阶段（Phases），并以核心工作流程为Y轴，阶段为X轴建立起一个项目视图（图一）。

本文将主要对先启阶段做介绍。

在先启阶段，需求是重中之中，这里指的需求不仅仅是RUP的一个工作流程（在业务建模下），而是比较广义的概念，包括了RUP的工作流程中的业务建模、需求、一部分的分析、测试计划、配置和变更管理。

需求是根本 由于忽略需求过程造成的项目返工是恶性的，大量的项目在需求阶段就注定了它的失败。

以下是需求过程不科学的典型例子： 1.开发人员在用户处呆了两三天就埋头开发； 2.用户告诉开发人员我要开发一个XX系统，但是我很忙，你先开发一个让我看看； 上面的这两种态度都意味着项目的不成功，应该说上面的开发人员和用户都应该对此负责。

需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。

当然，由于用户不是专业人士，开发者有权利告诉用户应该采用何种态度来对待项目的需求。

曾经和几个朋友聊过他们公司开发过的项目，最后得出一个结论，所有最成功的项目都有一个重要的特性：用户非常的支持。

评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题就是体现为用户的需求，需求也就顺理成章的成为项目的成功标准。

而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工，而需求的不慎不是说你小心就可以的，因为很多需求是隐性的，连用户都不清楚自己的需求。

这时候就需要一种科学的方法来帮助软件组织实施需求过程。

需求是变化的 大师说：＂没有不变的需求，世上的软件都改动过3次以上，唯一一个只...

软件需求模式有哪些分类？

需求可以按多种方式分类（例如，按功能和非功能分类）。

使用需求模式有一个优点，如果对模式分类，自动就对使用这些模式的需求分类。

分类告诉我们一些使用模式的需求的本性。

使用这些分类的其他方式是按照分类找到需求以及统计需求。

人们喜欢统计（至少有一些人，通常他们是高级行政人员，我们应该让他们高兴）。

对系统的需求的统计可以在很多方面有用。

可以帮助大概了解系统的复杂性和规模。

为了这个目标，需要对每个需求标记所需统计的数值。

（需求管理工具通常定义一些额外的需求属性，然后对每个需求输入属性的数值，这是个乏味的工作。

）使用需求模式可以节省这方面的工作，因为使用模式产生的所有需求有共同的属性。

它们只需要在模式编写的时候定义一次。

这个信息记录在每个模式的“模式分类”部分。

一旦需求以这种方式标记，就可能搜索分类查找到符合条件的所有需求。

如何把模式中的分类信息传送给需求取决于如何保存需求。

（这留给读者练习）一个直接的办法就是把需求拷贝到excel中，添加一列确定需求使用的需求模式，对每一个分类添加一列。

（按模式名排序可以更容易一次处理多个分类数值。

） 本书中的需求模式只包含了少量的基本分类方式，定义在下面。

你可以定义自己额外的分类方式，并用它们对模式分类。

如果是这样的话，按照下面的方式编写合适的定义，然后把它们放在引用它们的需求模式的地方。

分类可以帮助使用需求的任何人，包括开发人员。

因此，不必要所有人都理解每一个分类。

基于这个原因，每一个分类要有一个主要读者，并且明确的陈述。

如果你不属于这部分读者，不要担心不能理解它的目的或者对它不感兴趣。

需求模式的分类需要合适和精确的定义，否则基于分类的统计就不可能可靠。

每个分类需要定义以下内容： 名称：分类的唯一的，明显的名称读者：关于谁可能对这个分类感兴趣的解释：目标是谁。

目的：描述分类使用的意图是什么。

允许值：定义在模式中这个分类可以有的值，解释它们的含义。

最通常的方法是定义数值列表。

数字的或者文字的或者任何其他数值都可以使用，只要读者了解这些数值的含义。

缺省值：如果在模式中的分类没有定义（明确陈述），这就是采用的数值。

这样可以不必在模式中明确的定义分类，如果这个分类只对相对少量的模式有意义（换句话说，就是只对少量模式重要）。

本书中用到三个需求模式分类，下面使用这种格式描述。

“功能”分类 名称：功能读者：对挑选系统功能感兴趣的任何人，或者对功能数量感兴趣的人。

目的：指出这种类型的需求是否定义了系统必须提供的功能允许值：是每一个这种类型的需求是功能需求。

可能是有些这种类型的需求是功能需求；有些不是。

编写一个模式时，小心使用这个值。

确定模式是否定义清楚了；可能应该分成两个，一个是功能部分一个是非功能部分。

否这种类型的需求不是功能需求缺省值：否 “普遍性”分类 名称：普遍性读者：软件开发人员目的：指出这种类型的需求是否是普遍性的（也就是说，适用整个系统）。

它的目的是提醒开发人员注意，不管他们正在开发系统的那一部分，这个需求都影响他们。

允许值：是这种类型的需求是普遍性需求。

可能是有些这种类型的需求是普遍性的，有些不是。

否这种类型的需求不是普遍性需求缺省值：否 “影响数据库”分类 名称：影响数据库读者：数据库管理员（以及软件开发人员）目的：指出这种类型的需求是否会影响系统数据库的设计。

它的目的提醒负责设计数据库的人员关注这些需求允许值：是这种类型的需求影响数据库。

可能是有些这种类型的需求影响数据库，有些不影响。

否这种类型的需求不直接影响数据库。

软件需求分类有哪些

软件需求的定义；IEEE软件工程标准词汇表（1997年）中定义需求为：(1)用户解决问题或达到目标所需的条件或权能（Capability）。

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

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

简单的就是：用户需求；用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。

功能需求；将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。

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

说白一点就是软件项目的背景啊，要达到什么业务目的啊，然后要满足哪些人的哪些使用需求啊，这个需求的业务流程是怎样的啊，针对这个需求软件需要具备的功能是怎样的啊。

除了功能性方面的需求，还有些性能方面的需求，比如响应速度啊并发数啊之类的....网上可以找到标准的需求文档模版，模版里定义清楚了要包含的内容。

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

这个时期产生的主要文档是《XX软件需求规格说明书》。

需求规格说明书一般包含以下内容，但具体内容需要根据实际情况来书写，以下仅供参考：1.引言1.1编写目的【阐明编写需求说明书的目的，指明读者对象.】为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档.本文档供项目经理、设计人员、开发人员参考.1.2项目背景a.项目的委托单位、开发单位和主管部门b.该软件系统与其他1.3定义【列出文当中所用到的专门术语的定义和缩写词的原文.】1.4参考资料a.项目经核准的计划任务书、合同或上级机关的批文b.项目开发计划c.文档所引用的资料、标准和规范.列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源2.任务概述2.1目标2.2运行环境操作系统：Microsoft Windows 2000 Advanced Server支持环境：IIS 5.0数 据 库：Microsoft SQL Server 20002.3条件与限制3.数据描述3.1静态数据3.2动态数据【包括输入数据和输出数据.】3.3数据库介绍【给出使用数据库的名称和类型.】3.4数据词典3.5数据采集4.功能需求4.1功能划分4.2功能描述5.性能需求5.1数据精确度5.2时间特性【如响应时间、更新处理时间、数据转换与传输时间、运行时间等.】5.3适应性【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时，应具有的适应能力.】6.运行需求6.1用户界面【如屏幕格式、报表格式、菜单格式、输入输出时间等.】6.2硬件接口6.3软件接口6.4故障处理7.其它需求【如可使用性、安全保密、可维护性、可移植性等.】

怎样做软件的需求分析？

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

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

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

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

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

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

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

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

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

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

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

。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6）衡量需求稳定性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件需求工程有哪些过程？

一、 开始 1. 项目经理根据项目特点，指定对过程表格的具体要求； 2. 项目经理制订项目的标准，包括：DTS（缺陷类型）、TRA（风险类型）、TRS（需求类型）等，在过程表格中按标准引用. 二、 计划 1. 计划经理估算需求开发时间； 2. 计划经理完成：SPT（进度计划）、TPT（任务计划），将计划数据录入PDS（项目计划摘要）. 三、 需求获取 1. 软件需求工程师搜集系统概要信息，填写REQ（需求获取概貌）； 2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA（需求获取分析）、RES（需求获取情节）、UIR（用户交互需求）； 3. 检查需求获取过程，并填写REC（需求获取检查）； 4. 如果检查不通过，从1.重头开始过程； 5. 软件需求工程师填写TRL（时间记录日志）、PIP（过程改进建议）； 6. 计划经理整理本阶段数据，录入SPT、TPT. 四、 需求分析 1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）； 2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR; 3. 检查需求分析，完成RAC（需求分析检查）； 4. 如果检查不通过，从1重头开始过程； 5. 软件需求工程师填写TRL、PIP; 6. 计划经理整理数据，录入TPT、SPT. 五、 协商 1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR; 2. 软件需求工程师根据决议，修改REA等相关文档； 3. 如果有新的需求引入，需要重新进行需求分析阶段； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT. 六、 需求评审 1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表； 2. 评审员各自评审分派的内容，将发现的问题录入DRL（缺陷记录日志）； 3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论； 4. 评审小组以IRF形式提交检查报表； 5. 软件需求工程师根据IRF修订相关文档； 6. 计划经理整理数据，录入TPT、SPT。

七、 需求文档编写 1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需求说明书》 《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。

2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行； 3. 如果检查不通过，从1重头开始过程； 4. 软件需求工程师填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。

八、 需求确认 1. 评审小组，对需求进行确认： l 确认每一个需求及相互关系； l 需求的总体质量达到标准。

将结果写到RVC。

2. 软件需求工程师根据RVC，修订需求文档，并最终通过； 3. 软件工程师为每一个需求设计测试用例，并录入TRF; 4. 相关人员填写TRL、PIP; 5. 计划经理整理数据，录入TPT、SPT。

九、 配置管理 1. RD（需求文档）成为基线后，即纳入到配置管理； 2. 如果需要对基线RD（需求文档）进行修改，填写CCP; 3. 配置管理人员征求需求开发小组和其他相关人员（风险承担者）关于CCP的意见； 4. 如果所有人员通过CCP，则将需求文档的配置管理取出，并填写CCF； 如果否决需求，则填写RRF; 5. 软件需求工程师修改RD以适应新的需求 （可能包括REA等）； 6. 评审小组对修改的RD执行第八步； 7. 相关人员填写TRL、DRL. 十、 事后分析 1. 计划经理将DRL、TRL、需求增长率，整理到PPS; 2. 小组分析SREP过程，找出需要改进的地方，填写PIP，并提交质量经理； 3. 小组建立未来过程的改进目标.