系统开发中需求分析与管理（一） .pptVIP

二、需求开发 2、需求冲突的解决 需求从获取渠道收集到以后，可能产生不一致的地方。 解决原则主要有： 当客户需求与开发方预计需求冲突时，以客户需求为主。 用户间需求冲突则以级别大的用户需求为准，同级则少数服从多数。 多个客户以出钱多的客户需求为准 二、需求开发 3、用户需求说明书 对收集到的用户需求进行分析、归纳与总结，然后根据一定的格式撰写《用户需求说明书》，调查过程中的中间资料可作为附件。用户需求说明书完成后，应邀请专家与用户对其进行评审，使其最大限度地符合用户的真实意愿。之后才能进行进一步的需求分析与定义，产生《软件需求规格说明书。》 （模板） 二、需求开发 4、需求分析与定义 1)概述 需求分析的结果是通过建立系统的逻辑模型来定义需求。 逻辑模型：详细展示系统要完成的功能，而不依赖具体技术的模型。 物理模型：表明系统是如何真正实现的模型。 二、需求开发 4、需求分析与定义 1)概述 结构化分析方法兴盛的时期，软件系统的开发过程是从物理模型到逻辑模型，再从逻辑模型到新的物理模型的过程。这种方法可以保证系统分析能按步就班的完成，但缺点是 a) 系统分析时间较长，要花费更多时间与资金去分析、了解和记录旧系统的运行，提炼出运行逻辑。 b) 新系统往往是旧系统的简单自动化，不论原系统的效率有多低，是否合理，都原样地进入新系统，并不能通过信息化改造原来的业务管理流程，提高管理水平。 不适合于全新系统的开发，特别是一些WEB项目，如电子商务方面的项目开发，这些项目没有可参考的旧系统。 二、需求开发 4、需求分析与定义 1)概述 现代的需求分析过程，往往是直接在对用户需求进行收集地过程中直接产生新系统的逻辑模型（直接通过对比要解决的商业问题和软件需要实现的功能）。系统分析员只有在需要理解商业业务流程时才去检查现有系统。 系统分析员的焦点是：以新系统为中心。提出创新的问题解决之道是系统分析员的素质要求之一。此外，新系统的引入还可能对组织原来的业务流程进行改造——BPR。 两种思维方式： 还没有坏，就不需要修理 总有一种更好的解决方法 案例——Ford的业务流程重组 ? ? 20世纪80年代，福特北美分部的帐目支付部门雇佣了500多名员工。为了提高效率，公司决定引入信息系统，最初的目标是提高20%的效率。在项目小组进行系统分析时发现，马自达公司的帐目支付部门只有5名员工。虽然福特比马自达大得多，但相对于而言也达不到100倍的业务量。在借鉴了马自达的业务过程的同时，项目组设计了全新的自动化系统，将帐目支付功能包含在更大的购买功能中，实现了从购买到支付全程跟踪的自动化，项目结束时，只需求100人即可完成原来500多人才能完成的帐目支付功能，大大超出了预计。 二、需求开发 4、需求分析与定义 2)系统分析规程 目的 定义准确的产品需求，产生《产品需求规格说明书》 角色与职责 系统分析员定义产品需求，用户确认产品需求 启动准则 《用户需求说明书》撰写完成 输入 《用户需求说明书》 主要步骤 1．细化和分析用户需求 2．撰写《产品需求规格说明书》 3．需求确认 输出 《产品需求规格说明书》 结束准则 《产品需求规格说明书》撰写完成并通过确认（评审与承诺） 度量 系统分析员统计工作量与文档规模，上报项目经理 二、需求开发 4、需求分析与定义 2)系统分析规程 第一步：细化并分析用户需求 –需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，分析员应当根据自身水平进行取舍。 第二步：撰写产品需求规格说明书 –需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。 第三步：进行需求确认 –项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。 –需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。 二、需求开发 4、需求分析与定义 3)需求分析方法 文字描述（可从问答法直接获得） 模型描述 有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。因此在需求分析中常使用建模的方法来定义需求。 二、需求开发 4、需求分析与定义 3)需求分析方法 模型描述 (1)需