软件需求讲义-第四部分

软件(ruǎnjiàn)需求（四）共九十二页需求文档与需求质量(zhìliàng)验证软件需求规格(guīgé)说明需求验证需求评审共九十二页

第16章.需求规格(guīgé)说明共九十二页主要(zhǔyào)内容需求规格说明(shuōmíng)概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页需求规格说明(shuōmíng)概述

——获取VS分析VS规格说明需求获取目标是得到用户需求——收集需求信息需求分析(fēnxī)目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则需求规格说明目标是定义用户需求——准确描述需求及其解决方案共九十二页你可以用三种方法编写软件需求规格说明：•用好的结构化和自然语言编写文本(wénběn)型文档。•建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。•编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。软件需求(xūqiú)太原理工大学软件学院2015© 共九十二页第16章软件(ruǎnjiàn)需求规格说明

主要内容(nèiróng)：需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页SRS（SoftwareRequirementSpecification）是软件项目初期阶段重要的一步，它从问题域的识别和定义，逐步转移至解决域中。解决域需要用需求模型来描述。SRS提供了容纳(róngnà)这些模型的框架。一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性、期望性能等非功能性需求。SRS是初期问题域的识别和描述；解决域需要用需求模型来描述。SRS需求(xūqiú)规格说明书软件需求太原理工大学软件学院2015© 共九十二页1.需求(xūqiú)规格说明概述

——需求规格说明活动共九十二页主要(zhǔyào)内容需求规格说明概述需求规格说明文档模版的选择与裁剪(cáijiǎn)文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页需求规格(guīgé)说明模版（IEEE/ANSI830-1993）共九十二页2.需求规格说明(shuōmíng)文档

——作用更好的传递软件系统的需求信息和解决方案给所有的开发者拓展人们的知识(zhīshi)记忆能力作为合同协议的重要部分作为项目开发活动的一个重要依据发现和减少可能的需求错误，减少项目的返工，降低项目的工作量作为有效的智力资产共九十二页2.需求规格(guīgé)说明文档

——忽视的原因交流途径时间压力迭代式开发(kāifā)敏捷共九十二页2.需求规格(guīgé)说明文档

——类型共九十二页2.需求规格(guīgé)说明文档

——类型共九十二页2.需求规格说明(shuōmíng)文档

——内容前景(qiánjǐng)和范围内问题域信息解决方案需求共九十二页2.需求(xūqiú)规格说明文档

——作者项目管理者组织安排(ānpái)、提供条件需求工程师负责人、主导人文档写作人员有时会采用，节省需求工程师的时间涉众（用户）验证人共九十二页2.需求(xūqiú)规格说明文档

——读者共九十二页2.需求规格说明(shuōmíng)文档

——手段非形式化自然语言限制性文本半形式化结构化文本伪码/结构化英语(yīnɡyǔ)模型语言图、表…形式化形式化语言数学语言：BNF，Z…共九十二页主要(zhǔyào)内容需求规格说明概述需求规格说明文档模版的选择与裁剪(cáijiǎn)文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页3.模版的选择(xuǎnzé)与裁剪

——动机优秀的文档结构组织复用：模版选择与裁剪文字(wénzì)写作字词、句法写作技巧共九十二页共九十二页主要(zhǔyào)内容需求规格说明概述需求规格说明文档模版的选择(xuǎnzé)与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页4.文档写作技巧

——原则(yuánzé)写作是一门艺术没有什么固定的规律有一些效用有限的经验原则文档的组织方式；常见情景的处理；常用的写作技巧；容易出错的地方等。文档化的目标是交流简洁、易读VS严格、准确不要机械的照搬某些标准(biāozhǔn)和规则有没有另外一种更容易理解的表达方式？是否一次性提供了太多的信息？对读者来说什么是重要的，什么是不重要的？是否太抽象了？需不需要举例说明？是否太专业了？需不需要解释原理？会不会引起读者对内容的错误解释？哪些内容有益于读者？有益于哪些读者？文档在整体上是不是过于机械、乏味或者松散？文档枯燥吗？令人厌烦吗？共九十二页4.文档写作技巧

