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