软件工程方法课件sea02requirement

1、工程第二章. 需求02. Requirement内容安排1. 理解需求2.分析3. 需求获取4. 需求建模3Copyright © thbinCollege of Software, BUAA内容安排1. 理解需求2.分析3. 需求获取4. 需求建模4Copyright © thbinCollege of Software, BUAA需求：永远的痛5Copyright © thbinCollege of Software, BUAA需求v 需求是客户可接受的、系统必须满足的条件或具备的能力v IEEEu 用户解决或达到目的所需的条件和能力u 系统或系统部件为满足合

2、同、标准、规范或其他正式规定文档所需具有的条件和能力u 一种反映上述两条所描述的条件或能力的文档说明解决方案Copyright © thbin6College of Software, BUAA需求功能性需求v 功能性需求(Functionality)：详细描述了系统必须有能力执行的动作v 通过详细说明所期望的输入和输出条件来描述系统行为u 假定一个指定的输入，功能性需求规定了必须有什么样的输出u IPO：输入(Input, I)、输出(Output, O)、处理(Process, P)7Copyright © thbinCollege of Software, BUAA非

3、功能性需求v 非功能性需求定义了系统工作时的特性u 可用性(Usability)：人为因素(美观、易学、易用)和用户界面、用户文档、培训资料的一致性u 可靠性(Reliability)：故障频率和严重性、故障平均时间(MTTF)、故障恢复能力等u 性能(Performance)：响应时间、恢复时间和内存使用等u 可支持性(Supportability)：可扩展性、适应性和耐用性等方面的能力，以及可测试性、兼容性、可配置性等u 其它需求：设计约束、实施需求、接口需求和 物理需求等8Copyright © thbinCollege of Software, BUAA需求的重要性v 需求是

4、开发的第一个阶段，也是最重要的一个阶段u “千里之行，始于足下”v 需求探讨的系统“做什么”(What)的u 是后续分析、设计、编码、测试等各阶段的基础u 是决定项目的关键要素9Copyright © thbinCollege of Software, BUAA项目失败因素列表1. Incomplete Requirements2. Lack of User Involvement3. Lack of Resources4. Unrealistic Expectations5. Lack of Executive Support13.1%12.4%10.6%9.9%9.3%6. Ch

5、anging Requirements & Specifications 8.7%7. Lack of Planning8. Didnt Need It Any Longer9. Lack of IT Management10. Technology Illiteracy11. Others8.1%7.5%6.2%4.3%9.9%Source: Standish Group 1995，350个公司，8000个项目10Copyright © thbinCollege of Software, BUAA发现错误后，相对修复费用11Copyright © thbinCol

6、lege of Software, BUAA阶段相对修复费用需求阶段0.1 0.2设计阶段0.5编码阶段1单元测试阶段2验收测试阶段5维护阶段20需求中常见的错误12Copyright © thbinCollege of Software, BUAA错误百分比%不正确的事实49疏忽31不一致13二义性5放错位置2错误的需求导致的结果v 系统费用可能比计划的多v 系统可能比承诺的时间交付得晚v 系统可能没有满足用户的预期，而且这种不满意 可能使得系统不被采用v 一旦投入运行，维护和升级系统的费用可能会过 高v 系统可能会不可靠，而且容易产生错误和死机v 团队中IT职员的荣誉可能会因为项

7、目失败而蒙受损失，无论责任在谁，被认为是团队的错误13Copyright © thbinCollege of Software, BUAA结论v 需求中会大量的错误v 需求中的错误若未及时发现和更正，会引起开发费用增加、质量降低；严重时，会造成开发的失败v 需求中的错误究其是可以避免的需求也需要开发需求工程Copyright © thbin14College of Software, BUAA需求工程v 需求工程：以工程化的思想开发和管理软件需求u 需求开发：建立待开发的系统提供一个清晰的、一致的、精确的并且无二义模型u 需求管理：在整个系统开发过程对需求进行有效地管理，特