——结构(jiégòu)组织所有内容位置得当借鉴和使用标准的文档模版引用或强化(qiánghuà)，但不重复引用而不是复制强化与重复引言与冗余元文本共九十二页4.文档写作技巧

——表达方式形式依赖于内容根据需要表达的内容，选择合适的表达方式使用系统的表达方式人们倾向于系统的表达方式使用相同的语句格式来描述所有的细节需求。使用列表或者表格来组织独立、并列的信息。使用编号来表达繁杂信息之间的关系，包括顺序(shùnxù)关系、嵌套关系和层次关系。共九十二页4.文档写作技巧

——细节(xìjié)描述定义术语表或数据字典术语不一致“方言”问题错误术语和冗余术语避免干扰(gānrǎo)文本“这一段的意思是…”“上一句话是指…”避免歧义词汇表15－1共九十二页歧义词汇改进方法可接受的、足够的具体定义可接受的内容，说明系统怎样判断“可接受”或“足够”大概可行的、差不多可行的不要让开发人员来判断“大概”和“差不多”到底是否成立。应将其标记为待确定问题并标明解决日期至少、最小、不多于、不超过明确指定能够接受的最大值和最小值在……之间明确说明两个端点是否在范围之内依赖描述依赖的原因，数据依赖？服务依赖？还是资源依赖？等等有效的明确“有效”所意味的具体实际情况快的、迅速的明确指定系统在时间或速度上可接受的最小值灵活的描述系统为了响应条件变化或需求变化而可能发生的变更方式改进的、更好的、更快的、优越的定量说明在一个专门的功能领域内，充分改进的程度和效果包括、包括但不限于、等等、诸如应该列举所有的可能性，否则就无法进行设计和测试最大化、最小化、最优说明对某些参数所能接受的最大值和最小值一般情况下、理想情况下需要增加描述系统在异常和非理想情况下的行为可选择地具体说明是系统选择、用户选择还是开发人员选择合理的、在必要的时候、在适当的地方明确怎样判断合理、必要和适当健壮的显式定义系统如何处理异常和如何响应预料之外的操作无缝的、透明的、优雅的将词汇里面所反映的用户期望转化成能够观察到的产品特性若干声明具体是多少，或提供某一范围内的最小边界值和最大边界值不应该试着以肯定的方式陈述需求，描述系统应该做什么最新技术水平的定义其具体含义，即“最新技术水平”意味什么充分的说明“充分”具体包括哪些内容支持、允许精确地定义系统的功能，这些功能组合起来支持某些能力用户友好的、简单的、容易的描述系统特性，用这些特性说明词汇所代表的用户期望的实质共九十二页主要(zhǔyào)内容需求规格(guīgé)说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀需求规格说明文档的特性需求规格说明的实践调查共九十二页5.优秀需求(xūqiú)规格说明文档的特性完备性标准描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。定义(dìngyì)了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。前景和范围TBD问题共九十二页5.优秀需求(xūqiú)规格说明文档的特性一致性标准细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务(yèwù)需求、用户需求互相矛盾同一层次的不同需求之间也不能互相冲突评审自动化检查共九十二页5.优秀需求规格(guīgé)说明文档的特性根据重要性和稳定性分级建立需求的优先级可修改标准它的结构和风格使得人们可以对其中任一需求进行容易地、完整地、一致地修改，同时还不会影响文档现有的结构和风格文档的可修改性要求(yāoqiú)：有着条理分明并且易于使用的组织方式，包括目录、索引和显式的交叉引用。没有重复冗余。独立表达每个需求，而不是和其他需求混在一起。共九十二页5.优秀需求(xūqiú)规格说明文档的特性可跟踪后向跟踪（Backwardtraceability）能找到需求的来源，例如和更早期文档的显式关联。前向跟踪（Forwardtraceability）能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识(biāozhì)或者可供引用的名称共九十二页主要(zhǔyào)内容需求规格说明概述需求规格说明文档模版的选择与裁剪文档写作技巧优秀(yōuxiù)需求规格说明文档的特性需求规格说明的实践调查共九十二页6.需求规格(guīgé)说明的实践调查需求规格(guīgé)说明文档的编写和使用时间压力替代品迭代式开发共九十二页6.需求规格说明的实践(shíjiàn)调查需求规格说明(shuōmíng)文档的内容问题域描述业务过程操作功能用户行为任务事件场景术语首字母缩写量（Volume）估计值公司背景共九十二页6.需求(xūqiú)规格说明的实践调查需求规格(guīgé)说明文档的内容效果（解系统描述）特征通用标准特征独特特征事务更新插入删除修改信息需求特定报告（Adhocreporting）数据采集数据流数据库查询处理报表行为需求困难示例（Cornercase）错误示例（Errorcase）事件外部事件状态转移转换/转移（Transformation）需求共九十二页6.需求规格(guīgé)说明的实践调查需求规格(guīgé)说明文档的内容问题接口与其他系统接口系统接口用户界面变更目的目标可行性分析架构约束文档信息文档历史版本和草案签署日期传播（Circulation）授权列表原创作者目录参考文献共九十二页6.需求规格说明的实践(shíjiàn)调查模版和示例(shìlì)的使用共九十二页6.需求规格说明(shuōmíng)的实践调查需求(xūqiú)规格说明文档的描述语言共九十二页实例分析(fēnxī)(wiki的使用)由于时间压力以及采取迭代开发的方式，造成了该项目没有编写需求规格说明书。但是可以采用(cǎiyòng)更为灵活的方式编写，例如wiki。我曾在某一预研性质的项目中使用wiki来完成各类文档。结果证明它非常好用。wiki非常适合用在迭代开发以及预研性质的项目中编写文档。共九十二页实例分析(fēnxī)（公司A）我们公司项目的需求规格说明书，主要存在以下几点问题模版不是很统一，具有很多个人的特点没有明确的业务需求、用户需求、系统需求，这三个层次，在需求规格说明书中或多或少地涵盖前三项内容，但显得不够饱满和清晰鉴于项目的状况，一般较少考虑(kǎolǜ)硬件需求，倒是一般来说，项目上线选用的都是最新的硬件设备，成本较高。内容的书写，自然语言居多，出现歧义、省略、模糊的机会较多，质量不高从项目的后期来看，性能需求、约束、质量需求没有明确地分门别类地明确列出，导致后期项目中的各个业务流程还是基本可行，但是整体系统还是出现总体质量不满足的地方。共九十二页实例分析(fēnxī)（项目报告）需求分析报告中夹杂了很多专业名词和行业名词，例如横冲、平衡等等，有些部分客户看不懂，有些部分程序员看不懂，只有自己心里明白，但这样就会造成客户和程序员理解上的问题。另外报告中写得比较凌乱，没有把相关问题归类整合，编写目录，导致程序员零散地一条条对着开发，很多地方衔接不是很好，另外客户很多想法(xiǎngfǎ)尤其一些重要部分在软件交付的时候会有所改变。共九十二页需求文档的编写(biānxiě)原则句子和段落要短。要检查需求是否(shìfǒu)被有效地定义。需求编写者还要努力正确地把握细化程度。密切关注合成了多个需求的单个需求。通篇文档细节上要保持一致。共九十二页高质量的SRS的一些(yīxiē)特性完整性一致性可修改性可追踪书上P169

