dddd

 

1．原始需求

1)提交

描述：由业务部门或者IT部门提出需求，并填写必要的数据。

操作人：主要是业务部门，其次是IT部门

数据项：需求编号、状态、标题、系统、期望上线日期、提交人员、提交日期、业务部门、需求类型、提交日期、需求描述、期望完成日期、文档需求附件（下划线为必填，斜体字为系统默认填写，其他为可选项，以下相同）

状态变更：→已提交

2）需求主管审批:

描述：经过评估并被接受的需求需要经过需求主管进行审批，需求主管根据需求开发责任人给出的开发时间和工作量进行审批，决定是否开发此需求。动作包括审批通过、审批不通过和退回。

操作人：需求提出人所在的部门领导（系统已设定）

数据项：审批时间 审批意见

状态变更：审批通过： 已提交→已需求主管审批通过

   审批不通过： 已提交→已关闭

          退回：            已评估→已退回

3)二级主管审批(只有mis系统有这一步)：

描述：经过业务主管审批通过的需求需要经过二级主管审批，二级主管参考需求开发责任人给出的开发时间和工作量以及业务主管的审批意见进行审批，决定是否开发此需求。动作包括二级主管审批通过和二级主管审批不通过。

操作人：二级主管

数据项：审批时间 审批意见

状态变更：

审批通过：已需求主管审批通过→已二级主管审批通过

审批不通过：已需求主管审批通过→已关闭

4）分配

描述：所有需求分配到各个开发组将需求分派给业务分析人来做需求拆分拆分，此环节描述：所有需求核心系统接口人分配到各个开发室，此环节指定原始需求的开发具体项目经理、需求分析人。

操作人：核心系统接口人

数据项：项目经理、需求分析人、分配时间

状态变更：已提交→已分配

操作人：IT领导

数据项：业务分析人 分配日期

状态变更：已业务主管审批通过（已二级主管审批通过）→已需求分配

5)再分配：

描述：经过分配的需求还可以被再分配，由需求处理人继续对需求进行分配，转由其他人完成此需求的开发工作。

操作人：需求处理人

数据项：项目经理、需求分析人、分配时间

状态变更：已分配→已分配

6）接受：

描述：业务分析人对分派给他的需求进行接受并拆分

操作人：业务分析人

数据项：处理描述、需求拆分

状态变更：已分配→已开发处理

7)拒绝：

描述：业务分析人员对分配到的任务拒绝接受，将该需求关闭

操作人：需求分析人

数据项：关闭日期 关闭原因

状态变更：已分配→已关闭

8)IT主管审批:

描述：经过业务领导审批的需求，IT主管根据评估意见给出的开发时间和工作量 以及业务主管的审批意见进行审批，决定是否开发此需求。动作包括审批通过和审批不通过两个。

操作人：IT部门领导（系统已设定）

数据项：审批时间 审批意见

状态变更：审批通过： 已提交→已IT主管审批

   审批不通过： 已提交→已关闭

 9）需求分析：

描述：经过IT主管审批通过后，需要需求相关负责人进行需求分析。 

主管的审批意见进行审批，决定是否开发此需求。动作包括审批通过和审批不通过两个。

操作人：IT部门领导（系统已设定）

数据项：需求分析日期  预计规模 需求代码  需求描述 需求分析文档

状态变更：审批通过： 已业务主管审批→已IT主管审批

   审批不通过： 已业务主管审批→已关闭

10)开发处理:

描述：经过业务主管和IT主管审批的需求，将进入正式的开发环节。此环节由开发责任人负责对原始需求进行拆分，根据实际需要拆分成一个或者多个IT需求（至少拆分一个），由开发责任人负责完成新IT需求的提交数据填写（具体内容见IT需求部分）。可以根据版本和模块进行拆分。

操作人：项目经理

数据项：开始处理时间、处理意见、需求拆分*

状态变更：已IT主管审批→已开发处理

11)确认需求开发完成:

描述：当所有的需求都开发完成的时候，需要需求提出人确认，同时关闭CQ流程。

操作人：提交人员

数据项：确认完成时间、确认意见

状态变更：已开发处理→已确认开发完成