8、别是需求变更的管理Copyright © thbin15College of Software, BUAA需求分析过程用户要求不等于用户需求用户反复系统分析员主要工作： 发现和分析à分析技术 帮助用户从业务现状中发现系统 获取需求à 需求获取的启发技术 归纳整理用户的各种和要求，获得系统需求 文档化需求(需求建模)à 基于用例模型文档化需求 形成 分析需求 采用需求的文档化描述à 使用UML进行面向对象的分析观点表述需求（分析设计阶段）Copyright © thbin16College of Software, BUAA需求准则v

9、一致性u 需求不互相v 完整性或具有二义性u 需求描述了所有可能的系统输入和响应v 可行性u 需求可以基于可得到的足v 需要性和约束条件得到满u 需求是真正需要的并且实现了系统的目的17Copyright © thbinCollege of Software, BUAA需求准则v 正确性u 正确陈述了需求v 可跟踪性u 需求可以直接到系统的功能和特征v可性（可测试性）u 定义需求使得它们可以在测试期间展示出来18Copyright © thbinCollege of Software, BUAA内容安排1. 理解需求2.分析3. 需求获取4. 需求建模19Copyright

10、 © thbinCollege of Software, BUAA发现和分析v 用户为什么会投入大量的资金建设统？系u 用户在完成现有的业务时，事情，不能顺利的完成业务很多不如意的u 这些事情是业务吗？所在吗？是系统需求20Copyright © thbinCollege of Software, BUAA医生看病一位母亲带着孩子去看病，医生做的第一件事就是确定。这个孩子耳朵疼、发烧和流鼻涕，这是吗？透过现象看本质母亲已经给孩子吃了止痛药以减轻疼痛，但孩子没有好转。目前处理了症状（现象）而不是真正的。经过检查，医生得出结论，孩子得的是中耳炎，这是症状的根本，这才是的所在。现

11、在医生要给出治疗方案，他开出了抗生素治疗中耳炎。但在此之前医生还需要确定是否对使用的任何约束条件：孩子多大？体重多少？对什么东西过敏？可以吃药片吗？只有这些约束条件明确了，医生才能开出处方。21Copyright © thbinCollege of Software, BUAA发现和分析需要技术没经验的系统分析员经常把这些症状当作系统，结果可能会设计并实现一个没有解决真正或者可能引出新的的方案发现和分析也需要技术万物皆有因，从的结果入手，找到其次的22Copyright © thbinCollege of Software, BUAA鱼骨图v 鱼骨图(Fishbone Di

12、agram)u 1953年，(Kaoru管理大师Ishikawa)先生所提出的一种把握结果（特性）与（影响特性的要因）的极方便而有效的，故名“”u 因其形状很像鱼骨，是一种发现“根本原因”的，是一种透过现象看本质的分析方法，也既称为“鱼骨图”的特性总是受到一些因素的影响，通过头脑风暴法找出这些因素，并将它们与特性值一起，按相互关联性整理而成的层次分明、条理清楚，并标出重要因素的图形u23Copyright © thbinCollege of Software, BUAA头脑风暴v 头脑风暴法(Brain Storming, BS)u 一种通过集思广益、发挥团体智慧，从各种不同角度找出

13、法。v BS的四大原则u 严禁批评所有或要素的会议方奔放uu 多多益善u 搭便车24Copyright © thbinCollege of Software, BUAA鱼骨图的作用v 鱼骨图是一个非定量的工具，可以帮助我们找出引起u 它使我们问小组聚焦于u 能够集中于潜在的根本：的为什么会发生？使项目，而不是的症状的历的实质内容，而不是史或不同的个人观点u 以团队努力，u 辨识导致并攻克复杂难题或情况的所有，并从中找到根本u 分析导致的各之间相互25Copyright © thbinCollege of Software, BUAA鱼骨图基本结构26Copyright &#

14、169; thbinCollege of Software, BUAA大骨和要因v 要因：召开头脑风暴研讨会，在最初的草案阶段，对于鱼骨图的大骨通常采用6M。Manpower人力环境Mother-natureMachinery6M测量Measurement材料MaterialsMethods27Copyright © thbinCollege of Software, BUAA6Mv 6M常规图28Copyright © thbinCollege of Software, BUAA测环法中间/特性/结果料机人中骨、小骨和孙骨v 中骨、小骨、孙骨u 中骨事实u 小骨要为什么会

