软件需求分析说明指导书审查标准规范.doc

软件需求分析说明书审查规范文件编号受控编号版本1.0编制日期生效日期密级编制审核同意文件修改控制修改统计编号修改状态修改位置及内容修改人审核人同意人修改日期1.2.3.4.5.6.7.8.目录软件需求分析说明书审查规范1目录31.引言31.1.目标31.2.适用范围31.3.使用说明42.参考资料43.术语定义44.质量要求64.1.完整性64.1.1.整体内容完整性64.1.2.需求项信息完整性84.2.正确性94.3.一致性104.4.可验证性104.5.划分优先级104.6.可用性115.附件115.1.部分编写提议115.2.部分参考实例125.2.1.需求项表格125.2.2.表格需求项实例135.2.3.优先级划分方法实例145.2.4.软件需求分析说明书模板151. 引言1.1. 目标软件需求分析说明书在软件开发、测试、质量确保、项目管理和相关项目功效中起着关键作用。为了确保软件说明书对质量，本文档具体描述了软件需求分析说明书所要包含内容及其编制所要达成质量要求。1.2. 适用范围作为软件需求分析说明书是否能够进入正式评审审查标准，符合该规范能够提交正式需求评审；作为测试人员编制软件需求分析说明书审查列表依据；作为开发人员编制软件需求分析说明书指导标准；1.3. 使用说明本文关键对需求分析说明书内容进行要求，对表示方法、方法未明确提出要求对视为不作要求；本文中“应”、“必需”含义等同；本文中“现有技术水平”指和该需求相关行业中，可取得、已知、可实际利用于生产、可信、经过验证全部技术；本文中需求可行性以经过审核公布项目可行性研究汇报为依据；2. 参考资料 GB 8566 计算机软件开发规范 受控编号？GB 8567 计算机软件产品开发文件编制指南 受控编号？GB/T 11457 软件工程术语 受控编号？Systematic Software Testing Rick D.Craig, Stefan P.JaskielArtech House Publishers -05-1 统一软件开发过程RUP手册 IBM企业 3. 术语定义GB/T 11457所列术语和下列定义适适用于本文需求系统必需符合条件或含有功效软件需求分析软件需求分析基础任务是正确地定义未来系统目标，确定为了满足用户需求，系统必需做什么。需求分析包含需求获取和需求规约：需求获取是系统分析员经过学习和同用户交往，熟悉用户领域知识，并取得对未来系统需求；需求规约是系统分析员在取得了用户初步需求后，必需进行一致性分析和检验，经过和用户协商处理其中存在二义性和不一致性，并以一个规范形式正确地表示用户需求，形成软件需求分析说明书。软件需求分析说明书（Software Requirements Specifications，简称SRS）：软件需求分析说明书（也称软件需求规格说明书、软件需求分析汇报）是软件需求分析阶段得到最终文档，它以形式化术语和表示对软件功效和性能进行具体而具体描述。它是用户和开发者之间技术协议，是软件设计、编码阶段基础,也是软件测试和验收依据。IEEE软件工程标准词汇表(1997年)中定义为：(1) 用户处理问题或达成目标所需条件或权能(Capability)。 (2) 系统或系统部件要满足协议、标准、规范或其它正式要求文档所需含有条件或权能。 (3) 一个反应上面(1)或(2)所描述条件或权能文档说明。软件质量IEEE 610.12-1990中定义：一个系统、组件或过程满足用户或用户需求程度，或满足期望值程度。（“The degree to which a system, component, or process meets customer or user needs or expectations.” ISO/IEC9126中定义：和软件产品满足要求和隐含需求能力相关特征或特征全体。（The totality of features and characteristics of a software product that bear on its ability to satisfy stated or implied needs.）软件质量确保软件质量确保，是为确保产品和服务充足满足消费者要求质量而进行有计划、有组织活动。软件质量确保是面向消费者活动，是为了使产品实现用户要求功效，站在用户立场上来掌握产品质量。软件质量确保就是向用户及社会提供满意高质量软件产品。可跟踪性指假如每一个需求起源、变更历史是清楚，在深入产生和改变文件编制时，能够方便地引证每一个需求，则该软件需求分析说明书就是可追踪。可修改性指假如一个软件需求分析说明书结构和风格在需求有必需改变时是易于实现、且改变后仍然完整、一致，那么这个软件需求分析说明书就是可修改。可行性指在要求时间限制和开销下、在特定环境制约下、利用现有技术、工具、资源和人力下，需求必需是能够实现。具体包含：技术可行，现有技术水平能够实现全部需求；财政可行，有足够资金来实现全部需求，且实现成本在可接收范围内；时间可行，在指定时间范围内能够实现全部需求；资源可行，有足够人力、物力来实现全部需求；验证标准用以判定需求被实现后，实现结果是否正确依据。如：对于性能需求，其验证标准是具体性能指标；对于功效需求，其验证标准是具体功效效果描述。软件测试软件测试是为了度量和提升被测软件质量，对测试件进行工程设计、实施和维护整个生命周期过程。(Systematic Software Testing)统一建模语言（UML）UML(Unified Modeling Language)是一个构建软件系统和文档通用可视化建模语言。UML 能和全部开发方法一同使用，可用于软件开发整个生命周期。UML 能表示系统静态结构和动态信息，并能管理复杂系统模型，便于软件团体之间合作开发。UML 不是编程语言，但支持UML 语言工具能够提供从UML 到多种编程语言代码生成，也能够提供从现有程序逆向构建UML 模型。统一软件开发过程（RUP）RUP 是一个通用软件过程框架，能够应付种类广泛软件系统、不一样应用领域、不一样组织类型、不一样性能水平和不一样项目规模。“统一过程”是基于构件，这意味着利用它开发软件系统是由构件组成，构件之间经过定义良好接口相互联络。在准备软件系统全部蓝图时候，“统一过程”使用是“统一建模语言（Unified Modeling Language ）”。实际上，UML 是“统一过程”有机组成部分它们是被同时开发。然而，真正使“统一过程”和众不一样方面能够用三个句话来表示：它是用例驱动、以基础架构为中心、迭代式和增量性。4. 质量要求合格软件需求分析说明书要满足以下质量要求：1. 完整性2. 正确性3. 一致性4. 可验证性5. 划分优先级6. 可用性下面我们分别对每个质量要求进行说明，同时给出怎样满足各质量要求指导标准。4.1. 完整性 完整性是指软件需求分析说明书包含了全部应该含有内容，因为不一样产品、项目对软件需求分析说明书所应该含有内容不完全相同，所以为了便于指导和规范文档实际编制本规范将完整性划分为整体内容完整性、需求项信息完整性，并针对不一样内容提出不一样要求，包含：必需和可选，具体以下：4.1.1. 整体内容完整性整体内容完整性用以确定整个软件需求分析说明书中具体应该包含内容和不应该包含内容，具体以下：一. 需求没有遗漏：确定在需求分析说明书编制过程中，没有遗漏需求获取阶段所确定需求。其依据为包含但不仅限于经过正式审核下列文档：1. 市场调研汇报；2. 用户需求调查汇报；3. 需求分析讨论会议统计；二. 需求没有冗余：即同一需求不能在软件需求分析说明书中出现数次；三. 不存在超出产品/项目范围需求；四. 除设计上特殊限制之外，软件需求分析说明书中不描述任何设计、验证或项目管理细节内容；五. 软件需求分析说明书必需包含下列信息：1. 目标：说明编写这份软件需求说明书目标，指出预期读者2. 概述：说明产品或项目标背景、总体描述、功效、用户特点、通常设计约束。只描述影响产品及其需求通常原因，不说明具体需求，概述目标仅近使需求更易于了解3. 参考资料：列出软件需求分析说明书中全部用得到全部参考资料，具体说明参考资料起源。内容包含但不仅限于：1) 本产品或项目标经过核准计划任务书或协议、上级机关批文；2) 本项目标其它已经过审核正式文档；3) 企业内部制订公布正式管理文件；4) 各处引用资料，如出版物、网络资讯；5) 所要用到软件开发标准。 且每条参考资料统计中包含内容及格式应满足下列要求（按类型划分）：1) 专著出版物：关键作者，其它作者，书名，版本，出版地：出版者，出版年；2) 连续期刊出版物：文件作者，文件其它作者，题名，刊物名，版本：在原文件中位置；3) 标准：标准编，号标准名，企业受控编号；4) 文件：文件编号，文件名，文件版本5) 网络资讯：作者，题名，公布网址，公布时间4. 术语定义：提供软件需求分析说明书中用到专门术语、缩写词、缩略语定义，这部分信息能够在软件需求分析说明书中用一个单独章节提供或在附录中提供，也能够参考其它文件；5. 具体需求：指产品或项目必需符合条件或含有功效，它包含软件开发者在建立设计时需要全部细节。因为不一样产品项目其需求全部不一样，一样需求能够使用不一样分类方法进行划分，所以这里只列举一个比较常见划分方法，并分别加以说明：1) 功效需求：要求了在不考虑物理约束情况下必需能够实施动作，也就是通常所说系统能够做什么；2) 性能需求：是指软件功效在实施过程中需要满足强加条件，如速度、效率、可使用性、响应时间、多种软件功效恢复时间、吞吐能力、精度、频率、资源用途等等3) 属性需求：可扩展性、可移植性、稳定性、可靠性、可维护性、 兼容性、 安全性、可配置性、 可服务性、 可安装性，可国际化性、可用性、易用性等方面考虑原因；4) 外部接口：用户、硬件、其它软件和其它硬件相互关系，如用户接口、软件接口、硬件接口、通信接口等；5) 强加设计限制或实现约束：说明必需遵守技术标准和软硬件限制等设计约束，如对硬件配置要求，对软件开发环境限制、运行环境限制和对软件设计、实现方法限制；六. 包含第五条中未列出但应该在需求分析说明书中说明其它信息；七. 对第五条第5项具体需求所列出几类需求要求：除功效需求总是必需，其它需求依据产品/项目标实际情况进行增删淘汰。4.1.2. 需求项信息完整性需求项信息完整性指每个具体需求需求项需包含足够信息，来具体明确定义需求要实现目标。一. 针对每个需求项，必需包含下列信息：1. 唯一标识：跟踪需求标签，唯一且不变，提议采取“项目编号+内部编号”方法，使需求编号在整个企业范围内全部是唯一点；2. 简明描述：简单描述该需求要实现目标；3. 类型：需求类型，依所采取需求分类方法而定；4. 目标：简明描述提出该需求目标，若很显著则写“略”；5. 起源：谁提出该需求，具体能够是人(用户、用户、职员)、企业、市场等；6. 具体描述：对该需求具体说明；因为不一样类型需求其具体描述需要包含内容不一样，下面分类列出具体应该包含具体内容：A. 功效性需求：应包含但不仅限于下列内容：1) 环境要求：完成该功效应该满足具体条件，如什么状态、情况、什么样软硬件环境下能够进行该功效；2) 触发者：使该功效实施人或事，能够是用户或是其它系统、定时事件等；3) 输入：描述该功效实施前及在实施过程中全部输入具体定义。比如：数据类型输入数据类型、数量、度量单位、源、时间关系、要求（如精度）； 功效实施过程中用户操作控制信息；事件类型输入事件时间设定；所引用用以统一定义输入相关接口说明或接口控制文件。4) 处理：该功效所完成任务，即从输入到输出变换操作过程。具体应包含但不仅限于下列内容：对全部输入有效性检验；对全部输入处理次序、步骤或方法，即系统怎样把输入变换成对应输出，能够使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不一样表示方法进行描述；对全部输出有效性检验；对全部异常情况处理及响应，比如，溢出、通信故障、要全部非正当输入响应、错误处理等；5) 输出：描述该功效全部最终预期结果具体定义。如：数据类型输出数据类型、数量、目标地、度量单位、时间关系、要求（如精度）； 所引用用以统一定义输出相关接口说明或接口控制文件。B. 非功效性需求：性能需求：达成该性能需求必需含有条件或限制；该性能需求所要达成具体性能指标属性需求：可移植性：具体列出要求能够移植平台；可维护性：具体列出确保可维护性具体方法；安全性：具体列出要达成安全等级或安全程度；兼容性：具体列出所要兼容平台或软硬件环境；可测试性：具体列出确保该特征具体功效和方法；可靠性：具体列出可靠性要求，如无故障运行时间；设计限制：列出全部限制原因，如：需遵守技术标准: 列出全部必需遵守技术标准、规范（包含标准名、标准编号、版本号（或公布日期）、企业受控编号信息）硬件限制：列出全部影响或约束产品/项目标硬件成份，如运行环境最低配置；软件限制：列出全部影响或约束产品/项目标软件成份，如软件开发环境限制、软件运行环境限制和软件设计限制；7. 验证标准：用于该需求被实现后，检验实现结果是否符合需求，给测试或用户提供明确验证依据。如：对于性能需求，列出具体性能指标；对于功效需求，给出具体实现效果；若验证标准已包含在具体描述中，则指明位置即可；8. 优先级：用以表明该需求在产品/项目中关键程度及被实现代优先次序，应定义优先级划分方法，不一样产品/项目能够采取不一样划分方法； 9. 依靠性：对其它需求存在、改变依靠，如列出本需求所引用需求，若无任何依靠，则写“无”；二. 包含第一条中未列出但应该在需求项中说明其它信息；4.2. 正确性正确性指对需求定义必需是正确，它涵盖了软件需求分析说明书中所定义需求和用户实际需求是一致、对需求内容描述是明确、正确、正确和无歧义。具体应满足但不仅限于下列要求：1. 每个需求和用户实际需求是一致，即正确表示了用户真正需求，能够使用让用户确定方法来确保；2. 内容表示没有错误，应满足包含但不仅限于下列要求：1) 使用正确语法，拼写，标点；2) 无错字和别字；3) 用词贴确；3. 内容表示无歧义，如同一读者对同一表示经过不一样断句方法得出多个正确了解；4. 无不一致内容，详见质量要求“一致性”部分；5. 没有因使用不明确表述而存在可随意发挥内容，如：描述中出现了对于软件需求分析说明书作者自己很清楚但读者并不清楚主观性词语（除了已经对这些词语进行了明确定义或引用说明），具体如：“待定”、“可能”、“立即”、“考虑”、“最好”、“最差”、“通常情况”、“特殊情况”、“能够”、“用户友好性”，“轻易”，“简单”，“快速”，“有效”，“多个”，“艺术级”，“改善”，“最大”，“最小”、“很好”、“较差”、“等等”、“一期实现”、“依据需要”、“假如可能”、“高级”。4.3. 一致性 一致性指不存在内容相互矛盾地方。具体应满足但不仅限于下列要求：1. 同一内容在整个软件需求分析说明书中其内涵和外延全部是一致；2. 不存在一个需求和软件其它需求或高等级系统需求发生冲突现象；3. 术语定义和标准、规范、行业用户定义一致；4. 需求被引用时含义和定义时含义保持一致；5. 术语被引用时含义和定义时含义保持一致，若某一术语在某一特殊行文中使用时含有多个歧义，那么对该术语每种含义作出解释并指出其适用场所；4.4. 可验证性 可验证性指针对每项需求能够找到某种方法，经过这种方法能够验证该需求被实现后其实现结果是否正确。具体应满足但不仅限于下列要求：1. 每个需求必需是可行，只有可行才是可验证；2. 每个需求项必需有明确验证标准，且验证标准在现有技术水平下是可测量（能够找到某种测试方法，经过这种方法能够明确判定出是否已经达成预期指定要求），如对于该性能需求，必需给出已经量化所要达成具体性能指标，且这些指标全部能用某种方法或工具进行测量；3. 需求必需一致，详见质量要求“一致性”部分；4. 需求必需是明确，详见质量要求“正确性”部分第5条；如任何需求假如说“产品/项目将要支持什么”是不可验证，必需具体说明何时支持，怎样支持。4.5. 划分优先级划分优先级指为每个需求指定实施优先级，以表明它在产品/项目中关键程度及被实现代优先次序。具体应满足下列要求：为整个软件需求分析说明书制订统一优先级划分标准；为每个需求指定一个定义好优先级；4.6. 可用性可用性指需求分析说明书易于阅读、了解、修改、跟踪、维护、管理。具体应满足但不仅限于下列要求：1. 每项需求全部有唯一标识，便于需求引用、跟踪、管理；2. 明确指出需求间相互关联，便于在需求变更时确定变更所包含和影响范围；3. 明确说明每项需求起源和目标，便于需求跟踪、维护；4. 维护统计需求修改历史，便于需求跟踪、管理；5. 对需求进行良好组织，如：对需求进行类型划分后将相关需求分组，对需求进行层次划分使需求结构层次清楚，为需求建立目录表、索引等。便于需求阅读、管理。6. 编写、排版风格保持统一，便于阅读、了解，如对于同一类内容，使用相同表示方法和方法；7. 最终产品每一个特征用某一术语描述，便于修改、维护；8. 部分编写格式符合一定标准，如参考文档统计格式；9. 需求粗细粒度要保持一致；如软件需求分析说明书中同时存在下列需求描述，其粒度是不一致：“用户信息对于红色正当颜色代码应是R”、“对于绿色正当颜色代码应是G”、“产品应能对来自语音编辑指示做出反应”，最终一个需求应作为一个子系统而不应作为单个功效性需求。10. 对多处出现同一内容进行统一定义再分别引用，便于修改、维护和确保一致性；11. 避免将多个需求合成单个需求12. 若选择使用某软件需求分析说明书模板，应：1) 假如模板中部分章节或部分内容不适用，则在软件需求分析说明书中要保留章节号并写明不适用，不应删除；2) 若模板中未列出，但需求中应该包含信息，应在文档中合适位置添加；5. 附件此章节内容只作为开发人员编写软件需求分析说明书时一个参考，不作为审查内容。5.1. 部分编写提议列出软件需求分析说明书编写过程中部分提议，这些提议描述相对比较定性、笼统。1. 使用书面语，不用口语；2. 使用短句和短段落；3. 采取主动语气；4. 语句表示方法风格要保持一致；5. 编写时尽可能使用定量、用户词汇，少用定性、主观词汇；6. 编写时以开发人员角度来审阅是否需要软件需求分析说明书作者额外解释和帮助开发人员才能了解需求，才能进行设计和实现？若是，则需深入细化需求；7. 避免一个段落中包含了多个需求；8. 对软件需求说明书进行连续改善，软件产品开发过程中，在项目标开始阶段可能无法具体说明一些细节，在开发过程中可能发觉缺点、缺点和错误，一旦发觉需立即按需求管理步骤改善；9. 不要在一个需求中使用“和”/“或”，以避免将多个需求合成一个需求；10. 使用需求编制、管理工具，方便需求变更并确保变更后需求仍是一致、确保编写和排版风格统一；11. 尽可能使用形式化语言，少用自然语言，如使用UML、图、表格、规范化模型等方法。因为尽管自然语言是丰富多彩，但不易正确表述；12. 编写时关键在其表示内容，不要拘泥于表示形式，形式能够多个多样，适宜易用即可；13. 提议选择使用适用需求分析说明书模板；5.2. 部分参考实例列出软件需求分析说明书中部分关键内容常见表示方法例子。5.2.1. 需求项表格 使用表格方法来组织需求项内容。唯一标识【必需】(跟踪需求标签，唯一且不变，提议采取(项目编号+文档内部编号)方法，使需求编号在整个企业范围内全部是唯一点)简明描述【必需】(简单描述该需求要实现目标) 类型【必需】(需求类型，依需求分类方法而定)目标【可选】(简明描述提出该需求目标，若很显著则写“略”)起源【必需】(指谁提出该需求，具体能够是人(用户、用户、职员)、企业、市场等)具体描述【必需】对该需求具体说明；因为不一样类型需求其具体描述需要包含内容不一样，下面分类列出具体应该包含具体内容：A. 功效性需求：应包含但不仅限于下列内容：1. 环境要求：完成该功效应该满足具体条件，如什么状态、情况、什么样软硬件环境下能够进行该功效；2. 触发者：使该功效实施人或事，能够是用户或是其它系统、定时事件等；3. 输入：描述该功效实施前及在实施过程中全部输入具体定义。比如：数据类型输入数据类型、数量、度量单位、源、时间关系、要求（如精度）； 功效实施过程中用户操作控制信息；事件类型输入事件时间设定；所引用用以统一定义输入相关接口说明或接口控制文件。4. 处理：该功效所完成任务，即从输入到输出变换操作过程。具体应包含但不仅限于下列内容：对全部输入有效性检验；对全部输入处理次序、步骤或方法，即系统怎样把输入变换成对应输出，能够使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不一样表示方法进行描述；对全部输出有效性检验；对全部异常情况处理及响应，比如，溢出、通信故障、要全部非正当输入响应、错误处理等；5. 输出：描述该功效全部最终预期结果具体定义。如：数据类型输出数据类型、数量、目标地、度量单位、时间关系、要求（如精度）； 所引用用以统一定义输出相关接口说明或接口控制文件。非功效性需求：性能需求：达成该性能需求必需含有条件或限制；该性能需求所要达成具体性能指标属性需求：可移植性：具体列出要求能够移植平台；可维护性：具体列出确保可维护性具体方法；安全性：具体列出要达成安全等级或安全程度；兼容性：具体列出所要兼容平台或软硬件环境；可测试性：具体列出确保该特征具体功效和方法；设计限制：列出具体限制原因；验证标准【必需】（用于后期检验实现结果是否符合需求，给测试或用户提供明确验证依据。如：对于性能需求，列出具体性能指标；对于功效需求，给出具体实现效果；若验证标准已包含在具体描述中，则指明位置即可。）优先级【必需】(用以表明该需求在产品/项目中关键程度及被实现代优先次序，应定义优先级划分方法，不一样产品/项目能够采取不一样划分方法)依靠性【必需】(对其它需求存在、改变依靠，如列出本需求所引用需求，若无任何依靠，则写“无”。) 5.2.2. 表格需求项实例 使用表格方法组织需求项内容一个简单实例。唯一标识XX_SDK_1.1.1简明描述视频预览类型功效目标满足用户对视频进行实时预览要求提出人XX具体描述该功效环境要求：1 装有板卡及对应驱动；2 安装了显卡及对应驱动；该功效触发者：用户该功效输入：视频通道，显示位置该功效处理：能控制通道对应视频源数据经过显卡在屏幕上实时显示出来。能对以下异常情况反馈用户通知：1) 无视频信号；2) 显卡未准备好；该功效输出： 显示在屏幕上视频预览图像；该功效包含关键术语索引或解释：无验证标准1 能正常预览视频图像；2 预览图像实时（实时标准：24fps）；3 对异常情况下处理参考具体描述中内容；优先级高依靠性XX_SDK_：显卡管理5.2.3. 优先级划分方法实例 进行优先级划分时首先要制订划分标准，下面为优先级划分方法2个例子：1. 依据需求对产品或项目标关键性进行简单划分：高：必需实现基础功效、性能需求或用户强烈要求实现需求；中：辅助需求；低：特色需求；2. 以经过对每个需求综合评定优先级多个影响原因及每个原因权重，再计算出优先权值，最终再依据优先权值划分优先级，或直接使用优先权值表示优先级；如：确定优先权值和优先级对应关系：综合优先权值优先级70100高4069中139低确定优先级考虑原因、权重分配及综合优先权值算法：原因(Fn，列出全部考虑原因)原因优先权值（Pn：1100）权重(Wn：01，全部原因权重和为1)对用户关键程度最关键取100，最不关键取10.8预估实现成本成本最低取100，成本最高取10.150.05综合优先权值(Pn*Wn)优先级一个需求优先级评定：原因(Fn，列出全部考虑原因)原因优先权值（Pn：1100）权重(Wn：01，全部原因权重和为1)对用户关键程度900.8预估实现成本600.15400.05综合优先权值(Pn*Wn)900.8600.15400.0583优先级高5.2.4. 软件需求分析说明书模板 列出实际工作中可能比较常见软件需求分析说明书模板。1. 计算机软件产品开发文件编制指南（GB 8567-88）之软件需求说明书模板国家标准GB 8567-88计算机软件产品开发文件编制指南中软件需求说明书模板。2. RUP 模板包含软件需求规约模板和软件需求补充规约模板，二者组成相对完整需求分析，适适用于采取RUP过程需求分析。