需求分析_重点整理.docxVIP

名词解释： Baseline,requirement(基线，需求)一个时间快照，表示针对某一产品的特定版本达成一致意见的、经过评审的、并得到批准的需求集。 Commercial off-the-shelf product(商业现货(COTA)产品)从供应商购买的软件包，既可以独立作为问题的解决方案，也可以通过集成、定制和扩展以满足本地客户的需要。 Data dictionary(数据字典)有关对问题域重要的数据元素、结构和属性的定义的集合。 Extreme Programming(极限编程)一种“敏捷”软件开发方法，其特点是开发人员和现场客户代表之间面对面地协作；需求文档只限于采用“用户材料”的形式；以较小的增量迅速而频繁地交付有用功能。 Requirements tracebility matrix(需求跟踪矩阵)演示单个功能性需求和其他系统制品之间逻辑联系的一张表，这些系统制品包括其他功能性需求、用例、构架和设计元素、代码模块、测试用例和业务规则。 简答： 需求的层次： 软件需求包含三个不同的层次：业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能性需求。其中： 业务需求（Business requirement）表示组织或者客户高层次的目标。它通常来自项目投资人、客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了为什么要开发一个系统，即组织希望达到的目标。 用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件-响应表都是表达用户需求的有效手段。用户需求描述了用户能够使用系统来做些什么。 功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。它也被称为“行为需求”。 需求的来源 与潜在的用户进行交流和讨论 描述现有产品或竞争产品的文档 系统需求规格说明：需求分析员可从部分需求中推导出软件详细功能性需求。 现有系统的问题报告和改进要求：来自于客户服务和技术支持人员的需求。 市场调查和问卷调查：事先要想专家咨询如何设计和调查，以确保向正确的对象提提出正确的问题。调查能够检验你对于需求的理解，但不是刺激创造性思维的好方法。 观察用户如何工作：通过观察用户在实际工作环境下的工作流程，需求分析员能够验证之前在交谈中获得的需求、确定交谈的新主题、发现现有系统的缺陷，以及找到能让新系统更好地支持工作流程的方法。 用户工作的情景分析：在确定用户需要借助系统完成哪些工作之后，就能够推导出用户完成这些工作必须的功能性需求。 事件和响应：列出系统必须响应的外部事件和正确的响应，这对于实时系统十分重要。 需求管理工具可以完成哪些任务 管理版本和变更：我们可以记录每一个变更决策的理由，也可以恢复到前一个版本。 进行影响分析：在定义联系链以实现需求跟踪的基础上，确定某一提议的变更可能影响的系统元素，联系链可以帮助我们分析这一变更对某一特定需求将产生的影响。 存储需求属性：应该为每个需求记录一些描述属性，要清楚地标出各种版本的产品要实现的需求基线，其中一种方法是使用“版本号（Release Number）”属性。 重用需求：将需求保存在数据库中，就可以方便地在多个项目或子系统中重用这些需求，避免了重复需求。 访问控制：在这一级别数据库通过加锁机制来实现多用户同时更新数据库内容。 与涉众沟通：允许团队成员通过电子联系方式来讨论需求问题。保持需求的在线访问可以节省差旅费和减少文档的发放费用。 跟踪需求状态：通过跟踪开发过程中每个需求的状态，可以了解项目的整体跟踪状态。 画图题： DVD状态图： 序列图： 继承图： 聚合图： 到医院看病流程图： 有关需求改进：ch22 需求与其他项目的关系： 需求和各涉众组 软件过程改进的基本原则： 过程改进应是不断演化的、连续的、周期性的； 只有人们或者组织具有变更的动机时才可能实施变更； 过程变更要有的放矢； 将改进活动视作小型项目。 过程改进的周期 规划改进活动： 起草一个需求变更控制过程草案； 评审并修订变更控制过程； 在项目A中实验变更过程； 根据试验的反馈信息，修订变更控制过程； 评估问题跟踪工具，并从中选择一种来支持变更控制过程； 购买并定制问题跟踪工具以支持变更控制过程； 在组织中使用新的变更控制过程和工具。、 评估结果： 评估有助于团队在未来的改进活动中做的更好； 评估内容包括判断实验进行的是否顺利，在解决新过程的不确定方面是否有效，在下一次指导过程实验时是否需要做些变更； 同时还要考虑新过程的总体执行情况是否顺利，包括新过程的或模板的可用性是否有效地传达给了每个人，参与者是否理解并成功地应用了新过程，下次工作中是否需要有所变更等；