《需求分析文档编制.pptx》由会员分享，可在线阅读，更多相关《需求分析文档编制.pptx（31页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、v需求开发的最终成果是，在客户和开发小组对所要开发的产品达成共识后，所编写的具体文档。这一文档综合了业务需求、用户需求和软件功能需求。v只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。SRS-需求开发的成果第1页/共31页v采用以下几种方式来表示软件需求：文档 用结构合理的自然语言来精心编写需求文档。图形化模型 这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或者对象类及其关系。形式化规格说明使用数学上精确的形式逻辑语言来定义需求。最常用和最普遍的方式是什么？几种表示需求结果的方式第2页/共31页 必须使用软
2、件需求规格说明的涉众有以下几类：客户、市场部和销售人员 了解他们期望得到的产品。项目经理 估计项目的进度、工作量和所需资源。开发团队 了解需要开发什么样的产品。测试小组 开发测试计划、测试用例和测试过程。实例软件维护和支持人员 了解产品每一部分的功能是什么。软件需求规格说明的涉众第3页/共31页文档编写人员根据软件需求规格说明和用户界面设计来编写用户手册和帮助屏幕。培训人员根据软件需求规格说明和用户文档来编写培训材料。公司律师要确保该需求遵守相应的法律法规。分包商根据软件需求规格说明来进行工作。软件需求规格说明的涉众第4页/共31页测试与SRS某项目突然接到测试人员发出的错误灾难的报告。结果是
3、他们测试的是老版本的软件需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作是徒劳的，因为他们一直在老版本的软件需求规格说明中寻找错误的系统行为。第5页/共31页如何使涉众各方都能够理解SRS,增强其可读性？对节、小节和单个需求的标记格式必须一致。灵活地使用各种可视强调标志(例如，黑体、下划线、斜体和不同字体)。创建目录表，也许还需要创建索引，这有助于读者找到他们所需要的信息。(Word(Word中文档结构图的使用)增强SRS可读性第6页/共31页对所有图和表进行编号，并且给出标题，根据编号来引用这些图和表。使用字处理程序的交叉引用功能来引用文档中的其他位置，而不是通过页码或
4、节号进行引用。使用超链接使读者可以跳到软件需求规格说明或其他文档的相关部分。使用合适的模板来组织所有的必要信息。第7页/共31页 6.1.1 需求的标识v好的SRS特性：完整性、一致性、可修改性和可跟踪性。v为了满足可跟踪性和可修改性的质量标准，必须对每个功能性需求进行惟一而永久的标识，可以在变更请求、修改的历史记录中引用特定的需求。v几种不同的需求标识方法1.序列号序列号 2.层次型编号层次型编号 3.层次型文本标签层次型文本标签 第8页/共31页赋予每个需求一个惟一的序列号，如赋予每个需求一个惟一的序列号，如UR-2,SRS13 UR-2,SRS13 序列号的前缀代表了需求类型序列号的前缀
5、代表了需求类型 序列号不能重用序列号不能重用 不能提供相关需求在逻辑上或层次上的区别不能提供相关需求在逻辑上或层次上的区别 需求的标识不能提供任何有关每个需求内容的信息需求的标识不能提供任何有关每个需求内容的信息 1.1.序列号序列号 第9页/共31页如果功能需求出现在软件需求规格说明中第如果功能需求出现在软件需求规格说明中第3.23.2部分，那么部分，那么它们将具有诸如它们将具有诸如3.2.4.33.2.4.3这样的标识号。这样的标识号。能提供任何需求在层次上的区别能提供任何需求在层次上的区别 标识号会扩展到多位数字标识号会扩展到多位数字 插入一个新需求以及删除或移去一个需求，序号将改变。插
6、入一个新需求以及删除或移去一个需求，序号将改变。其他地方的引用将混乱其他地方的引用将混乱 2.2.层次型编号层次型编号 对需求中主要的部分进行层次化编号，然后对于每个部对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来分中的单一功能需求用一个简短文字代码加上一个序列号来识别识别,如如“第第3.2.53.2.5部分部分编辑功能编辑功能”。第10页/共31页3.3.层次型文本标签层次型文本标签“当用户请求打印超过当用户请求打印超过1010个副本时，系统必须让用户进行确个副本时，系统必须让用户进行确认判断。认判断。”这一需求可能被标识为这一需求可能被
7、标识为PRINT.COPIES.CONFIRMPRINT.COPIES.CONFIRM,这意味着这个需求是打印功能的一部分，并且与要打印的这意味着这个需求是打印功能的一部分，并且与要打印的副本数量的设置问题有关。副本数量的设置问题有关。能提供任何需求在层次上的区别能提供任何需求在层次上的区别 结构化结构化 具有一定含义具有一定含义 不受添加、删除或移去其他需求的影响不受添加、删除或移去其他需求的影响 编写复杂编写复杂第11页/共31页第12页/共31页功能标识符举例第13页/共31页 6.1.2 处理不完整性 使用TBDTBD符号（待定）作为标准指示器来强调软件需求分析规格说明书中这些需求的缺
8、陷。把每个TBDTBD编号并创建一个TBDTBD列表，这有助于方便地跟踪每个项目。一般地说，在系统设计之前，必须解决所有的TBDTBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。(to be determined(to be determined，TBD)TBD)第14页/共31页 6.1.3 用户界面和软件需求规格说明 把用户界面的设计纳入软件需求规格说明中既有好处也有坏处。坏的方面是，屏幕图像和用户界面构架描述的是解决方案(设计)，而不是需求。好的方面是，对可能的用户界面(例如，工作原型)进行研究会使需求无论对用户还是对开发人员都是实实在在的。合理的折中方法是，将所选择
9、的用户界面概念草图或说明写入到软件需求规格说明中，而在实现时并不要求精确地遵循这些草图模型。举例：某市工业统计系统的基层数据审核界面描述 第15页/共31页第六章 需求分析文档编制6.1 软件需求规格说明6.2 软件需求规格说明模板本章结构6.3 编写原则与改进示例6.4 需求文档示例本章目标：了解软件需求的几种表达形式掌握软件需求规格说明的编写方法第16页/共31页 6.2 软件需求规格说明模板1.1.引言引言(1)(1)目标(2)(2)文档约定(3)(3)读者对象和阅读建议(4)(4)项目范围(5)(5)参考资料每个软件开发组织都应该在它们的项目中采用一种或多种标准的软件需求规格说明模板。
10、软件需求规格说明模板改写自IEEE 830IEEE 830标准，该标准还包含了许多附加的特定需求的范例:第17页/共31页 6.2 软件需求规格说明模板2.2.总体描述总体描述(1)(1)产品前景产品前景(2)(2)产品特性产品特性(3)(3)用户类及其特征用户类及其特征(4)(4)运行环境运行环境(5)(5)设计和实现上的约束设计和实现上的约束(6)(6)用户文档用户文档(7)(7)假设和依赖假设和依赖3.3.系统特性系统特性系统特性系统特性X X3.x.1 3.x.1 描述和优先级描述和优先级3.x.2 3.x.2 激励激励/响应序列响应序列3.x.3 3.x.3 功能性需求功能性需求4.
11、4.外部接口需求外部接口需求(1)(1)用户界面用户界面(2)(2)硬件接口硬件接口(3)(3)软件接口软件接口(4)(4)通信接口通信接口5.5.其他非功能性需求其他非功能性需求(1)(1)性能需求性能需求(2)(2)防护性需求防护性需求(3)(3)安全性需求安全性需求(4)(4)软件质量属性软件质量属性第18页/共31页 6.2 软件需求规格说明模板6.6.其他需求其他需求定义在此软件需求规格说明中其他部分未出现的所有定义在此软件需求规格说明中其他部分未出现的所有其他需求其他需求，例如国际化需求，例如国际化需求(货币、日期格式、语言、货币、日期格式、语言、国际规则以及文化和政治上的问题国际
12、规则以及文化和政治上的问题)及法律上的需求。及法律上的需求。7.7.附录附录A A：术语表：术语表定义读者需要了解的所有专门术语定义读者需要了解的所有专门术语(包括缩略词包括缩略词)，以，以便他们能够正确地理解软件需求规格说明。便他们能够正确地理解软件需求规格说明。8.8.附录附录B B：分析模型：分析模型它包括或指向相关的分析模型，例如：数据流图、类它包括或指向相关的分析模型，例如：数据流图、类图、状态转换图实体图、状态转换图实体关系图，关系图，面向对象的用例图面向对象的用例图。9.9.附录附录C C：待确定问题的清单：待确定问题的清单这些问题包括标记为这些问题包括标记为“待确定待确定”的需
13、求、悬而未决的的需求、悬而未决的决策、所需要的信息以及有待解决的冲突等。决策、所需要的信息以及有待解决的冲突等。详细说明请参见“需求模板说明”第19页/共31页表格方式的需求分析文档模板第20页/共31页选择合适的SRS模板不同的软件项目，使用的模板不一，但前后项目使用同一模板有利于书面的沟通和知识的传承。另一常用的SRS模板第21页/共31页第六章 需求分析文档编制6.1 软件需求规格说明6.2 软件需求规格说明模板本章结构6.3 编写原则与改进示例6.4 需求文档示例第22页/共31页 6.3 编写原则与改进示例v编写软件需求文档时，应牢记以下几点建议：使用语法、拼写和标点正确的完整句子，
14、使语句和段落简短明了。采用主动语态的表达方式。使用的术语应该与术语表中定义的术语保持一致，要特别注意同义词和近义词。将含糊不明确的顶层需求分解成足够详细的几个需求，以便充分阐明这需求，并消除歧义。第23页/共31页当以“用户将”的形式来声明需求时，无论什么时候，只要可能，就要确定特定的参与者。使用列表、数字、图和表来表示信息，使其易于阅读。强调最重要的信息。有歧义的语言会导致需求无法验证，因此，要避免使用语义不清的主观术语。6.3 编写原则与改进示例第24页/共31页需求分析文档改进示例（一）“如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。”“如果可能的话”这句话意味着什么？如
15、果不能确信是否可以递交一个请求，那么就使用“待确定”(TBD)来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败，将会发生什么情况。应该尽量避免使用不精确的词汇，例如“应当”。一些需求规格说明利用关键字之间微妙的差别如“应当”，“必须”和“可能”来指明重要性。要使用“必须”或“将要”来明确说明需求的目的并且明确指定其优先级。改进后的该需求描述如下：“系统必须根据在线的主货物编号列表,确认所输入的货物编号。如果在主列表中查不到该货物的编号，系统必须显示一个出错消息并且拒绝订货。”第二种相关需求可能记录了一种异常情况：当进行货物编号确认时，主货物编号列表不可访问。第25页/
16、共31页“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错。”“迅速”这个词具有模糊性。缺乏对出错报告内容的定义,表明该需求是不完整的。不知是如何验证这个需求的。找一些HTML的初学者，看他们利用这个报告是否可以迅速排错？还有一点不清楚的是：HTML初学者使用的是分析程序还是出错报告。并且何时生成这样的报告？使用另一种方式表述这个需求：a.在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。b.如果在分析过程中未发现任何错误，就不必生成
17、出错报告。需求分析文档改进示例（二）第26页/共31页“产品不应该提供将带来灾难性后果的查询和替换选择。”“灾难性后果”的含义是中心词。在编辑文档时，毫无目的地作出全局性变化而用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。要合理地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意外损坏时，能保护文件的内容。真正的需求是针对多级撤销能力、全局变化或其它可导致数据丢失行为确定的。需求分析文档改进示例（三）第27页/共31页第六章 需求分析文档编制6.1 软件需求规格说明6.2 软件需求规格说明模板本章结构6.3 编写原则与改进示例6.4 需求文档示例本章目标：了解软件需求的几种表达形式掌握软件需求规格说明的编写方法第28页/共31页 6.4 需求分析文档示例一.某网络公司的OA系统二.HelpDesk 系统需求规格说明书第29页/共31页第30页/共31页感谢您的观看！第31页/共31页