软件需求复习

需求的层次
				业务需求：需求定义的产物
				用户需求：需求捕获的产物
				功能需求
				非功能性需求
				特性：指的是逻辑上相关功能的集合，给用户提供处理能力并满足业务需求
				
需求分析：
				为了准确的了解用户的需求，必须进行细致的调查分析，将用户非形式的需求陈述转换为完整的需求定义
				再由需求定义转换到相应的形式主义功能规约的过程


需求分析的基本任务是什么：
				1、问题识别
					双方对问题的综合需求，功能需求，性能需求，环境需求，用户界面需求
				2、分析与综合，导出软件的逻辑模型
				3、编写文档
											
软件需求说明书：
				1、引言部分
				2、编写目的
				3、任务概述
				4、数据描述
				5、性能需求
				6、运行需求
				7、其他要求


为什么软件需求那么难？
				客户说不清楚需求
				需求自身经常变动
				分析人员或客户理解错误


软件需求的定义
				软件需求=业务知识+问题列表+其他因素
				业务知识：包括业务事件，业务实体和业务规则
				问题列表：主要是用户在工作所遇到的困难与障碍
				其他因素：设计约束和一些非功能方面需求
								
软件需求的三种类型：
				功能需求：开发人员要实现什么
				非功能性需求：对产品功能描述的补充
				设计约束：在进行系统开发和构建的时候限制了开发人员选择的范围


需求工程划分为哪两个部分
				需求开发，需求管理


需求开发包括哪些内容
				需求获取，需求分析，需求规约（编写需求规格说明书）和需求验证


需求管理包括哪些内容：
				基线管理，变更管理，需求跟踪


优秀需求的特点：
				完整性，正确性，可行性，有优先次序，无歧义、可验证性、确定性
		
客户的含义：
				广义的来说，客户指的就是那些直接或者间接得益于产品的个人或组织
		
签字的含义：
				签字时项目的一个里程碑，是建立需求协议的基线
					
需求定义阶段的任务：
				确定项目的宏观需求，换句话说，就是定义项目的业务需求，也就是明确项目的目标和范围


需求定义的产物：
				根据项目类型的不同，需求定义的产物大致分为项目综述和愿景两大类


需求定义的要素：
				目标、范围、相关人员与用户、相关事实与假设

一个好的目标应该满足的条件
				必须是具体的
				必须是可以度量的
				必须是可以达到的
				必须和其他目标具有相关性
				必须具有明确的截止期限


需求开发过程：
				需求开发过程是一个迭代的过程，不要期望可以线性的、顺序的完成获取、
				分析、编写规格说明和验证这些需求开发活动
					
业务事件类型：
				外部事件（参与者发起的）
				内部事件（系统内部触发的）


需求分析人员的工作：
				需求分析人员是对项目相关人员的需求进行收集、分析、记录和验证职责的承担者，是用户群体和软件开发团队间进行需求沟通的主要渠道。
				定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。
					
需求分析人员必备的技巧和知识：
				需求分析员必须掌握的技能：包括倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。
				需求分析人员必备的知识：具备从实践经验中积累的广博知识
				需要将需求开发与管理活动贯穿于整个产品生命期中
				掌握应用领域的知识


如何成为一名需求分析人员：
				优秀的需求分析员是培养出来的，而不是训练出来的。
				这项工作包括很多面向人而不是技术的“软性技能”


需求捕获的主要方法
				用户访谈、用户调查、文档分析、现场访问客户


获取客户需求的主要步骤
				确定产品的不同用户类型。
				确定用户需求的来源。
				挑选出每一类用户和其他涉众的代表并与他们一起工作。
				商定谁是项目需求的决策者。


需求捕获应该是主动的和聚集的 


需求的来源：
				与潜在用户进行交谈和讨论
				描述现有产品或竞争产品的文档
				系统需求规格说明
				现有系统的问题报告和改进要求
				市场调查和用户问卷调查
				观察用户如何工作
				用户工作的情景分析
				事件和响应


用户代表：
				用户代表应当自始至终参与项目的整个开发过程，而不是仅参与最初的需求阶段。


需求捕获要具有计划性和科学性：
				计划应针对下面这些内容来制定：
				需求获取的目的
				需求获取的策略和过程
				需求获取工作取得的成果
				进度和资源评估
				需求获取的风险
						
需求获取中各种心理如何应对：
				言过其实心理
				差异展现法：也就是将不同用户代表的访谈结果进行整理，在系统开发之前把这些差异展示给中高层管理人员，就如何解决达成共识。
				瓶颈分析法：对流程执行过程中的瓶颈进行分析，例如时间瓶颈、人员瓶颈（比如所有的申请都要由处长审批）等方面，以避免流程瓶颈导致系统无法顺利运转起来 
				越俎代庖心理
				要解决这个问题，关键在于需求捕获人员能够识别出正确的被访谈者，也就是回答你要问的问题最佳的人选是谁。这里有两层意思：
				问题的层次是否正确：高层管理人员解决宏观问题，中层管理人员解决脉络问题，操作者解决细节问题。
				根据业务背景判断：也就是有效地识别该问题所针对的业务环节是由谁负责处理的？执行者往往是回答的最佳人选。
				非正事心理
				客观原因：办公室本身就是一个容易被干扰的环境。应对之道：访谈应该尽可可能的避开办公室。
				主观原因：非计划的事情通常会被看做是低优先级的事情。应对之道：做好一周的访谈计划，列出访谈人，访谈要点，让对方统一安排。
				抗拒心理
				我们需要先“化敌为友”。这是主导的策略，实际的方法有很多
				推卸责任心理
				破推卸责任心理的简单手段是让被访谈者介绍工作场景。


需求获取中的注意事项：
				如果没有一个有条理的组织方案（例如用例），要将来自众多用户的需求意见合并起来相当困难。
				只向很少的用户代表收集意见，或者只听取声音最大、最固执已见的客户的意见，也是需求获取过程中存在的问题。
				这将导致遗漏对某些用户类很重要的需求，或者引入一些大多数用户并不需要的需求。
				解决这一问题的最佳平衡方式是让用户代言人参与需求获取，这些代言人必须具备为所属的用户类代言的权力，同时每个代言人都有数名来自同一用户类的用户代表作为后援。
				需求获取过程中，你也许会发现项目范围定义不正确，或者太大，或者太小。


需求分析主要用来做什么；
				需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。
				更具体地描述需求分析工作的任务：分解、提炼、消除矛盾。连成一句话就是：
				需求分析就是先分解、再提炼，在这个过程中消除矛盾。 


建模的要点与原则：
				设计要考虑到计划之外的变化
				设计要文档化
				用可视化的模型表达架构
				切忌“为了建模而建模”


需求评审：
				同级桌查/轮查：是个人级的评审方法，是需求人员之间私下进行的交叉审查。