目录
一、需求定义
把已经分析好的需求，落成文档，把东西记录下来，成为《需求规格说明书》。需求定义的方法有严格定义法 以及 原型法。严格定义法认为所有需求都能够被预先定义 ，开发人员和用户能够准确和清晰的沟通，用图形和文字可以把整个系统充分地体现出来。而原型法认为并不是说有的需求在开发前都能够准确的说明，需要实际可供用户参与的系统模型。
二、需求验证
需要把定义的好的需求，需要把《需求规格说明书》提交给甲方/用户进行需求评审，需要业务人员、项目负责人以及能够确认需求的甲方负责人共同参与评审会。验证完成需要甲方签字确认，或者会议纪要，邮件等证明。以免最终产品验收时赖账。对于要验证可行性的需求需要进行测试，可以设置有代表性的简单场景验证开发的系统能否合规。
三、需求管理
1.定义需求基线
需求基线就是把固定的需求都落成文档，成为已经通过正式评审和批准的规格说明或产品。说明这些需求已经确定下来，添加新的需求或修改原有的需求都必须通过需求变更流程来操作。这样做的目的是防止需求的变化给系统造成重大影响。
2.需求跟踪
我们不仅要跟踪需求，也要跟踪需求的状态。也就是当时提出来的需求,评审有没有通过，开发到哪一步了。不要快要交付的时候在发现需求还没开发。
正向跟踪就是从用户的原始需求跟进到到软件需求还有下游工作产品(代码模块，测试用例)。可以通过需求跟踪矩阵来管理。
比如有原始需求FR-1,FR-2..FR-m 以及已经实现软件功能UC-1,UC2...UC-n。把功能(用例)和需求能够对应上的打上勾，或者其他状态。如果，某一列没有勾，那么表示没有一个原始需求能与这用例对应上，代表这个功能可能白白开发了；如果，某一行没有勾，那么表示没有一个用例能与这原始需求对应上，代表这个需求可能还没开发好。
3.变更控制
需求变更有三种状态，分别是工作状态，评审状态和受控状态。在基线形成好后，也就是需求文档，甚至设计文档、或者需求都已经开始开发了。然后发现方案需要改变，那么要走变更流程，而不是拍脑袋随意改，否则可能会有大量人员的信息不一致问题。
在基线形成好后，对于要变更的需求，首先需要提变更申请；然后要分析评估变更的影响性，比如变更需求的可行性，需求变更涉及的人力资源是否充足，变更造成的影响范围等；变更决策就是把评估中的问题抛出来，由甲乙双方共同探讨解决方案。之后变更实施完成后，进行验证是否已经变更，还要将变更中的信息进行存档。
四、软件系统建模
什么是软件系统建模呢？在分析、设计这个过程中，所画出来图纸的过程就是软件系统建模，比如E-R图，UML图等。在需求分析中建立逻辑模型(主要针对业务人员)，在软件设计中建立物理模型(主要针对技术人员)。
软件开发建模方法通常有如下几种：
- 结构化建模方法:以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。通常可以用数据流图(DFD)完成建模。此方法适用于较为稳定的系统。
- 信息工程建模方法/数据库建模方法：以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。通常可以用实体联系图(E-RD)完成数据建模。
- 面向对象建模方法：把数据和过程集成到“对象”结构中，消除了数据和过程认为分离的现象。面向对象技术的不断发展和应用，形成了面向对象的建模标准——UML。通过可以通过UML几种模型图对信息系统、应用系统进行建模.