神马文学网如何将业务需求转化成IT要求[1]
来源：百度文库 编辑：神马文学网 时间：2024/04/25 23:25:05
如何将业务需求转化成IT要求[1]
http://www.csai.cn 作者：Editorial staff 来源：IBM 2007年2月7日
作为IT架构师，很可能经常会发现自己处于进退维谷的境地—前有业务目标，后有IT系统。这两方面都具有规模大、不易改变和灵活性差的特点，制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。
业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。而这就是我们为了实现高效率而需要着手处理的问题:理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。
一个词:用例
在业务用例中，参与者是干系人，而系统则是业务本身。
用电影《毕业生》中的方式，我只想对你说一个词:用例。很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。
在Alistair Cockburn的《Writing Effective Use Cases》一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。
例如，股票交易Web站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
可以将用例用于对服务进行建模;我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。业务如何开展？客户希望业务如何开展？他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于，这些干系人如何与公司进行交互，这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程—公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司或公司的一部分建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。实现这种自动化的应用程序是采用面向服务的体系结构的应用程序，而现在正在进行SOA 实践。
记录流程
如果客户不了解业务，架构师有效定义系统要求的几率都很小。
笔者在与客户讨论新程序或开发工作时，会立即了解业务干系人是否出席或派代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”，否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率就很小。
笔者个人非常赞同开发业务场景来记录业务流程，业务场景允许在整个业务问题的上下文中标识系统要求。
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。我极力赞同使用工具来管理要求;为了达成此目的，我建议使用IBM Rational RequisitePro。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，可以召开联合应用程序开发（JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过JAD会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。
http://www.csai.cn 作者：Editorial staff 来源：IBM 2007年2月7日
作为IT架构师，很可能经常会发现自己处于进退维谷的境地—前有业务目标，后有IT系统。这两方面都具有规模大、不易改变和灵活性差的特点，制定业务目标的人员和开发系统的人员不一定了解彼此的工作内容和成果。
业务人员使用一种语言来表达他们希望实现的业务目标，而开发人员则使用另一种语言来表述技术要求。而这就是我们为了实现高效率而需要着手处理的问题:理解这两种语言并执行必要的转换，以便 IT 能反映业务的需求，并能在适当的时候对业务目标进行更改，使其与 IT 的能力相适应。这并不是一个容易完成的工作，但这正是您能够获得很大利益的原因。
一个词:用例
在业务用例中，参与者是干系人，而系统则是业务本身。
用电影《毕业生》中的方式，我只想对你说一个词:用例。很多年来，我们都将用例用于对应用程序进行建模。现在，在面向服务的体系结构 (SOA) 中，我们也使用这个概念来对业务进行建模。
在Alistair Cockburn的《Writing Effective Use Cases》一书中，他将用例定义为“系统干系人之间就系统的行为达成的协定”。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。
例如，股票交易Web站点的一个用例是“购买股票”，允许用户通过此站点购买股票。该用例描述了客户进行何种操作以及站点如何响应，而暂时忽略了站点将如何实际实现此行为。
可以将用例用于对服务进行建模;我将此称为服务用例。当用例描述服务时，参与者就是服务使用者，而系统则为服务提供者。与任何用例一样，此时的重点是服务提供者提供何种行为，而不是如何实现该行为。
还可以将用例用于对业务进行建模。在业务用例中，参与者是干系人——业务用户（如客户或员工，甚至股东或政府监管人员），而系统则是业务本身（生产产品并将其销售给客户的公司）。业务如何开展？客户希望业务如何开展？他们愿意为何种服务或产品付费？员工需要业务如何开展才能完成各自的工作？关键在于，这些干系人如何与公司进行交互，这些都是业务用例。
获得了业务用例后，则可以随后将其链接起来，以形成业务流程—公司可以执行的过程。这些流程本身就是业务用例，而复杂的业务用例可以被视为业务流程。简单地讲，这些流程显示了公司要做什么以及如何做。如前面所述，流程以及每个流程中的步骤都对服务进行建模。
通过用例将公司或公司的一部分建模为由服务组成的业务流程后，随后的目标就是尽可能多地实现流程和服务的自动化。实现这种自动化的应用程序是采用面向服务的体系结构的应用程序，而现在正在进行SOA 实践。
记录流程
如果客户不了解业务，架构师有效定义系统要求的几率都很小。
笔者在与客户讨论新程序或开发工作时，会立即了解业务干系人是否出席或派代表出席。然后，我会希望得到记录良好的业务流程和数据要求。除非相关工作是一片“处女地”，否则一定会对新应用程序或功能支持的原有的业务流程和将来的业务流程有良好的理解。不管采用哪一种方式，如果客户不了解业务，架构师有效定义系统要求的几率就很小。
笔者个人非常赞同开发业务场景来记录业务流程，业务场景允许在整个业务问题的上下文中标识系统要求。
确定了将来的业务需求后，如果能维护一份功能和非功能行式项目要求的列表，也很有好处。我极力赞同使用工具来管理要求;为了达成此目的，我建议使用IBM Rational RequisitePro。
通过使用根据业务场景确定的初始要求集，我们就可以开始定义系统行为的过程了。为此，可以召开联合应用程序开发（JAD）会议，以便根据一系列初始行式项目要求来充实将来的系统。通过JAD会议，架构师可以与干系人一起确定期望的系统行为，并以此为基础记录用例和场景。通过对用例和场景进行细化，可以帮助定义最终的一系列功能和非功能要求。
如何将业务需求转化成IT要求[1]
如何将业务需求转化成IT要求[2]
如何将业务需求转化成IT要求[3]
如何将业务需求转化成IT要求[1] - 希赛网软件工程
如何将业务需求转化成IT要求[3] - 希赛网软件工程
如何将业务需求转化成IT要求[2] - 希赛网软件工程
如何将从众效应转化为说服力？
如何将ppt转化为word_flysky
如何将只能输出摘要的RSS源转化成输出全文的RSS源
如何找需求练技术--IT学生解惑真经
如何找需求练技术--IT学生解惑真经
如何将免费社区转化为成功的商业模式
如何将思想转化为强大的习惯
如何将思想转化为强大的习惯
班主作如何转化差生1
班主作如何转化差生1
按面向用户需求业务划分 四类3G应用将风靡 — 通信产业
管理IT 驱动业务
vidoop——将你的密码转化成图片
20个将网页转化成RSS Feed的工具
20个将网页转化成RSS Feed的工具
20个将网页转化成RSS Feed的工具
第十六章 第6步：将失望转化成力量
评论：将U盘采购门归结于业务不精 是推卸责任-搜狐IT