产品的需求分析

需求定义

　　需求是人们对系统功能，性能，行为，设计约束，质量的期望。系统质量包括功能和非功能性质量比如可修改性，易用性，安全性，性能，可靠性等；设计约束是指设计时的一些约束条件比如操作系统选择等；
　　需求是多层次的从整体到局部可分为业务需求，用户需求，系统需求。业务需求是反映用户对系统的高层次要求；用户需求就是对于业务需求的细化，是用户的具体要求；系统需求是从开发角度定义的一些需求，包括功能性要求，非功能性质量要求和设计约束。开发人员必须实现这些功能，用户通过这些功能实现用户需求。
　　从用户角度可分为基本需求，扩展需求，额外需求；基本需求就是用户需要的基本功能，扩展需求就是用户没有具体说明，但是认为系统必须具备的一些功能，如果没有满足，会影响用户满意度；额外需求就是用户没有要求，但是如果满足会带来用户惊喜，从而提高用户粘连度，提高用户满意度的一些需求。
　　需求分析的主要过程分需求开发和需求管理。需求开发就是需求获取，需求分析的过程。需求管理是对需求进行管理，控制的过程。

需求开发

　　需求开发包括需求获取，需求分析，需求定义，需求验证，结果是需求规格说明书
　　需求获取的方法包括：用户访谈，问卷调查，抽样，情节串联，联合会议；
　　需求记录的方法有：记录卡，记录卡中包括的内容包括命名，目的，关键场景描述，输入，输出，变体，子任务，频率，质量要求等；
　　情节串联是通过讲故事的方式，通过图片，建立场景，描述功能实现过程，在过程描述过程中发现用户需求；
　　联合会议是一种比较高效的获取需求的方法，将项目干系人召集起来（业务代表，分析师，架构师，业务专家），分析原有系统的不足，通过讨论确定实现方案，对于关键环节进行讨论，最终总结报告包括达成一致和未解决的问题。会议原则包括：尽量完整记录，少用专业术语，充分发挥解决冲突的技能，鼓励取得一致意见，会议后一般有一个问卷调查。
　　需求分析的过程是通过对收集到的需求进行分析，建立概念模型。方法有结构化分析方法，面向对象的分析方法。结构化分析方法是通过数据流图和数据字典建立概念模型；面向对象分析方法是通过用例图描述用户功能需求，通过类图或对象图对现实进行概念抽象，通过交互图对系统行为进行抽象从而建立领域模型。
　　结构化分析方式是基于功能分解的一种分析方法，其中包括数据流图，数据字典，状态图；数据字典反映系统的概念模型，是核心，一般用ｅ－ｒ图来表现。数据流图是系统的功能模型，状态图是系统的行为模型；数据流表示数据流向其中包括流入，流出去向，数据内容；数据字典中包括数据元素，数据结构，数据流，处理，数据存储，外部实体；
　　面向对象的分析方法是对事物进行分析和理解，抽象出其中的概念和行为的方法。ｏｏａ中用例图建立过程：每个用例代表用户对系统的一个完整期待。首先识别用例使用对象，其次建立用例图。建立用例图的方法可以从获取的需求中分析用例，合并用例，对用例关系进行分析，调整用例，最终形成用例模型。另外一种方法是通过描述业务流程的活动图中发现用例。确定用例后对用例进行描述细化用例，用例名称采用动宾结构，用例描述采用主谓宾结构，用例描述中包括命名，目的，触发，描述，后置条件，频率，质量，优先级等。描述可以采用如下描述方式：主参与者提供某些信息给系统，系统做第一件事，第二件事。。。；将用例向系统设计转换，对于每个用例用一个类图建立系统静态模型，用交互图建立动态模型。通过名词分析有助于分析概念类或类属性，通过动词分析有助于建立类的功能。交易模型是一种建立概念模型的方法，以交易为中心，识别出相关的人，地，物，有助于分析出相关的实体类，接口类；
　　需求定义的方法有严格定义和原型定义方法。严格定义是一种预先定义，一旦确定需求就不再改变，但是实际操作中开始阶段不大可能能够全面的表达需求；原型定义就是先定义一个原型，在此基础上在逐渐丰富。编写需求规格书有两种形式：自然语言，图形化。需求规格书的格式一般包括范围，引用，需求，合格性规定，配置，注解，未解决问题，附录。
　　需求验证包括需求评审和需求测试。需求评审的目的是检查需求定义是否正确的反映用户的期望，完整性，无二义性，可跟踪性，对设计的指导性；测试是利用根据用户需求编写的测试用例检查需求分析结果，检查其功能性，完整性，二义性方面的错误或遗漏。测试工程师可以由分析师担任，但是必须与设计部门分开，避免身份重叠。

需求管理

　　需求管理内容包括版本管理，需求变更管理，需求跟踪；需求基线是是指对于需求，干系人达成一致，是需求管理的基础。
　　版本管理是对需求规格书的标识，第一版可以是1.0（草稿1），直到不在发生变化可定义为1.0（正式版）。其后的变化可以是1.1（草稿1）或变化较大的2.0（草稿）。对于每一项需求属性最好有相关记录：时间，创建者，认可者，需求产生原因，关联系统，优先级等。
　　变更管理：成立变更委员会，成员来自市场部门，开发部门，管理部门等。变更流程：问题分析和变更描述，变更分析成本分析，变更实现。变更原则：需求变更必须经过变更过程，未确定的变更不做设计和开发，由变更委员会决定变更，风险承担者必须了解变更，不能删除原始的记录，变更可以被追踪。变更委员会工作过程：决策（决策前需要明确人数，决策方式，委员会主席是否有决定权），通知，重新协商。
　　需求跟踪是建立每一项需求与其他元素之间的关系，其他元素包括其他需求，设计，代码，测试，用户文档。建立跟踪机制对于实现变更分析有用。对于确保需求的一致性,系统可维护性，重用具有重要意义。