需求文档编写解析.pptVIP

SSPM/WRL * SSPM/WRL 软件工程之软件需求工程Software Engineering of Web ApplicationSoftware Requirements Engineering SEWA-SRE(需求文档编写管理) 边耐政 */33 业务与业务规则 需求工程的 7大类46个方法 建立原型、应用原型 统一建模语言UML 课程回顾 */33 编写SRS的方法 采用SRS模板 指明需求来源 为每项需求注上标记 记录业务规范 定义质量属性 课程回顾 */33 理解文档编写的重要意义和作用； 掌握编写与管理需求文档的方法； 学会使用SRS模板； 掌握数据字典的定义过程。 学习目标 */33 8.1 需求文档的作用 作为系统分析员，很可能经常会发现自己处于进退维谷的境地—前有业务目标，后有IT系统。 这两方面都具有规模大、不易改变和灵活性差的特点，制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。 如果你无法足够详细而清晰地将干系人的需求用书面的形式表达出来，则表明你没有完成捕获项目要求的任务。 8 编写需求文档 */33 8.1 需求文档的作用 前景和范围文档包含了业务需求； 用例文档包含了用户需求； 根据系统需求和用例产生功能需求文档； 根据用户需求和系统需求编写质量属性和外部接口需求等非功能需求文档。 8 编写需求文档 */33 8.2 SRS 的作用与编写原则 软件需求规格说明 ( SRS Software Requirement Specification ) 也称为功能规格说明、产品规格说明、需求文档或系统规格说明; SRS 精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件; SRS 不仅是系统测试和用户文档的基础，也是所有子项目规划、设计和编码的基础; SRS 应该尽可能完整地描述各种条件下的系统行为; SRS 不应该包括设计、构造、测试或工程管理细节。 8 编写需求文档 */33 8.2 SRS 的作用与编写原则 SRS作为产品需求的最终成果必须包括所有的需求。 任何未写入SRS中的需求，将不能作为协议的一部分，并且不能在产品中出现。 所有的参与者必须根据已通过评审的需求来安排工作，以避免不必要的返工和误解。 高质量需求文档必须具有完整性、一致性、可修改性、可跟踪性和可读性的特征。 必须在实现每个需求集之前将需求集纳入基线。 8 编写需求文档 */33 8.3 SRS 的用途 不同的读者使用SRS来达到不同的目的 客户、市场部、销售人员根据它了解他们期望的产品； 项目经理根据它估计项目的进度、工作量和所需资源； 开发团队根据它来了解需要开发什么样的产品 ； 测试小组使用SRS来制定测试计划、测试用例和测试过程； 软件维护和支持人员根据SRS了解产品的功能； 文档编写人员根据SRS和用户界面设计来编写用户手册和帮助屏幕； 培训人员根据S R S和用户文档编写培训材料； 公司律师根据SRS来确保该需求符合相关法律法规； 分包商根据SRS来进行完成分包任务。 8 编写需求文档 */33 8.4 SRS编写方法 1）需求的标识 为了保证SRS的可跟踪性和可修改性的质量标准，必须唯一标识每个软件需求。 下面的标识方法有不同的优缺点需要根据具体情况进行选择： 序列号：赋予每个需求一个唯一的序列号 层次型编码：对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。 层次型文本标签。层次化文本标签是结构化的，具有语义上的含义， 并且不受增加、删除或移动其它需求的影响。 8 编写需求文档 */33 8.4 SRS编写方法 2）处理不完整性 由于缺少特定需求的某些信息，将出现需求不确定的问题。 在解决不确定性之前，必须与客户商议、检查外部接口描述或者构建一个原型。 使用“待确定”（to be determined, TBD）符号来标记这些尚未确定的需求。 在实现一个需求集之前，必须解决所有TBD问题。 8 编写需求文档 */33 8.4 SRS编写方法 3）用户界面和 SRS 用户界面的设计编入SRS中既有好处也有坏处。 由于屏幕图像和用户界面构架是系统设计，而不是用户需求，所以对它的关注可能使需求走入歧途。也限制了开发人员的发挥。 但是探讨屏幕图像和用户界面有助于精化需求并使用户对系统有亲和感和现实感，有助于用户需求的表述和交流。 一个合理的权衡点是，在SRS中加入用户界面组件的概念草图，而在实现时并不一定要精确地遵循这些草图模型。 8 编写需求文档 */33 8.4 SRS编写方法 4）几点建议 使语句和段落简短明了； 采用主动语态的表达