是从“ 5.1.3.3 确定业务活动”章节中梳理出来的;二是从“ 5.1.3. 4 确定业务功能”章节中梳理出来的。经过归集整理后,形成本项目的业务信息清单。每个业务信息都应该有业务信息编号,并应该将编号记录在其来源处,即业务活动或业务功能中。——针对每个业务信息,确定具体的信息内容; ——确定业务信息的校验规则(如不能为空); 国家电网公司系统架构设计指南第 6页 5.1.4 调研输出——《软件需求规格说明书》的第四章节“业务描述”。 5.1.5 执行角色表格 2 需求调研执行角色表角色负责执行询问通知客户与最终用户√√需求分析人员√√系统设计人员√ 5.2 需求分析 5.2.1 分析目标根据需求调研结果, 对用户需求进行分析归纳, 确定系统需要实现的功能和非功能需求。通过系统用例模型描述系统的功能需求, 使之成为在开发全过程中研讨系统需求和进行系统设计的依据, 在软件测试阶段作为系统测试的基础。需求分析粒度的说明: 1. 对于系统用例,要覆盖所有的业务活动,每个用例需明确基本流程和所有备选流程的操作步骤, 或者详细标识每个用例的功能点; 2. 对于系统功能点, 要逐级划分子功能, 直到每个子功能点具有明确的业务输入信息和业务输出信息; 3. 对于技术规格,要对需求调研阶段获得的所有非功能性需求,给出具体的技术规格说明。 5.2.2 分析输入——《软件需求规格说明书》的第四章节“业务描述”——总体架构蓝图 5.2.3 分析步骤 5.2.3.1 确定系统用例系统用例分为两种。一种是按业务步骤进行描述, 另一种是按功能进行分解描述。其目的是为了确定系统参与者和系统功能之间是怎么相互联系的。确定系统用例可以参考如下要点: ——根据总体架构蓝图及业务需求确定系统边界; ——基于“ 5.1.3.3 确定业务活动”章节中的业务活动清单,确定涉及到的系统用例清单,明确系统用例的子用例;
全文预览
