软件需求规格说明.ppt
20130206K,第五章 软件需求规格说明,周立新 博士北京大学软件与微电子学院,20130206K,课程提纲,软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具,20130206K,内容提要,需求规格说明技术、基本方法需求规格说明模板数据字典示例分析,20130206K,软件需求规格说明,软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。,20130206K,编写软件需求规格说明的方法,可以用三种方法编写软件需求规格说明：用好的结构化和自然语言编写文本型文档。建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。,20130206K,使用软件需求规格说明的目的,客户和营销部门依赖它来了解他们所能提供的产品。项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。软件开发小组依赖它来理解他们将要开发的产品。测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和测试过程。软件维护和支持人员根据SRS了解产品的某部分是做什么的。,20130206K,使用软件需求规格说明的目的,产品发布组在SRS和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。培训人员根据SRS和用户文档编写培训材料。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。所有的参与者必须根据已通过评审的需求来安排工作以避免不必要的返工和误解。,20130206K,可读性的建议,对节、小节和单个需求的号码编排必须一致。在右边部分留下文本注释区。允许不加限制地使用空格。正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。创建目录表和索引表有助于读者寻找所需的信息。对所有图和表指定号码和标识号，并且可按号码进行查阅。使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。,20130206K,标识需求,为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以使你在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。由于要达到这一目的，用单一的项目列表是不够的，因此，我们将描述几个不同的需求标识方法，并阐明它们的优点与缺点。可以选择最适合你的方法。,20130206K,标识需求,l）序列号2）层次化编码3）层次化文本标签,20130206K,处理不完整性,有时，你觉得缺少特定需求的某些信息。在解决这个不确定性之前，可能必须与客户商议。检查与另一个系统的接口或者定义另一个需求。使用“待确定”（to be determined，TBD）符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷(gap）。通过这种方法，你可以在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。,20130206K,用户界面和软件需求规格说明,把用户界面的设计编入软件需求规格说明既有好处也有坏处。消极方面，屏幕映像和用户界面机制是解决方案（设计）的描述，而不是需求。如果你在完成了用户界面的设计之后才能确定软件需求规格说明，那么需求开发的过程将会花费很长的时间。积极方面，探索潜在的用户界面有助于你精化需求并使用户-系统的交互对用户和开发人员更具有实在性。用户界面的演示也有助于项目计划的制定和预测。,20130206K,软件需求规格说明模板,a.引言 a.1 目的 a.2 文档约定 a.3 预期的读者和阅读建议 a.4 产品的范围 a.5 参考文献b.综合描述 b.1 产品的前景 b.2 产品的功能 b.3 用户类和特征 b.4 运行环境 b.5 设计和实现上的限制 b.6 假设和依赖C.外部接口需求 C.1 用户界面 C.2 硬件接口 C.3 软件接口 C.4 通信接口,d.系统特性 d.1 说明和优先级 d.2 激励响应序列 d.3 功能需求e.其它非功能需求 e.1 性能需求 e.2 安全设施需求 e.3 安全性需求 e.4 软件质量属性 e.5 业务规则 e.6 用户文档f.其它需求 附录A：词汇表 附录B：分析模型 附录C：待确定问题的列表,20130206K,需求规格说明模板-引言,a.引言 引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。a.1 目的 对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中说明的部分或子系统。a.2 文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。列如，说明了高层需求的优先级是否可以被其所有细化的需求继承，或者每个需求陈述是否都有其自身的优先级。,20130206K,需求规格说明模板-引言,a.3 预期的读者和阅读建议 列举了软件需求规格说明所针对的不同读者，列如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。a.4 产品的范围 提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。a.5 参考文献 列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。,20130206K,需求规格说明模板-综合描述,这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。b.1 产品的前景 描述了软件需求规格说明中所定义的产品的背景和起源。b.2 产品的功能 概述了产品所具有的主要功能。其详细内容将在d中描述，所以在此只需要概略地总结，例如用列表的方法给出。,20130206K,需求规格说明模板-综合描述,b.3 用户类和特征 确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。b.4 运行环境 描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。b.5 设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。b.6 假设和依赖 列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。,20130206K,需求规格说明模板-外部接口需求,需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。c.1 用户界面 陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。c.2 硬件接口 描述系统中软件和硬件每一接口的特征。c.3 软件接口 描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具和集成的商业组件 等。c.4 通信接口 描述与产品所使用的通信功能相关的，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。,20130206K,需求规格说明模板-系统特性,d.1 说明和优先级 提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用和风险，其相对优先等级可以从1（低）到9（高）。d.2 激励/响应序列 列出输入激励（用户动作、来自外部设备的信号或其它触发器）和定义这一特性行为的系统响应序列。d.3 功能需求 列出与该特性相关的详细功能。,20130206K,需求规格说明模板-其它非功能需求,这部分列举出了所有非功能需求，而不是外部接口需求和限制。e.1 性能需求 阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。e.2 安全设施需求 详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。e.3 安全性需求 详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。,20130206K,需求规格说明模板-其它非功能需求,e.4 软件质量标准属性 详尽陈述与客户或开发人员至关重要的其产品质量特性。e.5 业务规则 列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。e.6 用户文档 列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式和标准。,20130206K,需求规格说明模板-其它需求,定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。在模板中加入与你的项目相关的新部分。如果你不需要增加其它需求，就省略这一部分。,20130206K,需求规格说明模板-附录,附录A:词汇表 定义所有必要的术语，以便读者可以正确地解释软件需求说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。附录B：分析模型 这个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。附录C:待确定问题的列表 编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。,20130206K,数据字典（1/3）,数据字典是为了描述在结构化分析过程中定义的对象的内容，而使用的一种半形式化的工具。下面是对这个重要的建模工具的定义：数据字典是所有与系统相关的数据元素的有组织的列表，并且包含了对这些数据元素的精确、严格的定义，从而使得用户和系统分析员双方对输入、输出、存储的成分甚至中间计算结果有共同的理解。简而言之，数据字典是描述数据的信息的集合，是对系统中使用的所有数据元素的定义的集合。,20130206K,数据字典（2/3）,目前，数据字典几乎总是作为“结构化分析与设计工具”（CASE工具）的一部分实现的。尽管不同工具中数据字典的形式不同，但是绝大多数数据字典都包含下列信息：名字数据、控制项、数据存储或外部实体的主要 名称。别名第一项中对象的其他名字。使用地点与方式使用数据或控制项的处理的列表，以及使用这些对象的方式(例如作为处理的输入，从处理输出，作为数据存储，作为外部实体)。内容描述描述数据或控制项内容的符号。补充信息关于数据类型、预置值、限制等的其他信息。,20130206K,数据字典（3/3）,由数据元素组成数据的方式只有下述三种基本类型：顺序 即以确定次序连接两个或多个分量。选择 即从两个或多个可能的元素中选取一个。重复 即把指定的分量重复零次或多次。因此，可以使用上述三种关系算符定义数据字典中的任何条目。,20130206K,需求示例的改进前后,“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”a.在后台任务进程启动之后，消息必须每隔 60(10）秒更新一次，并且保持连续的可见性。b.如果正在正常处理后台任务进程，那么后台任务管理器（BTM）必须显示后台任务进程已完成的百分比。c.当完成后台任务时，后台任务管理器（BTM）必须显示一个“已完成”的消息。d.如果后台任务中止执行，那么后台任务管理器（BTM）必须显示一个出错消息。,20130206K,需求示例的改进前后,“产品必须在显示和隐藏非打印字符之间进行瞬间切换”“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换”“如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。”“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到该货物的编号，系统必须显示一个出错消息并已拒绝订货。”,20130206K,需求示例的改进前后,“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错。”a.在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。b.如果在分析过程中未发现任何错误，就不必生成出错报告。,20130206K,实例分析,网上书店需求规格说明书.doc,
