一个应用软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。

　　S = { D1，D2，D3，… Dn }

　　问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。

　　Di = { P1，P2，P3，… Pm }

　　问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。

　　Pj = { F1，F2，F3，… Fk }

　　按图4.1结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：

　　（1）好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用合适的技术来实现此需求。

　　（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

　　2．3咨询监理公司需求分析方法论

　　根据以往的工程经验基本认为需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

　　首先：“访谈式”，这一阶段为和具体用户方的领导层、业务层人员的访谈式沟通上，主要目的基本是从宏观上把我用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息。建立起良好的沟通渠道和方式，针对具体的职能部门以及各委办局好能指定本次项目的接口人。

　　实现手段：访谈、调查表格

　　输出成果：调查报告、业务流程报告

第二阶段：“诱导式”，这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的计算机、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示DEMO，来感受一下整个业务流程的设计的合理性、准确性等等问题，及时地提出改进意见和方法。

　　实现手段：拜访（诱导）、原型演示

　　输出成果：调研分析报告、原型反馈报告、业务流程报告

　　第三阶段：“确认式”，这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰的向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表；操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受审查过的报告、文档签字确认。

　　实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

　　输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

　　整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户、承建方来讲，都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式后，需求分析的工作会一直进行下去，在后期的需求改进中，基本是处于以后两个阶段。