第15章需求规格说明.

第15章.需求规格说明主要内容第1节需求规格说明概述第2节需求规格说明文档第3节模版的选择与裁剪第4节文档写作技巧第5节优秀需求规格说明文档的特性第6节需求规格说明的实践调查第1节需求规格说明概述•需求获取–目标是得到用户需求——收集需求信息•需求分析–目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则•需求规格说明–目标是定义用户需求——准确描述需求及其解决方案（1）获取——分析——规格说明（2）需求规格说明活动第2节需求规格说明文档（1）作用•更好的传递软件系统的需求信息和解决方案给所有的开发者•拓展人们的知识记忆能力•作为合同协议的重要部分•作为项目开发活动的一个重要依据•发现和减少可能的需求错误，减少项目的返工，降低项目的工作量•作为有效的智力资产（2）忽视的原因•交流途径•时间压力•迭代式开发–敏捷（3）类型业务需求用户需求系统需求项目前景和范围文档需要的特性具体的需求用户需求文档（用例文档）系统需求规格说明文档软件需求规格说明文档硬件需求规格说明文档人机交互文档接口需求规格说明文档软件需求硬件件需求用户界面细化的需求招标签约用户文档开发文档项目前景和范围文档用户需求文档系统需求规格说明文档软件需求规格说明文档硬件需求规格说明文档接口需求规格说明文档人机交互文档对解决方案的约束需求表达的真实度需求的丰富性和模糊性用户的理解度对非专业读者的可读性系统化和形式化方法的应用问题域解决方案（4）内容•前景和范围内容–问题域信息–解决方案–需求（5）作者•项目管理者–组织安排、提供条件•需求工程师–负责人、主导人•文档写作人员–有时会采用，节省需求工程师的时间•涉众（用户）–验证人（6）读者体系结构设计（体系架构师）需求工程（需求工程师）并行开发1（设计人员、程序员）并行开发n（设计人员、程序员）测试计划（测试人员）用户使用手册编写计划（文档编写人员）软件估算与进度安排（项目管理者）软件体系结构软件需求规格说明文档…...（7）手段•非形式化–自然语言–限制性文本•半形式化–结构化文本•伪码/结构化英语–模型语言•图、表…•形式化–形式化语言•数学语言：BNF，Z…第3节模版的选择与裁剪•优秀的文档–结构组织•复用：模版–选择与裁剪–文字写作•字词、句法–写作技巧标准模版组织模版项目模版项目的软件需求规格说明文档裁剪定制裁剪定制内容写作（1）动机（2）模板第4节文档写作技巧（1）原则•写作是一门艺术–没有什么固定的规律–有一些效用有限的经验原则•文档的组织方式；•常见情景的处理；•常用的写作技巧；•容易出错的地方等。•文档化的目标是交流–简洁、易读VS严格、准确–不要机械的照搬某些标准和规则有没有另外一种更容易理解的表达方式？是否一次性提供了太多信息？对读者来说什么是重要的，什么是不重要的？是否太抽象了？需不需要举例说明？是否太专业了？需不需要解释原理？会不会引起读者对内容的错误解释？哪些内容有益于读者？有益于哪些读者？文档在整体上是不是过于机械、乏味或者松散？文档枯燥吗？令人厌烦吗？（2）结构组织•所有内容位置得当–借鉴和使用标准的文档模版•引用或强化，但不重复–引用而不是复制–强化与重复–引言与冗余元文本（3）表达方式形式依赖于内容根据需要表达的内容，选择合适的表达方式使用系统的表达方式人们倾向于系统的表达方式使用相同的语句格式来描述所有的细节需求。使用列表或者表格来组织独立、并列的信息。使用编号来表达繁杂信息之间的关系，包括顺序关系、嵌套关系和层次关系。（4）细节描述•定义术语表或数据字典–术语不一致–“方言”问题–错误术语和冗余术语•避免干扰文本–“这一段的意思是…”–“上一句话是指…”•避免歧义词汇–表15－1歧义词汇改进方法可接受的、足够的具体定义可接受的内容，说明系统怎样判断“可接受”或“足够”大概可行的、差不多可行的不要让开发人员来判断“大概”和“差不多”到底是否成立。应将其标记为待确定问题并标明解决日期至少、最小、不多于、不超过明确指定能够接受的最大值和最小值在……之间明确说明两个端点是否在范围之内依赖描述依赖的原因，数据依赖？服务依赖？还是资源依赖？等等有效的明确“有效”所意味的具体实际情况快的、迅速的明确指定系统在时间或速度上可接受的最小值灵活的描述系统为了响应条件变化或需求变化而可能发生的变更方式改进的、更好的、更快的、优越的定量说明在一个专门的功能领域内，充分改进的程度和效果包括、包括但不限于、等等、诸如应该列举所有的可能性，否则就无法进行设计和测试最大化、最小化、最优说明对某些参数所能接受的最大值和最小值一般情况下、理想情况下需要增加描述系统在异常和非理想情况下的行为可选择地具体说明是系统选择、用户选择还是开发人员选择合理的、在必要的时候、在适当的地方明确怎样判断合理、必要和适当健壮的显式定义系统如何处理异常和如何响应预料之外的操作无缝的、透明的、优雅的将词汇里面所反映的用户期望转化成能够观察到的产品特性若干声明具体是多少，或提供某一范围内的最小边界值和最大边界值不应该试着以肯定的方式陈述需求，描述系统应该做什么最新技术水平的定义其具体含义，即“最新技术水平”意味什么充分的说明“充分”具体包括哪些内容支持、允许精确地定义系统的功能，这些功能组合起来支持某些能力用户友好的、简单的、容易的描述系统特性，用这些特性说明词汇所代表的用户期望的实质第5节优秀需求规格说明文档的特性•完备性–标准•描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。•定义了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。•为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。–前景和范围–TBD问题•一致性–标准•细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务需求、用户需求互相矛盾•同一层次的不同需求之间也不能互相冲突–评审–自动化检查•根据重要性和稳定性分级–建立需求的优先级•可修改–标准•它的结构和风格使得人们可以对其中任一需求进行容易地、完整地、一致地修改，同时还不会影响文档现有的结构和风格–文档的可修改性要求：•有着条理分明并且易于使用的组织方式，包括目录、索引和显式的交叉引用。•没有重复冗余。•独立表达每个需求，而不是和其他需求混在一起。•可跟踪–后向跟踪（Backwardtraceability）•能找到需求的来源，例如和更早期文档的显式关联。–前向跟踪（Forwardtraceability）•能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识或者可供引用的名称第6节需求规格说明的实践调查•需求规格说明文档的编写和使用–时间压力–替代品–迭代式开发•需求规格说明文档的内容问题域描述业务过程操作功能用户行为任务事件场景术语首字母缩写量（Volume）估计值公司背景需求规格说明文档的内容效果（解系统描述）特征通用标准特征独特特征事务更新插入删除修改信息需求特定报告（Adhocreporting）数据采集数据流数据库查询处理报表行为需求困难示例（Cornercase）错误示例（Errorcase）事件外部事件状态转移转换/转移（Transformation）需求•需求规格说明文档的内容问题接口与其他系统接口系统接口用户界面变更目的目标可行性分析架构约束文档信息文档历史版本和草案签署日期传播（Circulation）授权列表原创作者目录参考文献•模版和示例的使用0%25%50%75%100%使用标准文档结构需求表述格式规范要求使用经常使用有时使用从不使用•需求规格说明文档的描述语言0.00%25.00%50.00%75.00%100.00%自然语言半形式语言形式化语言规范要求使用经常使用有时使用从不使用实例分析（公司A）•我们公司项目的需求规格说明书，主要存在的问题：–模版不是很统一，具有很多个人的特点–没有明确的业务需求、用户需求、系统需求，这三个层次，在需求规格说明书中或多或少地涵盖前三项内容，但显得不够饱满和清晰–鉴于项目的状况，一般较少考虑硬件需求，倒是一般来说，项目上线选用的都是最新的硬件设备，成本较高。–内容的书写，自然语言居多，出现歧义、省略、模糊的机会较多，质量不高–从项目的后期来看，性能需求、约束、质量需求没有明确地分门别类地明确列出，导致后期项目中的各个业务流程还是基本可行，但是整体系统还是出现总体质量不满足的地方。实例分析（项目报告）•需求分析报告中夹杂了很多专业名词和行业名词，例如横冲、平衡等等，有些部分客户看不懂，有些部分程序员看不懂，只有自己心里明白，但这样就会造成客户和程序员理解上的问题。•另外报告中写得比较凌乱，没有把相关问题归类整合，编写目录，导致程序员零散地一条条对着开发，很多地方衔接不是很好，另外客户很多想法尤其一些重要部分在软件交付的时候会有所改变。本章小结•需求规格说明定义解决方案和需求，承载需求分析的成果•需求规格说明是一项复杂的活动，正确的文档写作要求准确的界定文档的特性•掌握文档模版的裁剪技巧和文档的写作技巧，可以帮助提高需求规格说明文档写作的能力•优秀的需求规格说明文档需要达到一定的要求思考题•什么时候建立术语表？•在需求获取和需求分析当中采用哪些手段可以保证最终需求集的完备性、一致性和正确性？