种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。
为什么要建立需求状态？在整个生命周期中，存在著有几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，还需要等待外部信息。还有是客户本身也说不清楚的。
对于这些需求，在开发进展的过程中，存在著以下几种情况:
有可能要取消的
有的因为不明确而可以后延的，同时可能转化为被取消的需求
与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。
下面是一个简单的状态例子：
CLOSED：经过确认，双方认可并达成共识；
OPEN:双方确认，但没有达成共识的需求；
待定：客户提出需求，但双方没有经过沟通或确认；
需求评审(Requirement Review)
对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。对于任何重要的工作产品，都应该至少执行一次正式技术评审。在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。
需求评审的规程与其它重要工作产品（如系统设计文档、源代码）的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。
有人问：需求评审究竟评审什么？要细到什么程度？怎么样进行？
严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。
需求评审面临的困难及对策如下：
需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。评审组长还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次。另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。
需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态。评审状态，初始状态等。只有进入评审状态时，我们可以用不同的方式来对文档进行评审。但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。
开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。同时，评审会必须明确一位评审组长，对时间与问题进行控制。
开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。