怎样做软件的需求分析？

1. 怎样做软件的需求分析？

软件需求的定义：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：
需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：
（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：
1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。
4.需求分析评价标准
（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

2. 软件的功能需求分析要怎么写？

1. 引言

1.1　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.

1.2　项目背景

1.2.1项目委托单位:****公司

1.2.2开发单位:***公司

1.3　定义

1.4　　参考资料

2. 任务概述

2.1　目标:

 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.

2.2　运行环境:

 硬件方面:Pentium级处理芯片
　　1兆显存的兼容显卡
　　256色,800*600的兼容显示器
　　标准兼容打印机

软件方面: WIN95操作系统

2.3　条件与限制:

　　编程用计算机一台
　　完成期限2000/7/1
　　无资金供给

3. 数据概述

数据流程图如下: 

3.1　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

3.2 　动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

3.3　数据库描述:

　　人事管理数据库:公司内人员的个人详细信息,包括档案信息
　　销售管理数据库:当日销售记录及以前的销售统计,用于销售分析
　　财务管理数据库:公司内部账目及收支情况详表
　　技术管理数据库:公司所需各技术档案的详细记录(包括文档) 

3.4 数据字典:

数据流词条描述:

　　1.数据流名:登录信息
　　来源:用户的输入
　　去向:系统内部检验部分
　　组成:用户名,密码
　　流通量:每次登录输入一次

　　2.数据流名:登录结果
　　来源:系统
　　去向:用户
　　组成:返回信息
　　流通量:每次登录返回一次

　　3.数据流名:输入修改信息
　　来源:用户
　　去向:系统判断部分
　　组成:根据各数据库内容而不同
　　流通量:依用户输入而定 

　　4.数据流名:反馈信息
　　来源:系统判断部分
　　去向:用户
　　组成:系统经判断后发回的字符数据
　　流通量: 依系统当前信息而定

　　5.数据流名:识别信息
　　来源:系统内部检验部分
　　去向:系统判断部分
　　组成:系统各数据库的标识信息
　　流通量:用户每次输入流通一次

　　6.数据流名:处理信息
　　来源:系统判断部分
　　去向:各数据库处理部分
　　组成:读取/修改标识,读取/修改的变量名称
　　流通量:用户每次输入流通一次

　　7.数据流名:读取修改
　　来源:系统判断部分
　　去向:系统各数据库
　　组成:读取/修改标识,读取/修改内容
　　流通量: 用户每次输入流通一次

数据文件词条描述:

　　1.数据文件名:人事数据
　　简述:存储人员信息
　　数据文件组成:人员的各项信息(以CString类型为主)

　　2.数据文件名:销售数据
　　简述:存储当日及从前的销售记录
　　数据文件组成:销售的各项信息

　　3.数据文件名:财务数据
　　简述:存储财务管理信息
　　数据文件组成:财务管理的各项记录

　　4.数据文件名:技术数据
　　简述:存储公司内部使用的技术档案信息
　　数据文件组成:技术档案名称,内容

加工逻辑词条描述:

　　1.加工名:检验
　　简要描述:判断用户的许可性
　　输入数据流:登录信息
　　输出数据流:登录结果
　　加工逻辑:判断是否与系统内部用户信息相符合

　　2.加工名:判断
　　简要描述:判断用户的操作并进行相应的读取/存储工作 
　　输入数据流:输入修改信息
　　输出数据流:反馈信息
　　加工逻辑:判断用户的操作->调用数据库->读取/修改->反馈

　　3.加工名:人事档案管理
　　简要描述:对人事数据库进行相应要求的操作,并与判断部分交互
　　输入数据流:处理信息,读取修改
　　输出数据流: 读取修改, 处理信息
　　加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

　　4.加工名:销售统计
　　简要描述:对销售数据库进行相应要求的操作,并与判断部分交互
　　输入数据流:处理信息,读取修改
　　输出数据流: 读取修改, 处理信息
　　加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

　　5.加工名:财务统计
　　简要描述:对财务数据库进行相应要求的操作,并与判断部分交互
　　输入数据流:处理信息,读取修改
　　输出数据流: 读取修改, 处理信息
　　加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

