| 词条 | 用户需求分析 |
| 释义 | 定义用户需求分析 User Requirement Analysis 在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。 过程需求说明当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需。例如采用Rational的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致。 当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为《需求分析说明书》。 邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。具体的同行评审详见需求评审章节。 需求确认需求确认（Requirement Validate）是需求管理过程中的一种常用手段，也是需求控制的五一节之一；确认有两个层面的意思，第一是进行系统需求调查与分析的人员与客户间的一种沟通，通过沟通从而对需求不一致的进行剔除；另外一个层面的意思是指，对于双方达成共同理解或获得用户认可的部分，双方需要进行承诺。 建立需求状态需求状态（Establish Requirement State），顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。 为什么要建立需求状态？在整个生命周期中，存在着几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，还需要等待外部信息。还有是客户本身也说不清楚的。 对于这些需求，在开发进展的过程中，存在着以下几种情况： 有可能要取消的； 有的因为不明确而可以后延的，同时可能转化为被取消的需求； 与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。 下面是一个简单的状态例子： CLOSED：经过确认，双方认可并达成共识； OPEN:双方确认，但没有达成共识的需求； 待定：客户提出需求，但双方没有经过沟通或确认； |
| 随便看 |
|
百科全书收录4421916条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。