共九十二页评审需求(xūqiú)规格说明书的常见问题

叙述的软件目标和系统的目标是否保持一致？所有系统元素的重要(zhòngyào)接口都已描述了吗？问题域的信息流和结构都已被恰当地定义了吗？图示是否清楚？每个图都可以不需要文字补充了吗？是否包括了所有主要的功能，它们都已描述清楚了吗？系统的功能和用户需求一致了吗？设计约束是现实可行的吗？是否考虑过开发的技术风险？是否考虑过其他可选的软件需求？检验标准是否被详细地陈述？它们能有效地检验系统是否成功吗？是否存在不一致性、是否信息被忽略或冗余？和客户全面接触过吗？客户的主要意见都已被考虑了吗？用户是否评审过初步的原型？计划的估算受到什么样的影响？共九十二页发现需求规格说明书中问题(wèntí)的一些方法

搜寻说服性的连接词(例如，当然、因此、明确地、显然)，并问“为什么”。观察含糊的术语(例如，一些、有时、经常、通常、一般地、大多数)，并进行澄清。当给出了不完整的列表时，确定已理解了所有的项。关键是查找“等等、如此这样”。确定陈述的范围内条件清晰。(例如，从10到100的校验代码范围究竟是整数？实数？还是复数？)避免含糊的动词，如“处理、拒绝、处制、跳过、限制”等，它们可以有很多方式来解释。避免含糊的代词(dàicí)(例如，I/O模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？)查找蕴含了确定性判断的语句(例如，总是、每次、所有、无、永不)，证明它们是合理的。某个术语一旦被明确地定义，就要在文中前后一致地使用。用图示的方法可以帮助理解。共九十二页本章(běnzhānɡ)小结需求规格说明定义解决方案和需求，承载需求分析的成果需求规格说明是一项复杂的活动，正确的文档写作要求准确的界定文档的特性掌握文档模版的裁剪技巧和文档的写作技巧，可以帮助(bāngzhù)提高需求规格说明文档写作的能力优秀的需求规格说明文档需要达到一定的要求共九十二页思考题什么时候建立术语表？在需求获取和需求分析当中(dāngzhōng)采用哪些手段可以保证最终需求集的完备性、一致性和正确性？共九十二页

