需求的基本概念
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。
需求工程——所有与需求直接相关的活动通称为需求工程。包括需求开发和需求管理。
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系
前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
需求分析
分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。
“问答分析法”比较适合于用户需求调查阶段
“建模分析法”比较适合于产品需求定义阶段
需求建模就是指用图形符号来表示、刻画需求。
建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
好的需求规格说明书
正确——正确地反映用户的真实意图，《产品需求规格说明书》最重要的属性
清楚——让人易读易懂
无二义性——每个需求只有唯一的含义
一致——“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾
必要——《产品需求规格说明书》中的各项需求对用户而言应当都是必要的
完备——（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求
可实现 ——《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）
可验证 ——《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）
确定优先级
阐述“做什么”而不是“怎么做”——《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情
需求管理
需求确认（评审和承诺）——开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”
需求跟踪——目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处
需求变更控制——提出需求变更目的是希望产品更加符合用户的需求。项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
