实验教学教案由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“小学实验教学教案”。
《人机交互技术》实验教学教案
实验一：怎样做用户需求分析
1．项目需求获取的几种方法及适用环境
我们知道，需求调研不充分、用户需求描述不完整不准确，轻则影响项目建设的顺利程度，重则影响应用系统的质量，甚至决定项目的成败。
俗话说，“良好的开端是成功的一半”，需求获取作为项目伊始的活动，是非常重要的。目前我们所开发的软件项目一般有两种类型：产品项目和工程项目。
产品项目一般都会有充足的时间进行非常仔细的需求调研和分析，而工程项目却并非如此（因为它往往受诸多因素的影响）。本文拟讨论如何根据工程项目的实际特点，采用合适的方法低成本高效率地获取用户的需求。
产品项目一般是根据公司战略和市场需求研发的旨在进行批量出售或推广的项目，工程项目一般是根据与用户签定的合同研发的旨在满足特定用户需求的项目。
这里说的项目主要是工程项目，在项目的建设过程中，感觉到最头疼的是项目需求的获取，我们往往要花相当大的精力在需求获取和需求确认上，然而有时效果还很不理想。经过几年时间的项目实践，我们逐步总结出针对不同项目情况所适合采用的需求获取方法，这些方法能大大提高需求获取的效率。现总结之，愿与大家分享。
我们知道，一个工程项目，如果从开发方（即软件开发团队）和用户方（即客户）对需求的清楚程度来分，大致可以分为如下四种：开发方和用户方都清楚项目需求、开发方不清楚项目需求但用户方清楚、开发方和用户方都不清楚项目需求、开发方清楚项目需求但用户方不清楚。
针对这四种类型的项目，我总结出四种对应的需求获取方法：问卷调查法、会议讨论法、界面原型法和可运行原型系统法。
以下逐一解析之。
一、问卷调查法
所谓“问卷调查法”，是指开发方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。
这种方法的一般操作步骤是：
步骤
一、开发方先根据合同和以往类似项目的经验，整理出一份《用户需求说明书》和待澄清需求（或问题）的《问卷调查表》提交给用户；
步骤
二、用户阅读《用户需求说明书》，并回答《问卷调查表》中提出的问题，如果《用户需求说明书》中有描述不正确或未包括的需求，用户可一并修改或补充；
步骤
三、开发方拿到用户返回的《用户需求说明书》和《问卷调查表》进行分析，如仍然有问题，则重复步骤二，否则执行步骤四；
步骤
四、开发方整理出《用户需求说明书》，提交给用户方确认签字。
由于这种方法比较简单、侧重点明确，因此能大大缩短需求获取的时间、减少需求获取的成本、提交工作效率。
二、会议讨论法
所谓“会议讨论法”，是指开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。
这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握。
这种方法的一般操作步骤是：
步骤
一、开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；
步骤
二、会后开发方整理出《需求调研记录》提交给用户方确认；
步骤
三、如果此主题还有未明确的问题则再次沟通，否则开始下一主题；
步骤
四、所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。
由于开发方不清楚项目需求，因此需要花较多的时间和精力进行需求调研和需求整理工作。
三、界面原型法
所谓“界面原型法”，是指开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。
这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取。
这种方法的一般操作步骤是：
步骤
一、开发方根据其所了解到的需求（如通过合同或与用户交流），采用界面制作工作描画出应用系统的功能界面；
步骤
二、将应用系统的功能界面提交给用户并与用户沟通，挖掘出新需求或就需求达成理解上的一致；
步骤
三、开发方就不断获取的需求进行增量式整理，根据新的需求丰富和细化界面原型；
步骤
四、双方经过多次界面原型的交互，开发方最终整理出《用户需求说明书》，提交给用户方确认签字。
由于开发方和用户方都不清楚项目需求，因此此时需求获取工作将会比较困难，可能导致的风险也比较大。采用这种“界面原型”的方式，能加速项目需求的“浮现”和双方对需求的一致理解，从而减小由于需求问题可能给项目带来的风险。
针对这种类型的项目，我们也可以采用下面将要介绍的“可运行原型系统法”，但由于开发方对需求不了解（证明以前缺乏类似项目的开发经验和产品积累），如果开发一个可运行的原型系统，则几乎需要从零开始编写代码，前期投入会很大。
四、可运行原型系统法
所谓“可运行原型系统法”，是指开发方根据合同中规定的基本需求，在以往类似项目应用系统的基础上进行少量修改得出一可运行系统，通过“可运行原型系统”这一载体，达到彻底挖掘项目需求的一种需求获取的方法。
这种方法比较适合于开发方清楚项目需求但用户方不清楚项目需求的情况。这种类型的项目，开发方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一可运行系统，然后借助于这一“载体”来加快对需求的挖掘和双方（特别是用户方）对需求的理解。这种情况下，采用“所见即所得”的可运行原型系统法比较可取。
这种方法的一般操作步骤是：
步骤
一、开发方根据其所了解到的需求（如通过合同或与用户交流），在以往类似项目的基础上，快速“构建”出一可运行系统；
步骤
二、通过向用户演示“可运行原型系统”，逐步挖掘并让用户确认项目需求；
步骤
三、开发方就不断获取的需求进行增量式整理，根据新的需求丰富可运行原型系统；
步骤
四、双方经过多次可运行原型系统的交互，开发方最终整理出《用户需求说明书》，提交给用户方确认签字。
由于开发方清楚用户的需求（证明以前有类似项目的开发经验和产品积累），但用户方自己不清楚，因此此时开发一个“可运行原型系统”，开发方的投入不会很大，但对于用户理解和确认项目需求非常有利，因此针对这种类型的项目这是一种比较理想的需求获取方式。
这种方法的另一个好处是：正式系统一般可以在该“可运行原型系统”的基础上演化而成，为后续开发工作节省不少的工作量和成本。
值得注意的是，以上总结出的这四种需求获取方法不是互斥的，我们可以根据项目的实际特点独立应用或组合应用。
“忙碌，不代表有效率；方法，远胜于苦干”。但愿我们从事软件项目开发的朋友们，都能掌握好恰当的方法，以图能获得“事半功倍”的效果。
2．需求分析阶段的工作
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求
这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动
● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
● 需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：
⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：
⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
⑵使需求符合系统的整体目标；
⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
分析用户需求
在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：
● 以图形表示的方式描述系统的整体结构，包括系统的边界与接口；
● 通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；
● 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；
● 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。图2描述的是某个项目的DFD示意图。
ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。
在面向对象分析的方法中通常使用Use Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。Use Case方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能的测试用例
介绍了需求分析五个步骤中的前两个步骤（获取用户需求、分析用户需求），本期将继续介绍后三个步骤（编写需求文档、评审需求文档、管理需求），并与大家讨论相关实践问题。
1、编写需求文档
需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。
2、评审需求文档
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。
3、管理需求
需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图1和图2所示。
常见问题及建议
Q、客户与最终用户的区别是什么？
A、可以借助图3来说明它们之间的区别。
软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。
Q、如何进行用户访谈？
A、首先，一定要事先确定访谈的目的和提纲。其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。
Q、用户访谈内容是什么？
A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。
Q、采用哪一种方式做需求分析最好？
A、不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。一般来说，可以使用DFD＋ERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。
Q、怎样做原型，原型的目的是什么？
A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。
原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。
