http://www.4000871331.cn

需求分析的步骤以企业流程类软件为例聊聊需求

  本文侧重企业流程类软件需求,其它类产品可参考,总体分为8个步骤,按照顺序依次为:需求识别、业务流程/统计查询/接口、数据实体、角色及使用场景、系统功能、数据割接、用户体验、非功能需求。

  需求是通过需求收集获取的用户需求,选择一种业务导向的线索将零散的需求起来,进行业务、消除矛盾,并在业务基础上结合系统现状进行系统并最终形成方案和系统需求说明书的过程。

  需求人员在此步骤应该需求类别、需求复杂度和需求价值用来确定需求实施的优先级。

  需求类别包含流程类需求、统计类需求、接口类需求,一个需求可能为某一类型需求,也可能包含多类需求。

  确认需求类别后应对每类需求的数量进行初步(比如流程类需求包含几个流程、统计类需求包含几个报表、接口类需求包含几个接口)。

  一般需求受理工作量在1-5人天的需求复杂度低,工作量在5-15人天的需求复杂度中,工作量在15人天以上需求复杂度高。(工作量表示需求受理全过程需求人员需要付出的工作量)。

  需求人员收到需求后应根据收集需求内容初步需求痛点/目标、需求复杂度、业务重要程度确定需求价值,需求价值可参考如下模型:

  针对流程类需求必须进行业务流程,统计查询和接口类需求可不进行详细的流程。

  部门级流程关注脉络需要涉及哪些具体岗位、执行活动、每个活动之间的关联关系,需求分析的步骤它是需求的主线条,也是流程的主要产物。组织级流程关注宏观一般不会直接绘制,是对部门级流程的概括和抽象。岗位级流程关注每个业务活动的执行步骤属需求细节范畴,在流程阶段不要过度进入细节。

  一个流程为一个业务事件,一般是外部角色发起或系统内部主动发起(比如时间事件或状态事件),发起后会触发一系列业务活动。

  流程图中的每个泳道都必须对应到角色,每个角色对应多个业务活动。需求人员在确认业务活动时一定要活动的粒度,一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。

  比如项目输入项目名称是一个执行步骤,这个动作没有价值,项目经理查询项目信息就是一个业务活动。

  一般若某个角色业务活动工作量较大,或流程涉及高级领导,一般都会造成瓶颈,这种情况需求人员应想办法分散工作量提出流程优化。

  3.针对统计查询类需求及接口类需求,按照上述业务活动确定原则、确定角色,并明确每个角色所执行的业务活动即可。

  针对流程类需求需要各业务活动传递的数据实体,统计类需求需要统计查询条件和查询展现两类数据实体、接口类需求需要接口传递数据实体,需求分析的步骤具体包含如下内容:

  确认需要的所有数据实体,明确哪些为系统原有实体、哪些为新增实体、哪些为实体。

  实体间关系包含(1对1、1对多、多对多),另外需要数据实体变更是否需要保留版本,实体删除(逻辑删除、物理删除)是否影响其它数据实体。

  针对新增数据或数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式(人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式)。

  需要不同角色在数据权限方面的差异,若涉及纵向多级用户,要说明对于集团/省/地市用户的数据隔离。

  一般来说每个业务活动是对用户使用场景的抽象,每个业务活动可能包含多个场景,使用场景时应按照业务活动为主线逐个进行,每个业务活动时应包含如下内容:

  描述执行步骤时应使用简单的语法,主语明确语义易于理解,每个步骤不应该在任何一方(执行角色、系统)停留两部以上,重点描述如何交互。

  明确在每个业务活动下应遵循的业务规则和约束,这里一般是与业务流程相关的行为规则(比如项目周期时长超过90天必须提交二级领导审批),或与数据实体相关的数据规则(需求交接单拒收时候必须填写拒收原因,且拒收原因不能超过500字)。

  系统功能是结合系统现状和上述进一步明确实现相应用户场景的系统功能,主要还包含内容如下:

  得出实现上述业务活动对应的功能/接口列表,并明确新增功能、功能;

  实现某个业务活动需要新增或的功能对其它关联功能/接口的影响。比如请购池受理功能,可能会影响采购项目创建功能;采购项目创建功能修改一个字段取值范围,会影响项目统计和同步ES系统接口。

  需求人员应遵循界面规范,并与研发沟通确定系统交互原型。用户原型的目的,是为了帮助研发或用户更好的理解需求场景,而非真正系统实现后高保真原型。

  原型界面的名称、入口,原型间关联关系和使用角色页面内容、格式及排序方法操作要点:比如交互的信息提示、界面规则和约束(比如界面以不同颜色显示不同的校验结果)。

  很多功能/流程都会涉及数据割接,需求人员应在需求阶段明确割接规则并与研发沟通明确割接方案,常见的割接场景如下:

  主要针对业务流程、用户使用场景、系统交互原型时充分考虑用户体验,进行用户体验时可遵循如下用户体验要素模型:

  主要针对业务流程阶段、角色及使用场景阶段及系统功能阶段增加用户体验,比如流程环节是否存在瓶颈环节、整体流程效率是否高、使用场景的执行步骤是否繁杂、制定的业务规则是否会增加工作量或导致难以实施等。

  简化原则:删除不必要的功能直到不能再减少为止;组织原则:按照有意义的标准确定功能,信息展示按照业务含义进行分组;隐藏原则:隐藏非关键信息,凸显关键信息,避免分散用户注意力,但隐藏信息可通过某种线索找到;习惯原则:设计功能尽量贴近用户的操作习惯,避免用户思考;帮助原则:为用户提供适量的帮助和引导;响应原则:每次用户进行操作后,都需要给用户一个响应反馈;容错原则:必须允许用户犯错,给予用户后悔的机会;转移原则:对复杂性操作进行转移,用户擅长做的转移给用户,需求分析的步骤计算机擅长做的转移给计算机。

  主要针对系统原型界面设计增加用户体验的,主要由界面规范和系统技术架构决定。

  包含需求的可行性、健壮性、可扩展性、执行效率,可行性从以下几个方面进行:

  1.技术可行性:针对数据割接方案、系统交互实现方式与研发确认是否可行,需求人员在与研发沟通过程中需要不断积累哪些功能实现在技术层面很难支撑;

原文标题:需求分析的步骤以企业流程类软件为例聊聊需求 网址:http://www.4000871331.cn/dongmanpindao/2020/0517/10303.html

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。