网站需求分析.doc

修订历史 版本 说明 编制 批准 批准日期 1.1 初次编写 SEPG 目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 1.3. 假定和约束[可选] 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。 1.4. 用户的特点[可选] 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。 2. 功能需求 2.1. 系统范围 明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。 如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选] 以图+文本结合的方式描述系统的总体架构。 以下应提供系统总体架构图： 以下对系统总体架构进行描述： 2.3. 系统总体流程 以图+文本结合的方式说明系统的总体流程。 图一是计划合同管理系统的总体流程图。 图一 2.4. 需求分析 需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？ · 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系 · 描述用例：角色与系统如何交互的规格说明。 2.4.1. XXXXXXX(功能需求名称) 2.4.1.1. 功能描述 功能编号： 功能需求：从用户业务的角度描述功能需求。 2.4.1.2. 业务建模 从可视化的角度--用例图--描述功能需求 图二是综合计划管理系统合同编辑业务的功能需求用例图。 图二 2.4.1.3. 用例描述 以文本的方式描述每一个用例中角色与系统相互交互的规格说明。 1、 XXXXXX(用例名称) 描述对象 描述内容 标识符 用例的唯一标识符 说明 对用例的概要说明 参与者 与该用例相关的参与者列表，以及参与者的特点 频度 参与者访问此用例的频率 状态 通常分为：进行中、等待审查、通过审查或未通过审查 前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足 后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足 被扩展的用例 此用例所扩展的用例（如果存在） 被包含的用例 此用例所包含的用例（如果存在） 基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式 可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径 修改历史记录 修改人 ： 修改日期：修改原因： 问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表 以下是综合计划管理系统中的合同编辑功能需求中的合同增加用