本次软件工程项目是重建办公业务流程管理平台，需要在继承原370个流程基础上，还需要提供快速流程开发能力，并要求体现出流程管理的规范性，以及流程的执行力、效率、效益，最终为企业管理创新提供流程再造的能力。
在项目前期及需求分析阶段，开发人员致力于“降低成本”，以最小的代价完成项目，其可预见性的软件产品是经过系统平台升级的，并经过改良的第二个办公业务流程管理平台。按客户验收要求，“只能打60分，是不能给予验收”。
在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解得到重复代码。如果从设计出发找需求，会得到一大堆假的“需求”。
拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳…。但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”，人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、
“神经子系统”“内分泌子系统”…..。
首先，回顾我们常用的软件需求开发过程。
1. 需求分析定义
在软件工程中，需求分析指的是在建立一个新的或改变一个现存的信息系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后，他们才能够分析和寻求新系统的解决方法。需求分析阶段的任务是确定软件系统功能。
2. 需求开发过程综述
（1）目的：
用以指导项目组客观、准确地识别和文档化客户及相关干系人的需求，并在已确认的用户需求基础上完成软件需求的分析及文档化工作。
（2）角色职责：
客户经理：协助项目经理与顾客的沟通与需求的获取。
项目经理：.负责全程的需求标识的管理。及时与顾客进行沟通，了解客户需求，审查客户所提需求，协调对需求标识的评审。
项目成员（需求开发人员）：协助项目经理完成客户需求的收集；将收集的需求，通过分析、整理制作成文档；协助项目经理审查收集到的顾客的初始需求。
客户代表：尽可能完整、准确的提出系统所要求的目标、功能、性能、技术、界面、安全水平等需求。并对需求评审结果进行确认。
用户代表：为客户代表和项目成员提供业务需求，并对需求结果进行确认。
（3）输入：
所有与客户需求相关的材料。
（4）输出：
原始需求索引表；
用户需求说明书；
需求获取分析表；
需求用例文档；
软件需求说明书
（5）开发过程
图1
3、关键开发活动
（1）“确认用户需求”活动中，不仅要形成用户需求说明书（格式不限，只要求把需求描述清楚），还必须有用户方客户代表签字确认，最好内附用户代表确认签字。
（2）“评审需求文档”活动，不能省略，需要系统分析、设计人员全面了解、分析需求，确认需求分析描述清楚，并且不超出范围。
（3）“创建及发布需求基线”活动，通过此活动固化了需求，并要求创建需求跟踪矩阵。
接着，我们再重点说需求分析。
需求分析借助UML建模工具EA，通过EA进行业务建模和开发需求用例和对象模型。此段重点关注业务建模实践过程，回答办公业务流程平台要做什么？
1、业务建模
在业务建模用例图上表述出370个业务流程是不合适的，这些流程的功能基本是一致的。流程业务通常情况是这样的，工作人员填写业务申请单（填写表单），并准备好相关资料（添加附件），把业务申请单和资料打包（保存）后，送出传递给流程下一环节审批人办理。
既然要管理370个流程，而且是不停在变的流程，那么从流程建模开始，到流程上线应用、执行流程实例，再到对监控及分析流程，对流程的使用情况进行绩效管理。这样，流程再造是永恒的主题，这也是回答办公流程平台要做什么。至于快速开发流程、监控分析流程，以及体现执行力、效率等管理目标都是属于表面只管需求。业务建模是要通过信息化管理模型来提供有效流程再造的支撑，以此达到管理创新的终极目标。
图2
通过上述分析，业务建模就不必画具体流程用例，也不必画具体报表用例…。下图3才是办公业务流程平台系统核心业务模型用例，而资费审批流程、中层领导请假流程…，仅仅是流程模型【注：为图3中监管流程（定义）信息】不同。
图3
业务模型应用简单场景如下：
（1）通过快速开发流程（建模流程）用例，开发资费审批流程模型，并发布流程；
（2）申请、审批流程用例，是执行流程实例；
……。
2、系统平台建模
此系统平台用例，本不应该放在此处，但是，由于此项目的特殊性，建设目标之一是搭建办公能力平台，所以，就出现了系统平台建模，也可以看作系统用例。概念有些模糊，姑且先放在这儿。
图4
为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后发现问题，自然要改。“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变化，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求变化会消于无形。
业务用例是组织的、而不是组织内某个系统的用例。组织的用例不会因为某个人肉系统或电脑系统的存在或消失而改变。
综上所述，软件项目需求开发过程中，业务建模是非常重要的活动，直接关系到项目的成败。而本项目实质是用户化的BPM，例如解决人员跨组织问题，以及提供流程业务数据统计支撑需求等。
|
