2014年12月8日星期一01:00

我们在芝麻街上学到的所有知识

撰写者

“其中一些事物与其他事物一样,其中一些事物并不完全相同,您能猜出哪些事物……”分析是“反方法论”,始终追求连贯,联系和意义,而不是排斥。

让我们使用一些BABOK类别来组织利益相关者“规定的要求”。在此过程中,我们将看到在对潜在解决方案建模时如何区分“需求”与需求。

假设您的利益相关者已经声明了以下内容:

  1. 我们要减少数据输入错误
  2. 我们要增加销量
  3. 我们不想更改工作或条件
  4. 我们想要易于使用
  5. 我们希望用户编写自己的报告,而不是等待IT人员
  6. 我们希望客户满意
  7. 我们想在一个软件包中购买
  8. 我们要外包所有软件配置和维护
  9. 我们希望在PC上使用大型显示器,铝制外壳和无线键盘
  10. 我们想在任何地方捕获名称和地址以及联系信息
  11. 我们希望用户拥有覆盖业务规则的自由
  12. 我们希望获得一致的高质量客户体验
  13. 我们希望系统选择最佳方法
  14. 我们不希望经理干扰我们的工作(微观管理)
  15. 我们想要更轻松,更好的调度,更少的中断
  16. 我们想摆脱旧技术
  17. 我们想要直接访问数据库
  18. 我们想要可靠性,可维护性,可扩展性和无烦恼
  19. 我们一看到就会知道,但不会很快
  20. 我们必须在发布之前构建所有内容
  21. 发布后,我们必须能够更改任何业务规则,因此我们现在不必弄清楚它们。

这是典型列表的一个很好的示例–我们忽略了诸如“我们希望需求成为我们在一次会议中写下的内容”,“我们要设计系统架构,因为我们编写检查”之类的东西,而“我们希望做到这一点”更好,更快,更便宜”。那是不同论文的不同列表。这些陈述不是作为要求提供的,而是试图规定方法论或缺乏方法论。

如此-鉴于以下的BABOK类别,去哪儿了?某些陈述会影响多个类别吗?您可以从上述内容中推断出什么以“发现”未说明的需求?

  1. 业务需求
    1. 业务目标/目的
    2. 业务需求
    3. 能力差距
    4. 解决方法
    5. 解决方案范围
    6. 商业案例(重要,重要以及为什么重要)
  2. 要求[陈述]
  3. 需求[分析/建模]
  4. 业务分析计划
  5. 解决方案要求
    1. 功能性
    2. 非功能性/品质
  6. 过渡要求

一种“故障”可能看起来像:

Arrrghh –不再!我们将继续考虑直到以后的博客。 the作者难道不明白思考很难吗?

答案是肯定的-作者知道。思维很难,大脑比身体的任何其他部分消耗更多的氧气和能量。从未想过跑50英里的人实际上相信,他们的想法与其他任何人都一样。可能会欣赏运动员而又不认为应该与运动员竞争的人,毫无疑问地相信,他们与具有实际记录的表演者一样,对创建业务解决方案也了解甚多。

您是BA的思想家,还是只是参与者–另一个讲话者?您是建模人员,还是仅仅是抄写员?您有能力解决此问题。

对于那些练习建模/技术BA技能的人,这是一个很酷的图,显示了BABOK中提到的所有需求“类型”。您可以在句子中使用每个人吗?

酷图:
费雷尔Dec8

下次-综合。

不要忘记在下面留下您的评论。

马科斯·费雷尔(Marcos Ferrer)

CBAP的Marcos Ferrer 在业务分析和信息技术应用于流程改进方面拥有20多年的经验。 1983年从芝加哥大学毕业后,费雷尔先生加入IBM在芝加哥,在那里他致力于各种行业的需求和系统实现。他最近的项目包括退伍军人管理局的工作要求,在华盛顿市郊区卫生委员会介绍BA实践,并为NRG Bowl LLC创建保龄球行业模型。 2006年11月,Marcos Ferrer是IIBA认证的首批CBAP之一。他曾担任过最近担任总统IIBA,的DC-地铁章的当选委员,并在BOK 2.0测试的写作协助。

©BA Times.com 2020

麦格雷戈徽标白色网站