系统分析经验两点

    上次做一个项目的需求分析。总结2点经验。

 

1 系统分析师的工作职责范围包含帮用户单位规划业务流程

    一般程序员、高级程序员认为，或大家的映像里面；做系统分析，主要是和用户交流，建立系统的模型，完成需求分析、需求分析文档；然后进一步，完成概要设计，再完成详细设计；然后就可以开始实际的开发；最终交付软件系统给用户。
    当时去用户单位了几天；后来总经理说，有很多工作要做，连带用户单位的业务流程，也要帮他们规划。也没太多想，只想着完成交代的工作就是了。
    当时去到用户单位。他的工作场所还没彻底建好。房间的划分基本就是它的部门。各部门需要不同的设备，配了一部分，还未完全配备和安装好。工作人员和工人还待招聘。现场还有一个系统集成方面的负责人，还有一个工程监理。各部门需要的电脑台数也要帮它规划，业务流程要帮它规划；当然它有一个基本的业务流程。我记不太清了，好像是各部门需要的人员和工人人数还需要帮它细化确定一下。还有搬运物件的方式和设备，也帮它规划。
    后来我读了几页软考用的系统分析师教材。查了一下。具体在多少页我记不清了。系统分析师的职责范围，包含帮用户单位规划业务流程这一项。
    从实际来说，到这一步，跟用户已经接触比较深入了。
    这个看具体情况，如果你在做的项目的系统分析需要帮用户单位规划业务流程，或者辅助他们规划业务流程，就做一下；否则的话也不必要。

2 需求用例图

    待开发的软件有各种不同的类型。不同类型的系统使用不同的方法描述其模型。
    对于系统的角色比较多的系统，再画一下需求用例图来描述系统的模型比较好；在需求分析文档中逐一画出系统的需求用例图。不同的角色可以进行的操作，可以操作的模块，看上去比较清晰。
   一个示例的需求用例图如下；下图有三个角色；

    很多类型的系统可能并不需要画需求用例图。