需求分析的概念
前言
软件开发的成功要素在于能够充分了解需求，否则无论多么好的系统设计或是多么强的程序设计能力，都无法弥补因需求不够明确对整体系统开发所造成的危害。
需求分析是一连串的处理过程，处理的精神在于找出使用者的需求，经过萃炼，将需求﹝数据的、功能的以及行为的需求﹞模式化，最后产出一份需求规格。在过程中，系统开发者扮演的角色，是利用高度的沟通技巧，采各种不同的询问角度﹝肯定句、疑问句或不断地重复﹞，将可能是被误解或是模糊不清的讯息一一加以澄清。由以上对需求分析的定义，衍生出软件需求分析的五大主要部份，分别为问题的认知、问题的评估及综合、模式化的过程、需求规格的产生及需求规格的审查。
问题的认知：需求范围的产生是来自于项目计划中所定义的系统规格，系统开发人员﹝即系统分析师﹞必须对项目计划有充分的了解，为促成系统分析师与用户之间对系统开发基本问题的共识，可以透过召开项目计划会议，邀请系统影响所及的相关人员及主管参与，针对系统的目标及效益及系统分析师所提出项目中可能的解决方案充分讨论及协调，了解每个人在项目进行中所扮演的角色，凝聚双方对项目成功的共识。
问题的评估及综合：系统分析师在这部分的工作着重于必须清楚地定义所有可观察到的数据主体，评估信息的流向及信息的内容，定义及演化出应有的系统功能，了解系统如何因外来事件的触发而有的正常响应，进而建立系统之间的接口，并能发掘一些未来系统设计的限制。在评估现有的问题及必须的输入及输出的讯息，系统分析师在整理这些相关的资料过程中，已慢慢厘出未来被建置的系统应有的功能架构。
模式化的过程：主要在描述用户需要些什么、当系统完成时能验证这些需求是否被满足。系统分析师透过一些系统化的方法，创造出能被系统设计人员充分了解的有关数据流向、控制流向、功能处理、系统行为运作及数据内容的模式，利用这些模式产生的软件需求规格做为进一步系统设计的基础。模式化的核心，有赖于定义一致的数据辞典来包含软件开发中所需的所有数据体的描述，藉由数据辞典做为需求分析沟通的共同语言。而模式化可分为三方面，一是数据模式，二是功能模式，三是行为模式。常用来表示这三方面的分析模式有ERD(Entity Relationship Diagram)，DFD(Data Flow Diagram)，CFD(ControFlow Diagram)，STD(State Transition Diagram)...等，系统分析的模式必须达成三个主要的目标: (1)描述使用者的需求，(2)建立基本的软件设计环境，(3)定义软件设计完成后验证需求的方法。
图一 结构化分析模式
数据字典位于图一的核心-存放所有输入及输出数据对象的叙述。围绕于图一核心的三种图表其中的实体关系图(Entity-Relationship Diagram，ERD)，为描述数据对象之间的关系。ERD同时也用来表示数据模块之间的运作方式。数据对象叙述(Data Object Description)说明ERD中数据对象的属性。
数据流程图(Data Flow Diagram，DFD)主要有二种目的: (1)显示数据在系统中的流向，(2)描述处理数据流的功能项目。DFD在信息范围的分析过程中可提供附加信息并可将其当做是基本的功能模式。在DFD中每一个功能的叙述是在功能规格(Process Specification，PSPEC)中完成。
状态转换图(State Transition Diagram，STD)显示系统对外部事件作何种反应。为此，STD显示系统不同的行为状态及状态与状态间转换的不同方式。也可把STD当做是基本的行为模式。控制规格(Control Specification，CSPEC)则包括软件控制观点的其他相关信息。这些模式分析的产出最终的目的在于让需求分析的结果愈趋近于可被建置的系统。
需求规格的产生：系统分析师将需求以一种能被成功建置的方式展现给系统开发人员及用户，透过需求规格的产生，将系统分析师对使用者需求的认知转化成可阅读及可被了解的文件，作为双方对谈及后续开发的基础，需求规格的可读性与系统分析师的文件表达能力有强烈的正相关。基本的需求规格架构涵盖：
- 系统概述：描述系统所欲达成的目标，使用何种计算机系统及规划的软件范围。
- 信息描述：提供软件所要解决问题的详细描述，包括信息的内容，对应关系，流程及架构，并且以外部系统组件及内部软件功能来描述软硬件及人机接口。
- 功能描述：描述每项功能所能解决的问题及其相关程序，经由陈述并证实设计上的限制，及未来系统建置后可达成之系统执行效率的耍求，并辅以多张图表解释整个系统的架构及系统功能与其他系统组件之间的相互关系。
- 行为模式的描述：如何因应外部事件的触发及内部控制的特性而导致影响系统软件操作所产生之结果。
- 验证及标准：用以验证软件开发完成后之正确性。需要彻底地了解软件需求方可明确地描述验证方法及标准，做为重新检视所有的需求之依据以求未来系统设计之完整性。
- 参考文献及附录。
需求规格的审查：应由系统分析师及用户一起进行需求规格的审查，从宏观及微观的角度来检视规格书的内容。从宏观的角度应确认规格的完整性，一致性及正确性。从微观的角度应审视规格书中的用字遣词，是否有尚未发现的潜在问题存在。一旦审查完成，规格书即被双方签名确认，虽不排除在规格被确认后仍有需求变更的可能，但须让使用者了解，每一需求的变更形同软件范围的扩张且将导致项目时程的延长及成本的增加，其所带来的影响是难以预估的。在需求规格确认后，系统开发人员则依据此规格书进行后续系统设计的工作。