需求分析常见知识点合集.docx

《需求分析师常见知识合集》工具类软件项目需求与设计案例——计时工具系统对于类似word之类的工具类软件，应该如何获取它的需求呢？五维三级需求法应该如何应用呢？该案例以一步一动的方式详细剖析了需求的过程......计时工具系统案例与需求方法简介计时工具系统案例与需求方法简介某软件公司的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。以下是公司领导之间的对话：市场部经理：研发部承诺本月实现的产品功能又没按期交付，这已经是第三回了。这导致产品上市时间总是不确定，给我们市场和营销人员带来很大的麻烦，你们知道吗？研发部经理：针对这个问题我们花了很多时间来解决，但一直收效不好。我也在积极想办法，我用过FP模型、WBS方法等....总经理：（打断研发经理的话）这问题靠我们自己闭门造车是不行了，看看能不能借助外脑？我看这样吧，由你（研发经理）负责，请一个这方面的顾问，如果有必要还可以采用信息化手段，采购或研发个工具软件，帮助我们更好地解决该问题....这就产生了一个项目机会，那么对于这类件项目，又该如何抓需求呢？五维三级需求法“五维三级需求法”即从广度（五维：因、人、事、物、规）和深度（三级：业务和用户需求、产品需求、功能需求）两个视角分解复杂问题，展开需求分析，获取高质量的需求结果。1．分析软件的“因”。任何信息系统项目建设的出发点一定是要解决业务中存在的问题，以期达到某种建设目标，所以应将“因”维（分析业务问题，确定项目目标）作为软件需求分析的起点。2．分析软件的“人、事、物、规”。围绕达成“因（项目目标）”的几个关键业务场景，通过“人”维了解组织结构、清晰岗位职责，通过“事”维区分业务场景、梳理业务流程，通过“物”维收集单证报表、获取数据求，通过“规”维分析软件相关系统、明确时间节点等限制条件。3．形成软件的“业务和用户需求”。在“因、人、事、物”分析的基础上，分别描述核心业务流程和收集用户需求。（1）对于存在业务变革的项目，讨论重点在核心业务流程，主要关注业务现在具有怎样的组织、执行怎样的流程、传输怎样的单证，并探讨未来会怎么办。为了保证需求效果，讨论可一次围绕一个特定业务场景展开，事先草拟好业务流程图当“靶子”，并尽量邀请高层参加。对于如体制调整等一些短期内无法决策的问题，也应标识出几种可能的变化情况，为后续的系统架构设计指明应考虑适应的变化点。（2）对于不存在业务变革的项目（如工具软件、局部技术改造类项目），重点在于收集用户提出的各类意见（常以解决方案的形式出现），并挖掘意见背后的真正问题，结合行业最佳实践协商解决方案，形成用户期待软件具有的特性列表。4．形成软件的“产品（软件）需求”。任何软件或产品都必须在“时间、成本”等约束下，对“质量和功能”进行折衷，业务和用户需求中的很多事并不一定都要纳入系统中去实现。因此，在产品（软件）需求阶段重点是在“规”的约束下，协商确定现阶段产品的项目范围和开发任务，如现阶段“到底有哪些岗位使用该系统，用户能够使用系统完成哪些工作，系统怎样帮助用户完成这些工作（自动化程度有多高）？”等等。本阶段形成的文档名为《用户需求分析说明》，主要采用用例模型来描述。5．形成软件的“功能需求（需求规格说明）”。这阶段主要是对产品需求中的每个用例（即用户使用系统完成的一项工作），由系统开发者和具体用户协商，按用例优先级逐个确定其操作界面、操作步骤等，这层次的工作将为具体的物流信息系统开发提供完备的需求规格说明。本阶段形成的文档名为《用户需求规格说明》，一般采用用例细化描述文档和补充规约（非功能性需求等）来表示。注：业务、用户、产品等需求的概念和区别参考推荐阅读16. 需要特别说明两点：一是为了化解需求复杂度，“五维三级需求法”可逐个业务场景的迭代应用。比如，在应用时可针对一个业务场景，完成一次需求分析过程。待完成该业务场景下的业务需求、产品需求和功能需求后，再着手另一个业务场景下的需求分析过程；二是五维度中的核心是“因”。只有准确把握好“因”，才能把握住“人、事、物、规”的变化趋势。由于“因”常常由上一层次目标所决定，所以软件建设，需将建设目标纳入企业信息化顶层设计的背景中通盘考虑，才能准确到位。从“因”维确定用户痛点和协商解决方案获取甲方用户需求时，首先应访谈谁？怎么约？怎么谈？首先约谁谈？抓需求，第一个要约见的是甲方的项目负责人。因为他负责这个项目，有责任和义务去和乙方交流，选择乙方。至于甲方的其他人员，应该通过甲方项目负责人去协调约见，如果擅自约见，可能会遭到拒绝，并引起甲方的反感。约谈对方方式主要有电话、邮件、面谈三种建议先提前一周发邮件约见，再提前半天打电话确认提醒，最后面谈。一般应在邮件里包含：公司优势和访谈提纲。