　　6.加工名:技术管理
　　简要描述:对技术统计数据库进行相应要求的操作,并与判断部分交互信息
　　输入数据流:处理信息,读取修改
　　输出数据流: 读取修改, 处理信息
　　加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息

源点及汇点词条描述:

　　名称:用户
　　简要描述:既是源点又是汇点,发出动作信息给"检验"和"判断"加工,通过交互界面接受反馈信息有关数据流:登录结果,登录信息,输入修改信息,反馈信息
　　数目:一个

4. 功能需求

4.1　功能划分

　　可细分为四部分:人事管理,销售管理,财务管理,技术档案管理

4.2　功能描述

人事功能:

　　(1)能对公司内部的所有人员有关档案详细资料记录并保存。
　　(2)能对数据库内人事档案的数据进行查阅和修改。
　　(3)能按部门或姓名检索人员。
　　(4)当某员工的雇用期限达到整年时，按时提醒。

销售统计功能

　　(1)按日对公司的销售情况进行统计,包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况
　　(2)制定销售情况的月报表\季报表以及年报表对销售情况进行分析,对不同销售人员的业绩进行评定

财务管理功能

　　(1)协助财务人员进行计算机管理,对库存情况\进货情况\销货进行登录和输出
　　(2) 根据预设的库存情况提醒进货
　　(3) 对收款情况进行统计,在应收帐款达到预设值时进行提示

技术管理功能

　　(1)对技术资料进行登录
　　(2)对维修记录进行登录和统计,按不同型号的机器进行故障整体分析,并作出分析报告
　　(3)对维修配件的需求进行管理并及时提示备货

5. 性能需求

5.1　数据精确度:因为此数据为公司内部数据,所以要求不能有误差

5.2　时间特性:当日销售统计要求有即时性,马上能反应出存货的问题;同时财务管理数据计算当前存货情况,并对进货情况进行估算

5.3 　适应性:此软件只在公司内部管理人员的机器上使用,因此不考虑适应性

6. 运行需求

6.1　用户界面:

　　屏幕格式:

　　(1)要求有菜单及工具栏以方便操作
　　(2)各数据库信息可在屏幕上直接修改
　　(3)各数据统计结果可在屏幕上显示
　　(4)进行系统分析后的结果在另一窗口中显示

　　报表格式:

　　(1)人事管理报表只要求有个人的普通数据
　　(2)销售统计报表要求可分别打印当日统计或之前的统计
　　(3)财务统计报表要求打印出存货及公司帐务详表
　　(4)技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式:要求菜单项大致与WIN95标准相同,另外附加的功能做到新的单项中输入输出时间:年份以4位数字表示

6.2　硬件接口:需要标准打印机接口进行报表打印

6.3 　软件接口:Windows标准接口

7. 其他需求

　　可使用性:要求容易使用,界面友好

　　安全保密性:因本数据属于公司内部管理用关键数据,因此除公司管理人员外,其他人员不得访问.要求设有登录密码检验功能,并且此密码可以在以后进行修改

　　可维护性:要求本软件的维护文档齐全,便于维护

3. 如何进行软件需求分析

软件需求分析免费下载    
链接:https://pan.baidu.com/s/1qNBwqvbRS5ziBSIeanLQAQ
 提取码:qoyw    
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

4. 软件需求分析有哪些方法

软件需求分析免费下载    
链接:https://pan.baidu.com/s/1qNBwqvbRS5ziBSIeanLQAQ
 提取码:qoyw    
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

5. 如何进行软件需求分析

如何进行软件需求分析，简而言之不是几句话可以描述清楚的，这里给你一些方法功能参考。

