转载本文需注明出处:微信公众号EAWorld,违者必究。
需求是业务和技术的桥梁,是行业知识向数字化转换的过程,业务是需求的输入,需求是设计的输入。即需求的关键元素必须从业务分析的元素演化而来,后续的高阶设计需要从需求一脉相承,一以贯之,每个元素需要有完整的生命周期和演化链,这是一个有机的整体。以业务对象为例,在业务分析阶段,业务客体是业务对象,在需求阶段,业务客体演化为对象实体,在设计阶段,对象演化成为数据库物理模型中的表或者视图。
需求内涵包括业务需求、管理需求、运维需求、外部服务需求四部分。
需求分析师的职责是依据业务分析输出,根据业务边界,界定需求边界,根据业务参与者厘清用户,根据业务用例深化使用用例,并衍生出管理用例、运维用例、系统用例、外部服务用例,根据业务规则,规定需求的约束和限制,根据业务流程,确定工作流程、页面流、数据流,根据业务对象,定义对象实体和界面元素。
需求分析的目标已清晰,那我们如何正确打开需求分析这个迷宫呢?需要一个好的方法论指导,我们采用的是Rational提出的基于面向对象的软件工程RUP方法论,基于RUP方法论,对业务需求、管理需求、运维需求、外部服务需求和约束进行提取、组织、文档化,从而定义一份完美的需求。下面我们就像庖丁解牛一样,朝着目标,沿着正确的路径昂首前行。
在进入正题前,我们先解个惑,那就是业务和需求的差异究竟是什么,为何资深需求分析师也会将二者混淆?
首先,内涵不同,业务是政府或者企业的运营内容,比如石油勘探开发业务,普查->详查->精查->勘探钻井->开发钻井->输油->炼化的全流程的业务通过全手工的方式同样可以完成。而需求是信息化领域概念,特指业务中能够数字化、需要数字化的用户要求,再比如勘探钻井需要用钻井平台去实现,这个动作,信息化是无法完成的,因此这个动作是无法进入信息化需求的列表的。
其次,外延不同,业务的外延涵盖组织的全部社会活动,但是需求的外延是可以数字化的组织工作。
最后,主体不同,业务分析的主体是甲方或者乙方组织的行业专家或者业务专家,可以完全没有信息化的知识背景。但是需求分析的主体是甲方或者乙方具备信息化知识背景而且具备需求转化能力的分析师。
需求分析师是天才的转换器和过滤器,依据业务边界,将能够数字化同时需要数字化的业务转换为需求,而过滤掉不能数字化或者