选课系统的补充规约.PPTVIP

* 前置条件：把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 前置后置条件是约束，不是动作。 前置后置条件要有系统的味道。 “系统正常运行”、“网络连接正常”等放之四海皆准的约束，和所研究系统没有特定关系，不能作为前置后置条件，否则又将是一大堆正确而无用的废话。 * 需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。 * * 思考： 假设有这样的需求，在学生档案管理中，管理员经常需要做3件事：增加一条学生记录、修改一条学生记录、删除一条学生记录。如果要画出用例图，下面哪种方法更合适？ A B 用例规约--进行用例阐述 用例规约：描述每一个用例的功能，一个用例对应一个用例规约，用来描述用例的细节。 而用例图作为用例文档的总图,描述了系统所能提供的所有功能 用例规约组成 用例名称： 涉及的参与者 简要说明 事件流（基本流 备选流） 特殊需求 前置条件和后置条件 事件流 基本流：指该用例最正常的一种场景 每个步骤都需要用数字编号，以清楚地标明步骤的先后顺序。 每个步骤的主要内容用一句简短的标题来概括。 备选流：描述用例执行过程中的异常或偶尔发生的情况 事件流描述要点 一个正常的业务事件流描述 只书写“可观测”的 使用主动语句 句子必须以参与者或系统作为主语 不要涉及界面细节 要点1-只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息 要点2-主动语句 欧文从贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 要点3-以参与者或系统作主语 参与者…… 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统…… 系统显示出应找还给顾客的余额，打印付款收据 要点4-不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 特殊需求 与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。 前置条件 前置条件约束在用例开始前系统的状态 后置条件 后置条件约束用例执行后系统的状态 用例建模示例—选课用例规约 1．简要说明 本用例允许学生选本学期提供的课程。在学期开始的添加/删除时期，学生可以修改或删除选择的课程。课程目录系统提供了当前学期开设的所有课程的列表。 2．事件流 2.1基本事件流 用例开始于学生选择选课，或修改已存在的课程表。 1）系统要求学生指出要执行的操作（创建，修改或删除课程表） 2）一旦学生提供了所需要的信息，以下的一条子事件流将被执行 如果选择的是“创建课程表”，创建课程表子事件流将被执行 如果选择的是“修改课程表”，修改课程表子事件流将被执行 如果选择的是“删除课程表”，删除课程表子事件流将被执行 2.2备选事件流 。。。。。。 3．特殊需求 无 4．前置条件 本用例开始前学生必须已经登录进系统。 5．后置条件 如果用例成功，学生的课程表被创建，修改，删除。否则系统状态不变。 描述补充规约示例 选课系统的补充规约 1．目标 本文档的目的是定义选课系统的需求。本补充规约列出了不便于在用例模型的用例中获取的系统需求。它和用例模型一起记录关于系统的一整套需求。 2．范围 本补充规约适用于选课系统，除定义了在许多用例中所共有的功能性需求以外，还定义了系统的非功能性需求，例如：可靠性、可用性、性能和可支持性等。（功能性需求在用例规约中定义。） 3．参考——无 4．功能 多个用户必须能同时执行操作。 如果某个学生所建的课程表中包含人数已满的课程，必须通知这位学生。 5．可行性 桌面用户界面应与 Windows 98/2000/XP 兼容。 6．可靠性 选课系统在每周7天，每天24小时内都应是可用的。宕机的时间应少于 10%。 7．性能 。。。。。。 术语表示例 选课系统的术语表 1.??简介 这份文档是用来对一些术语进行定义的，同时将用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。通常来说，这份文档对一些数据信息进行一些定义，从而使得用例规约和其他的文档显得简洁易懂。 2.? 定义 这份术语表包含了选课系统中核心概念的定义。 课程：大学提供的某一门课。 开设课程：某一课程的具体安排情况，包括一周上课的天数、时间和教授。 课程目录：大学所开设的所有课程的完整目录。 教员：所有在此大学内任教的教授。 财务系统：用来处理收费信息的系统。 成绩：学生某门课程的成绩。 。。。。。。 5. 软件需求描述 软件需求规格说明书 Softwar