首先，在进行软件需求分析之前，得有一份软件说明书或者软件需求规格说明书，因为这个是我们进行需求分析的对象。但是这个需求规格书写的质量怎么样，实际上是决定了软件项目的进度、成本甚至成败的？为什么这么说呢？因为当前软件开发这个行业最大的问题是需求质量低下，这个导致了项目成本至少增加了30%以上，这也是为什么软件这个行业有钱的公司不多的主要原因。或者说能做出一份有质量的需求规格说明书将体现这个企业的挣钱能力，但现实是绝大多数企业都像人月神话中描述的一样：一步一步踏入了泥潭。。。由于这个工作产品如此重要，因此通过过个步骤来保证它的质量：需求策划、获取、分析、确认以及后期需求管理，尤其是变更管理。如果想了解具体的每个步骤的详细内容可以联系我。
其次，如果需求规格说明书有了，我们怎么分析呢？在具体说明分析方法之前，首先我们要明确一个问题：需求分析到底是在分析什么？其目的是什么？其实我们绝大多数的需求工程师都不太清楚或者不能明确的回答这些问题，从而导致他们花费了大量的时间来写用例（user case），写了很多关系复杂甚至连需求人员都看不明白或者越看越糊涂的东西，因为他们认为这样后续的开发、测试人员就能开明白了，事实上是这样的吗？根本不是，如果是的话，我们的软件行业中的绝大多数企业活的普遍不那么悲惨了。。。回到软件开发，我们来想一下，我们开发这个东西给谁用？是自己吗？？？如果是自己事情就简单了，因为需求都在自己脑子里面了，就算不完整起码也不会缺多少，但问题正好相反，99.999999%的情况下我们是为别人或者说我们的用户开发的，也就是说需求其实是在客户的脑子了，而不是我们的脑子里！！！我们的首要目的应该是如何通过一套完整的套路把需求从客户的脑子里面传输到我们的脑子里面，然后按照规格化（这个是另外一个重点）的方式把它按照说明书一样描述出来让后续人员能够看得清清楚楚、明明白白，这个步骤是最关键的一环，因为我们的绝大多数客户都不会写需求规格说明书，所以这个任务落在我们的身上。那么我们到底都问什么不会丢需求呢？这个是有一套方法和模板来指导需求人员和UI工程师（调研时就需要画原型，可以稍微想一下这么做的好处）来获取完整的需求。只有这样，才能获取有质量的需求。
那么说了这么多，分析到底是干什么的呢？分析就是需求人员首先自己要系统的检查一下需求来保障需求的质量，记住不是保证，是保障，它就像软件开发中的评审或测试一样，是保障产品的质量进行的检查活动，它们不能保证质量，只是保障作用。就像我们考试一样，你认真的答完题了，还是需要认真的检查一遍，因为这个是人的天性之一。那么问题来了，怎么进行检查或者从哪些方面进行检查呢？我推荐的策略是先外后内、先系统后模块、先功能后非功能、先业务后属性，通过整套方法下来可以帮我们查到不少之前遗漏、写错、或者矛盾的地方，当然也包括可能不是客户需要的needs，只是expectation。这个工作比获取要简单一些，但是是一个繁杂的活，要逐项逐项的检查每一个需求的内容以保障需求的质量。到底检查哪些内容呢？这个太多了，就不罗列了，需要的网友可联系我。
同样，需求评审就是另外一帮人帮我我们再次检查一下需求，看看里面是否有什么问题存在，是进行需求质量保障的另外一个重要环节。
因此，分析与评审其实是很类似的工作，只是参加检查的人员角色从单一角色变为多角色，因为需求规格说明书要被他们拿来进行实现和测试。
我们常规的需求分析，基本上可以认为是在 盲人摸象，在主观的发挥着他们的想象力去判断，而忘记了 需求其实在客户脑子里 这个基本的原则，你用一套方法和模板问出来就是了。。。当然前提是套路要实用，模板要详尽。。。
就说这么多，希望对你能有所帮助。。

6. 软件需求的分析方法

