|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求是指由项目接受的或项目产生的产品和产品构件需求，包括由组织征集的对项目的需求。有技术性的，也有非技术性的。
|
|
|
|
需求管理的目的是确保各方对需求的一致理解；管理和控制需求的变更；从需求到最终产品的双向跟踪。
|
|
|
|
|
|
需求工程是所有与需求直接相关的活动的通称，它的活动可分为两大类：需求开发和需求管理。
|
|
|
|
需求开发的目的是通过调查和分析获取用户需求并定义产品需求。
|
|
|
|
需求基线：软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型，经评审批准，这些文档就定义了开发工作的需求基线。
|
|
|
|
|
|
.需求获取。与用户进行交流，捕捉、分析用户对目标系统的需求，提炼出符合解决问题的用户需求，产生《用户需求说明书》。
|
|
|
|
.需求分析。对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。
|
|
|
|
.需求定义。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。
|
|
|
|
.需求验证。指开发方和用户共同对需求文档评审，经双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
|
|
|
|
需求管理和需求开发密切合作，需求开发涉及把项目关系人的需要转换成产品需求和决定如何在各个产品构件之间安排或分配需求；需求管理要收集需求的变更和变更的理由，并且维持对原有需求和所有产品及产品构件需求的双向跟踪。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
除了文本，每个功能需求应该有一些相关的信息或属性与之相联系。这些属性在它的预期功能性之外为每个需求建立了一个上下文和背景资料。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
建模是在计算机上创造三维形体的过程，建模是三维动画的基础，没有一个好的模型，其他好的效果都难以表现。三维建模的基本方法主要有：利用二维形体的技术、直接进行三维物体建模、造型组合等。
|
|
|
|
利用二维形体进行建模的技术的主要思想是首先创建简单的二维形体，如样条线和形状等，然后对这些创建的二维形体进行挤压、旋转、放样等操作以创建三维造型。
|
|
|
|
直接进行三维物体建模的常用方法有多边形建模、面片建模、NURBS建模等。
|
|
|
|
造型组合是把已有的物体组合成新的物体，其中布尔运算是最重要的组合技术。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
|
|
|
|
（1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
|
|
|
|
（2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
|
|
|
|
（3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
|
|
|
|
|
|
（5）如有必要，可开发一个原型系统以验证用户的需求。
|
|
|
|
|
|
|
|
（1）功能需求。所开发的软件必须具备什么样的功能。
|
|
|
|
（2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
|
|
|
|
（3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
|
|
|
|
|
|
需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，也就是指需求开发和需求管理两大工作。
|
|
|
|
（1）需求开发。包括需求捕获、需求分析、编写规格说明书和需求验证4个阶段。在需求开发阶段需要确定产品所期望的用户类型、获取每种用户类型的需求、了解实际的用户任务和目标，以及这些任务所支持的业务需求。同时还包括分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成为软件规格说明书和需求分析模型，以及对需求进行评审等工作。
|
|
|
|
（2）需求管理。通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
|
|
|
|
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话来说，需求开发是努力更清晰、更明确地掌握客户对系统的需求；而需求管理则是对需求的变化进行管理的过程。
|
|
|
|
|
|
（1）在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前就已开始建模，这经常会导致产生一个解决错误的问题。
|
|
|
|
（2）开发原型，使得用户能够了解将如何发生人机交互。因为人们对软件质量的感觉经常基于对界面“友好性”的感觉，所以强力推荐使用原型方法（以及相应产生的迭代）。
|
|
|
|
（3）记录每个需求的起源及原因，这是建立回溯到客户的可追踪性的第一步。
|
|
|
|
（4）使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。
|
|
|
|
（5）给需求赋予优先级。过短的时限可能使每个软件需求得以实现的可能性减小，如果采用增量模型，则必须标识那些将在第一个增量中要交付的需求。
|
|
|
|
（6）努力删除含糊性。因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求管理通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。根据考试大纲和培训指南的规定，本节要求考生掌握需求变更、需求跟踪和需求变更风险管理3个方面的知识。本节只简单介绍有关需求跟踪方面的知识。有关定义需求基线和需求变更的知识，请阅读12.7.3节；有关风险管理方面的知识，请阅读12.11节。
|
|
|
|
|
|
（1）审核。跟踪能力信息可以帮助审核确保所有需求被应用。
|
|
|
|
（2）在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素。
|
|
|
|
（3）使得维护时能正确、完整地实施变更，从而提高生产率。
|
|
|
|
|
|
（5）再工程。可以列出旧系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
|
|
|
|
（6）重新利用跟踪信息可以帮助开发人员在新系统中对相同的功能利用旧系统相关资源。
|
|
|
|
|
|
|
|
在信息系统项目中，需求变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。
|
|
|
|
需求跟踪包括编制每个需求与系统元素之间的联系文档。这些元素包括别的需求、约束、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪分为正向跟踪和逆向跟踪，一般合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。它跟踪的是已明确的需求的实现过程，不涉及需求开发人员的职责，也无法用于防止变更矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在需求获取的过程中，主要解决需求调查的问题。要想做好需求调查，必须清楚地了解3个问题：
|
|
|
|
|
|
|
|
|
|
|
|
从宏观的角度来看，要获取的信息包括三大类：一是与问题域相关的信息（如业务资料、组织结构图、业务处理流程等），二是与要求解决的问题相关的信息，三是用户对系统的特别期望与施加的任何约束信息。
|
|
|
|
|
|
除了要明确地知道我们需要什么方面的信息，还要知道它们可以从哪里获得。而通常情况下，这些你需要的信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
|
|
|
|
面对这么许多种可能，在具体实践中该从何下手呢？其实也很简单，首先从人的角度来说，应该首先对项目干系人进行分类，然后从每一类项目干系人中找到1或2名代表；而对于文档、产品而言，则更容易有选择地查阅。
|
|
|
|
在制定需求获取计划的时候，我们可以列出一个表格，第1列是我们想了解的信息，第2列是信息可能的来源，这样就能够建立起一一对应的关系，使得需求获取工作更加有的放矢，也更加高效。
|
|
|
|
|
|
当我们知道需要去寻找什么信息，并且也找到了信息的来源地，接下来就需要选择合适的技术进行需求获取了。
|
|
|
|
（1）用户访谈。用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行。用户访谈具有良好的灵活性，用较宽广的应用范围，但是也存在着许多困难，诸如客户经常较忙，你难以安排到时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要分析员有足够的领域知识；另外，在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此，这看似简单的技术，也需要分析人员拥有足够多的经验和较强的沟通能力。
|
|
|
|
（2）用户调查。用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常较广，不可能一一访谈。因此，我们就需要借助用户调查，通过精心设计要问的问题，然后下发到相关的人员手里，让他们填写答案。这样就可以有效地克服前面提到的两个问题。但是与用户访谈相比，用户调查最大的不足就是缺乏灵活性；而且双方未见面，分析人员无法从他们的表情等其他动作来获取一些更隐性的信息；还有就是客户有可能在心理上会不重视一张小小的表格，不认真对待从而使得反馈的信息不全面。因此较好的做法是将这两种技术结合使用。具体来说，就是先设计问题，制作成为用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
|
|
|
|
（3）现场观摩。对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。因此，针对这一现象，分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解，甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
|
|
|
|
（4）阅读历史文档。这种方式也称为“文档考古”。对于一些数据流比较复杂的，工作表单较多的项目，有时是难以通过语言，或者通过观察来了解需求细节的。这个时候就可以借助于阅读历史文档的方法，对历史存在的一些文档进行研究，从中获得所需的信息。这个方法的主要风险是历史的文档可能与新系统的流程、数据有一些不吻合的地方，并且还可以承载一些原有系统的缺陷。要想有效地避免和发现这些问题，就需要分析人员能够运用自己的聪明才智，将其与其他需求捕获技术结合对照。还有一个负面因素就是，这些历史的文档中记载的信息有可能涉及客户的商业秘密，因此对数据信息的保密也是分析人员基本的职业道德。
|
|
|
|
（5）联合讨论会。这是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6~18人，召开时间为1~5小时。在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后，首先应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，就是针对所列举的问题进行逐项专题讨论，然后对原有系统、类似系统的不足进行开放性交流，第三步则是大家在此基础上对新的解决方案进行一番设想，在过程中将这些想法、问题、不足记录下来，形成一个要点清单。第四步就是针对这个要点清单进行整理，明确优先级，并进行评审。这种联合讨论会将会起到群策群力的效果，对于一些问题最有歧义的时候、对需求最不清晰地领域都是十分有用的一种技术。而且最大的难度就是会议的组织，要做到言之有物，气氛开放，否则将难以达到预想的效果。
|
|
|
|
|
|
在整个需求过程中，需求捕获、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展，而且应该采用迭代式的演化过程。也就是说，在进行需求捕获时，不要期望着一次就将需求收集完，而且应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
观察和研究某一事物或某一系统时，常常把它抽象为一个模型。创建模型是需求分析阶段的重要活动。模型以一种简介、准确、结构清晰的方式系统地描述了软件需求，从而帮助软件开发人员理解系统的信息、功能和行为，使得需求分析任务更容易实现，结果更系统化，同时易于发现用户描述中的模糊性和不一致性。模型将成为复审的焦点，也将成为确定规约的完整性、一致性和精确性的重要依据。模型还将成为系统设计的基础，为设计者提供系统要素的表示视图，这些表示可被转化到实现的语境中去。模型还可以在分析人员和用户之间建立更便捷的沟通方式，使两者可以用相同的工具分析和理解问题。
|
|
|
|
在系统需求分析阶段所创建的模型，更着重于描述系统要做什么，而不是如何去做。目标系统的模型不应涉及系统的实现细节。通常情形下，分析人员用图形符号来创建模型，将信息、处理、系统行为和其他相关特征描述为各种可识别的符号，同时与符号图形相配套，并辅助于文字描述，可使用自然语言或某特殊的专门用于描述需求的语言来提供辅助的信息描述。
|
|
|
|
目前已经存在的多种需求分析方法引用了不同的分析策略，常用的分析方法有以下几种：
|
|
|
|
|
|
|
|
|
|
其中，结构化的分析方法和面向对象的分析方法应用非常广泛，本章将在后续小节中进行详细介绍。
|
|
|
|
|
|
|
|
|
|
|
|
|