15、那样？来写u 孙骨要更进一步来追查为什么会那样？来写29Copyright © thbinCollege of Software, BUAA中骨曾孙骨小骨孙骨大骨通过头脑风暴分析要因v 头脑风暴时，让所有成员表达心声，应尽可能多而找出所有可能，而不仅限于能完全掌控或正在执行的内容。对人的动而非思想态度面着手分析u 目标集中，追求设想数量，越多越好，u 主张思考，各抒己见u 鼓励巧妙地利用和他人的设想发言，任意思考，知无不批评和评论，提倡言，言无不尽uu 与会一律平等，各种设想全部u 不强调个人成绩，以整体利益为重，创造环境u 不阻碍个人新观点，激发个人追求更好的主意30Copyrig

16、ht © thbinCollege of Software, BUAA采用5W1H分析？31Copyright © thbinCollege of Software, BUAA1.WHAT做什么去除不必要部门和动作,对象是什么？目的是什么？是否无其他可做？ 应该做些什么？2.WHERE何地改变场所或场所的组合，作业或作业者的方向是否在正确状态？为什么在那地方做？在何处做才是效率最高？3.WHEN何时改变发生的时间、时期或顺序。为何在那时做？是否在别的时间做更有利4.WHO何人人的组合或工作的分担， 重新加以检查讨论。为何要这个人做？是否有可以做的更好的人5.HOW如何做改变

17、或步骤，使所需人力减少， 熟练度较低，使用费用更低的。为何要这么做？有无其他可替代的更好的？6.WHY为何将所有的事情怀疑一遍，用WHY探讨，找到最好方案。为何现在要这么做？ 有无好的补充或改变？鱼骨图分析过程不能放到作业工程内从工程下来的空箱多需要箱子组装的零件种类较多放空箱架子大放空箱的架子和工程分离32Copyright © thbinCollege of Software, BUAA推定多是为什么推定大是为什么推定不能放是为什么推定分离是为什么事实所以放空箱的架子和工程分离所以不能放到作业工程内所以放空箱架子大所以从工程下来的空箱比较多所以需要箱子的组装零件种类多花费时间是为

18、什么中骨【事实】搬运空箱较费时间示例：送货时间太长工具/环境无太多的系统故障未听到声音送货时间太长搬运工太少不清楚谁接听人33Copyright © thbinCollege of Software, BUAA示例：开发失败34Copyright © thbinCollege of Software, BUAA内容安排1. 理解需求2.分析3. 需求获取4. 需求建模35Copyright © thbinCollege of Software, BUAA需求获取v 通过分析定义需求v 为了进而理解了，即可开始地定义需求，系统分析员必须熟练掌握收集信息的有效启发技术

19、v 需求获取的启发技术：需求获取的系统分析员用来从用户团队那里确定或提u取系统和方案的相关技术36Copyright © thbinCollege of Software, BUAA需求获取的启发技术v 1. 对现有文档、表格和数据库进行抽样v 2. 调研v 3. 观察工作环境v 4.v 5. 面谈v 6. 原型表v 7.需求计划37Copyright © thbinCollege of Software, BUAA1. 从现有文档收集事实v 第一份文档：组织结构图u 该项目的关键所有者和用户，以及他们之间的组织v 其它文档u 产生这个项目的历史文档，收集并检查描述问题的文

20、档u 描述正被研究或设计的业务功能的文档u 以前系统研究和设计文档38Copyright © thbinCollege of Software, BUAA2. 调研v 全面研究领域u 通过互联网、计算机期刊杂志和参考书等获取相关信息或实地对类似有经验的公司uu 专业社团、工作组等提供了对相关解决方案的集中39Copyright © thbinCollege of Software, BUAA3. 观察工作环境v 观察u 系统分析员或者参与到活动中，或者观察他人执行活动来了解系统u 为了获得对系统的理解，观察是一种有效的数据收集技术u 当通过其它，或者收集的数据有效性值得怀疑

