《业务架构视图-需求开发与UML用例建模》由会员分享，可在线阅读，更多相关《业务架构视图-需求开发与UML用例建模（107页珍藏版）》请在金锄头文库上搜索。
1、业务架构视图-需求开发与UML用例建模内容提要Redq:如何有效地开发需求UML:用例建模全貌UML:用例的执行者友UML:用例么UML:用例模型UML:用例规格么UML:用例结构Rea:用例之外。Req:需求开发中的信息收集Reaq:测试用例与用例疗广焱东不发需下需求开发中的常见问题“需求规格罗列了一大堆功能规格说明,但看不到用户需要它们的理由,用户的真正需要并没有得到如实地反映;“到了开发后期才发现理解错用户需求的实际含义,返工最后演变成一场灾难;“开发人员拿到一个功能列表,然后要么对着它发呆,要么开始玩猜守谜的游戏,揣摩用户将会在什么情形下,如何来使用这个功能,最后想象出一个功能的执行步
2、骤来开发;“编码人员不知道自己做的事与需求到底有什么关系,最后只能将一个让用户目瞪口呆的系统发布给客户;“测试人员拿到一份看起来很完美的需求规格,但是却在编写测试用例时感到无从下手,因为它既没有给出执行一个功能的前提条件,也无执行的具体步骤,执行后的结果更4“是一头雾水;软件需求表达的要求v软件需求规格必须如实地反映用户的真正需要,这是保证目标系统最终成功熹邛寸给客户的首要前提(做正确的)3v软件需求规格必须能够在开发过程的各个环节中被不同的角色方便地使用,这是确保系统的实施总是符合需求规格要求的必要条件(正确地去做)。6软件需求的定义“IBBB对需求的定义为:(1)用户解决问题或达到目标所需
3、的条件或能力(Capability)。一一针对用户(2)系统或系统部件要满足合同、标准、规范或其它正我规定文档所需具有的条件或能力。一一针对开发者“需求定义的过程:明确问题,给出目标系统的上下文一指定目标,勾画目标系统的范围一定义系统,规格化目标系统的行为、特性或属性。如何理解软件需求软件需求不能脱离目标系统的上下文:对系统行为、特性或属性的规格说明不是需求的全部,因为它还要依赖上下文一一系统、外部系统与用户一道才能完成任务。北帕灵一用户目标系统需求的层次组织机构或客户对系统、产品的高尿次的目标描选了用户完成业务任务而对产品的要求定义了开发人员必须实现的系统的功能与性能示例:字处理器s业务上下文一用户能有效的纠正文档中的错误。“用户需要一找出文档中的拼写错误并通过一个提供替换项列表来提供替换拼错的词。“s系统需求一系统对文档中的文字进行拼写检查。如果发生错误,则提供词条替换列表,以供选择。“10软件需求的内容v软件需求大致包含功能性Functional1需求与Non-Functional非功能性需求(诸如性能、可靠性等)两类;*其中功能性需求的实质是目标系统与用户或外部系统间的交互而体现出的一种外在行为;*非功能性需求则蕴吴于这些外在行为中,体现为行为的空间(执行的环境和数量,例如PDA上的浏览器、并发用户数)和时间(性能,例如执行的延迟时间)等附属特性;
