需求工程与需求分析PPT课件

1 第5章需求工程与需求分析 软件需求工程需求分析与建模需求获取的常用方法需求模型需求描述需求管理需求建模示例 2 5 1软件需求工程 软件需求 requirements 描述了系统应该提供的服务以及实现和运行时所受到的约束 Lethbridge定义为需求是关于系统将要完成什么工作的一段描述 它们必须经过所有相关人员的认可 其目的是彻底的解决用户的问题 需求是一段描述 意思是每个需求是相对短小简明的一段信息 表现为一个事实 它可以是一段话或用各种图表示 一组需求的集合成为需求文档 3 关于系统将要完成什么工作 需求描述了系统应当完成的任务 不描述系统将如何实现 必须经过所有相关人员的认可 意指需求必须经过评审 才能成为正式的需求 其目的是彻底的解决用户的问题 有助于解决用户的问题 该需求才有存在的价值 4 美国队每年的项目统计 2500亿开发175000个IT项目 大的200万美元 小的几十万美元 只有16 的项目按时按预算满足要求地交付 大约31 的项目在完成之前被取消 52 7 的项目成本是原来预算成本的189 主要原因 缺乏用户参与占所有项目的13 不完整的需求和规格说明17 不断改变的需求和规格说明占12 5 需求 1 2美元设计 5美元编码 10美元单元测试 20美元验收测试 50美元维护 200美元据国外统计资料表明 在典型环境下开发软件 需求分析阶段的工作量大约需占整个系统开发工作量的20 需求的代价 6 需求分析的定义 需求是指明系统必须实现什么的规格说明 它描述了系统的行为或属性 是在开发过程中对系统的约束 7 需求分析的重要性 有关软件错误的一些事实在软件生命周期中 一个错误发现得越晚 修复的费用也越高许多错误是潜伏的 并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误在需求阶段 代表性的错误为疏忽 不一致和二义性需求错误是可以被检查出来的 了解客户 最终用户 间接用户 基本概念 用户 user 是一种泛称 它可细分为 客户 customer 最终用户 theenduser 和 间接用户 或称为关系人 掏钱买软件的用户称为客户 而真正操作软件的用户叫最终用户 客户与最终用户可能是同一个人也可能不是同一个人 客户是掏钱买软件的人 所以他是 上帝 某饭店经理在解释 先有鸡还是先有蛋 这个哲学问题时 精辟地阐述了客户的地位 如果顾客先点鸡 那么就先有鸡 如果顾客先点蛋 那么就先有蛋 现代营销学之父 菲利普 科特勒所著的 市场营销导论 是这样描述客户的 客户永远是本公司的座上客 客户并不依赖我们 而我们却依赖客户 客户不是我们工作的障碍 而是我们工作的目标 我们并不因为服务于他而对他有恩 他却因为给予我们服务于他的机会而有恩于我们 客户不是我们要与之争辩和斗智的人 从未有人曾在与客户的争辩中获胜 客户是把他的欲望带给我们的人 因此我们的工作就是满足这些欲望 从而使客户和我们共同获益 与客户打交道的主要目的是 一是获取需求 二是签合同 不要把钱仍到水里 9 了解客户 最终用户 间接用户 即使最终用户不是上帝 也算是 上帝 的 亲戚 同样怠慢不得 如果项目规模比较大 那么开发方与最终用户的来往就比较多 如从最终用户那里获取详细的需求 请最终用户试验软件 对最终用户进行培训等等 公司新员工上产品培训课 有位小领导匆匆赶来作指示 隔壁班正在给电信局的员工们进行培训 他们都是上帝派来的 大家要注意形象 由于休息室空间有限 请大家自觉让位 午休时他们可以躺着睡 我们只能坐在位置上打个盹儿 重视 间接用户 千万别 大意失荆州 间接用户既不掏钱买该软件产品 也不使用该软件 但是它可能对软件产品有很大的影响 例如 财务软件开发商在把 财务软件 卖给客户之前 这个 财务软件 必须得到国家财政部的批准 否则即使该软件的功能是完美的 但却被政府认为是非法的 所以国家财政部就是所有财务软件的间接用户 它不仅不付钱给财务软件开发商 反而要收取鉴定费 手续费等 同理 市面上流通的信息安全软件 杀病毒软件必须得到国家公安部的批准 否则软件开发商被逮住后戴上 非法经营 的帽子就惨了 需求开发的主要困难与对策 知识技能问题应用域的知识是无边无际的 任何人都不可能是 万事通 俗话说 隔行如隔山 需求分析员可能是某一领域的专家 但当他接手陌生的业务时 他可能是个 无知 者 一个企业要谋求发展 不能总在做老的业务 人一生中会有许多充满挫折的 第一次 不可以逃避 当需求分析员缺乏应用域知识时 他该怎么办 首先他要有勇气做事 否则连实践的机会都没有 其次他应当赶紧补习应用域知识 不论是通过自学还是培训的方式 否则他很难与用户交流 如果可能的话 开发方最好请既懂软件又懂应用域知识的行家来帮忙 态度问题相当多的开发人员习惯于被动地对待需求开发 每当遇到麻烦 挫折时 他们会发牢骚 找出一堆用户的毛病 很多开发人员错误地以为 需求是用户的事情 不是我们的事情 我们为用户开发软件 难道用户不该告诉我们应当开发什么吗 如果用户说不清楚需求 或者经常变更需求 这类问题是用户产生的 应当由他们自己负责 用户说不清楚需求或者需求发生变更 这些都是常见的问题 并不是绝症 是人们可以设法解决的 可悲的是开发人员把这些问题当成了借口 不愿主动攻克问题 导致需求问题扩散到整个软件开发过程 产生太多的后患 软件企业的领导应当给具有错误观念的开发人员们洗脑 需求分析员的天职就是在有限的时间内获取准确而细致的用户需求 如果做不到就是失职 不要找借口 需求开发的主要困难与对策 合作关系如果需求分析员不能与用户建立良好的合作关系 那么他们在需求开发过程中会很疲惫 倘若用户不能很好地配合需求分析员 那并不表示他是个坏蛋 因为用户有他自己的想法 我回答了你们的问题 讲了该讲的 我们付钱给你们 难道还要我伺候你们不成 我还要干自己的事情 别打扰我了 你们自己想办法把活干好吧 对于一些竞标项目 在合同未签订之前的需求开发工作尤为困难 用户未必会买你的产品 他不会投入很多精力来协助你搞需求开发 需求分析员不是销售人员 他们不可能象销售人员那样通过某些手段笼络住用户就能成功 出色的需求分析员不仅要有过硬的专业知识 还要具备较强的交流 沟通能力 开发方与用户的合作关系对需求开发而言是至关重要的 对于重大的 复杂的项目 我们不能完全期望双方能够自发地建立起良好地合作关系 这样风险太大 开发方和用户方在开展需求开发之前 双方协商并撰写 用户在需求工程中的权利与义务 即以协议的方式确定合作关系 好话 和 丑话 都说在前头 这样能减少今后的摩擦 如果条件允许的话 开发方最好为用户举办关于需求工程的培训 这样的培训将使用户明白需求的重要性以及忽视需求的危害性 从而促使他们积极友善地参加需求工程中的各项活动 12 需求开发的主要困难与对策 用户在需求工程中的 权利 1 有权要求开发方派遣资质合格的需求分析员和相关人员 2 有权要求开发方采用用户熟悉的语言来描述需求 即开发方必须提供用户看得懂得需求文档 3 有权审查需求文档 并对有争议的需求作出决策 如果认为需求文档不能准确地反映用户真实的意愿 可以拒绝在需求文档上签字 4 如果用户想要变更需求 有权要求开发方对该变更将产生的影响作出真实可信的评估 以便用户决定是否变更需求 用户在需求工程中的 义务 1 以积极友善的态度与开发方人员交流 协作 尽可能地为开发方人员提供工作和生活上的便利 2 乐意接受需求分析员的采访 在不泄漏机密的前提下尽可能地回答需求分析员的问题 3 在不泄漏机密的前提下 尽可能地向需求分析员提供与需求相关的材料 4 与需求分析员共同评审需求文档 确保需求文档准确地反映用户真实的意愿 13 需求开发的主要困难与对策 用户说不清楚需求用户说不清楚需求是普遍现象 这是让开发人员头痛的大问题 有些用户真的不知道需求是什么 或者对需求只有朦胧的感觉 他当然说不清楚需求 例如开发方的营销人员水平比较高 他能够在用户不清楚自己要什么的情况下引导用户 消费 例如前些年全国各地的很多政府机构大搞网络建设 这些机构的领导和办公人员大多数不清楚网络干什么用 就让开发人员替他们设想需求吧 反正是花公家的钱 有些用户虽然心里明白想要什么 但却说不清楚需求 比如说买鞋子 我们非常了解自已的脚 但很难用语言说清楚脚的大小和形状 通常拿鞋子去试 试穿时感觉到舒服才会买鞋 需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作 否则会连累整个开发团队的 无论是什么原因导致用户说不清楚需求 需求分析员必须设法搞清楚用户真正的需求 这是需求分析员的职责 也是职业的挑战 14 需求开发的主要困难与对策 双方误解需求人们在交流的时候 经常会发生 问非所求 答非所问 的事情 有时用户会把开发人员的建议或答复给想歪了 有一个软件开发人员滔滔不绝地向用户讲解在 信息高速公路上做广告 的种种好处 用户听得津津有味 最后 心动的用户对软件开发人员说 好得很 就让我们马上行动起来吧 请您决定广告牌的尺寸和放在哪条高速公路上 我立即派人去做 而用户表达的需求 不同的开发人员可能有不同的理解 如果需求分析员误解了需求 那会导致后续的不少开发人员将错就错 白干活 就像作文写跑题了 写得再好也白搭 这类错误连高智商的外星人都不能避免 有个外星人间谍潜伏到地球刺探情报 它给上司写了一份报告 主宰地球的是车 它们喝汽油 靠四个轮子滚动前进 嗓门极大 在夜里双眼能射出强光 有趣的是 车里住着一种叫作 人 的寄生虫 这些寄生虫完全控制了车 不论是复杂的项目还是简单的项目 需求分析员和用户都有可能误解需求 所以需求确认工作 属于需求管理 必不可少 15 需求开发的主要困难与对策 开发人员写不好需求文档需求调查工作不充分 获取的需求信息太少或者太乱 以至于写不成需求文档 古时候 一书生在考试前补习 写文章 成天愁眉苦脸 其夫人甚为不解 问 相公 你写文章比我生小孩还难吗 书生长叹一声 娘子你哪里知道我的难处啊 你生小孩时肚子里有东西 可我写文章时肚子里没东西啊 所以要想写出好的需求文档 前提条件是把需求调查工作做好 开发人员写作能力比较差 虽然在调查过程中已经获得了不少需求信息 却写不出好的需求文档来 16 需求开发的主要困难与对策 用户经常变更需求需求变更通常会对项目的进度 人力资源 经费产生很大的影响 这是开发商非常畏惧的问题 如果在项目开发的初始阶段 开发人员和用户没有搞清楚需求或者搞错了需求 到了项目开发后期才将需求纠正过来 导致产品的部分内容需要重新开发 毫无疑问 这种需求变更将使项目付出额外的代价 这种损失是由于双方工作失误造成的 双方应当好好反省 认真学习需求开发和管理的方法 避免再犯相似的错误 如果由于市场变化而导致产品需求发生变更 开发商大可不必为此烦恼 应当高兴才对 倘若市场静如死水 那么开发商吃了 上一顿 就没有 下一顿 正因为市场在变化 才会产生更多商机 聪明的开发商才会有活干 有钱赚 其实需求变更并不可怕 可怕的是需求变更失去控制 导致项目混乱 所以需求变更控制是需求工程的重要活动 17 由于使用不同的方法和抽象层次来表达需求 Sommerville根据需求的来源将需求分成用户需求和系统需求两个概念 用户需求 用自然语言加图标的形式给出高层概要需求的描述 系统需求 详细描述系统要提供的服务以及所受到的约束 将成为合同的重要内容 需求的层次 18 用户需求 用户需求是为面向使用系统的用户写的 使用自然语言和图标的形式 以便用户容易理解 定义标准格式描述需求 使用主动式的前后一致的肯定语句 如 必须 应该 的区别 突出关键性的需求 如用黑体 避免计算机专业术语 19 系统需求 系统需求是更详细的需求描述 解释如何能让系统提供用户需求 是系统设计和实现的依据 为了使开发人员更好的理解 系统需求可能包括许多不同的模型 因此在需求分析阶段需要建模 20 需求的进一步分类 1 功能需求描述系统应该做什么 即必须为用户和其它系统完成的功能 提供的服务以及在特定的条件下系统的行为 例 图书馆系统的几个功能需求 1 用户能从总的数据库中查询或者是选择其中的一个子集并从中查询图书 2 系统能提供适当的浏览器供用户阅读馆藏文献 3 每次借阅能对应一个独特的识别符 可拷贝到用户帐户的常备存储区内 21 许多问题来自于需求描述的不严密 如 适当的浏览器 用户要求浏览器对所有格式的文献都支持 但这个需求没有表达清楚 开发者可能只提供一个文本格式的浏览器 需求描述应该全面一致 有时在深入分析时才能发现出来 因此需求评审是很重要的 22 2 非功能需求指那些不直接与系统具体功能相关的一类需求 如必须遵循的标准 外部界面的细节 实现的约束条件 系统可靠性 系统响应时间 存储空间等质量属性 非功能需求不仅与软件系统本身有关 还与开发过程等外界因素有关 如过程中必须遵循的原则 标准 运行平台 实现技术 编程语言和工具以及用户的限制 资金的约束 机构政策 与其他软硬件之间的互操作 安全规章 隐私权保护等等因素 两种需求互相有联系 也可能有冲突 分开描述 有利于分析各个指标 视系统的类型而定 23 3 领域需求 业务需求 来源于系统应用的领域或业务 反映了该领域的特点 如特定的计算 某一功能的约束 领域需求可能是功能的 也可能是非功能的 一般用领域专用的术语来描述 24 业务需求 项目范围文档 用户需求 用例文档 功能需求 质量属性 其他非功能需求 设计约束 需求规约 非功能需求 系统需求 需求组成的全景图 需求的组成 对系统 产品高层次的目标要求 用户使用产品必须要完成的任务 25 如一个小型超市需要一个产品的查询系统 业务需求 进货人员需要查询商品库存以便保证及时进货 收款员需要查询商品的销售价格以便结账 经理需要查询商品的销售及盈利情况 这三类用户怎样去查询系统 查询哪些信息 还需要哪些操作 这些都属于用户需求 功能需求定义了开发人员必须实现的软件功能 如必须要建立一个数据库来存储数据 需要建立不同的界面来显示信息等 以上模型中的系统需求指从整个系统的角度对该软件的要求 26 下面以一个字处理程序为例来说明需求的不同种类 业务需求可能是 用户能有效地纠正文档中的拼写错误 该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器 而对应的用户需求可能是 找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词 同时 该拼写检查器还有许多功能需求 如找到并高亮度提示错词的操作 显示提供替换词的对话框以及实现整个文档范围的替换 29 30 需求分析的步骤 需求获取获取用户对软件功能和界面的需求考虑对质量的要求 包括性能 有效性 可靠性等需求提炼 分析建模建立分析模型 常用的有 数据流图 实体关系图 控制流图 状态转换图 用例图 类对象关系及其行为图等需求描述 编写SRS编写软件规格说明书SRS SoftwareRequirementSpecification 需求验证通过验证完善SRS 确保作为软件设计和最终系统验收的依据 31 需求验证阶段 良好的需求规格说明属性 具有良好的需求规格说明属性的需求文档 具有如下的属性 1 不含糊性 如果每一个需求只有唯一的一种解释 那它是不含糊的 2 完整性 如果需求包括了功能 性能 时间响应要求 限制 接口等属性 不存在没有界定的 以为是隐含或默认而实际存在认知差异的需求 是完整的 3 可检验性 存在有限的 经济与技术都是可行的检验方法和程序 对需求的实现与否 进行检验 使得用户和组织通过该检验 确认需求被按照需求规格说明实现 4 一致性 需求作为一种要求是一致的 不存在系统内相互冲突的需求要求 5 可跟踪性 需求可追踪 6 可使用性 可为产品的各阶段 特别是维护阶段 提供充分有用的信息 32 需求获取技术 建立联合分析小组 33 系统分析员不熟悉用户业务过程 术语用户不熟悉计算机的处理过程用户业务人员 演员 主角系统分析员 导演其他开发人员 配角 建立联合分析小组 34 考察现场了解用户实际的操作环境 操作过程和操作要求 对照用户提交的问题陈述 对用户需求可以有更全面 更细致的认识 观察用户工作流程观察用户执行业务任务的过程 能够确定用户对新的应用程序可能有哪些应用 可以画一张简单的工作流程图来描绘用户什么时候拥有什么数据 以及怎样使用这些数据 35 在做调查研究时 可以采取如下的调查方式 制定调查提纲 向不同层次的用户发调查表 按用户的不同层次 分别召开调查会 了解用户对待开发系统的想法和建议 向用户领域的专家或在关键岗位上工作的人个别咨询 实地考察 跟踪现场业务流程 查阅与待开发系统有关的资料 使用各种调查工具 如数据流图 任务分解图 网络图等 36 市场调查了解市场对待开发软件有什么样的要求 了解市场上有无与待开发软件类似的系统 访问用户和用户领域的专家把从用户那里得到的信息作为重要的原始资料进行分析 访问用户领域的专家所得到的信息将有助于对用户需求的理解 37 客户访谈 前准备 确定目的 选择相关的用户 确定参加会议的项目小组成员 建立要讨论的问题和重点列表 复查有关文档和资料 确定时间 地点 进行面谈 寻找异常和错误情况 指出和记录未回答条目和未解决问题面谈后 复查笔记的准确性 完整性和可理解性 确定需要进一步澄清的问题域 38 强调两点 发现问题及时与开发人员沟通软件开发过程 用户的每个需求都要经过需求分析 将用户的需求变为软件的功能 用户的一个需求肯呢个对应软件的多个功能 这些功能经过系统设计有一次被放大了 即在需求阶段引入了1个错误的需求 在设计时这条错误的需求可能需要5 10条设计才能够展开 1条设计可能需要5 10条程序才能够实现 1条程序可能需要3 5种测试组合才能让人放心 在设计阶段 因为对需求理解的偏差 加上设计本身考虑不周可能引入新的设计错误 在编码阶段存在3部分错误 由于编程本身和对设计的理解偏差可引入新的错误错误设计的编程错误需求的编程用户必须坚持需求评审领域专家 计算机专家和最终用户一起对需求逐条进行讨论 为使用户能够积极参与讨论所有的需求文档必须有一份是使用用户能够理解的语言编写的 39 用户坚持需求评审 有助于确定需求 减少需求的变更用户坚持在需求分析阶段的后期进行需求评审 若有问题 不管使用多么先进的技术 开发出来的软件一定不能投入到实际应用中 因此用户和开发人员必须在需求的理解上意见一致 最有效的方法是 开发人员在讨论中讲述软件要达到的目标 软件涉及的范围 详细说明每条需求要做什么 并且定义每一条需求的优先级 实现的风险 预防风险的措施 用户及领域专家评价需求被理解的程度 领域专家可能会提出一些关于业务规范或改进的建议 这些建议通常对改进用户当前的工作流程是必要的 40 需求评审 需求评审是一个手工过程 需要有客户方和承包商方的人员共同参与 检查文档中的不规范之处和遗漏之处 这个评审过程可以与程序审查过程一样来管理 也可以将文档的不同部分分散到每个人 对文档进行大规模地撒网式检查 需求评审可以是正式的也可以是非正式的 非正式的评审是由承包商人员与尽可能多的系统项目相关人员讨论需求 在需求导出后 开发者可能要与项目相关人员进行多次的讨论 项目相关人员可能也没有对文档中的需求是否正确有一个肯定的答复 即使这样 还是能通过与项目相关人员交谈来发现问题 非正式评审方法包括 同级桌面检查这种方法是请某一位同事检查工作产品 轮查这种方法是同时请若干同事分别检查可交付产品 走查这种方法是可交付产品的作者向评审人员描述该产品并请求做出评论 41 正式评审 与非正式评审的临时性质形成对照的是 则遵循一个固定合理的过程 正式评审会生成一份报告 报告中指明具体材料 评审人员以及评审团队认为产品是否可以接受 主要提交对发现的错误和提出的问题的总结 正式需求评审时 开发团队要拿着需求 遍访 客户 逐条解释需求含义 评审团对应该检查需求的一致性和作为一个整体的完备性 除此之外 评审人员还要检查一下内容 可验证性描述的需求是否可实际测试 对于规格说明书中的任意需求 均存在技术和经济上可行的手段进行验证和确认 可综合性可追溯性需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来 并为后续开发和其他文档引用这些需求项提供便利 如果需求是可追溯的 那么当更改发生时 找出产品的哪些部分将受到更改的影响就更容易 评估更改对产品其他部分的影响也更容易 可适应性需求变更能否不对其他系统带来大规模的影响 42 原型化方法 在开发初期 要想得到一个完整准确的规格说明不是一件容易的事 特别是对一些大型的软件项目 用户往往对系统只有一个模糊的想法 很难完全准确地表达对系统的全面要求 软件开发者对于所要解决的应用问题认识更是模糊不清 43 随着开发工作向前推进 用户可能会产生新的要求 或因环境变化 要求系统也能随之变化 开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难 需要以改变需求来解脱困境 因此规格说明难以完善 需求的变更 以及通信中的模糊和误解 都会成为软件开发顺利推进的障碍 为解决这些问题 逐渐形成了软件系统的快速原型的概念 44 软件原型的分类 在软件开发中 原型是软件的一个早期可运行的版本 它反映最终系统的部分重要特性 探索型 目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 45 实验型 这种原型用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠 进化型 这种原型的目的不在于改进规格说明 而是将系统建造得易于变化 在改进原型的过程中 逐步将原型进化成最终系统 46 原型使用策略 废弃策略追加策略 47 建立快速原型 进行系统的分析和构造的好处 增进软件者和用户对系统服务需求的理解 使比较含糊的具有不确定性的软件需求 主要是功能 明确化 软件原型化方法提供了一种有力的学习手段 48 使用原型化方法 可以容易地确定系统的性能 确认各项主要系统服务的可应用性 确认系统设计的可行性 确认系统作为产品的结果 软件原型的最终版本 有的可以原封不动地成为产品 有的略加修改就可以成为最终系统的一个组成部分 这样有利于建成最终系统 49 5 4需求模型 结构化需求模型面向对象需求模型 52 面向对象需求模型 用例模型用例图 显示软件系统的功能用例规约 对每个功能的具体描述补充规约 全局功能和可靠性 性能等非功能性需求的文字描述 术语表 与需求相关的术语的定义 目标简要描述用例的最终任务和结果 事件流 1 说明用例是怎样启动的 即哪些角色在什么情况下启动执行用例 2 说明角色和用例之间的信息处理过程 如哪些信息是通知对方的 怎样修改和检索信息的 系统使用和修改了哪些实体等 3 说明用例在不同的条件下 可以选择执行的多种方案 4 说明用例在什么情况下才能被视作完成 完成时结果应传给角色 右图用例描述的事件流 通常 事件流包括基本流程和可选流程两部分 基本流程说明了角色和系统之间相互交互或对话的顺序 当这种交互结束时 角色便实现了预期目的 可选流程也可促进成功地完成任务 但它们代表了任务的细节或用于完成任务的途径的变化部分 在交互过程中 基本流程可以在一些决策点上分解成可选流程 然后再重新汇成一个基本流程 在上图中 Step1 5为基本流程 Step3a 3c为可选流程 特殊需求说明此用例的特殊要求 前提条件说明此用例开始执行的前提条件 如角色登录成功等 后置条件说明此用例执行结束后 结果应传给什么角色 58 学生注册课程系统 某大学准备开发一个学生课程注册系统 学生可以使用该系统查询新学期将开设的课程和讲课教师情况 选择自己要学习的课程进行登记注册 并可以查询成绩单 教师可以使用该系统查询新学期将开设的课程和选课学生情况 并可以登记成绩单 注册管理员使用该系统进行注册管理 包括维护教师信息 学生信息和课程信息等 在每个学期的开始 学生可以获得该学期的课程目录表 课程目录表列出每门课程的所有信息 诸如基本信息 教师 开课系和选课条件等 59 学生注册课程系统 新学期开始前两周为选课注册时间 在此期间学生可以选课注册 并且允许改变或取消注册申请 开学两周后注册管理员负责关闭课程注册 每个学生可以选择不超过4门课程 同时指定2门侯选课程以备主选课程未选上 每门课程最多不能超过10人 最少不能低于3人 低于3人选课的课程将被取消 一旦学生的注册过程完毕 注册系统将有关信息提交收费系统以便学生付费 如果在实际注册过程中名额已满 系统将通知学生在提交课程表之前予以更改 在学期结束时 学生可以存取系统查看电子成绩单 由于学生成绩属于敏感信息 系统必须提供必要的安全措施以防非法存取 用例 登记成绩 1 目标本用例允许教师提交上学期完成的一门或多门课程的学生成绩2 事件流基本流程当教师希望提交上学期完成的一门或多门课程的学生成绩时 本用例开始执行 1 系统显示教师上学期所教的课程列表 2 教师选择所教课程 3 系统检索出已注册此课程的学生列表 显示每个学生及其以前所给的成绩 4 对于列表中的每个学生 教师输入百分制成绩 系统记录所提供课程的学生成绩 如果教师希望跳过某个特定的学生 其相应的成绩可以为空 以后在进行填写 教师可以修改学生的成绩 62 用例 登记成绩 可选流程在主流程中 如果教师在上学期没有教课 系统将显示错误信息 教师接受此信息 用例结束 3 特殊需求无 4 前提条件用例开始之前 教师必须在系统登录成功 5 后置条件如果用例执行成功 所提供课程的学生成绩被更新 否则 系统状态不变 66 软件需求说明 引言信息描述功能描述行为描述质量保证接口描述其他描述 67 引言确定软件的目标与范围 简要介绍系统背景 概貌 软件项目约束和参考资料等信息描述给出软件系统所含的详细描述 包括信息的内容 关系 数据流向 控制流向和结构等 功能描述软件功能要求的说明 包括系统功能的划分 每个功能的处理说明 限制和控制描述等 行为描述包括对系统状态变化以及事件和动作的叙述 据此可以检查外部事件和软件内部的控制特征 68 质量保证阐明在软件交付使用前需要进行的功能测试和性能测试 并规定源程序和文档应该遵守的标准 接口描述包括系统的用户界面 硬件接口 软件接口和通信接口 其他描述系统设计和实现上的限制 系统的假设和依赖等其他需要说明的内容 69 需求文档应满足如下要求 具有准确性和一致性一个微小的错漏 后期纠正时将付出巨大的代价 无二义性双方要用它来表达对于需要计算机来解决问题的共同理解 因为不易理解的内容双方可以做出不同的解释 导致系统的失败 直观 易读和易于修改陈述语句尽量简短 表达完整 尽量使用标准的图形 表格和简单的符号来表示 70 需求规约的结构 IEEE ANSI830 1998标准为需求规约提出了以下结构 组织机构内部可以基于此标准扩展 1 引言需求文档的目的 产品范围 文档约定 参考文献等 2 综合描述产品前景 产品功能与优先级 用户特征 运行环境 设计与实现上的限制 假设和依赖性 71 3 需求描述a 功能需求b 数据需求 与功能有关的数据定义和数据关系c 性能需求 响应时间 容量要求 用户数等d 外部接口 用户界面 软硬件接口 通信接口e 设计约束 软件支持环境 报表 数据命名等f 软件质量属性 可维护性 可靠性 可移植性 可用性 安全性等等 g 其他需求 如系统进化 这一节是文档中最实质性的部分 由于在机构组织的实践中存在极大的变数 对这一节定义的标准结构可以进行选择与改编 教材P84表6 5是基于IEEE标准的需求文档的结构 4 附录 词汇表 分析模型 硬件需求 数据库需求 待定问题列表等 5 索引 72 计算机软件文档编制规范 GB T8567 2006 需求规格说明 模