软件需求分析方法56232.docx
《软件需求分析方法56232.docx》由会员分享，可在线阅读，更多相关《软件需求分析方法56232.docx（42页珍藏版）》请在冰豆网上搜索。
软件需求分析方法56232
软件需求分析方法
软件需求分析（SoftwareReguirementAnalysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。
软件需求分析是一个项目的开端，也是项目实施最重要的关键点。
据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。
因此，一个项目的成功软件需求分析是关键的一步。
一、软件需求分析理论
如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、…Dn表示，那么，我们可以用一个表达式描述为
S={D1，D2，D3，…Dn}
但是，功能域Di依然存在着有若干个问题P1、P2、P3、…Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为
Di={P1，P2，P3，…Pm}
同样，功能Pj有若干个行为F1、F2、F3、…Fk，每个行为对应于软构件中的实现方法
Pj={F1，F2，F3，…Fk}
一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。
需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。
需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规与个性化追求。
二、软件需求分析目标
软件需求分析的主要实现目标：
1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整 性，促使用户在软件设计启动之前周密地、全面地思考软件需求；
2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；
3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据；
需求分析的具体容可以归纳为六个方面：
软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。
软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。
这就要求软件需求分析容应正确、完整、一致和可验证。
此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。
2.1、 软件功能需求
软件的功能需整个需求分析最主要、最关键和最复杂的部分，它描述软件的各种可能的条件下，对所有可能输入的数据信息，应完成那些具体功能，产生什么样的输出。
描述软件功能需应注意下面几点：
1）功能需求的完整性和一致性
对功能的描述应包含与功能相关的信息，并应具有在的一致性（即各种描述之间不矛盾、不冲突）。
应注意以下几点：
（1） 给出触发功能的各种条件（如：
控制流、运行状态、运行模式等）；
（2） 定义各种可能性条件下的所有可能的输入（包括合法的输入空间和非法的输入空间）；
（3） 给出各种功能间可能的相互关系（如各个功能间的控制流、数据流、信息流，功能运行关系：
顺序、重复、选择、并发、同步）；
（4） 给出功能性的主要级别（如：
基本功能、可由设计者选择逐步实现的功能、可由设计者改变实现的功能等）；
（5） 尽可能不使用“待定”这样的词。
所有含有待定容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分容说明，落实负责人员、落实实施日期。
2）功能描述的无岔意性和可追踪性
需求功能描述的无岔意性、可追踪性和规化：
（1） 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；
（2） 可以用语言、方程式、决策表、矩阵或图等对功能的描述。
如果选用语言描述必须使用结构化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择，重复，还是并发，然后说明步骤逻辑。
整个描述必须单入单出。
（3） 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进行描述，这样便于功能的追踪和修改。
（4） 功能描述应注意需求说明和程序设计的区别。
需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采用和种数据结构，定义多个模块，接口间的接口等）是设计阶段的事情，功能描述不应涉及到那些细节问题，以避免给软件设计带来不必要的约束。
2.2、 软件与硬件或其他外部系统接口
软件与硬件或其它外部系统接口包括下述容：
（1） 人机接口：
说明输入、输出的容、屏幕安排、格式等要求；
（2） 硬件接口：
说明端口号，指令集，输入输出信号的容与数据类型，初始化信号源，传输通道号和信号处理方式。
（3） 软件接口：
说明软件的名称、助记符、规格说明、版本号和来源；
（4） 通讯接口：
指定通讯接口和通讯协议等描述。
2.3、 软件的非功能性需求
软件非功能性需指软件性能指标，容限等功能以外的需求。
一般指下述容：
（1） 时间需求：
输入、输出频率，输入、输出响应时间，各种功能恢复时间等；
（2） 处理容限、精度、采样参数的分辨率，误差处理等；
（3） 可靠性的MTBF要求，可维护性、安全性要求等。
（对可能的不正常的输入给以正常响应是可靠性的重要容，这属于功能性需求。
）
2.4、 软件反向需求
软件的反向需求描述软件在那些情况下不能做什么。
这一条是随软件实际要求而定。
有两类情形需要采用反向需求的形式。
第一种情况：
某些用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。
第二种情况：
对一些可靠性和安全性要求较高的软件，有些必须描述软件不能做些什么。
如控制点火时序，我们必须交代清楚在那些情况下不能点火，否则会造成故障。
2.5、 软件设计和实现上的限制
软件设计和实现上的限制主要指对软件设计者的限制。
如软件运行环境的限制（选择计算机类型，使用配置，操作系统的限制等）、设计工具的限制（使用语言、执行的标准）和要求等。
2.6、 阅读支持信息
这部分容是为了更好的帮助我们理解用户需求，也是为了使需求便于修改和追踪。
其本身并不是对需求的描述，但它影响到需求分析的可读性，也属于需求分析的一个重要部分。
一般目录、需求背景信息、容索引、交叉引用表、注释等均属于这个部分的容。
三、软件需求分析人员组织
软件需求分析其根本性问题是理解用户功能需求，由此软件需求分析实际上是与客户间交流过程完成的目标。
要求我们组织适当的参与人员进行交流活动。
需求分析是一个综合团队的工作，是在需求分析理论的指导下，对用户需要进行渐进方式逐步深化；通过不断变化方式形成具体约束；努力实现需求功能目标形成特色效果的商业化产品。
需求分析是一个商业行为，完全是一个商业化操作，要求有商业、技术等结合的团队共同合作，解决需求和设计的同步，设计符合需求。
项目涉及容，项目大小都需要我们考虑参加软件需求分析工作团退的人数，配置合理的参与人员。
一般我们必须有商务活动人员，项目管理人员，设计技术人员等参加，而且要求组织人员必须明确负责围，以及明确工作目标，保证实施的有效性。
四、软件需求分析方法
为了保证项目的正常实施，并且能够顺利的完成，我们必须加强项目管理和重视项目分析工作。
我们只有从实际出发，切切实实地把握用户需求，把握用户需求目标，把握用户将来功能界定，保证我们开发工作正确性方向。
4.1、重点监控软件需求分析办法
由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。
其原因基本是由于以下情况造成的。
4.1.1、客户说不清楚需求
有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。
例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。
此时，用户就会要求软件系统分析人员替他们设想需求。
工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。
4.1.2、需求自身经常变动
根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。
事实上，历史上没有一个软件的需求改动少于三次的！
所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。
咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。
4．1．3、分析人员或客户理解有误
软件系统分析人员不可能都是全才，更不可能是行业方面的专家。
客户表达的需求，不同的分析人员可能有不同的理解。
如果分析人员理解错了，可能会导致以后的开发工作劳而无功。
记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：
“主宰地球的是汽车。
它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。
”所以分析人员知识的专一性也会造成需求分析的误解和失败。
这时，咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。
4.2、有效性软件需求分析三步法
根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。
4.2.1、“访谈式Visitation”阶段
这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。
建立起良好的沟通渠道和方式。
针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。
实现手段：
访谈、调查表格
输出成果：
调查报告、业务流程报告
4.2.2、“诱导式Inducement”阶段
这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。
用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。
实现手段：
拜访（诱导）、原型演示
输出成果：
调研分析报告、原型反馈报告、业务流程报告
4.2.3、“确认式Afirm”阶段
这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。
用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。
实现手段：
拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统
输出成果：
需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。
当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。
五、软件需求分析工具
我们根据用户需求，通过反复讨论、分析，最终明确一个唯一性的用户需求，这个结果其实就是我们的软件需求分析报告。
一般我们采用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同时可能采用一些开发工具，如VC或BC等，同样也会使用一些图形工具，如Potoshop、调色板等画图工具。
使用各种工具表达软件需求分析，其具体表达手段可以分为：
效果图描述。
主要是用户UI界面的描述反映用户需求功能；
逻辑图描述。
根据用户需求功能，使用抽象化理论，以及需求分析理论，对用户需求功能进行全面的分析，建立功能性逻辑关系图，流程逻辑关系图等；
关系图表描述。
主要是对信息关系、数据库表格、接口函数等描述；
工程数学描述。
分析用户需求，分析用户需求信息，运用工程数学进行算法推导，进行合理化需求分析推导；
甘地图描述。
主要是软件项目工作安排，开发周期预估；
其它方法描述。
保证完整性合理性的有效描述。
六、软件需求分析评估
软件需求分析评估是为了检查我们进行软件需求分析工作，保证软件需求分析工作正确性、完整性、有效性、合理性、可确认性、可实施性，完全保证用户所需求的功能。
6.1、组织结构与责任管理
我们对组织结构与责任管理的评估主要有：
参与人员任务和责任界面的明确；安排计划按时完成状况；相互间的协调能力状况。
6.2、满足用户需求的功能
我们进行需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。
需求分析的特点是需求的完整性、一致性和可追溯性。
完整性：
是准确、全面的描述用户的需求。
一致性：
是通过分析整理，剔除用户需求矛盾的方面，规用户需求。
可追溯性：
有两个方面的含义，整理和规的需求，其一，需要不断的和用户进一步交流，保持和用户最新的需求一致。
其二，和系统分析（设计）保持一致。
因此在需求分析之前我们必须建立需求分析技术层面的基本框架，从技术上保证需求分析的要求，在此基础上我们进行的需求分析才能满足项目对需求分析的要求。
6.3、保证可实施性
我们必须以用户软件需求为依据，以的态度详细的、准确的、完整的编写软件需求分析，避免空想世界，空中楼阁的想法；避免无逻辑性、无核心的描述；避免无量化思维，无实际空间概念。
6.4、需求分析评价指标
主要有这么几个指标：
功能性、完整性、正确性、逻辑性、表现性、合理性，可实施性等。
6.5、工作周期
评价人员投入，以及费用支出的合理性问题。
正确制定工作周期，保证软件项目的顺利完成。
6.6、需求不确定更改与可确认保证
可确认需求功能是实现用户需求的基本保证，如果不可确认的、不确定更改存在，将会阻碍软件实现，或者软件设计存在着不完整性缺陷，或者存在着不可实施性问题，我们必须区分是功能性障碍问题，还是未来性问题。
如果不能够明确是未来性问题，则必须调整功能需求，化解不确定更改的问题。
因此，判断不确定性更改是一个非常重要的问题。
、如何进行软件需求分析
作者：
伟 来源：
2003年3月10日 进入社区
需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些部特性）来阐述需求。
关键的问题是一定要编写需求文档。
我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。
系统的分析人员说：
“我们想与你谈谈你的需求。
”客户的第一反应便是：
“我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统”。
而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。
所以如果只有一堆、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。
需求的另外一种定义认为需“用户所需要的并能触发一个程序或系统开发工作的说明”。
有些需求分析专家拓展了这个概念：
“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。
这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。
而下面的定义则从用户需要进一步转移到了系统特性：
需指明必须实现什么的规格说明。
它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
从上面这些不同形式的定义不难发现：
并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。
系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述。
2．需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么。
最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。
同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
目前，国产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。
对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。
但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？
而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？
然而，即便并非出于商业目的的软件需求也是必须的。
例如库、组件和工具这些供开发小组部使用的软件。
当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国的软件开发者身上发生。
近来，我遇到一个开发小组开发包括代码编辑器在的一套部使用的计算机辅助软件。
不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。
结果这个小组只好手工抄写源代码文档以供代码检查。
这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。
相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。
而操作系统系统管理员在为处理脚本时发现简单的一需求清单竟是如此有用。
他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。
事实上，需求文档在开发过程中一直起指导作用。
3．需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适，如图4-1所示：
图4-1需求工程域的层次分解示意图
需求开发可进一步分为：
问题获取、分析、编写规格说明和验证四个阶段。
这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。
需求开发活动包括以下几个方面：
确定产品所期望的用户类别。
获取每个用户类的需求。
了解实际用户任务和目标以及这些任务所支持的业务需求。
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
了解相关质量属性的重要性。
商讨实施优先级的划分。
将所收集的用户需求编写成文档和模型。
评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
需求管理需要“建立并维护在软件工程中同客户达成的合同”。
这种合同都包含在编写的需求文档与模型中。
客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。
通常的需求管理活动包括：
定义需求基线（迅速制定需求文档的主体）。
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
以一种可控制的方式将需求变更融入到项目中。
使当前的项目计划与需求一致。
估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上。
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
在整个项目过程中跟踪需求状态及其变更情况。
以上几点说明是我总结了成功实施项目后系统分析人员的经验，同时也根据国外的其他系统实施的相关成功经验，进行了总结。
4．需求的类型
下面这些定义是需求工程领域中常见术语的定义。
软件需求包括三个不同的层次：
业务需求、用户需求和功能需求（也包括非功能需求）。
1．业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与围文档中予以说明。
2．用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。
3．功能需求（functionalrequirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。
软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。
作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
所谓约束是指对开发人员在软件产品设计和构造上的限制。
质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。
多角度描述产品对用户和开发人员都极为重要。
下面以一个字处理程序为例来说明需求的不同种类。
业务需求可能是：
“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。
而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。
同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档围的替换。
从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。
需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。
尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
5．需求分析的原则
不重视需求过程的项目队伍将自食其果。
需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望。
下面将讨论一些需求风险。
不适当的需求过程所引起的一些风险:
1.无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。
究其原因：
一是因为开发人员感觉与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。
在某些情况下，与实际使用产品的用户直接
升级会员 