21、时某方面的复杂度妨碍了用户作出清晰的解释时，使用该技术40Copyright © thbinCollege of Software, BUAA观察用户观察者-41-Copyright © thbinCollege of Software, BUAA观察误区：铁路悖论（纯属虚构）随着北京房价的急速攀升，租房价格也水涨船高，大量的“蚁族”搬离市区，到郊区租住。沙河地区就是这样一个 区域，这里住着大量的“码农”等“蚁族”群体，他们每天早上忍受着拥挤的地铁、人满为患的公交，从遥远的沙河去旗等地上班，晚上再以同样的方式返回的小屋。一些居住在沙河的“蚁族”们发现，其实在沙河和旗附近火车

22、站，每天早上路过此处的火车进城、晚由于沙河火车站和上也有从城里出来的火车路过。旗的清河火车站等级太低，这些火车都不在此停车。为此， 这些“蚁族”们发起一个签名活动，希望早上进城的火车和晚上出城的火车能够在沙河火车站和清河火车站停车上客，这 样他们可以早上坐火车从沙河到清河，晚上再从清河回到沙 河。最终有500多人在这份提案上签名，这份提案最终通过一些途径被提交到了*铁路公司，并且也在网上引起了轰动。42Copyright © thbinCollege of Software, BUAA观察误区：铁路悖论（纯属虚构）由于正值各级响应号召，开展群众路线学习的敏感时期，铁路公司非常重视，成

23、立了组论证此事，1后，“蚁族”们收到了铁路局的回信：尊敬的各位沙河居民们：感谢对公司的一贯支持。我们郑重地承诺为住在本公司铁路沿线所有人提供服务，而且愿意接受对本公司各方面反馈意见。对于的提案，委员会的成员代表在10个不同日子走访了沙河和7:00 旗车站，均在早9:00和晚17:0019:00。尽管做了十分仔细的观察，但是10次中没有1次看到有任何乘客在此等后过往的火车。我们只能得出结论，认为没有真正的必要要求火车在这两个车站停靠，因此十分抱歉地拒绝的请求。*铁路公司委员会特别说明：此案例是为了便于大家理解观察的误区，在Jeffrey L. Whitten所著的一书的“铁路的悖论”案例基础上改

24、编的而成，纯属虚构，系统分析与设计里面的内容纯属虚构，而且有很大的夸张的成分。对号入座！43Copyright © thbinCollege of Software, BUAA观察的特点v 优点u 收集的数据可能十分可靠u 能够确切地明白要做什么：复杂的任务有时难以用语言解释，只能求助于观察u 系统分析员可以进行工作度量v 缺点u 人们在被观察时通常会觉得不舒服，可能会不自觉地表现得与平常不一样u 效率较低，没有时间询问所有的点都弄清楚，把每一u 有遗漏，有些任务可能在特定时间发生u 观察只能反映当前状况，无法体现系统未来的状况44Copyright © thbinColl

25、ege of Software, BUAA4.表v表是一种具有特殊目的的文档，分析员使用它从回答者那里收集信息和观点u 由一组用来收集信息的表的类型组成v格式表：为回答者提供了很大的回答u范围，提出一个的空白区填写，回答者在后面提供u 固定格式工作选择的表：由需要从预先定义的中45Copyright © thbinCollege of Software, BUAA表的特点v 特点u 能够得到用户的回答u 可能会受到用户态度的影响，具有性u 对于大规模的，要考虑聘请经过专门培训的专业问卷来设计结果和表，并分析46Copyright © thbinCollege of Soft

26、ware, BUAA5. 面谈v 面谈u 系统分析员从个人那里通过面对面的交互收集信息u 可以一对一，也可以多对多地进行v 特点u 通过建立相互之间的友善够给用户一种主动，系统分析员能项目作出贡献的感觉，并能够获得的反馈u 面谈的系能力极大地取决于系统分析员的人际关v 面谈由三部分组成u 面谈者、被面谈者和47Copyright © thbinCollege of Software, BUAA面谈者v 礼貌u 抓紧一点，时间宝贵×u 你都不知道你在说什么u 你不懂！u 是这样，但是48Copyright © thbinCollege of Software, BU