第17章.需求(xūqiú)验证与

第18章需求评审

共九十二页主要(zhǔyào)内容验证与确认(quèrèn)需求验证需求验证方法问题修正需求验证的实践调查共九十二页1.验证与确认(quèrèn)

——概念需求验证：以正确的方式建立需求需求集是正确的、完备的和一致的；技术(jìshù)上是可解决的；它们在现实世界中的满足是可行的和可验证的。需求确认：建立的需求是正确的每一条需求都是符合用户原意的系统验证：正确的建立系统系统能够在预期的环境中正确的执行设定的功能。系统确认：建立的系统是正确的建立的系统是符合系统需求和系统设计的共九十二页第17章需求(xūqiú)验证需求验证所包括的活动是为了确定以下(yǐxià)几方面的内容：软件需求规格说明正确描述了预期的系统行为和特征。从系统需求或其它来源中得到软件需求。需求是完整的和高质量的。所有对需求的看法是一致的。需求为继续进行产品设计、构造和测试提供了足够的基础。需求验证确保了需求符合良好特征并且符合需求规格说明的良好特性。共九十二页需求(xūqiú)验证的意义

需求验证并不仅仅是一个独立的阶段。一些验证活动，例如对迭代增量型软件需求规格(guīgé)说明的反复评审，将贯穿着反复获取需求、分析和编写规格(guīgé)说明的整个过程。当你的项目计划或实际工作中的独立任务破坏了结构性时，就要结合进行需求验证活动。为防止错误而花费1美元将可以为你修补错误节省3~10美元。**[Jones1994]共九十二页1.验证(yànzhèng)与确认

——软件工程的验证与确认共九十二页主要(zhǔyào)内容验证与确认(quèrèn)需求验证需求验证方法问题修正需求验证的实践调查共九十二页2.需求验证(yànzhèng)

——概念验证普遍存在获得的用户需求是否正确和充分的支持业务需求？建立的分析模型是否正确的反映了问题域特性和需求？细化的系统需求是否充分和正确的支持用户需求？需求规格说明文档是否组织良好、书写(shūxiě)正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动共九十二页2.需求验证(yànzhèng)

