需求核对表

针对功能需求

  • 是否详细定义了系统的全部输入,包括其来源、精度、取值范围、出现频率等?
  • 是否详细定义了系统的全部输出,包括目的地、精度、取值范围、出现频率、格式等?
  • 是否详细定义了所有输出格式(web页面、报表等)?
  • 是否详细定义了全部外部通信接口,包括握手协议、纠错协议、通信协议等?
  • 是否列出了用户想要做的全部事情?
  • 是否详细定义了每个用户所用的数据,以及每个人物得到的数据?

针对非功能需求(质量需求)

  • 否是为全部必要的操作,从用户的视角,详细描述了期望相应时间?
  • 是否详细描述了其他与计时有关的考虑,例如:处理时间、数据传输率、系统吞吐量?
  • 是否定义了安全级别?
  • 是否详细定义了可靠性,包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等?
  • 是否详细定义了机器内存和剩余磁盘空间的最小值?
  • 是否详细定义了相互竞争的特性之间的权衡——例如,健壮性与正确性之间的权衡?
  • 是否避免在需求中规定设计(方案)?
  • 需求是否在详细程度上保持相当一致的水平?有些需求应该更详细地描述吗?开发者也这么想吗?
  • 每个条款都与待解决的问题及解决方案相关吗?能从每个条款上溯到它在问题域中对应的根源吗?
  • 是否每条需求都是可测试的?是否可能进行独立的测试,以检验漫步满足各项需求?
  • 是否详细描述了所用可能的对需求的改动,包括各项改动的可能性?

需求的完备性

  • 对于是否详细定义了系统的可维护性,包括适应特定功能的变更、操作系统的变更、与其他软件的接口的变更能力?
  • 是否包含对“成功”的定义?“失败”的定义呢?
  • 需求是用用户的语言写的嘛?用户也这么认为吗?
  • 每条需求都不与其他需求冲突吗?
  • 对于在开始开发之前无法获得的信息,是否详细描述了信息不完全的区域?
  • 需求的玩被堵是否能达到这种程度:如果铲平满足所有需求,那么他就是可接受的?
  • 你对全部需求都感到很舒服吗?你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西?
时间: 2024-10-10 10:28:59

需求核对表的相关文章

核对表:需求(代码大全2)