27、AA面谈者(2)v 安全感u 事实：系统的出现可能对被面谈者不利p 头脑里的经验不再那么重要p 职位还可能会取消×u “我们来这里是为了让你”u “我们来这里是为了帮助您更方便地完成工作”49Copyright © thbinCollege of Software, BUAA面谈者(3)vu 身体前倾u 点头，嗯嗯u 不要作任何假设(偏见)u 手上做笔记(表明重视)u 适当的时候作两句总结v50Copyright © thbinCollege of Software, BUAA被面谈者v 项目关联u 关联代表必须名副其实！= 部分主管！=v 尽量不要互相干扰(单独

28、面谈)51Copyright © thbinCollege of Software, BUAAv 面谈的目标是收集信息用于创建用例和使用场景v 5W+1Hu 谁(Who)u 什么(What)u 什么时候(When)u 什么地点(Where)u 为什么(Why)u 怎么进行(How)52Copyright © thbinCollege of Software, BUAA(2)v 多问开放型u 开放式p 您对目前的工作情况不满意的是什么？u 封闭式p 会受限制出现现有信息不足以作出审断的情况？v 避免诱导性u 难道一定要在报表里包含所有这些信息吗？u您备使用这个操作码，是不是？

29、u 我觉得这一步是多余的，您看是不是这样？53Copyright © thbinCollege of Software, BUAA(3)v 避免不礼貌的u 你为什么要这么做？u 您觉得您的工作还有什么地方需要改进吗？v 用户语言、用例、类、数据库、填单u 操作者、关联u 岗位、工作、买54Copyright © thbinCollege of Software, BUAA面谈其他注意事项v 环境要适当v 在面谈前做好充分准备v 可以先做问卷再作面谈v 连续时间不应超过90分钟v 不要遗漏任何事情v 55Copyright © thbinCollege of Sof

30、tware, BUAA面谈其他注意事项v 环境要适当v 在面谈前做好充分准备v 可以先做问卷再作面谈v 连续时间不应超过90分钟v 不要遗漏任何事情v Copyright © thbin-56-College of Software, BUAA6. 原型v 原型u 是为了发现或用户需求而构造那些需求的一个小规模的，有代表性的活动或初步的工作模型u 原型应该被快速地开发出来，并只对那些没有被清楚地理解的需求建立原型v 特点u 用户和开发获得对系统可能如何工作的一致理解，并可作为给用户的一种培训机制u 有助于定义更、更可靠的需求u 用户可能基于原型的性能、可靠性和特征产生出不现实的预期u

31、 制作原型可能延长了开发进度并增加开发费用57Copyright © thbinCollege of Software, BUAA7.需求计划v需求计划(JRP)u 是一个过程，其中高度结构化的小组会议被用来分析v JRP与会者u JRP会议并定义需求一些不同的参与者和，每个参与者都被期望能够参加并主动地参与整个JRP会议u 主要：、用户和管理、抄写员、IT职员58Copyright © thbinCollege of Software, BUAAJRP会议的典型房间布局59Copyright © thbinCollege of Software, BUAA总结：