——活动共九十二页测试与开发平行，验收测试以用户需求为基础(jīchǔ)，系统测试以功能需求为基础(jīchǔ)，集成测试以系统体系结构为基础(jīchǔ)。软件开发的V字模型(móxíng)软件需求太原理工大学软件学院2015© 共九十二页主要(zhǔyào)内容验证与确认需求验证需求验证方法评审原型与模拟开发测试用例用户手册编制利用跟踪关系自动化分析问题(wèntí)修正需求验证的实践调查共九十二页3.1评审(pínɡshěn)由作者之外的其他人来检查产品问题的方法是主要的静态分析手段原则上，每一条(yītiáo)需求都应该进行评审共九十二页3.1评审(pínɡshěn)

——参与人员共九十二页3.1评审(pínɡshěn)

——过程共九十二页3.1评审(pínɡshěn)

——检查方法检查方法描述自由方法（Ad-hoc）没有为检查人员提供系统化的引导检查清单（Checklist-Based）以通用的检查清单来引导检查过程缺陷（Defect-Based）用于需求文档，根据缺陷的分类来组织和检查场景功能点（FunctionPoint-Based）按照功能点来组织和检查场景视角（Perspective-Based）按照不同涉众类型的视角来组织和检查场景场景（Scenario-Based）对每一个场景，都利用一系列的问题或者细节要求，来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。逐步提升（StepwiseAbstraction）净室软件开发中的一种方法。阅读者描述一些独立代码段的功能，然后将描述的范围逐步扩大，描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件共九十二页3.1评审(pínɡshěn)

——类型共九十二页3.2原型(yuánxíng)与模拟涉及到复杂的动态行为(xíngwéi)时成本较高共九十二页3.3开发(kāifā)测试用例如果无法(wúfǎ)为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷例外排斥性需求（ExclusiveRequirements）这种需求要求特定的行为绝对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃全局性非功能性需求（GlobalNon-FunctionalRequirements）例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理共九十二页3.4用户手册编制(biānzhì)验证功能需求对软件系统功能和实现的描述验证项目范围对系统没有实现的功能的描述验证异常流程需求问题和故障的解决验证环境与约束需求系统的安装(ānzhuāng)和启动共九十二页3.5利用(lìyòng)跟踪关系业务需求

用户需求

系统需求如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明(shuōmíng)文档就存在不完备的缺陷。系统需求

用户需求

业务需求如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。共九十二页3.6自动化分析(fēnxī)共九十二页主要(zhǔyào)内容验证(yànzhèng)与确认需求验证需求验证方法问题修正需求验证的实践调查共九十二页4.问题(wèntí)修正需求澄清（RequirementsClarification）理解偏差：重新进行分析工作分析遗漏：重新分析和文档化这部分信息表达不当：重新以合适的方式表达缺失需求重新执行需求获取等一系列工作需求冲突协商(xiéshāng)解决不切实际的期望项目调整与需求协商共九十二页主要(zhǔyào)内容验证与确认需求验证需求验证方法(fāngfǎ)问题修正需求验证的实践调查共九十二页5.需求验证(yànzhèng)的实践调查需求验证是重要的需求验证是容易被忽视的需求验证的方法是多样的评审(pínɡshěn)和原型最为广泛客户对线索（Threads）和场景（Scenarios）表现出了最大的兴趣技术人员、领域专家、客户以及用户是最合适的评审者共九十二页实例(shílì)分析(一个公司的业务管理系统)问题需求虽然写好了也定稿了，但是并没有得到最终确认就开始了软件开发工作。这种现象主要是由于业务小组和技术小组沟通不全面造成的，在双方(shuāngfāng)就某一问题产生分歧的情况下，没有一个能出来拍板的人决定（有权利决定的领导不参与开发和需求编写）。所以整个项目的开发是在业务小组和技术小组的争论中走过的。经常出现业务小组提出的方案技术小组难以落实，等到后期变通修改造成功能损失的情况。因为需求得不到最终确认，一直在修改中，造成技术小组不停的修改已经编写完毕的模块，有些改动甚至涉及到公共基类的修改和各模块之间的关联，造成很大的浪费。解决验证与确认+需求管理共九十二页实例(shílì)分析（地税系统）问题系统开发过程中，没有好的办法检测需求落实的情况。最后验收(yànshōu)的时候功能是否实现由技术小组说了算。解决需求规格说明+需求验证与确认用户为中心共九十二页本章(běnzhānɡ)小结验证与确认是软件工程(gōngchéng)当中一项重要的活动。需求验证是需求工程(gōngchéng)中发生的对需求规格说明文档进行的验证与确认活动需求验证有多种有效的方法，实践中最为重要和广泛应用是的评审方法和原型方法需求验证不仅要发现问题，而且要监督问题的解决共九十二页思考题用于需求获取的原型与用于需求验证的原型有何异同？多种需求验证的方法应该(yīnggāi)如何结合运用？共九十二页第18章需求(xūqiú)评审需求评审为涉众们提供(tígōng)了在特定问题上达成共识的方法。评审类型：评审、检察、走查。进行成功的评审有几个关键要素：理解评审流程；确保评审员理解自己的角色；指定协调员；使评审保持简短，严格按照议程进行；确定问题，而不要解决问题。评审过程。需求评审中常见的问题。软件需求规格说明书的评审清单。

