许多主流软件工程项目已经成功地使用用例来指定应用程序的外部特征。用例使功能需求对所有涉及到项目中的风险承担者是具有易访问性的且可理解的。

    IvarJacobson1992年所介绍的用例被定义成系统执行的动作序列，能够生成对特殊参与者价值的引人注目的结果。统一建模语言（UnifiedModelingLanguage，UML）为用例定义图形符号，针对系统应该做什么，而不是如何去做。用例作为客户（如，用户）和系统开发人员之间沟通的共同语言。因此，在开发项目的早期可以用它们来获取需求。

    尽管用例获取用户和任务的一般化观点，但是依据具体的工作流，情境描述具体的用例实例。情境使用具体的数据，具体的事件，和可能具体的用户界面，有时候描述情节。开发团队为每个用例生成一些情境来说明事件流和各种错误条件（参见图1）。情境基于真实数据，这使得它们成为后来过程中测试用例的适当基础。 

    RUP使用用例将使用方法描述连接到应用程序的体系结构和代码上。其实，用例像增加的应用程序开发和在项目生命周期中连接各种开发活动的线程一样运行。

    然而，用例和情境有局限性。它们把用户仅视为“参与者”并且获取他们的用户界面需求——和他们的功能。虽然这些技术提供了杰出的方法来描述系统行为，但是它们不能传达真实的用户环境和界面需求的足够信息。

    添加角色以获取易访问性需求

    AlanCooper1999年所介绍的概念，使用角色是弥补缺陷的一个恰当的方法。指定角色包括为系统用户分配假想的名称和面容（照片）并撰写一篇工作生活中一天的大体描述。虽然假想的角色被描绘成个体，但轮廓反映出整个的用户组。

    Cooper区分了主要角色和次要角色。主要角色代表主要的目标用户，因此是设计应用程序用户界面的主要推动力。次要角色有额外的需求，如果为满足这些需要而进行变更，符合此描述的人就可以使用主要角色的界面。当然，这些变更必须不能与主要角色或者其他次要角色的界面需求冲突。

    事实上，使用角色会导致有效的，以用户为中心的设计。角色能够使开发人员通过各种各样有多样化界面需求和参数选择的潜在用户的眼光来观察他们的系统。

    有代表性的是，产品设计人员不知道人们实际上如何使用产品，甚至很少知道用户的需求和目标。除此之外，如果设计人员很年轻，技术熟练，并设计为老年人所用的产品，是特别成问题的。这对残疾人来说也是重要的问题。如果角色被定义成带有个人感觉并在生命中挣扎的，角色可以帮助设计人员理解老年人和残疾人如何使用产品。

    随着开发人员与该角色的接触——他们会更加熟悉它们的需求和参数选择——甚至同情他们。这些角色所代表的残疾用户会切实地，普遍地出现在开发过程中。

    角色规范含有用户环境，包括任何使用产品时所需要的辅助技术。您可能会为一个人书写多种描述，或者，将一个用户组分成多个角色来表示盲人用户的范围（语音输出用户、盲点法用户、天生的盲人、后天失明的等等）。

    单独的角色不是易访问性需求的代替，它们是向这些需求中添加意义和上下文的装置。它们可以使需求更加具体并更容易理解。随着时间的推移，它们可以帮助开发人员将需求内在化，以便照例依照它们，不需要记住它们或者迷信地遵循它们。与易访问性需求迷信地保持10一致经常导致满足规范的设计，但不是必要地理想甚至可操作。利用角色来举例说明设计过程中的易访问性需求，并随后在实现和测试中追溯可测试评估点是有效的。稍候我们将讨论此后面的功能。

    您应该为每个人类参与者提供一组相关的角色（参见图2）。对每个组，您必须指派一个主要角色，其他的都是次要的。主要角色应该为每个涉及相关人类参与者的用例推进用户界面设计。然后，对每个用例，您应该用所有次要角色来“代替”主要角色，修改用户界面设计，并确保用户界面满足每个次要角色的需要。您可以依照与情境类似的程序。很少情况下，主要角色是两个，因为他们有冲突的用户界面需求。在这种情况下，您可以复制用例，为一个主要角色分配每个用例，并为每个用例创建分开的界面。

    用例、情境和角色共同组成了支持用户为中心的分析和设计的强大技术。用例获取产品的整体功能行为，角色为用例指定（不同的）目标用户集，并因此可以表达易访问性需求，并且连接到具体用例的情境为真实用户描述现实的事件顺序。

    您需要多少角色？要表示一组完全的用户，包括多种残疾的用户（一般在老年人中），我们的研究表明您也许需要三十个角色（假设该组中极大的可变性和许多残疾的方面）。用更小的数字获得完全的覆盖面会更有利，对这方面的研究在UniversityofWisconsin的TraceCenter中正在进行。然而，目前，对不能表示局限性不同排列的一组角色的使用、开始的年龄、技能，和残疾人之间等的内容能够导致严重的误解和浪费了的工作。甚至对易访问性很热心的设计人员还经常不注意地忽略重要用户组的需求——包括那些上了年纪的用户。需要做更多的研究来识别应用程序开发中使用的标准角色组。此外，启发式的和对于易访问性的设计指导方针对创建伴有角色的易管理的设计过程是关键的。

    确保为用户提供对易访问性的支持

    当您完成了产品的开发时，进行部署的用户会需要支持。这是角色的另一个有用之处，它们可以为这些用户推动支持机制。您可以利用角色来开发产品文档（例如，用户的指导、安装指导、课程和培训材料）。如果您计划以印刷形式散发文档，您也需要做电子形式的。您需要检查这些文档，以及其他在线材料（例如，在线帮助，版本注释，用于下载的Web页面）是否对目标用户组有易访问性。如果要将产品以物理包的形式售出，您也需要检查包装的易访问性。如果您在举行辅导活动，那么房间应该是具有易访问性的。

    如果您决定为直接的用户支持提供热线，那么您还应该为此检查易访问性。您需要为文本电话用户安装单独的热线，并在文档中包含其号码。