项目需求管理.doc

项目需求管理第8章 需求管理 2 8.1 介绍 2 8.2 需求确认 3 8.2.1 目的 3 8.2.2 角色与职责 3 8.2.3 启动准则 3 8.2.4 输入 3 8.2.5 主要步骤 4 Step1 非正式需求评审 4 Step2 正式需求评审 4 Step3 获取需求承诺 4 8.2.6 输出 4 8.2.7 结束准则 4 8.2.8 度量 4 8.3 需求跟踪 5 8.3.1 目的 5 3.3.2 角色与职责 5 3.3.3 启动准则 5 3.3.4 输入 5 3.3.5 主要步骤 5 Step1 建立与维护需求跟踪矩阵 5 Step2 查找不一致 6 Step3 消除不一致 6 8.3.6 输出 6 8.3.7 结束准则 6 8.3.8 度量 6 8.4 需求变更控制 7 8.4.1 目的 7 8.4.2 角色与职责 7 8.4.3 启动准则 7 8.4.4 输入 7 8.4.5 主要步骤 7 Step1 需求变更申请 7 Step2 审批需求变更申请 7 Step3 更改需求文档 7 Step4 重新进行需求确认 8 8.4.6 输出 8 8.4.7 结束准则 8 8.4.8 度量 8 8.5 实施建议 8 第8章 需求管理 需求管理（Requirement Management, RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。 需求管理过程域是SPP模型的重要组成部分。本规范阐述了需求管理过程域的三个主要规程： 需求确认 SPP-PROC-RM-VALIDATE 需求跟踪 SPP-PROC-RM-TRACKING 需求变更控制 SPP-PROC-RM-CHANGE 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 8.1 介绍 我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。图8-1为需求工程的结构图（流程见图9-1）。 图8-1 需求工程结构图 需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制。 一、需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 二、需求跟踪 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 三、需求变更控制 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。 需求管理过程域产生的主要文档有： 需求评审报告，同技术评审报告的模板 SPP-TEMP-TR-REPORT。 需求跟踪报告，模板见 SPP-TEMP-RM-TRACKING。 需求变更控制报告，模板见 SPP-TEMP-RM-CHANGE。 8.2 需求确认 8.2.1 目的 开发方和客户对需求文档如用户需求说明书和产品需求规格说明书进行评审，并作书面承诺。l 补充说明：用户需求说明书和产品需求规格说明书可以分开也可以放在一起进行需求确认，视项目的具体情况而定。 8.2.2 角色与职责 开发方和客户共同组织人员对需求文档如用户需求说明书和产品需求规格说明书进行评审。l l 开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。 8.2.3 启动准则 l 需求文档如用户需求说明书和产品需求规格说明书已经完成。 8.2.4 输入 需求文档如用户需求说明书和产品需求规格说明书。l 8.2.5 主要步骤 Step1 非正式需求评审 l 项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非正式的需求评审方式请参考技术评审过程域的对应规程SPP-PROC-TR-ITR。 Step2 正式需求评审 l 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。正式需求评审方式请参考技术评审过程域的对应规程SPP-PROC-TR-FTR。 Step3 获取需求承诺 当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下： 本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。 甲方负责人签字 乙方负责人签字 8.2.6 输出 需求评审报告l 书面的需求承诺l 8.2.7 结束准则 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。l 8.2.8 度量 项目经理统计工作量和上述文档的规模l 8.3 需求跟踪 8.3.1 目的 l 将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档设计文档代码测试用例”之间的一致性，确保产品依据需求文档进行开发。 3.3.2 角色与职责 项目经理跟踪需求。l 3.3.3 启动准则 需求文档已经通过正式评审并获得了承诺。l l 系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。 3.3.4 输入 需求文档l 设计文档、代码、测试用例等l 3.3.5 主要步骤 Step1 建立与维护需求跟踪矩阵 正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。l 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。l l 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表8-1为简单的需求跟踪矩阵格式。 当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。l 需求文档 （版本，日期） 设计文档 （版本，日期） 代码 （版本，日期） 测试用例 （版本，日期） 1 标题或标识符，说明 标题或标识符，说明 代码名称，说明 测试用例名称，说明 2 表8-1 简单的需求跟踪矩阵格式 Step2 查找不一致 l 使用需求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如： 后续工作成果没有实现需求文档中的某些需求； 后续工作成果实现了需求文档中的不存在的需求； 后续工作成果没有正确实现需求文档中的的需求； l 项目经理将发现的“不一致性”记录在需求跟踪报告之中，并通报给相关责任人（工作成果的开发者）。 Step3 消除不一致 l 相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划记录到需求跟踪报告之中。 l 相关责任人消除“不一致性”之后，项目经理更新“需求跟踪矩阵”。 8.3.6 输出 需求跟踪报告l 8.3.7 结束准则 l 每个开发阶段的“需求跟踪矩阵”都已经建立。 已经消除了需求文档与后续工作成果之间的不一致性。l 8.3.8 度量 l 项目经理统计工作量和上述文档的规模。 8.4 需求变更控制 8.4.1 目的 修改“原需求文档”中不正确的内容，产生新的需求文档。l 控制需求文档的变更，防止发生混乱。l 补充说明：本规程中的“原需求文档”是指已经通过了评审并获得书面承诺的需求文档。 8.4.2 角色与职责 开发方负责人（项目经理）和客户共同控制需求变更。l 8.4.3 启动准则 l 某人（来自开发方或客户方）提出变更“原需求文档”的申请。 8.4.4 输入 “原需求文档”l 8.4.5 主要步骤 Step1 需求变更申请 需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负责人。l l “需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响。 Step2 审批需求变更申请 开发方负责人（项目经理）和客户共同审批“需求变更申请书”： 如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。l l 如果双方都同意变更，转向 Step3。 Step3 更改需求文档 需求分析员根据 Step1 和 Step2l 更改“原需求文档”，产生新的需求文档。 Step4 重新进行需求确认 重新进行需求评审，参见需求确认规程中的 Step2。l 重新获取书面的需求承诺，参见需求确认规程中的 Step3。l 8.4.6 输出 需求变更控制报告l 8.4.7 结束准则 新的需求文档已经被确认。l 8.4.8 度量 项目经理统计工作量。l 8.5 实施建议 l 先对项目经理和客户进行培训，让他们掌握必要的需求管理知识。 对需求管理过程域产生的所有有价值的文档进行配置管理。l l 对于非合同项目，本规范中有关客户的活动可以被裁减掉。 需求分析说明书的编写第9章 需求开发 1 9.1 介绍 1 9.2 用户需求调查 2 9.2.1 目的 2 9.2.2 角色与职责 2 9.2.3 启动准则 2 9.2.4 输入 2 9.2.5 主要步骤 3 Step1 准备 3 Step2 调查与记录 3 Step3 分析需求信息 3 Step4 撰写用户需求说明书 3 后续活动：需求确认 3 9.2.6 输出 4 9.2.7 结束准则 4 9.2.8 度量 4 9.3 产品需求定义 4 9.3.1 目的 4 9.3.2 角色与职责 4 9.3.3 启动准则 4 9.3.4 输入 4 9.3.5 主要步骤 5 Step1 细化并分析用户需求 5 Step2 撰写产品需求规格说明书 5 后续活动：需求确认 5 9.3.6 输出 5 9.3.7 结束准则 5 9.3.8 度量 6 9.4 需求分析方法概述 6 9.4.1 问答分析法 6 9.4.2 建模分析法 6 一、结构化分析法 7 二、面向对象分析法 7 三、恰当地使用图形符号 8 9.5 实施建议 8 第9章 需求开发 需求开发（Requirement Development, RD）的目的是通过调查与分析，获取用户需求并定义产品需求。 需求开发过程域是SPP模型的重要组成部分。本规范阐述了需求开发过程域的两个主要规程： 需求调查 SPP-PROC-RM-SURVEY 需求定义 SPP-PROC-RM-DEFINE 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 需求分析是需求开发过程域的重要活动之一，但是不宜用“规范”这种形式来论述。本章对需求分析方法作了概括性介绍，请读者阅读更加专业性的需求分析论著。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 9.1 介绍 需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程结构图如图8-1所示，需求开发和需求管理的流程如图9-1所示。 图9-2 需求开发与需求管理流程图 需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”。而“需求分析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员），避免与其它开发人员混淆。 一、需求调查 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。 二、需求分析 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常用的需求分析方法有“问答分析法”、“结构化分析法”和“面向对象分析法”。 三、需求定义 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。 需求开发过程域产生的主要文档有： 用户需求说明书，模板见 SPP-TEMP-RD-UR。 产品需求规格说明书，模板见 SPP-TEMP-RD-PRS。 9.2 用户需求调查 9.2.1 目的 l 获取用户（客户与最终用户）的需求信息，经过分析后产生用户需求说明书。 9.2.2 角色与职责 需求分析员调查、分析用户的需求。l 客户与最终用户提供必要的需求信息。l 9.2.3 启动准则 需求分析员已经确定。l 9.2.4 输入 l 任何与用户需求相关的材料 9.2.5 主要步骤 Step1 准备 需求分析员确定需求调查的方式，例如：l 与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操作。 向用户群体发调查问卷。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求。 从行业标准、规则中提取需求。 从Internet上搜查相关资料。 l 需求分析员准备调查问卷（问题表）。 需求分析员与被调查者建立联系，确定调查的时间、地点、人员等。l Step2 调查与记录 l 需求分析员调查用户需求，随时记录调查过程中所获取的需求信息。 Step3 分析需求信息 l 需求分析员分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。 Step4 撰写用户需求说明书 l 需求分析员按照指定的文档模板撰写用户需求说明书，主要内容包括： 产品介绍； 描述用户群体的特征； 产品应当遵循的标准或规范； 描述产品的功能性需求； 描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。 补充说明：调查过程中获取的需求信息可以作为用户需求说明书的附件。 后续活动：需求确认 l 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审用户需求说明书，尽最大努力使用户需求说明书能够正确无误地反映用户的真实意愿。 l 需求评审之后，开发方和客户方的责任人对用户需求说明书作书面承诺。 补充说明：“需求确认”活动属于需求管理范畴，详见 SPP-PROC-RM 。 9.2.6 输出 用户需求说明书l 9.2.7 结束准则 l 需求分析员已经撰写完成用户需求说明书，并做了内部审查（消除拼写、排版等错误）。 9.2.8 度量 l 需求分析员统计工作量和上述文档的规模，汇报给项目经理。 9.3 产品需求定义 9.3.1 目的 l 定义准确无误的产品需求，产生产品需求规格说明书。 9.3.2 角色与职责 需求分析员定义产品需求。l l 客户与最终用户提供必要的需求信息，并确认产品需求。 9.3.3 启动准则 用户需求说明书已经撰写完成。l 9.3.4 输入 用户需求说明书l 9.3.5 主要步骤 Step1 细化并分析用户需求 l 需求分析员对用户需求说明书进行细化，以便产生详细的产品需求。 l 需求分析员对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。建议采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为产品需求规格说明书的附件。 补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。 Step2 撰写产品需求规格说明书 l 需求分析员按照指定的文档模板撰写产品需求规格说明书。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写软件需求规格说明书和硬件需求规格说明书。 产品需求规格说明书的主要内容包括：l 产品介绍； 描述用户群体的特征； 定义产品的范围； 阐述产品应当遵循的标准或规范； 定义产品中的角色； 定义产品的功能性需求； 定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求； 后续活动：需求确认 l 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审产品需求规格说明书，尽最大努力使产品需求规格说明书能够正确无误地反映用户的真实意愿。 l 需求评审之后，开发方和客户方的责任人对产品需求规格说明书作书面承诺。 补充说明：“需求确认”活动属于需求管理范畴，详见 SPP-PROC-RM 。 9.3.6 输出 产品需求规格说明书l 9.3.7 结束准则 产品需求规格说明书已经撰写完成。l l 已经对产品需求进行了评审，并且获得了开发方和客户方对需求的承诺。 9.3.8 度量 项目经理统计工作量和上述文档的规模。l 9.4 需求分析方法概述 很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。 需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误、弥补不足，确保需求文档正确地反映用户的真实意图。 需求分析是需求开发过程中“最费脑子”的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用，很有实用价值。 9.4.1 问答分析法 问答分析方法很简单：刨根究底地问，如果解答了这些问题，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。 问答分析最重要的问题是：“是什么”和“为什么”。 每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？ 9.4.2 建模分析法 人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。 在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。 一、结构化分析法 软件的建模分析兴起于20世纪60年代末期和70年代初期。结构化分析方法并不是由里程碑式的明确地涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在70年代和80年代非常流行，相关论著很多。对结构化分析方法有较大贡献的学者有DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文献Pressmen99, p206-p214对结构化分析方法作了高度概括（如图9-2所示），我们不妨称之为“一个中心三种图”： “数据字典”是中心，它包含了软件中所有数据对象的描述。 “实体关系图”是用图形符号来标识数据对象以及它们之间的关系。 “数据流图”指明了数据在系统中移动时如何被变换。 “状态变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。 图9-2 结构化分析方法示意图 二、面向对象分析法 面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。 作者在读本科（90年至94年）时就充分地感受到了人们对“面向对象”的狂热。关于“面向对象”的课堂、学术报告常常人满为患。搞软件研发的人都“言必谈对象”，并引以为荣。 面向对象分析设计领域有一些比较著名的学派，如： Coad和Yourdon学派，其代表作为Coad91。 Booch学派，其代表作为Booch94。 Jocobson学派，其代表作为Jacobson92。 Rumbaugh学派，其代表作为Rumbaugh91。 有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每年诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活啊！ 终于等到了那一天，Rational公司招纳了Booch, Jocobson, Rumbaugh，这三位“面向对象”业界的权威强强联手，制定了“统一建模语言”（UML）。1997年11月，UML被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标准。 UML吸取了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而详细的定义。UML的建模能力超过了以往任何一种OOAD方法，当然其复杂性也随之膨胀。大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档（如Rumbaugh99）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的喜爱。 介绍UML和Rose的书籍非常多，读者自己选择、学习，这里不再论述。 三、恰当地使用图形符号 现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图它能完整地描述需求。需求建模不可能取代文字描述。在需求规格说明书中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求规格说明书的附录中，便于正文引用。 9.5 实施建议 先对需求分析员进行培训，让他们掌握必要的需求开发技能。l 对需求开发过程域产生的所有有价值的文档进行配置管理。l 对于非合同项目，本规范中有关客户的活动可以简化。l l 需求的建模分析有较高的技术难度，需求分析员应当根据自身水平进行取舍。建议企业购买Rational Rose作为需求建模分析的工具。 l 需求分析员根据产品的特征，适当地修改用户需求说明书和产品需求规格说明书的模板。系统详细设计说明书编写指导第11章 系统设计 2 11.1 介绍 2 11.2 用户需求调查 3 11.2.1 目的 3 11.2.2 角色与职责 3 11.2.3 启动准则 3 11.2.4 输入 3 11.2.5 主要步骤 3 Step1 设计准备 3 Step2 确定影响系统设计的约束因素 4 Step3 确定设计策略 4 Step4 系统分解与设计 4 Step5 撰写体系结构设计文档 4 Step6 体系结构设计评审 5 后续活动 5 11.2.6 输出 5 11.2.7 结束准则 5 11.2.8 度量 5 11.3 用户界面设计 5 11.3.1 目的 5 11.3.2 角色与职责 5 11.3.3 启动准则 6 11.3.4 输入 6 11.3.5 主要步骤 6 Step1 设计准备 6 Step2 用户界面设计 7 Step3 撰写用户界面设计文档 7 Step4 用户界面设计评审 7 后续活动 8 11.3.6 输出 8 11.3.7 结束准则 8 11.3.8 度量 8 11.4 数据库设计 8 11.4.1 目的 8 11.4.2 角色与职责 8 11.4.3 启动准则 8 11.4.4 输入 9 11.4.5 主要步骤 9 Step1 设计准备 9 Step2 数据库设计 9 Step3 撰写数据库设计文档 10 Step4 数据库设计评审 11 后续活动 11 11.4.6 输出 11 11.4.7 结束准则 11 11.4.8 度量 11 11.5 模块设计 12 11.5.1 目的 12 11.5.2 角色与职责 12 11.5.3 启动准则 12 11.5.4 输入 12 11.5.5 主要步骤 12 Step1 设计准备 13 Step2 模块设计 13 Step3 撰写模块设计文档 13 Step4 模块设计评审 13 后续活动 14 11.5.6 输出 14 11.5.7 结束准则 14 11.5.8 度量 14 11.6 实施建议 14 第11章 系统设计 系统设计（System Design, SD）是指设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。 系统设计过程域是SPP模型的重要组成部分。本规范阐述了系统设计过程域的四个主要规程： 体系结构设计 SPP-PROC-SD-ARCHITECTURE 用户界面设计 SPP-PROC-RM-UI 数据库设计 SPP-PROC-RM-DATABASE 模块设计 SPP-PROC-RM-MODULE 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 11.1 介绍 系统设计过程域分为两个阶段：高层设计阶段和详细设计阶段。 高层设计阶段的重点是软件系统的体系结构设计。详细设计阶段的重点是用户界面设计、数据库设计和模块设计，如图11-1所示。 图11-1 系统设计过程域示意图 系统设计过程域产生的主要文档有： 体系结构设计报告，模板见 SPP-TEMP-SD-ARCHITECTURE。 用户界面设计报告，模板见 SPP-TEMP-SD-UI。 数据库设计报告，模板见 SPP-TEMP-SD-DATABASE。 模块设计报告，模板见 SPP-TEMP-SD-MODULE。 11.2 体系结构设计 11.2.1 目的 l 分析与设计软件的体系结构。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，产生体系结构设计报告。 11.2.2 角色与职责 项目经理指定若干名开发人员从事体系结构设计（以下称为体系结构设计人员）。l 11.2.3 启动准则 l 体系结构设计人员已经确定。 11.2.4 输入 需求文档如产品需求规格说明书l 11.2.5 主要步骤 体系结构设计流程如图11-2所示。 图11-2 体系结构设计流程 Step1 设计准备 l 项目经理或者技术负责人分配系统设计任务，包括体系结构设计、模块设计、用户界面设计、数据库设计等。本活动可能产生一份阶段性的开发计划，如系统设计计划，视工作量而定。 体系结构设计人员阅读需求文档，明确设计任务。l 体系结构设计人员准备相关的设计工具（如Rational Rose）和资料。l Step2 确定影响系统设计的约束因素 需求约束。体系结构设计人员从需求文档如软件需求规格说明书中提取需求约束，例如：l 本系统应当遵循的标准或规范 软件、硬件环境（包括运行环境和开发环境）的约束 接口/协议的约束 用户界面的约束 软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。 l 隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。 Step3 确定设计策略 体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：l 扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。 复用策略。说明本系统在当前以及将来的复用策略。 折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时空”效率折衷，复杂性与实用性折衷。 Step4 系统分解与设计 l 体系结构设计人员： 将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系。 将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 确定系统开发、测试、运行所需的软硬件环境。 Step5 撰写体系结构设计文档 体系结构设计人员根据指定的模板撰写体系结构设计报告，主要内容包括：l 软件系统概述 影响设计的约束因素 设计策略 系统总体结构 子系统的结构与模块功能 开发、测试、运行所需的软硬件环境 Step6 体系结构设计评审 体系结构设计人员邀请同行专家、开发人员对体系结构进行正式技术评审，评审流程请参考l SPP-PROC-TR-FTR。 体系结构评审的重点不是“对还是错”，而是“好还是差”。主要评审要素包括：l 合适性。考察该体系结构是否适合于产品需求，是否可在预定计划内实现。 系统的综合能力（Capability）。例如“时空”效率（性能，容量等），可扩展性，可管理性（可维护性），可复用性，安全性等等，视产品特征而定。 后续活动 体系结构设计完成后进入详细设计阶段（用户界面设计、数据库设计、模块设计等）。l 11.2.6 输出 l 体系结构设计报告 11.2.7 结束准则 体系结构设计报告已经完成，并且通过了技术评审。l 11.2.8 度量 l 体系结构设计人员统计工作量以及文档的规模，汇报给项目经理。 11.3 用户界面设计 11.3.1 目的 l 设计软件的用户界面，产生用户界面设计报告。 制作用户界面的资源如图像、图标或者界面专用组件等。l 11.3.2 角色与职责 l 项目经理指定若干名开发人员从事用户界面设计（以下称为界面设计人员）。 如果可能的话，邀请用户或美工人员协助设计用户界面。l 11.3.3 启动准则 需求文档已经完成。l 体系结构设计已经完成。l 11.3.4 输入 需求文档l 体系结构设计文档l 11.3.5 主要步骤 用户界面设计流程如图11-3所示。 图11-3 体系结构设计流程 Step1 设计准备 界面设计人员阅读需求文档和体系结构设计文档，明确界面设计任务。l 界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。l 界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源如图像、图标以及通用的组件。l l 界面设计人员确定本软件的用户界面设计规则（或指南），主要包括： 优秀界面的特征或通用的设计原则； 软件主界面（如主窗口、主页面）的设计规则； 软件子界面（如子窗口、子页面）的设计规则； 标准控件的使用规则； 美学设计规则。 Step2 用户界面设计 用户界面设计一般要经历“原型创作原型评估细化”等步骤，通常迭代进行。 l Step2.1 原型创作 界面设计人员创作界面原型： 先徒手画，或者用Visio 等工具绘制界面的视图； 再用软件开发工具实现可以运行的原型。 Step2.2 原型评估l 界面设计人员邀请用户和同行们评估界面的原型，汇集意见，及时改进。 Step2.3 细化l 界面设计人员细化界面原型，例如美工处理，添加细节等。 补充说明：开发人员在本阶段不必关心界面原型的代码质量，因为界面原型可能不断地被修改甚至被抛弃。 Step3 撰写用户界面设计文档 l 用户界面定型之后，界面设计人员根据指定的模板撰写用户界面设计报告，主要内容包括： 应当遵循的界面设计规范； 界面的关系图和工作流程图； 主界面的视图、功能说明、操作方式； 子界面的视图、功能说明、操作方式； 美学设计说明。 Step4 用户界面设计评审 l 界面设计人员邀请用户和同行们对定型后的界面进行正式技术评审，尽最大努力使界面变得更加美观、易用。评审流程请参考 SPP-PROC-TR-FTR。 l 用户界面的主要评审要素包括： 合适性 简洁易用 一致性 美观 动态反馈 功能屏蔽和出错处理 用户控制 国际化（兼容性和可移植性） 适应性（针对各种用户） 后续活动 l 在系统设计工作结束之后，开发人员编写界面的代码，并和用户一起通过各种途径测试界面，从而不断地完善用户界面。（请参考有关测试的文档） l 界面设计人员总结经验教训，不断地完善适用于本机构的“用户界面设计指南”。 11.3.6 输出 用户界面设计报告l 11.3.7 结束准则 用户界面设计报告已经完成，界面原型已经通过评审。l 11.3.8 度量 l 界面设计人员统计工作量以及文档的规模，汇报给项目经理。 11.4 数据库设计 11.4.1 目的 l 设计软件的数据库，产生数据库设计报告。 11.4.2 角色与职责 项目经理指定若干名开发人员从事数据库设计（以下称为数据库设计人员）。l 11.4.3 启动准则 需求文档已经完成。l 体系结构设计已经完成。l 11.4.4 输入 需求文档l l 体系结构设计文档 11.4.5 主要步骤 数据库设计流程如图11-4所示。 图11-4 数据库设计流程 Step1 设计准备 数据库设计人员阅读需求文档和体系结构设计文档，明确数据库设计任务。l l 数据库设计人员准备相关的设计工具和资料。 数据库设计人员确定本软件的数据库设计规则（或指南），主要包括：l 数据库命名规则 逻辑设计规则（或指南） 物理设计规则（或指南） 安全性设计规则（或指南） 优化规则（或指南） 数据库管理与维护规则（或指南） Step2 数据库设计 数据库设计一般要经历“逻辑设计物理设计安全性设计优化”等步骤，通常要迭代进行。 Step2.1 逻辑设计l 数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。 Step2.2 物理设计l 设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。数据库表的参考格式如表11-1所示。 对表结构进行规范化处理（第三范式）。 表名 功能说明 列名 数据类型（精度范围） 空/非空 约束条件 补充说明 表11-1 数据库表的参考格式 Step2.3 安全性设计l 提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全性设计。 用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径可以操作数据库。 对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码的明文。 确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。 Step2.4 优化l 分析并优化数据库的“时空”效率，尽可能地“提高处理速度”并且“降低数据占用的空间”。 分析“时空”效率的瓶颈，找出优化对象（目标），并确定优先级。 当优化对象（目标）之间存在对抗时，给出折衷方案。 给出优化的具体措施，例如优化数据库环境参数，对表格进行反规范化处理等。 Step3 撰写数据库设计文档 l 数据库设计人员根据指定的模板撰写数据库设计报告，主要内容包括： 数据库环境说明 数据库的命名规则 逻辑设计 物理设计 安全性设计 优化 数据库管理与维护说明 Step4 数据库设计评审 l 数据库设计人