软件需求工程备课-3-4.docxVIP

 PAGE \* MERGEFORMAT 15 软件需求工程备课资料 教材：毋国庆 梁正平 需求获取 需求获取过程： 3.1 确定项目的目标和范围 根据项目目标把项目相关人员定位到一个共同的和明确的方向上，并决定软件系统的范围。 软件开发商 自动售货机开发商 要求：开发自动售货管理系统 零售客户 提供：自动售货管理系统 开发：自动售货机 目标需求： ——从开发商角度 》为客户提供便利的自动售货功能； 》通过管理系统向顾客提供品种较齐全的消费品； 》吸引顾客对商品的兴趣； 》高可靠性 ——从零售商的角度 》能吸引和方便更多的顾客； 》代替人工操作，节省开支； ——从开发人员角度 》使用较为先进的开发技术和工具； 》建立高科技系统。 3.2 确定调查对象 3.3 实地收集信息 1. 步骤 ——向掌握全局的 负责人调查； —???向部门负责人调查； ——向业务人员调查； 2. 方式 ——座谈会 ——书面咨询 ——利用用例表示 3. 需求信息分类 ——目标需求 ——用例说明 ——业务规则 ——功能需求 ——性能需求 ——外部接口需求 ——限制 ——数据定义 4. 确定非功能需求 ——可靠性 ——可扩充性 ——安全性 ——互操作性 ——易使用性 ——可维护性 ——可移植性 ——可重用性 3.4 使用场景技术的需求获取 场景是指用户与软件系统实现某个目标二进行交互活动过程的描述。是对使用系统经历的描述 场景的构成 ——执行者； ——进入场景前系统状态； ——执行者的目的； ——动作和事件序列（包括正常或非正常事件流）。 场景的表示 非形式化表示形式化表示自然语言转台图结构化语言流程图图形时序图动漫画等代数描述图等 3.5 使用用例的需求获取 用例描述可发生的所有事件序列，描述软件系统与外部执行者的交互顺序，而场景描述起哄的一部分，因此，用例也可以说是场景的集合，一个场景是用例的实例。 ——例如;ATM机的用例模型和取现金的用例。 ——场景技术特点： 》把软件系统的需求信息文本化； 》有助于实现软件系统前，明确用户与软件系统的相互作用； 》可以把当前系统存在的问题作为实例记录下来； 》可以成为项目相关人员间的共同语言； 》具体、易理解； 需求分析 ——基本任务：提炼、分析和审查已收集到的需求信息，找出真正的和具体的需求； ——具体工作： 》建立系统关联图； 》构建用户接口模型； 》分析需求可行性； 》确定需求的优先级； 》需求过程； 》建立数据词典。 4.1 建立系统关联图 根据需求获取阶段确定的系统范围，用图形表示系统与外部实体间的关联。 ——关联图含义： 用于描述系统与外部实体间的界限和接口，而且明确通过接口的信息流和物质流。类似于结构化需求建模中的0层图。 ——关联图图例： 》系统表示为椭圆，内有名字； 》带标识的有向边表示系统系统与外部实体间的关系和信息（物质）流向； 》方框表示系统外部实体。 ——实例： 4.2 分析需求的可行性 ——目的：在允许的成本和性能要求以及系统范围内，分析每项需求得以实施的可能性。目的是明确风险。 ——风险类型： 》性能风险； 》安全风险； 》过程风险； 》实现技术风险； 》数据库风险； 》日程风险； 》外部接口风险； 》稳定风险。 4.3 构建用户接口原型 ——含义：一个可能的局部实现。 ——目的：对于软件开发人员或用户不能明确化的需求，通过建立相应的用户接口原型然后评估该原型，使得项目相关人员能更好理解所要解决的问题。 ——分类：抛弃型原型、进化型原型。 ——构建方法： 》纸上原型化 》人工模拟原型化 》自动原型化 4.4 确定需求的优先级别 4.5 需求建模 4.6 建立数据词典 1. 含义 是定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、格式和度量单位、精度及允许取值范围的共享数据仓库。 作用 确保软件开发人员使用统一的数据定义，提高需求分析、设计、实现和维护过程的可跟踪性。 注意 每个项目建立一个独立的数据字典，而不是每个需求出现的地方定义每个数据项。 需求建模方法与技术 5.1 软件工程中的模型 1. 模型分类 ——描述性模型：能真实和较完整地反映客观世界（如：照片）； ——规约性模型：能用于创造新事务的规约（如需求模型）； ——探测性模型：过渡性的、经常被修改而非最终决定的模型。 软件工程中的模型概念与数学和逻辑学中的模型概念不一样 软件