概述
- 软件需求特点：模糊性、不确定性、变化性和主观性
- 基本任务：不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。
- 方法：借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
任务（综合要求）
- 功能需求：指定系统必需提供的服务。划分出系统必需完成的所有功能
- 性能需求：指定系统必需满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求
- 可靠性和可用性需求：可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用的程度
- 错误处理需求：系统对环境错误应该怎样响应
- 接口需求：描述应用系统与他的环境通信的格式。
- 约束：在设计或实现应用系统时应遵守的限制条件。
- 逆向需求：说明软件系统不应该做什么
- 未来要求：应明确列出那些不属于当前系统开发范畴，但是根据分析将来很有可能会提出来的要求。
步骤
- 需求获取：需求收集的活动，从人员、资料和环境中得到系统开发所需要的相关信息，实在问题及其最终解决方案之间架设桥梁的第一步
- 需求分析：也是建模的过程，借助当前系统模型，导出目标系统模型，解决系统“做什么的问题”，建模工具：系统流程图、数据流程图、实体关系图、数据字典。
需求规格说明书：需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。
需求验证：需求将作为系统设计和最终验证的依据，正确性、一致性、完整性、可行性、必要性、可验证性、可跟踪性。
需求变更：需求变更会发生在任何阶段，必需接受“需求会变动”的事实（原因：用户认识的提高和业务水平的提升），解决办法：系统设计时。，软件核心必需建立在稳定的需求之上，流出变更的空间，在设计上具有可扩展性，加强变更的控制。
需求分析模型
![]()
需求分析模型.png
需求分析模型.png
成果
- 需求分析就是为了实现系统需求，并是最后交付成果与需求所要求的目标不产生：含糊性、不完整性、不可见言行、不一致性、不可追溯性和不可用性。
- 需求分析面向下阶段：总体设计，需求具有承前启后的作用
- 需求分析采用自己的特定方法，达到相应的阶段要求
- 采用的方法尽量地让用户和开发团队都能理解并认同系统目标和范围界定的方法——业务/系统模型、用例、界面原型等2. 需求分析阶段的目标是用计算机的（而不再是用户）眼光和语言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼光，是体统分析师的眼光。3. 经过需求处理后，达到需求规范要求。4. 分析的方法是一套“建模”技术。
软件需求的三个层次
软件需求的三个层次.png
- 业务需求：反映了组织和客户对系统和产品的目标要求
- 用户需求：描述用户使用软件需要完成的任务
- 功能需求：是开发者要实现的软件功能
需求获取的几个原则
- 深入浅出：需求获取要尽可能全面、细致。如果获取的需求是个全集，系统真正实现的是个子集。
- 以流程为主线：在与用户交流的交流过程中，应该用流程将所有的内容串起来。流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。注意：以流程为中心，从组织结构直接转变为系统功能结构是初级系统分析师常犯的错误。
- 中有通过有效的客户/开发者的合作才能成功：1.需求具有不稳定性，在整个软件生存周期内软件需求会随着时间的推移发生变化；2. 需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。
需求获取的内容
- 定义项目的范围：组织结构图、各部门的岗位/角色列表、岗位职责，从功能上区分有多少额子系统，划分系统的大致范围，明确系统的目标。
- 确定用户类：包括人员/责任矩阵。
- 确定目标系统的业务工作流程（系统流程图/业务流程图）。收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。
- 确定业务功能的优先级
- 确定功能需求和非功能需求。
- 详细拟定规格说明：用以澄清需求获取的参与者对需求的理解。
- 评估界面原型：设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。
需求获取的方法
- 前期准备：进入客户现场之前，要了解客户的背景情况（抓住核心人物，了解客户之间的内部矛盾），提前补足功课，熟悉业务，准备各式调研的表格，了解可和的类型：成熟度，做好针对的应对方法。
- 访谈：正式访谈（实现准备好具体问题），非正式访谈（开放式自由提问，例如问一些现有系统存在的问题）
- 调查表：客户方人员很多，采用书面调查的方式，手机调查表后再针对性问一些问题
- 情景分析：模拟实际场景（最好有类似的系统或案例）某种程度上演示目标系统的行为，从而便于用户理解，用户在需求分析过程中始终扮演一个积极主动的角色。
- 咨询：向用户领域的专家个别咨询
- 实地考察：跟踪现场业务流程
- 查阅资料：查阅与待开发系统有关的资料
- 面向数据流自顶向下逐步求精
需求分析需要做的工作
- 建立三种模型
- 功能模型（数据流图）：数据在软件系统中被变换的逻辑过程
- 数据模型（实体关系图）：数据对象以及数据对象之间的关系
- 行为模型：表示系统的各种行为状态以及状态间的转换方式
- 编写需求规格说明书
功能模型（数据流图）
功能建模的基础：数据流图（DFD）
步骤：
- 需求获取：用户现有业务有软件系统，整理出软件系统的跨职能系统流程图（增加上新的业务需求）；如果现业务没有软件系统，则整理现业务的跨职能业务流程图。
- 功能建模：两种方式
方式一：将跨职能系统/业务流程图导出数据流图，从高层数据流图开始，逐步细化。
方式二（常用的方式）：从系统流程图中分离处理过程，再考察每个处理过程的输入输出数据，将所有的输入输出数据流，惊醒有机集成，就形成了一个完整的数据流程图，数据流图一步到位。
应当遵循的原则
- 分层时，子图的输入输出数据流必须和父图中相应加工的输入、输出数据流一致
- 加工的编号应该唯一且具有层次性；
- 加工不应该只有输入或输出，通常既有输入又有输出；
- 数据流图不应反应处理的顺序
- 加工之间应该通过数据存储进行通信，避免从一个加工直接流到另一个数据存储；
- 数据流图中所有元素的命名应当对客户有意义，且与业务相关；
- 不要在一个图中绘制7个以上的加工，否则难以绘制和理解。
三大模型对应关系
三大模型对应关系.png
实体-联系图（E-R）
- E-R图：用来建立数据模型的工具。
- 数据模型：是一种面向问题的数据模型。是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与软件系统中的实现方法无关。
- 数据模型中包含3中相互关联的信息：数据对象（实体）、数据对象的属性以及数据对象彼此间相互连接的关系。
数据字典
目的：规范统一对数据的描述
- 数据字典描述数据流图的数据存储、数据加工（最底层加工）和数据流，它记录的主要内容有:
基本信息：名字、别名、描述；
定义：数据长度、数据类型、数据结构；
使用特点：取值范围、使用频率、使用方式等；
控制信息：来源、用户、应用程序、读写权限等；
- 数据字典是数据的描述，是元数据，不是数据本身
- 数据字典分为：数据项和数据结构
- 数据字典在需求阶段建立，数据库设计阶段不断修改、完善、充实
