软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
1，需求的层次
1）业务需求；
2）用户需求；
3）系统需求；
2，质量功能部署（QFD）
一种可以将用户需求转化为软件需求的技术，QFD将需求分为三类，常规需求，期望需求和意外需求。
3，需求获取
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程，常见的需求获取方法包括，用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
4，需求分析
1）PDOA方法（Problem Domain Oriented Analysis: 面向问题域分析方法）
与SA和OOA相比， PDOA更多的强调描述， 少强调建模
PDOA的两个部分
(1)关注问题域：对问题域进行相关的描述， 列出需要再该域中求解的问题列表（需求列表）
(2)关注系统实现的待求行为：对系统待求行为进行描述
PDOA过程
(1) 收集基本信息并开发问题框架， 以建立问题域的类型
(2) 在问题框架类型的指导下， 进一步收集详细信息， 并给出一个问题域相关的特性的描述
(3) 给予以上两点，收集并用文档说明系统的需求
2）SA方法（Structured Analysis 面向结构的分析方法）
关注功能的分层和分解， 符合自上而下，逐步分解问题， SA方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型
1. 数据模型 E-R图
2. 功能模型 DFD图
3. 行为模型（状态模型） STD图
3）OOA方法（Object-Oriented Analysis：面向对象分析方法）
基于抽象，信息隐藏，功能独立和模块化的基本理念对系统进行分析。
OOA，对象彼此之间通过接口来互相沟通，只有观测内部才能看到具体的属性和方法。
5，软件需求规格说明书（功规，SRS）
国标规定SRS需要包含以下内容
1）范围
2）引用文件
3）需求
4）合格性规定
5）需求可追踪性
6）尚未解决的问题
7）注解
8）附录
6，需求验证
包括以下内容：
1）SRS正确的描述了预期的，满足项目干系人需求的系统行为和特征
2）SRS中的软件需求是从系统需求，业务规格和其他来源中正确推导而来
3）需求是完整的和高质量的
4）需求的表示在所有地方都是一致的
5）需求为继续进行系统设计，实现和测试提供了足够的基础
7，UML（Unified Modeling Language又称统一建模语言或标准建模语言）
1）UML的结构
①构造块 事物（thing）、关系（relationship）
②规则
③公共机制
2）UML中的事物
①结构事物
②行为事物
③分组事物
④注释事物
3）UML中的关系
①依赖关系
②关联
③泛化
④实现
4）UML2.0中的图
①类图
②对象图
③构件图
④组合构件图
⑤用例图
⑥顺序图
⑦通讯图
⑧定时图
⑨状态图
⑩活动图
⑪部署图
⑫制品图
⑬包图
⑭交互概览图
5）UML视图
①逻辑视图
②进程视图
③实现视图
④部署视图
⑤用例视图
8，需求评审：
评审方式： 评审， 检查，走查
如何做好评审推荐方法如下
分层评审
正式评审和非正式评审相结合
分阶段评审
精心挑选评审人员
对评审人员进行培训
充分利用需求评审检查单
建立标准的评审流程
做好评审后的跟踪工作
充分准备评审
9，需求测试（6，需求验证，详细化）：
很多项目中， 软件测试都是后期的开发活动， 实际上，软件测试在需求定会就应该开始。
如果在项目早期就定制测试计划进行测试用例设计，就可以发送错误时立即检测并纠正他。
需求遗漏和错误具有很强的隐蔽性， 仅仅通过阅读SRS，很难想象特定环境下的系统行为。
概念测试用例：
需求开发不可能有真正意义的测试进行， 因为没有可执行的系统， 需求测试仅仅是给予需求进行概念上的测试
以需求为基础（SA需求分析模型）或用例为基础（OOA需求分析模型）来书写测试用例， 可以是项目干系人更清楚
的了解系统的行为，虽然没有执行测试用例，但是设计测试用例的简单动作可以解释需求的很多问题。
需求测试的过程：
1. 根据概念测试用例所描述的若干可能过程， 进行“概念”上的执行，期望发现遗漏的，错误的， 不必要的需求
2. 根据测试结果快速的修改对应的需求文档，完成一轮完整的需求测试过程。
需求获取，需求分析，需求定义，需求验证 4个阶段，不应该是瀑布式的发展，应该采用迭代式的演化过程。
10，需求管理
需求管理是可重复级的一个关键过程域， 其目标是为软件需求建立一个极限， 供软件开发及其管理使用，
使得软件计划，产品，活动与软件需求保持一致。其中有如下几个活动
1. 需求变更管理
2. 需求风险管理
3. 需求跟踪--设计跟踪矩阵， 各种测试用例跟踪矩阵，缺陷跟踪矩阵。