Checklist: Requirement 针对功能需求  是否详细定义了系统的全部输入,包括其来源.精度.取值范围.出现频率等?  是否详细定义了系统的全部输出,包括目的地.精度.取值范围.出现频率.格式等?  是否详细定义了所有输出格式(Web页面.报表.等等)? 是否详细定义了所有硬件及软件的外部接口?  是否详细定义了全部外部通信接口,包括握手协议.纠错协议.通信协议等? 是否列出了用户想要做的全部事情?  是否详细定义了每个任务所用的数据,以及每个任务得到的数据? 针对非功能需求(质

软件架构————架构核对表

架构的典型组成部分 一.程序组织: 1.系统架构首先要以概括的形式对有关系统做一个综述.如果没有这种综述,要想将成千的局部图片拼成一幅完整的图画是相当伤脑筋的. 2.在架构中,应该发现对那些曾经考虑过的最终组织结构的替代方案的记叙,找到之所以选用最终的组织结构,而不用其他替代方案的理由. 3.架构应该定义程序的主要构造块.根据程序规模不同,各个构造块可能是单个类,也可能是有许多类组成的一个子系统. 4.应该明确定义各个构造块的责任.每个构造块应该负责某一个区域的事情,并且对其他构造块负责的区域知

第3章三思而后行:前期准备下(代码大全8)

第3章 Measure Twice, Cut Once:Upstream Prerequisities 三思而后行:前期准备 3.4 需求的先决条件 3.5 架构的先决条件 3.6 花在前期准备上的时间长度 要点 3.4 Requirements Prerequisite 需求的先决条件 软件架构(software architecture)是软件设计的高层部分,是用于支撑更细节的设计的框架. 为什么要把架构作为前期准备工作呢?因为架构的质量决定了系统的“概念完整性”.后者继而决定了系统的最终质

代码大全学习笔记(一):第1-3章

1. 本书全面阐述 软件构建活动的方方面面 2. 软件开发过程中的各种活动: (1)   定义问题 (2)   需求分析 (3)   规划构建 (4)   软件架构 (5)   详细设计 (6)   编码与调试 (7)   单元测试 (8)   集成测试 (9)   集成 (10)  系统测试 (11)  保障维护 3. 发现错误的时间要尽可能接近引入该错误的时间 4. 软件开发两种方式: (1)迭代式开发:需求不稳定或理解暂时不透彻,变动较多 (2)序列式开发:需求比较稳定,长期可预测性 5.

《敏捷软件测试》的读书笔记(三)

第三部分 敏捷测试象限 6. 测试的目的 敏捷测试的象限 支持团队的测试:帮助开发开发产品 象限一:TDD/TD测试.使用和应用相同的编码.一般内部质量由程序员定义.参与测试.CI环境. 象限二:测试每个产品的细节,自动化测试运行于业务逻辑层.自动化持续集成.构建.测试过程.快速测试,反馈BUG.功能环境 支持产品的测试:确认产品满足需求,改进产品.测试 象限三:评价产品满足客户需求.竞争力,改进产品.仿真最终用户测试. 象限四:性能安全开发的每一步都应考虑,不要留到最后. 知道一个产品何时完成

软考中级笔记

9大管理总复习 5大过程组 范围管理 1)      范围管理的过程和各自的工具是什么? 2)     产品范围包含(产品规格),( 性能技术指标)的描述. 3)     项目范围是否完成以什么为衡量标准. 以项目管理计划,项目范围说明书,WBS,以及WBS字典作为衡量标准. 要基于项目管理计划来度量 4)     WBS的表示形式是什么?各有什么优缺点? 树型和列表形式. 优点 缺点 树型 层次清晰,非常直观,结构性强 不容易修改,对于大的复杂的项目很难表示出项目的全景.一般应用在中小型项目中

2015.09.30信息系统项目管理师作业

2015.09.30 高级 第八章 项目成本管理重点 1.成本管理的意义和范畴: 2.成本估算:是编制一个为完成项目各活动所需要的资源成本的估算:是一个要钱的计算:是申请资金的: 3.成本预算,是花钱的计划:成本预算的输出就是成本基线: 4.成本失控的原因:成本估算工作和成本预算工作不够准确细致,思想认识存在误区,项目在进行成本估算和预算没有统一规范, 5.成本估算内容对完成项目个项活动所必需的各种资源的成本做出近似的估算,:编制成本估算:编制成本造价:项目造价包括项目成本和项目盈利: 6.编制

项 目 管 理 知 识 体 系 指 南 (PMBOK2008)

项 目 管 理 知 识 体 系 指 南 (第4版) PMBOK2008 输入 工具与技术 输出 4.项目整合管理 4.1 制定项目章程 4.1.1.1 项目工作说明书 4.1.2.1 专家判断 4.1.3.1 项目章程 4.1.1.2 商业论证 4.1.1.3 合同 4.1.1.4 事业环境因素 4.1.1.5 组织过程资产 4.2 制定项目管理计划 4.2.1.1 项目章程 4.2.2.1 专家判断 4.2.3.1 项目管理计划 4.2.1.2 其他规划过程的输出 4.2.1.3 事业环境因素

2015.9.30日作业

项目成本管理重点梳理 项目成本管理的概念:项目成本管理是项目管理的一个重要组成部分,它是指在项目的实施过程中,为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算.项目预算编制和项目成本控制等方面的管理行为. 其中 成本估算是编制一个为完成项目各活动所需要的资源成本的近似估算(业主/甲方做) 成本预算是将总的成本估算分配到各项活动或工作包上,来建立一个成本的基线.(集成商/乙方做) 成本控制是控制项目预算的并更(甲方.乙方和监理方都参与做). 成本失控的原因: 成本估算工作和成本