研究用户需求所获之物即软件需求分析, 它要全面透彻理解用户软件需求所涵盖的完整功能, 对用户软件功能需求予以确认, 进而构建出一个具备可确认性、可验证性的基本依据。
项目的开端是软件需求分析, 它还是项目实施极其重要的关键点。有关机构的分析结果显示, 我们所设计的软件产品, 存在不完整性, 存在不正确性等问题, 其中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}。
一个软件, 它涵盖了所有功能的集合, 并且还包含了实现所有功能的各种方法以及相应算法的描述部分。需求分析, 它是依据用户需求来开展的任务, 先是历经需求问题的具体识别过程, 后续还要进行分析、消化以及综合这些步骤, 接着去制订规格说明, 再进行评审这一道程序。需求分析一共分为四个阶段, 其目的是让用户需求和设计同步开展, 同时实现设计能够满足用户需求的这一目标理念。需求分析方法, 它自始至终贯彻着吸收、同化、贯彻这些相关的方法和手段, 通过商业化行为去处理需求与实现过程当中所存在的矛盾所在, 进而解决用户需求与商业化产品达到融通的问题, 还要应对规范与个性化追求之间的状况。
二、 软件该怎么样去分析目标呢, 软件在进行需求分析时主要实现的目标有这些呢: 首先, 要对实现软件的那种功能去做出全面性质的描述, 以此来帮助用户判断所实现功能的正确性、保证有一致的状态以及具备完全的完整性, 最后驱使用户处于软件设计真正启动前可以十分细致严谨、全方位地去进行思考软件需求；其次, 得知晓并且描述软件实现会需要的全部信息, 进而为软件设计设定个基准、进行确认以及展开验证；最后, 要借助这样的需求为担任软件管理的人员去当作软件成本计价的依据以及去完成编制属于软件开发计划的那种书提供凭依。
那么, 关于需求分析这一回事儿, 它的具体内容, 能够归纳成为六个不同的方面, 分别是, 软件所具备的功能需求, 还有软件跟硬件或者是其他外部系统之间的接口情况, 再者是软件自身拥有的非功能性需求, 以及所谓的软件反向需求, 另外不可或缺的还有软件设计以及实现这件事情上存在的限制, 最后一项便是阅读支持信息。而软件需求分析这一过程, 需要尽可能地去呈现出软件达成功能需求的全部各种信息, 如此这般, 才能够让软件设计人员以及软件测试人员, 不再非得要跟需求方进行接触。这样一来, 就对软件需求分析的内容提出了要求, 必须要做到正确无误、完整无缺、保持一致并且是能够进行验证的。并且, 致力于确保软件设计的质量, 使得软件功能的修整与验证更为便利, 软件需求的表达不存在歧义, 具备可追踪以及能够修改的特性。
2.软件的功能需求, 属于整个需求分析里头, 最为主要、最为关键以及最为复杂的部分, 它会描述在软件的各种可能状况之下, 针对所有可能输入的数据信息, 应当完成哪些具体功能, 又会产生怎样的输出。描述软件功能需求的时候, 需要注意下面几点: 其一, 功能需求的完整性与一致性, 对功能的描述应当涵盖跟功能相关的信息，并且要具备内在的一致性, 也就是各种描述之间既不矛盾, 也不冲突。需要留意下面这些要点: 其一, 给出使得功能触发的各类条件, 像控制流、运行状态、运行模式等；其二, 界定各种可能性条件下的全部可能输入, 涵盖合法输入空间以及非法输入空间；其三, 给出各种功能间有可能存在的相互关系, 比如各个功能间的控制流、数据流、信息流, 功能运行关系包括顺序、重复、选择、并发、同步；其四, 给出功能性的主要级别, 例如基本功能、可由设计者选择逐步达成的功能、可由设计者改变实现的功能等；其五, 尽量不要运用"待定"这类词汇。带有待定相关内容的需求, 都并非完整的文件, 一旦有出现待定的情况, 就得针对待定部分展开内容说明, 还要明确负责人员, 确定实施日期。
2）要实现需求功能描述具备那种令人摸不着头脑的无岔意性所需追踪的功能, 这功能描述得有着那种清晰无比的能从怎样输入达成到怎样输出的呈现, 而且, 输入以及输出方面呈现出来的细致描摹, 是得匹配有着数据流方面的详细表述以及控制流方面那个勾勒图形展示的, 同时还得注意, 这些所进行的所有描摹, 必须实现在有关其他地方所描述时得保证口径相同, 保持一致的情形才行；然后, 还能够采用像语言这样的形式, 或者方程式模式, 又或者运用决策表样式, 甚至矩阵格式或者呈现图形等方式来进行该功能的描绘说明。假设选用语言描述要采用结构化的语言, 在开始使用该结构化语言描述前，得先说明此结构化语言在使用时, 其本身属于顺序、选择、重复或者并发中的哪一种, 接着再阐述步骤逻辑。整个描述要保持单入单出。 然后还要注意, 在运用结构化语言描述时, 每一个功能名称以及参照编号务必得保持是唯一的, 不可以把多个不同的功能混杂在一起去进行描述, 因为这样便利于功能的追踪以及修改。 另外, 功能描述可是要特别留意需求说明和程序设计之间的区别的。需求设计并非只是关于软件在功能方面的设计, 它所给出的涉及软件运行的内容是外部功能领域的表述, 而且还要明确为了成就这一外部功能务必付诸怎样的行动, 诸如采取何种数据结构形式, 定义数目众多的模块, 以及处理接口之间的接口等操作, 这些都属于设计阶段当倾力而为的事情, 然而功能描述切不可牵扯那些细节层面的问题, 惟其如此才能规避给软件设计招致那些不必要的限制。
2.2、 软件与硬件或其他外部系统接口
软件囊括与其它外部系统以及硬件的接口, 其涵盖这些内容: 其一人机接口这方面, 需对输进去的、输出来的内容, 屏幕样式的规划、呈现形式这类要求作出注解；其二硬件接口那里, 将端口番号表明白, 还要理清指令集聚合情形, 输入出去与输入之间那种信号的内含以及数据的类别情况, 开始运作时信号的源头, 数据传送经过的通路编号以及信号处置运用的办法；其三软件接口这儿, 得说明所属软件的称呼是什么, 有什么样儿易于记住的符号, 详细的说明内容, 版本的序号以及出处是哪里。
（4） 通讯接口：指定通讯接口和通讯协议等描述。
2.3、软件存在非功能性需求, 其指的是软件性能指标、容限等功能以外的需求, 一般涵盖下述内容: （1）有时间需求, 包含输入、输出频率, 输入、输出响应时间, 各种功能恢复时间等；（2）存在处理容限、精度、采样参数的分辨率, 误差处理等；（3）有可靠性的MTBF要求, 可维护性、安全性要求等。（对可能的不正常的输入给以正常响应属于功能性需求, 是可靠性的重要内容）
2.4、软件存在反向需求, 软件的反向需求用于描述软件在何种情况下无法进行何种操作, 这一条是依据软件实际要求来确定的, 存在两类情形需要采用反向需求的形式。第一种情况是, 某些用户需求适合采用反向形式加以说明, 像数据安全性要求便属于这类形式。第二种情况是, 对于一些可靠性和安全性要求较高的软件, 有些内容必须描述软件不能做的事情, 比如控制点火时序时, 我们必须清晰地交代在哪些情况下不能点火, 否则将会导致故障。
2.5、软件设计存在限制, 软件实现也存在限制, 软件设计和实现上的限制主要是针对软件设计者而言的限制。比如说, 软件运行环境存在限制, 这包括选择计算机类型的限制, 使用配置方面的限制, 操作系统方面的限制等等。还有设计工具存在限制, 这涵盖使用语言的限制, 执行标准的限制。另外还有保密要求方面的限制。
2.阅读支持信息, 这部分内容, 是为帮忙理解用户需求而设, 也是为让需求利于修改与追踪, 它本身并非需求描述, 是属于需求分析重要部分, 其对需求分析可读性有影响, 一般目录、需求背景信息、内容索引、交叉引用表、注释等都属于这部分内容。
三、 软件需求分析人员组织
软件需求分析的根本问题在于理解用户的功能需求, 借由这个, 软件需求分析本就是和客户交流过程所达成的目标。这要求我们组织合适的相关人员去开展交流活动。这里的需求分析是属于综合团队的工作事宜, 是依据需求分析理论的指引, 针对用户的需求运用渐进的方式逐步深入；依靠不断变换的方式来形成实质的约束；尽力达成需求功能目标从而塑造出具有特色效果的商业化产品。需求分析属于一种商业行为, 它全然是商业化范畴的操作, 其要求具备将商业、技术等多方面融合的团队一同协作配合, 用来解决需求与设计的同步问题, 达到设计契合需求。
对于需要考虑参加软件需求分析工作团退的人数, 以及配置合理参与人员的情况, 涉及项目大小, 就连项目涉及内容也得纳入考量范畴。通常要保障必然存有一些商务活动人员参与其中才行, 然后就是项目管理人员所需也不可或缺, 再者设计技术人员此类同样得确保有适当数量参与。并且, 对于组织人员而言, 明确确定负责范围这一事项是务必达成的要求, 同时还需要明确工作目标, 以此来保证具体实施过程具备有效性那般有着相应保障工作的开展。
四、 为确保项目正常开展, 且能顺利达成, 我们得强化项目管控及重视项目剖析工作。我们唯有立足实际, 切实掌握用户需求, 掌握用户需求目标, 掌握用户未来功能界定, 方能保障我们开发工作的正确 。
4.1、重点监控软件需求分析办法, 鉴于软件项目独具的特性以及行业覆盖范围的宽广性, 还有需求分析所蕴含的高风险性, 软件需求分析极度重要性切实不容小觑, 与此同时需求分析实在是相当难做。而其缘由本质上是由如下一系列情况所导致形成的。
4.有的客户, 对需求仅具朦胧之感, 故而讲不清具体需求, 比如各地众多部门 、机构 、单位于推进应用系统与网络建设之际, 客户方办公人员大多不明计算机网络用途，更缺 IT 系统建设方面专家与知识, 这时用户便会要求软件系统分析人员代其构想需求, 工程需求具主观性, 给项目未来建设埋下潜在风险。
4.需求自身常常变动, , 依据以往的历史经验来讲, , 随着客户方对于信息化建设的认识以及自身业务水平的提升, , 他们会在不同的阶段与时期, , 针对项目的需求提出新的要求以及需求变更, , 实际上, , 历史当中没有一个软件的需求改动是少于三次的！所以, 一定要接受"需求会出现变动"这一情形, 在实施需求分析期间, 得明白要防患于未发生前, 尽可能全力详细分析出哪些属于稳定的需求类目, 哪些属于容易变化的需求类别, 从而当着手去进行系统设计之际, 把软件的关键性架构建立于稳定的需求层面上, 与此同时要预留出可供变更的空间。咨询监理方于需求分析的功能界定方面承担着一个具备居于中间位置特性、保持公正态势、做到公平性质的角色, 因而同样一定要极具主动性地投身到需求分析的准备进程里, 以此来辅助客户方以及承建方去界定"做什么"、"不做什么"的系统功能界限。
4．3、分析人员或者客户存在理解错误, 软件系统分析人员并非全是全才, 更不是行业方面的专家, 客户所表达的需求, 各位不同的分析人员可能有不一样的理解, 要是分析人员理解有误, 那么可能致使往后的开发工作徒劳无功, 记得有一则笑话, 有个外星人间谍悄然潜伏到地球刺探情报, 它给上级写了一份报告: "主宰地球的乃汽车。"。分析人员知识专一性会造成需求分析误解和失败, 所以呢会出现这一情况, 而这时咨询监理公司就得照实际项目需求调研计划去提醒承建方增强业务知晓程度并重视沟通技巧, 因为有这样一些东西, 它们喝的是汽油, 靠四个轮子滚动向前行进, 嗓门特别大, 双眼夜里能射强光, 特别有趣, 竟是车里住着一种名为"人"的寄生虫, 还是这些寄生虫完全掌控了车。
4.2、依据过往工程经验, 需求分析工作方法应定位于"三个阶段", 此即所谓的"三步法", 它归属于有效性软件需求分析三步法。
4.这一阶段被称作"访谈式"阶段, 它是与具体用户方的领导层、业务层人员就项目相关内容展开访谈式沟通 , 通过这种沟通方式要达成的主要目的是, 从宏观层面去精准把握用户的具体需求方向以及需求趋势 , 清楚了解具体的现有组织架构、复杂的业务流程、相关的硬件环境、配套的软件环境、当前运行的系统等诸多具体情况 , 获取客观的信息 , 还要构建起良好的沟通渠道以及沟通方式 , 针对具体的职能部门以及各委办局 , 最好能够指定出本次项目的接口人 , 实现手段是访谈以及调查表格 , 输出成果为调查报告、业务流程报告。
4.2.2、"诱导式"阶段, 此阶段处于承建方已明晰具体用户方的组织架构后, 以及业务流程、硬件环境、软件环境、现有的运行系统等诸多具体实际且客观的信息之上, 结合现有的硬件、软件实现方案, 制作出简单的用户流程页面, 同时依据以往的项目经验, 针对用户运用诱导式、启发式的调研方法与手段, 与用户共同探讨业务流程设计的合理性, 探讨业务流程设计的准确性, 探讨业务流程设计的便易性, 探讨业务流程设计的习惯性。能够操作简单演示的DEMO的用户, 去感受一下整套业务流程在设计方面的合理性、准确性等诸多问题, 进而及时地给出改进意见与方法。实现手段包含拜访（诱导）、原型演示, 输出成果有调研分析报告、原型反馈报告、业务流程报告。
4."确认式Afirm"阶段, 处于上述两个阶段成果之上, 是具体流程细化、数据项确认阶段, 此阶段承建方要提供原型系统、明确业务流程报告、数据项表, 清晰向用户描述系统业务流设计目标, 用户方通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统, 提出反馈意见, 对已可接受的报告、文档签字确认。实现手段为, 进行拜访, 此拜访包含回顾以及确认环节, 接着要提交业务流程报告与数据项表, 还有原型演示系统；输出成果有需求分析报告、数据项以及业务流程报告, 另外还有原型系统反馈意见, 后三者能够被统一归入需求分析报告里, 将其提交给用户方与监理方进行确认以及存档；总体而言, 需求分析的三个阶段是需求调研里一个举足轻重不可被忽视的部分, 其三个阶段或者说三步法的实施与采用, 对用户和承建方均可同样提供项目成功的保证。确实在系统建设进程里 尤其是采用迭代法的开发模式之际 需求分析的工作得持续开展着 而在后期需求改进阶段 工作基本上聚焦于后两个阶段当中。
五、 面对软件需求分析工具, 我们依据用户需求, 历经反复讨论、深入分析, 最终明确并确定一个具有唯一性的用户需求, 而后这个得出的结果实际上便是我们的软件需求分析报告。通常情况下, 我们会选用Word、Visio。、Excel等工具, 与此同时, 可能予以采用一些开发工具, 诸如VC或者BC等, 同样地, 也会运用一些图形工具, 像是调色板之类的画图工具。
运用各类工具来表达软件需求分析, 其具体的表达形式可划分成, 效果图描述, 这主要是关于用户UI界面的描述, 以此来反映用户需求功能, 逻辑图描述, 依据用户需求功能, 运用抽象化理论以及需求分析理论, 去对用户需求功能作全面剖析, 进而建立功能性逻辑关系图、流程逻辑关系图等, 关系图表描述, 主要针对信息关系、数据库表格、接口函数等展开描述, 工程数学描述。针对用户需求展开剖析工作, 针对用户需求所涵盖的各类信息予以深入分析, 借助工程数学知识来开展算法方面的推导工作, 进行具备合理性的需求分析推导工作；甘地图用于描述相关内容这一块。主要涉及软件项目具体工作的安排事宜, 就该软件项目开发周期进行预估工作；其他方法进行描述这一块。确保能够实现完整性以及合理性的有效描述工作。
六、 软件需求分析评估, 其目的在于检查我们开展的软件需求分析工作, 确保该工作具备正确性, 拥有完整性, 体现有效性, 呈现合理性, 具备可确认性, 具有可实施性, 从而全面保障用户所需求的功能。
6.对于组织结构与责任管理所做的评估, 主要涵盖这些方面, 有关于参与人员任务以及责任界面是否明确这一点, 还有安排计划能否按时完成的状况, 另外就是相互之间的协调能力状况。
6.2、针对满足用户需求的功能, 我们开展需求分析, 其目的在于, 要对用户的需求予以完整且准确无疑的描述, 还要跟踪用户需求的变化情况, 进而极其精准地把用户的需求反映到系统的分析以及设计里面, 并且要让系统的分析、设计与用户的需求始终保持一致。需求分析有着这样的特点, 即需求具备完整性、一致性以及可追溯性。而所谓完整性, 指的是要对用户的需求做出既能确保准确无误又涵盖方方面面的描述。所谓一致性, 指的是借助分析整理, 去除用户需求当中存在矛盾的部分, 以此规范性地处理用户需求。可追溯性存在两个方面的含义, 一方面是整理和规范的需求, 而为此之一, 就得持续且不断地跟用户进一步开展交流, 以此维持跟用户眼下最新需求处在一致状态。另一方面是要跟系统分析（设计）使其处于全然相同的情况。所以呢, 在需求分析正式开启之前, 我们必定要创建需求分析技术层面的基础架构, 从技术角度确保需求分析能够符合要求, 在这个基础之上我们所举行的需求分析才行得通去满足项目针对需求分析所提出的要求。
6.为保证可实施性要做的是, 以用户软件需求作为其依据, 以求实态度、详细且准确又完整地去编写软件需求分析去, 避免那种空想不切实际的空幻、虚幻不实以及不存在于坚实基本之上的想法和观念；还要避免没有逻辑性遵循以及欠缺核心要点那种样子的描述；为了保证可实施性还要务必避免没有量化概念思维以及没有实体实际空间等方面概念的情况出现。
6.4、需求分析的评价指标, 存在着这样几个方面的指标, 分别是功能性、完整性 、正确性、逻辑性、表现性、合理性 、可实施性等。
6.5、评价人员把精力投入进去, 还有费用花销支出是否合理的问题, 这关乎工作周期。要正确地制定出工作周期, 从而确保软件项目能够顺利地完成。
6.可确认需求功能, 是实现用户需求的基本保证, 若存在不可确认的、不确定更改, 会阻碍软件实现, 或者软件设计有不完整性缺陷, 或者有不可实施性问题。我们得区分是功能性障碍问题, 还是未来性问题。若没法明确是未来性问题, 就得调整功能需求, 去化解不确定更改的问题。所以, 判断不确定性更改是非常重要的问题。