Aaron
More options Sep 16 2009, 10:10 am
各位可否讨论一下在各自的团队中，需求分析要做哪些工作？
需求分析和系统分析的界限、关系是如何？
umlchina@gmail.com
More options Sep 16 2009, 10:26 am
"需求分析"，"系统分析"是过去的说法，不严谨。
参见幻灯片umlchina_01_overview
业务组织要解决什么问题？－－业务建模 范围：业务组织内部各系统之间
为了解决组织的问题，新系统应提供什么功能和性能？－－需求 范围：待开发系统的边界外部
为了提供功能，系统内部应该有什么样的业务核心机制？－－分析 范围：系统内部，仅涉及核心域
为了满足性能，系统的核心机制如何用选定技术实现？－－设计 范围：系统内部，叠加非核心域
Aaron
More options Sep 16 2009, 7:29 pm
那么"分析"是由什么角色来做？需求分析师还是技术架构师，还是both？
umlchina@gmail.com
More options Sep 17 2009, 9:44 am
业务组织要解决什么问题？－－业务建模 范围：业务组织内部各系统之间
为了解决组织的问题，新系统应提供什么功能和性能？－－需求 范围：待开发系统的边界外部
在此线之上，需求人员解决"提升软件销售"的问题，至于需求人员是否再分为BA，SE,,,视情况而定
－－－－－－最重要的角色分工线－－－－－－－－－－－－－－－－－－－－－－ －－－
在此线之下，设计人员解决"降低开发维护成本"的问题，至于设计人员是否还分分析员，设计员，视情况而定－
为了提供功能，系统内部应该有什么样的业务核心机制？－－分析 范围：系统内部，仅涉及核心域
为了满足性能，系统的核心机制如何用选定技术实现？－－设计 范围：系统内部，叠加非核心域
＝＝＝＝＝＝＝＝＝＝＝＝
根据你描述的两个职位：需求分析师还是技术架构师
"分析"是为了提炼出核心域的内涵，这样就可以随着外面业务的变化而以最小的成本变化，所以承担任务的人应该精通核心域（即所谓"业务"）的知识，按道理需求人员是具备这个知识的，但让需求人员继续做分析的工作，会产生困扰，因为：
需求要具体
设计要抽象
如果需求人员不知不觉从分析设计（抽象、复用）的角度去找需求，会更麻烦。
分析和设计着重点在于抽象和复用，架构师是具备这个思维的，但这个架构师不仅要精通某种分析设计方法（例如面向对象），还要精通核心域（即所谓"业务"）的知识。也就是说需要有一个大脑把两边串起来。
也就是说，需要一个业务架构师或者精通核心域的技术架构师。现在一说到架构师，好像就沉迷于容量、负载、部署等...这些东西不是不重要，但淘宝能用，优酷能用，腾讯能用。而淘宝、优酷、腾讯的核心域是有很大区别的。
Aaron
More options Sep 18 2009, 9:16 am
说得有理...但是需要"一个大脑把两边串起来"，这个大脑很难得到。
所以会产生一些问题，比如：要使用实现机制来实现具体需求时产生的问题只能靠开发人员自己去分析。
比如，为了提高频繁访问某些被联系对象的信息的效率，在内存缓存了这些联系对象的信息。但是一旦这些联系对象的信息发生变更（比如系统用户通过界面修改），则需要通知系统去修改内存中的相关信息。那么对"联系对象管理功能"的实现来说，每次保存需要通知内存...
这里，"联系对象管理功能"的实现其实需要将需求和实现机制结合起来考虑。这在很多时候都容易被忽略，甚至直到测试了才会发现"为什么修改了联系方式，却没有生效"。
这些问题归咎于哪个环节呢？肯定不是需求环节，那么是分析环节还是设计环节？
umlchina@gmail.com
More options Sep 18 2009, 9:38 am
“只能靠开发人员自己去分析” －－当然，否则领那么多工资干什么。开发人员要注意在扮演不同角色时把各种知识分开。
"为了提高频繁访问某些被联系对象的信息的效率，在内存缓存了这些联系对象的信息。但是一旦这些联系对象的信息发生变更" 这是一种知识；
"在阿里巴巴的业务中，订单就是一个这样的对象" 这是另外一种知识
第一种，就是设计，即非核心域的知识，和选择的框架、平台密切相关，可以叠加到淘宝，开心网，盛大的业务上
第二种，就是分析。是你的系统所处的核心域才有的知识。
或者可以这样理解，解决功能需求的，叫分析；解决非功能需求的，叫设计。

针对你上面的问题，我的回答再修改一下：分析并不关心"订单要不要缓存"
分析：类图上有许多业务类，根据对业务的理解，订单、客户、商品分别形成了自己的聚合。
设计：根据××框架的最佳实践，为了提升性能，针对聚合根对象应采用以下方式处理......
Allen
More options Sep 25 2009, 12:59 pm
潘老师，在您提到的两点：
为了提供功能，系统内部应该有什么样的业务核心机制？－－分析 范围：系统内部，仅涉及核心域
为了满足性能，系统的核心机制如何用选定技术实现？－－设计 范围：系统内部，叠加非核心域
中，我有些理解不清晰，望指点：
首先，其中有一个名词叫"业务核心机制"，这个词感觉好抽象，是否就是通常说的领域问题？即就是系统要解决什么样的业务？
另外，从这两点描述是否可以这样理解：分析针对的是系统的功能性能需求，而设计针对的则是非功能性需求？另外，这两项活动对应于MDA 中产生的模型都是PIM 吗？而PSM 模型应该算是什么活动（分析、设计或实现）中产生的呢？以及PSM 该由什么角色负责呢？
umlchina@gmail.com
More options Sep 25 2009, 2:36 pm
> 首先，其中有一个名词叫"业务核心机制"，这个词感觉好抽象，是否就是通常说的领域问题？即就是系统要解决什么样的业务？
－－对，用某种建模方式把系统需要封装的核心域知识提炼和整理出来
> 另外，从这两点描述是否可以这样理解：分析针对的是系统的功能性能需求，而设计针对的则是非功能性需求？
－－对的
另外，这两项活动对应于MDA 中产生的模型都是
> PIM 吗？而PSM 模型应该算是什么活动（分析、设计或实现）中产生的呢？以及PSM 该由什么角色负责呢？
－－分析即PIM，设计即PSM
采用核心域，非核心域描述，比业务、平台、技术等说法要严肃一些。