北京大学软件与微电子学院-软件需求工程考试整理

2015级北大软微软件需求工程期考试资料考试时间：12月7号上午9:00-11:00考试地点：3303题型：简答4道论述题5道Lecture_1：软件需求工程介绍一．需求概念和软件需求的概念，为什么需求要分层（考试考到了），怎么分的需求定义是（P5）(1)用户解决问题或达到目标所需条件或权能(Capability)。(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。(3)一种反映上面(1)或(2)所述条件或权能的文档说明。需求是“任何促成设计决策的因素”需求的分层问题：（P6-7）我们的软件产品或者项目，其需求都有三个层级和三个方面。软件需求包括3个不同的层次-----业务需求、用户需求和功能需求。业务需求（Businessrequirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（visionandscope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。用户需求（userrequirement）描述的是用户的目标，或用户要求系统必须能够完成的任务。用例，场景描述和事件-响应表都是表达用户需求的有效途径。也就是说，用户需求描述了用户能使用系统来做些什么。功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。业务规则包括企业方针、政府条例、工业标准、会记标准和计算方法等。业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特地用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。除了功能需求外，SRS中还应该包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。二.软件需求工程的概念，需求开发和管理，什么是需求的基线，开发和管理怎么区分的需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。（以上是百度百科参考的）软件需求工程划分为需求开发和需求管理需求开发（P9）可进一步分为问题获取、分析、编写规格说明和确认四个阶段,需求开发活动包括以下几个方面：(1)确定产品将要面对的各种用户(2)获取每个用户类的需求(3)了解实际用户任务和目标以及这些任务要实现的业务目标(4)分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议以及其他无关信息区分开来。(5)将顶层的需求分配到系统架构内定义好的软件组件中。(6)了解各质量属性的相对重要性(7)协商需求的实现优先级(8)将收集的用户需求表述为书面的需求规格说明和模型(9)审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分歧。需求管理（P10）的任务是“与客户就软件项目的需求达成并保持一致”，这种一致性应该体现在书面的需求规格说明和模型中。取得用户认可，并且必须让开发人员接受需求规格说明书并同意在产品中加以实现，需求管理包含如下活动：(1)定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)(2)审查需求变更请求，评估其可能产生的影响以决定是否批准。(3)以一种可控制的方式将准的需求变更融入到项目中(4)保持项目计划与需求的同步(5)估计需求变更的影响，并在此基础上协商新的需求约定。(6)跟踪每项需求，找到与其对应的设计、源代码和测试用例(7)在项目开发过程中，始终跟踪需求的状态和变更。需求基线（P222）是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。定义了一个需求基线之后，项目的涉众各方就可以对发布的产品中希望具有的功能和属性有一个一致的理解。确定需求基线时--一般是在通过正式的评审和批准之后，就应该对它们进行配置管理。后续的变更也必须遵守项目预先定义好的变更控制过程。在确定需求基线之前，仍然可以对需求进行变更，因此，把一些不必要的过程开销强加于这些变更就没有什么意义。但是一旦建立了初步的文档草稿，就应该开始实施版本控制--唯一地标识每一个需求文档的不同版本。需求开发和管理的区分图：三.关于软件需求常见的问题（P11）（1）用户参与不足（2）用户需求扩展（3）有歧义的需求（4）镀金问题（5）过于抽象的需求（6）忽略了某类用户（7）不准确的计划四.好的需求是什么样子7+4原则（P15）一、需求陈述的特点1.完整性每一项需求都必须完整地描述即将交付使用的功能，必须包含开发人员设计和实现这项功能需要的所有信息。2.正确性每一项需求都必须准确地陈述其要开发的功能。判断正确的参考是需求的来源，如实际用户和高级的系统需求。3.可行性需求必须能够在系统及其运行环境的已知能力和约束条件内实现。4.必要性每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。5.有优先次序为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。6.无歧义一项需求声明对所有读者应该只有一种一致的解释。编写需求时应该使用用户所在领域的、简洁明了的语言。7.可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。二、需求规格说明的特点1.完整性不能遗漏任何需要或者必要的信息。2.一致性指需求不会与同一类型的其他需求或更高层次的业务、系统或者用户需求发生冲突。3.可修改性必须能够对SRS作必要的修改，并可以为每项需求维护修改的历史记录。4.可跟踪性应能在每项软件需求与它的来源和设计单元、源代码、测试用例之间建立起链接链。五.对需求签约问题的理解（要自己写，不能重了P22-23）站在公正的立场，从建立里程碑的立场来看待，签约是可以变化的，但需要额外的成本和协商在软件项目执行过程中，需求的变更在所难免。让用户对需求变更签字确认往往是项目组比较头疼的事情之一。一般来说，正常的需求变更还是需要用户签字确认的，当然要做通客户的工作，让客户理解：签字是为了更好的保障开发人员理解真正需求。要互相体谅理解，遇到新的调整时，需要进行新的协商。Lecture_2：软件需求工程介绍一.理解好的需求工程什么样（P28）二．学习项目管理三.需求开发过程（P38）需求开发过程是一个迭代的过程1.定义项目的视图和范围2.确定用户类3.在每个用户类中确定适当的代表4.确定需求决策者和他们的决策过程5.选择你所用的需求获取技术6.运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级7.从用户那里收集质量属性的信息和其它非功能需求8.详细拟订使用实例使其融合到必要的功能需求中9.评审使用实例的描述和功能需求10.如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解11.开发并评估用户界面原型以助想像还未理解的需求12.从使用实例中开发出概念测试用例13.用测试用例来论证使用实例、功能需求、分析模型和原型14.在继续进行设计和构造系统每一部分之前，重复6~13步四，一个好的需求人员具备的能力？（P41-4.1.2）需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，也是用户群体与软件开发团队间进行需求沟通的主要渠道。（1）倾听的技巧要善于双向交流，就必须知道如何有效地倾听。不能分神，保持专注与目光接触，以及重复要点以证实自己的理解。熟悉对方表达习惯，挖掘话语里潜在的信息。（2）交谈和提问的技巧大部分需求时经过讨论得到的，因此，需求分析员必须能够与不同的个人或者小组就需求展开讨论。（3）分析能力能以不同方式思考问题（4）协调能力对相关人员进行协调，帮助团队建立信任，改善业务人员与IT人员之间的关系。（5）观察能力可以从不经意间的闲谈中发现重要信息，可以察觉用户不曾提到的细微之处。（6）写作阅读能力必须具备良好的语言驾驭能力，能够清晰地表达出复杂的概念，提交需求规格说明书。（7）组织能力能在大量杂乱的信息中找出有意义的信息，能妥善快速处理变化的信息并将其组织成一致的整体。（8）建模能力掌握多种分析模型与分析工具。（9）人际交往能力让各种人员能团结合作，轻松交流。（10）创造力能够创造需求，构思新颖的产品功能，推测新的市场和商业机会，帮助客户发现隐含的需求。Lecture_3&4：需求获取（了解）1，视图与范围（P51）（整体目标是什么，不会）2，描述用户类，找到用户代表和ProductChampion（P62）4、需求获取的过程、方法的回归（P75）1）用户访谈用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。2）用户调查在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。3）现场观摩俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。4）文档考古文档考古是指对历史存在的—些文档进行研究，从带有数据的文件表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。5）建立联合分析小组在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。6）原型法原型是在软件开