共九十二页非正式评审(pínɡshěn)

非正式评审的方法可以是把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍(walkthrough)，或是由产品开发者描述产品，征求大家的意见。非正式评审对于获得分散而随机的反馈是有效的，但非正式评审是非(shìfēi)系统化的，不彻底的，它在实施过程中具有不一致性。共九十二页正式(zhèngshì)评审正式评审则遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题(wèntí)的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。共九十二页评审(pínɡshěn)类型

[IEEE]评审：一次正式的会议。在会议上向用户、客户或其他相关各方介绍一个或一组工件，以征求对方的意见和批准。检查：一种正式的评估方法，将由非制作者本人的个人或小组详细检查工件，以查明是否有错误、是否违反开发标准、是否存在其他问题。走查：一个评审过程，由某个开发人员领导一个或多个开发团队成员对他（或她）所编写的一段工件进行检查；同时，由其他成员针对技术、风格(fēnggé)、可能的错误、是否违反开发标准和其他问题提出问题并发表意见。共九十二页评审(pínɡshěn)流程评审流程是一个重复进行的循环过程：评审员提出问题—〉讨论问题—〉对问题进行确认—〉确定缺陷（确定需要解决的地方(dìfāng)），直到没有确定的问题时再继续下一步。RUP强调确保质量的主要因素：同事检查。共九十二页需求评审(pínɡshěn)中常见的问题需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚。没有作好(zuòhǎo)前期准备工作，需求评审的效率很低。需求评审的节奏无法控制。找不到合格的评审员，与会的评审员无法提出深入的问题。共九十二页需求评审(pínɡshěn)技术细节上的常见错误

根本不进行需求评审，而是让程序员随心所欲地写程序。用例不能符合所需的系统行为(xíngwéi)。不使用任何GUI原型来帮助验证系统行为。用例高度抽象，让不懂技术的客户如坠迷雾中。概念模型不能准确地反映真实世界的概念性对象。用例建模没有参考概念模型。对不包含任何分支流程的用例不提出疑义。共九十二页分层次评审用户需求(xūqiú)分为：目标性需求，系统目标功能性需求，系统任务操作性需求，人机交互正式结合非正式评审分阶段评审充分利用需求评审检查单，如下表软件质量因素。如何(rúhé)做好需求评审

软件需求太原理工大学软件学院2015© 共九十二页对需求定义(dìngyì)进行静态测试的对照条例

兼容性：界面需求是否使软硬件系统具有兼容性？完备性：需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？功能性需求是否覆盖了所有非正常情况的处理？是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？是否识别定义了在将来可能会变化的需求？是否定义了系统的所有输入？是否标识清楚了系统输入的来源？是否识别了系统的输出？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的值域、单位、格式等？是否说明了如何进行系统输入的合法性检查？是否定义了系统输入、输出的精度？在不同负载情况下，系统的生产率如何？在不同的情况下，系统的响应时间如何？系统对软件、硬件或电源故障必须作什么样的反应？是否充分定义了关于人机界面的需求？一致性：各个需求之间是否一致？是否有冲突和矛盾？所规定的模型、算法和数值