第4章 需求分析

1 第4章需求分析 2020 4 8 2 第4章需求分析 软件需求分析的基本任务就是分析和综合己收集到的需求信息 其中分析的工作就在于透过现象看本质 找出这些需求信息间的内在联系和可能的矛盾 综合的工作就是去掉那些非本质的信息 找出解决矛盾的方法并建立系统的逻辑模型 2020 4 8 3 第4章需求分析 4 1建立系统关联图4 2分析需求的可行性4 3构建用户接口原型4 4确定需求的优先级别4 5实例讲解4 6需求建模4 7建立数据词典 2020 4 8 4 4 1建立系统关联图 关联图是用于描述系统与外部实体间的界限和接口的模型 也明确通过接口的信息流和物质流 目的根据需求获取阶段确定的系统范围用图形表示系统与外部实体间的关联 2020 4 8 5 4 1建立系统关联图 例 某培训中心管理信息系统的关联图 2020 4 8 6 4 2分析需求的可行性 任务分析需求可行性的基本任务是在允许的成本和性能要求 以及系统的范围内分析每项需求得以实施的可能性 2020 4 8 7 4 2分析需求的可行性 在实际需求分析中应考虑的风险类型 性能风险安全风险过程风险实现技术风险 数据库风险日程风险外部接口风险稳定风险 通常使用定性的方法如分类为 高 中 低 来评估风险 而且所需要的时间可与需求的数目成正比 2020 4 8 8 4 3构建用户接口原型 任务对于软件开发人员或用户不能明确化的需求 通过建立相应的用户接口原型然后评估该原型 使得项目相关人员能更好理解所要解决的问题 用户接口原型一个可能的局部实现 而不是整个系统 目的可使许多概念和可能发生的事更为直观明了 2020 4 8 9 4 3构建用户接口原型 两个概念抛弃型原型和进化型原型 抛弃式原型 将开发原型看做是沟通工具 永远也不会将一次式原型引入正式运行环境中 主要解决需求的不确定性 二义性 不完整性等 进化式原型 会在未来的系统中包含的原型 这种方法能够将最大量的工作投入到正式系统中 构建用户接口原型的方法纸上原型化方法 人工模拟原型化方法 自动原型化方法 2020 4 8 10 4 4确定需求的优先级别 好处帮助项目相关人员判断系统的核心需求 并有助于项目相关人员集中于重点问题的交流和协商 需求优先级之间的关联可以帮助软件开发人员决定软件体系结构 还可以帮助解决可能发生的设计冲突 根据需求的优先级权衡合理的项目范围和进度安排 预算 人力资源以及质量目标的要求 2020 4 8 11 4 4确定需求的优先级别 分配需求优先级的方法 2020 4 8 12 4 4确定需求的优先级别 在确定了所有需求的优先级后 必须把每个需求优先级记录入需求规格说明中 并可通过设置相应的字段给予标识 2020 4 8 13 确立系统基线 基线必须满足 至少对客户来说 是可以接受的 在开发团队看来 具有合理的成功可能性 2020 4 8 14 建立基线的步骤 首先是建立系统的特征表 对前面取得的特征表 我们先来对每项特征设定其优先级 接下来的工作就是要评估每项特征所需花费的工作量 还有一项因素要考虑 那就是与每项特征相关的风险 在上述工作的基础上 我们要考虑在各种因素之间寻求最佳的平衡点 2020 4 8 15 特征 feature 特征 feature 是系统为了完成涉众的一个或多个需要而提供的服务 特征范例 Leffingwell 2003 2020 4 8 16 任意复杂性的系统都可以用一个有25到99个特征的表来定义 特征的数量将决定定义的抽象级别 为管理我们设想的系统复杂度 对于任何新系统或是对已有系统的改进 能力可以被抽象到足够高的级别上 以便最多产生25到99个特征的表来定义 最好是不多于50个 2020 4 8 17 特征属性 即提供有关该条目其他信息的数据元素 利用属性对要实现的特征进行跟踪 划分优先级以及管理 例如 优先级属性可用于获取自由讨论会话中累计投票的结果 版本号属性可以用来记录我们实现特定特征的特定软件发布的版本 2020 4 8 18 特征属性 2020 4 8 19 案例 我们将要开发一个在线图书借阅系统 传统的借书方式要求读者亲自来到图书馆 这显得非常不方便 而且随着藏书的增加和读者群的增长 尤其而且大量的读者到图书馆 使得图书馆的场地不足 工作人员也不够了 所以想到借助网络 让读者通过网络借 还书 这样可以省掉大量的场地维护和工作人员成本支出 同时计算机可以方便的检索目录 让读者可以足不出户借到需要的书 为了把书送到借阅人手里 我们已经联系了快递公司 初步达成协议 由他们往返借阅人和图书馆之间 把图书送出和收回 读者在网上出示和验证借书卡 找到他们需要的书 提交申请 图书管理员确认后 就会通知快递公司来取书 当读者拿到书之后 快递公司需要把读者的签单拿回来以证明读者已经拿到了书 当然这个过程中 读者是需要付费的 还书基本上也是同样的过程 2020 4 8 20 在线图书借阅系统的特征表 2020 4 8 21 设定优先级关键的 重要的 有用的三个等级评估工作量高 中 低三档加入风险因素高 中 低三档 2020 4 8 22 缩小项目范围 确定基线 考虑在各种因素之间寻求最佳的平衡点 例如 一个特性的优先级时关键的 中等工作量 低风险的 它通常就是一个要投入资源的候选特性 下表给出了在属性的基础上划分关键特性开发优先次序的一般原则 表8 2优先排序原则 2020 4 8 23 2020 4 8 24 2020 4 8 25 2020 4 8 26 评估工作量 基线划定的要素 工作量估算估算是一种手段 其目标是追求管理上的可控性 而非估算结果的准确性 软件估算类似于财务估算活动 估算的结果是一个可控范围 需动态调整 由各个自项的值累加起来的 1 何时进行估算在需求定义阶段完成时 应安排一次估算 需求分析一阶段完成时 也应安排一次估算 每次迭代开发完成之后应该填充实际进度数据 并调整估算值 2020 4 8 27 2 估算的核心思想寻找计数单元 考虑复杂因子 如 外部查询 外部接口文件 外部输入 外部输出 内部逻辑文件皆为计数单元的复杂因子 难以估算 计数单元的寻找方法 1 需求定义阶段 可以考虑业务事件 报表类型 接口为计数单元 2 需求分析一阶段 用例可以作为计数单元 3 需求分析后阶段 可以考虑使用常用功能点 FP 或COCOMO中推荐的计数单元3 建议的估算操作要点一 分部分 分内容 二 采用权重 2020 4 8 28 划定基线 当确定了所有需求项的优先级 对其工作量做了基本的估算之后 就可以开始划定基线了 因此我们采用的是 早基线 晚冻结 的策略原则 优先级越高 安排在越早的基线中 关键 重要 有用 一般 2020 4 8 29 4 5案例 XX体检医院背景资料 背景介绍企业概括 XX体检医院椒一家只开展体检业务的专业医院 它主要针对企业 团体 VIP客户 散客三类客户提供服务 当前除了有一套记账用的财务软件之外 还没有任何信息系统 问题点 经过一段时间的经营 该医院的领导发现在管理上有两个方面存在很大的问题 希望通过信息系统来解决 一方面是预约安排不合理 销售不够高效 因为针对企业 团体的销售人员没有进行统筹安排 经常会出现一天内安排太多体检单的情况 而且也经常出现相互抢客户的问题 另一方面是物资供应存在脱节的现象 造成这个现象的原因是物资在使用的过程中没有对存量进行有效管理 当体检科室发现某类物资不足时 采购部门才开始采购 但很多供应商是无法马上提供的 这样就产生了一些时间差 2020 4 8 30 组织结构 经过第一轮的调查 需求分析人员整理出了它们的部门设置情况 以下是对各个部门职责的总结 客服中心 负责完成销售工作 为VIP和企业 团体客户安排预约时间 预约时将根据已预约情况进行调整 服务中心 负责现场的开单工作 如果已经预约则直接领取体检单即可 收费 如果企业 团体也统一通过转账付过费用 则直接盖上 收费已讫 的章 返回报告 这是统一的窗口 公司客户的体检单可以由客服中心到此代领 再寄给客户 体检科室 负责完成体检 并记录体检结果 系统上线后将实现电子化 综合科 出具诊断报告 根据体检结果给出建议 物资 完成相关物资的采购 申领 仓管工作 财务 当企业 团体采用转账形式付费时 则由财务部门负责收取 2020 4 8 31 业务范围是关键 业务大块 事件与管控点黑盒思路 灰盒思路 2020 4 8 32 范围 No 1 2020 4 8 33 划分主题域的原因 由于利用子系统的划分方法 在进行需求捕获和分析是就会发现各个子系统和模块与客户部门是交错在一起的 每个模块都需要对不同的部门进行调研 它只是一种逻辑划分 并没有很好地把业务结构体现出来 它只是采用 业务名字 管理 的形式命名的 其中业务名词实际上就是业务实体 也就是物的线索 对于大多数业务系统而言都不是最佳的分解方式 因为这些业务实体会牵涉到大量的业务流程 合适的划分是根据业务流程 也就是以 事 为线索 2020 4 8 34 主题域划分原则 1 独立性原则2 与业务部门对应关系简单原则 1对多 3 主题域之间接口简明原则 2020 4 8 35 主题域划分示例 2020 4 8 36 接口是变更的防火墙 该阶段标识的接口是服务接口 2020 4 8 37 构件与接口的关系 2020 4 8 38 体检医院管理系统的主题域划分结果图如下 2020 4 8 39 范围 No 2 2020 4 8 40 上下文关系图绘制要点 1 用矩形表示系统 写上名称 将其视为黑盒子 2 确定Customer 主题域外的员工与客户 3 逐一考虑Customer触发的事件 带出Worker行为4 逐一考虑Worker主动触发的行为5 思考时间 状态触发的事件 2020 4 8 41 通过绘制上下文关系图来确定主题域的范围步骤 首先画一个矩阵 写上系统的名称找到该系统的所有客户 考虑这些客户会发起什么事件 这些事件会引发内部工作人员的什么工作 将这些序列列出最后看看每个内部工作人员有没有一些主动发起的事件 2020 4 8 42 第一步 对主题域有哪些外部用户和内部要做些什么 2020 4 8 43 第二步 体检者除申请体检之外还有什么独立行为 如修改体检项 2020 4 8 44 第三步 寻找是否有除系统主要发起人之外的用户发起的事件 如财务部门 2020 4 8 45 第四步 考虑内部的Worker是否有主动的行为 2020 4 8 46 范围 No 3 2020 4 8 47 业务事件解析 业务事件是业务流程的触发点 标示出业务事件能够帮助我们认识业务流程 而业务流程是为了响应业务事件而触发的一系列业务活动 它通常是由于不同部门 不同岗位协作完成的 业务流程的信息掌握在中层管理人员的手里 它属于脉络信息 业务活动是一个特定的业务流程 它是一个人的活动 因此一个业务流程应该是有一个或多个业务活动组成的 而业务步骤是完成某个业务活动所需要的具体步骤 因此业务活动和业务步骤的信息是掌握在操作层人员手里 它属于细节信息 2020 4 8 48 业务事件解析 业务事件 事件vs 系统响应 交互行为客户购买商品客户提供信用卡事件到哪是个头 客户想买一件衬衫 客户开车来到购物中心 客户试穿衬衫 客户购买一件衬衫 有前提吗 触发系统吗 2020 4 8 49 体检业务子系统的业务事件列表 2020 4 8 50 体检医院管理系统 设定优先级 基线划定的基础 优先级评价组织需求项 2020 4 8 51 筛选出关键需求项 2020 4 8 52 业务优先级评价 2020 4 8 53 根据技术依赖性和项目风险调整优先级 2020 4 8 54 建立项目前景文档 项目前景文档示例 2020 4 8 55 b 2主要特性包括新产品将提供的主要特性和用户性能的列表 强调的是区别于以往产品和竞争产品的特性 可以从用户需求和功能需求中得到这些特性 2020 4 8 56 b 2主要特性 项目范围定义了所提出的解决方案的概念和适用领域 而局限性则指出产品所不包括的某些性能 澄清范围和局限性这两个概念有助于建立各风险承担者所企盼的目标 有时客户所要求的性能太奢华或者与产品所制定的范围不一致 一般客户所提出的需求超出项目的范围时就应当拒绝它 除非这些需求是很有益的 这时 可适当扩大项目范围来适应这些需求 在预算 计划 人员方面也要相应进行变化 记录这些需求以及拒绝它们的原因 以备日后重新遇到时 有记录可查 2020 4 8 57 c 1首次发行的范围总结首次发行的产品所具有的性能 描述了产品的质量特性 这些特性使产品可以为不同的客户群 customercommunity 提供预期的成果 c 2随后发行的范围如果你想象一个周期性的产品演变过程 就要指明哪一个主要特性的开发将被延期 并期待随后版本发行的日期 c 3局限性和专用性明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径 列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能 2020 4 8 58 4 6需求建模 任务导出目标系统的逻辑模型 或需求模型 以明确目标系统 做什么 的问题 需求建模需求建模就是把由文本表