我做过C 程序员、C#程序员、Java程序员、大数据工程师、软件测试工程师，做过MFC小程序，也写过Python爬虫，但都不是很喜欢。如今，有幸做一回系统分析师。
我不清楚别人家的系统分析师是干什么的，我只说我现在是干什么的。以此回答很多小伙伴的询问，（1）你是干什么的？（2）系统分析师是干啥的？
简洁一句话：我是专注需求工程的分析师，主要是分析需求。
是不是感觉不太懂，那么我就相对地细数一下我这三个月的收获。
整个工作主要包括需求获取、需求分析、定义需求、完成需求验证、参与需求管理几个主要环节，我现在是不写代码的（点名不允许写代码，可以私下写的，哈哈）。
我这样划分，是想将需求开发和需求管理分开，采用的思想是开发库、受控库和产品库的思想。
需求分类（越详细，抽象层次越低）主要考虑：业务需求（整体全局）、用户需求（用户视角）和系统需求（计算机化）。而系统需求包括功能需求、非功能需求和设计约束。大家常见的性能需求属于肺功能需求，如界面打开速度锁遵循业界的258原则（2秒打开可接受，5秒打开可容忍，8秒打开垃圾产品）。
需求功能开发常常包含基本需求（明示，常规需求）、期望需求（隐含）和兴奋需求（多余）。而期望需求因为是隐含的，所以是项目的风险多发区域。比如：我们是开发或者是设计人员，没写某些期望需求，那么就不实现了，这种做法是不正确的。
pieces方法是衡量非功能性需求的，包括6个维度性能、信息、经济、控制、效率、服务。
需求开发主要包括需求获取、需求分析、需求定义和需求验证，这部分是我花时间最多的工作。
（1）需求获取的方式
- 用户访谈：1对1-3有代表性的用户。
- 问卷调查：用户多，无法一一访谈。
- 现场观摩：针对较为复杂的流程和操作。
- 联合需求计划（JRP）：高度组织的群体会议，各方参与，成本较高。
- 情节串联板：一系列图片，通过这些图片来讲故事。
- 收集资料：把与系统有关的、对系统开发有益的信息收集起来。
- 参加业务实践：有效地发现问题的本质和寻找解决问题的办法。
- 阅读历史文档：对收集数据性的信息较为有用。
- 抽样调查：降低成本。 样本大小=α* （可信度系数/可接受的错误）2 注：α一般取0.25，
（2）需求分析包括结构化需求分析和面向对象的需求分析。
结构化需求分析，俗称3 1视图，3个模型和1个数据字典，这个并没有被淘汰，依旧经典。
相对于结构化分析的3 1视图，面向对象的需求分析可以记做经典的4 1视图。
用例图：最终用户，需求分析模型
逻辑视图：系统分析、设计人员，类和对象
进程视图：系统集成人员。线程、进程、并发
实现视图：程序员。物理代码文件和组件
部署视图：系统和网络工程师。软件到硬件的映射
需求建模包括用例模型和分析模型。
（3）需求定义（需求规格说明书，SRS）
严格定义法
原型法
（4）需求验证
需求评审包括正式评审和非正式评审
需求测试，不是软件测试那个针对代码的测试哦！
需求管理主要包括变更管理、版本控制、需求跟踪、需求状态跟踪、需求风险管理。
需求风险管理是工作中最容易犯的问题，可以结合一下几点考虑，避免返工。
- 无足够用户参与
- 忽略了用户分类
- 用户需求的不断增加
- 模棱两可的需求
- 不必要的特性
- 过于精简的SRS
- 不准确的估算
总而言之，我现在的工作很大程度上依赖于都业务的熟练程度，以及个人对业务、系统的把控，再加上专业知识，完成当前的分析任务，产出结果物。我要强调三点：
1.沟通，高效沟通很重要，在团队内外快捷有效的沟通，并能确认沟通结果。
2.专业知识真的不是很重要，就是你根本不知道我写的这些内容，你也一样可以做好；如果有更好，毕竟方法论是一种升华。
3.业务的熟练是重点，如果能做到想熟悉自己家一样，那你基本上一个不可替代的人物。
专业的路上没有捷径，也没有绝对的对与错，我分享我这三个月的收获，希望能给那些国内的某些企业提点建议，你们能不能也设几个系统分析师的岗位，搞得我们都没法投奔你们了！
