软件需求分析定义 需求分析工具软件
- 作者: 嬲嬲嬲嬲嬲嬲嬲嬲613
- 来源: 51数据库
- 2020-04-15
如何进行软件需求分析
1.概念需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起.系统的分析人员说：＂我们想与你谈谈你的需求.＂客户的第一反应便是：＂我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统＂.百事通而实际上，UGGs，需求并未编写成文档，因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人.需求的另外一种定义认为需求是＂用户所需要的并能触发一个程序或系统开发工作的说明＂.有些需求分析专家拓展了这个概念：＂从系统外部能发现系统所具有的满足于用户的特点、功能及属性等＂.这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性，是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的＂需求＂术语存在，真正的＂需求＂实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难.目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生.近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了.相反的情况，我曾见一个要集成到＂错误跟踪系统＂中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误.事实上，需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：图4-1 需求工程域的层次分解示意图需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面：确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要＂建立并维护在软件工程中同客户达成的合同＂ .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中.通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）.评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以上几点说...
怎样做软件的需求分析？
软件需求的定义：（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：1）确定需求变更控制过程。
制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。
评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。
确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。
将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。
可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。
可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。
过多的需求变更＂是一个报警信号＂，意味着问题并未真正弄清楚。
4.需求分析评价标准（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。
例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。
除了语言的二义性之外，注意不要使用行话，就是计算机术语。
需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。
要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。
在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。
实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。
这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
软件项目分析需求
需求分析，我刚做了个项目就用它，不知道是不是你想要的1引言 21.1编写目的 21.2背景 21.3定义 21.4参考资料 22任务概述 22.1目标 22.2用户的特点 32.3假定和约束 33需求规定 33.1对功能的规定 33.2对性能的规定 33.2.1精度 33.2.2时间特性要求 33.2.3灵活性 43.3输人输出要求 43.4数据管理能力要求 43.5故障处理要求 43.6其他专门要求 54运行环境规定 54.1设备 54.2支持软件 54.3接口 54.4控制 5 软件需求说明书的编写提示1引言1.1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。
1.2背景 说明：待开发的软件系统的名称；本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料 列出用得着的参考资料，如：本项目的经核准的计划任务书或合同、上级机关的批文；属于本项目的其他已发表的文件；本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。
解释被开发软件与其他有关软件之间的关系。
如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。
如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
|2.2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。
这些是软件设计工作的重要约束2.3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3需求规定 3.1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定3.2.1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求 说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和传送时间；解题时间；等的要求。
3.2.3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化；运行环境的变化；同其他软件的接口的变化；精度和有效时限的变化；计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.4数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定4.1设备 列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能，包括：处理器型号及内存容量；外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；输入及输出设备的型号和数量，联机或脱机；数据通信设备的型号和数量；功能键及其他专用硬件4.2支持软件 列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4.3接口 说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
软件需求分析的需求类型有哪些呢？
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需说明了提供给客户和产品开发商的新系统的最初利益，反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。
因此，软件需求分析能力和水平，对软件项目至关重要。
一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
软件测试问题定义（需求分析）错误是什么？
1.市场规模 含义：指特定商品的潜在购买者数量。
潜在购买者3个特点：兴趣、收入与途径。
潜在市场是对某种特定商品有某种程度兴趣的消费者。
市场规模是兴趣与收入的函数。
市场规模还会因为途径的限制而缩小。
有效市场是对某种特定商品有兴趣、收入与途径的消费者的集合。
企业现在可以追求全部合格的有效市场或集中在其中的细分市场上。
服务市场（目标市场）是公司决定追求的那部分合格的有效市场。
渗透市场是指已经购买了该产品的消费者的集合。
2.市场总需求 含义：指在特定地理范围内、特定时期、特定市场营销环境、特定市场营销计划的情况下，特定的消费者群体可能购买的总量。
市场总需求是给定条件下的函数，称之为市场需求函数。
不需任何刺激需求的费用就会有其基本的销售量，称为市场最低量，随着行业市场营销费用的增加会引起需求水平的提高，开始以加速度增高。
市场需求有一个上限，称为市场潜量。
市场最低量与市场潜量间的距离表示出需求的市场营销敏感性。
可以设想有两个极端的市场——可扩展市场与非扩展市场。
市场预测是在相对条件下预期的市场需求。
市场潜量是在特定的环境下，随着行业营销费用的无限增长，市场需求所能达到的极限。
软件需求分析报告主要是由哪些部分组成的？它的作用是什么？
软件需求的定义 IEEE软件工程标准词汇表（1997年）中定义需求为： （1）用户解决问题或达到目标所需的条件或权能（Capaility）。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
业务需求（ usiness equiement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求（useequiement） 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenaio）说明中予以说明。
功能需求（functional equiement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性（featue）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
软件需求各组成部分之间的关系如图所示。
作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制。
质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。
多角度描述产品对用户和开发人员都极为重要。
如何才能把软件需求分析做好？
我的第一个故事来自大名鼎鼎的东软。
我在2005年接一个项目的时候，听说这个项目之前是东软做的。
当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。
据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。
之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。
最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。
多么惨痛的教训啊！我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。
客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。
如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。
记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。
我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。
当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