软件需求分析方法大体分为如下四类：结构化方法、面向对象方法、面向控制方法和面向数据方法。限于篇幅，将主要从结构化方法和面向对象方法以及RUP三个方面进行简要的探讨。 面向对象（Object Oriented, OO）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分．每一级抽象都重复对象建模(对象识别)一动态建模(事件识别)一功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现为止。面向对象需求分析(OORA)利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求：整体—部分模型：该模型描述对象(类)是如何由简单的对象（类）构成的。将一个复杂对象(类)描述成一个由交互作用的若干对象(类)构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的类型甚至使用伪码或小说明的形式来详细刻画。对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过消息传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。状态模型既可以用状态转换因的图形化手段，又可用决策表或称决策矩阵的形式来表。 RUP（Rational Unified Process）是Rational公司开发和维护的过程产品。RUP是工程化的软件开发过程，它提供了在开发机构中分派任务和责任的纪律化方法。RUP不仅仅是一个简单的过程，而是一个通用的过程框架，可用于各种不同类型的软件系统、各种不同的应用领域、各种不同类型的组织、各种不同的功能级别以及各种不同的项目规模。RUP的突出特点可以由以下三个关键词来体现——用例驱动、以构架为中心、迭代和增量的。这些是RUP所特有的，也是同等重要的。构架提供了一种结构来指导迭代过程中的工作，而用例则确定了目标井驱动每次迭代的工作。进行需求分析的基础是要获得用户的需要，为了完成这一工作，必须建立业务模型，通过描述业务规则、业务逻辑，明确业务过程并对其进行规范、优化。对于一个系统，在建立业务模型时，应从3个方面来描述其特性：功能、行为、数据，对应于这些特性。 基于上述分析可知，结构化分析方法与面向对象分析方法的区别主要体现在两个方面：* 将系统分解成于系统的方式不同。前者将系统描述成一组交互作用的处理，后者则描述成一组交互作用的对象。* 子系统之间的交互关系的描述方式不一样。前者加工之间的交互是通过不太精确的数据流来表示的，而后者对象之间通过消息传递交互关系。因此，面向对象软件需求分析的结果能更好地刻画现实世界，处理复杂问题，对象比过程更具有稳定性，便于维护与复用。

7. 如何进行软件需求分析

　　需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。
　　关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。系统的分析人员说："我们想与你谈谈你的需求。"客户的第一反应便是："我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统"。而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。
　　需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"。有些需求分析专家拓展了这个概念："从系统外部能发现系统所具有的满足于用户的特点、功能及属性等"。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性：
　　需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
　　从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的"需求"术语存在，真正的"需求"实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
　　任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述。

8. 如何进行软件需求分析

功能：
　　软件功能又分关键功能，次要功能等。在第二阶段，我们要做的就是分辨并整理关键功能，和次要功能。根据项目的规划，找出当前需要实现的关键功能，与此同时，对于高风险，技术风险大的功能，或者关键功能中相互冲突的功能进行前期取舍。（当然啦，在取舍和确定具体的功能范围，还是要和客户之间相互沟通的）
　　最后要补充一点的，就是确定关键功能这个过程是不停递归的一个过程。
　　质量：
　　一般质量分类包含 性能，安全性，可靠性，易用性，可扩展，可维护，可移植等。
　　在需求分析中，和关键功能一样，要根据项目的愿景，进行关键质量的筛选。
　　在某种情况下软件的质量之间还是有冲突，鱼和熊掌不可兼得的情况，如 可维护性和性能是一对对立的两兄弟。我们还需要对这样的关键质量进行必要的取舍。在作出这样的取舍，依据的标准就来源于我们需求的第一阶段的工作。
约束：
　　软件的约束分好多的角度，
　　业务级约束：举例：项目的组织结构和人员信息来源于企业人事系统
　　用户级约束：举例：使用客户用一部分是残障人事等，其包含了藏语用户等
　　开发级约束：举例：开发人员的技术水平等。
　　在调研并完成这样的二维需求表后，及时的和客户沟通，确定关键功能，关键质量和约束等。对二维需求表中的内容进行取舍和确定。
　　在第二阶段出的配置项二维需求表
在第二阶段的基础上，我们就可以对项目核心功能进行数据流需求调研分析，业务逻辑分析。并在这基础上编写用户用例 ，数据流转图，业务逻辑图等
　　在完成了以上业务核心功能的详细调研分析后，将全部用例和其他内容组合在一起，制定《项目需求规格说明书》。