32、需求获取v 综合利用各种启发技术获取需求u 1. 了解现有文档、表格、报告和文件，能在没有同任何人接触的情况下了解很多u 2. 如果合适，观察工作中的系统u 3. 根据已经收集到的所有事实，设计并分发澄清没有完全理解的事情u 4. 进行面谈(或小组工作会议)，因为已经通过较少的用户接触收集了大部分相关事实，所有现在可以使用面表，(可考虑用JRP代替或补谈来 充面谈)和澄清最的u 5. 作为备选，对没有理解的功能需求或需要被需求构造原型的u 6. 追查到底，使用合适的或观察)事实(面谈研究技术60Copyright © thbinCollege of Software, BUAAOsb

33、ert Oglesby实例研究Osbert Oglesby，著名的艺术品经销商，需要一个产。Osbert专门品来协助他和销售绘画法国印象派，如果他认为可在他的画廊Les画家的画作，Objetsd' Orient中卖出好价钱，他实际上也会Osbert Oglesby的生意多年以来一直很Osbert开始亏损。一个管理顾问分析了生意任何画作。后来，结论是Osbert收购绘画Osbert希望这个的最高价格；然后可将该的价格太高。能够在画算出所能提供用在他的画廊中，在顾客家里或办公室看画时带上这个电脑。与大多数商人不一样，Osbert不赞成侃价。当他想要买一副格。类似地，当他卖一副即是最终价格。

34、时，他开的价就是他的最终价时，他也不讲价，他所要的价格61Copyright © thbinCollege of Software, BUAAOsbert Oglesby实例研究(续)另外，Osbert希望该能够尽可能地探测出艺术品市场的新趋势，他尤其关注用比预想高的价格某个特定画家的的，以便能够在其他人注意到这个趋势之前就买断该画家。高于Osbert在购入时的期望值时做为了能在画作的出标记，该需要保留所有购入和售出的。假设在他的计算机里这个信息可用，Osbert可能想要利用它获得关于 他的生意的额外信息。特别地，Osbert目前手工生成两个报表，一个报表显示过去一年里购入的所有画作

35、，另一个报表显示过 去一年里售出的所有画作。62Copyright © thbinCollege of Software, BUAA需求获取v 首先，通过对现有文档抽样、 调研等技术获得应用领域知识，即关于绘画和艺术市场的常识u 系统分析员品经销商了两个大型博物馆和两个艺术u 获得了有关绘画分类的相关和知识，从而建立了系统的术语表v 之后，结合已经掌握的基础知识建立系统与Osbert进行的解，并就具体面谈，明确相关的需求63Copyright © thbinCollege of Software, BUAA(相关术语)绘画三种分类v 按材质分类u 油画(基于油的)、水彩画(

36、基于水的)、其它材质(如铅笔、彩色蜡笔)v按分类u 肖像(人物)、风景(自然)、静物(静止物体)v 按质量分类u 杰作(最优秀的)、大作(曾经画过杰作的艺术家画的稍差的)、其它画作64Copyright © thbinCollege of Software, BUAA内容安排1. 理解需求2.分析3. 需求获取4. 需求建模65Copyright © thbinCollege of Software, BUAA基于用例的需求模型66Copyright © thbinCollege of Software, BUAA用例模型v 用例模型u 描述了系统的功能需求u 模

37、型化了系统对外所提供的功能(用例)和系统的外部使用环境(参与者)商品收银员退还商品67Copyright © thbinCollege of Software, BUAA概念v 参与者(执行者, Actor)u 表示v 用例进行有意义交互的任何事物u 系统为参与者所提供的目标u 表示系统执行的一系列动作，这些动作产生某个参与者可观测的结果68Copyright © thbinCollege of Software, BUAA用例建模过程v 用例建模过程u 1. 定义参与者u 2. 定义用例u 3. 构造用例图u 4. 撰写用例文档69Copyright © thb

38、inCollege of Software, BUAA1. 定义参与者v 通过以下的寻找参与者u谁提供输入u 谁接收系统的输出u 需要与其他系统连接的接口吗u 是否在预定时间自动触发的u 谁将维护系统中的信息v 使用名词或名词短语为参与者命名v Obsert Oglesby系统中的参与者？u Obsert本人（用户）70Copyright © thbinCollege of Software, BUAA2. 定义用例v 当寻找用例时，询问以下u 参与者的主要任务是什么u 参与者需要系统什么信息u 参与者提供什么信息u 系统需要通知参与者发生的变化和u 参与者需要通知系统发生的变化和v

39、 Obsert Oglesby系统中的用例？吗吗u Obsert用这个p 帮助买画p 帮助卖画p 制作报表干什么？71Copyright © thbinCollege of Software, BUAA3. 构造用例图72Copyright © thbinCollege of Software, BUAA为每个用例添加描述73Copyright © thbinCollege of Software, BUAA4. 编写用例文档v 用例图仅是对系统目标的总体描述u 有关需求的细节需要在用例文档中描述v 用例文档：更进一步的精度u 对达成用例目标所需的输入和输出进行详细的描述u 是需求文档的索引图，而用例图作为用例文档的u 进一步的精度：有层次的文档u 有很多用例文档的模板可供参考Copyright