从用户的角度创建系统规格说明书Word文档格式.docx

从用户的角度创建系统规格说明书Word文档格式.docx

《从用户的角度创建系统规格说明书Word文档格式.docx》由会员分享，可在线阅读，更多相关《从用户的角度创建系统规格说明书Word文档格式.docx（12页珍藏版）》请在冰豆网上搜索。

易用，因为它与概念模型匹配。

　　定义概念模型

　　概念模型定义我们预期事物将如何工作。

它是根据我们以前的经验动态构建的。

人们使用可见的线索和控制器（如手柄和开关）来操作看到的物体，以实现其目标。

概念模型可帮助我们了解各种新情况。

　　想想通过不熟悉的门进入建筑物的情况。

您不需要借助操作手册或培训课程来通过这扇门。

您将首先找到可以旋转的房门把手，或推动门板。

这些部件的位置告诉您折叶的位置以及门是向里开还是向外开。

如果没有这些，您可以试试门会不会检测到有人靠近就自动打开。

在这个过程中，您在使用来自概念模型的知识进行一系列试验。

您收到的反馈和结果将确定您后面的步骤。

　　通过我们的概念模型，我们可以容易地处理很多新情况。

不过，当某个东西不按照我们预期的方式工作时（由于缺少可见线索，或被线索误导），我们会发现一片混乱。

如果折叶位于门的顶部，其工作方式有些像门上的猫洞，或者如果门把手位于折叶旁边，您会有什么样的感觉呢？

　　当事物不按照我们预期的方式工作时，我们经常会由于失败而感到有些不好意思，或者感到非常气恼。

即使了解了其工作方式，将来使用时仍然需要特别注意，否则就可能继续犯错。

我们认为它“很难使用”，因此会采取措施来避免使用。

　　将概念模型应用于IT解决方案

　　概念模型也适用于IT解决方案。

IT解决方案在屏幕上显示对象，如文档或文件夹，并为人们提供操作对象实现其目标的方法。

　　IT对象经常与现实世界中的物体非常相似。

就像实际物体一样，解决方案中的IT对象必须按照与我们认为其应该的行为方式的概念模型一致的方式工作。

当IT对象模拟现实世界的物体，必须准确。

IT解决方案必须具有与概念模型预期相符的可见操作，并对每项操作提供清楚、明确的反馈。

　　例如，以在线文档库为例。

用户可以创建在线文档并将其放入电子文件夹中。

文档和文件夹的电子版本需要按照与现实世界的对等项相同的方式工作。

可以对电子版本添加或扩展在现实世界中无法完成的功能（例如，将文档同时放入多个文件夹的能力）。

不过，进行扩展时必须格外小心，以避免给使用系统的人员造成混淆。

　　将解决方案的外部设计元素与使用它的人员的概念模型匹配，这是成功的关键。

对解决方案满意的用户是此解决方案最强大的销售推广力量。

用户如果不满意，可能甚至会劝阻其他人试用此解决方案。

　　了解用户是用户建模的第一步

　　为了构建有用而且易用的解决方案，您必须从以下方面了解其使用者的特征：

　　他们的目标是什么

　　他们如何将目标转换为行动

　　他们的概念模型的相关部分如何操作

　　此信息捕获在用户模型中。

　　用户模型是由简单类关系图组成的专用UML模型，描述用户的目标和技能、您要求他们执行的任务以及在IT解决方案中将使用的对象。

其中的每个概念都作为自己的造型化UML类表示，并具备描述其间关系的UML关联。

　　从确定解决方案的使用者开始构建用户模型。

　　用户角色

　　由于概念模型是以我们的经验为基础构建的，因此每个人的概念模型都是唯一的。

不过，这并不意味着我们需要针对每个个人用户进行建模。

幸运的是，我们与具有类似背景和教育的其他人有相似的经验。

在解决方案操作的领域，可以将可能具有类似概念模型的用户分组到一起。

这些用户组称为用户角色。

　　用户角色代表具有类似职责和技能的用户组。

可以将用户角色视为组织内的工作角色，如采购员、营销经理、系统管理员和办事员。

　　务必为解决方案的所有方面定义用户角色，包括业务使用、自定义、管理及操作等。

如果忽略了某个使用领域，此领域可能在部署解决方案时带来意外成本和造成用户不满意。

　　用户目标

　　对于每个用户角色，为其定义目标及您预期其将具有的技能。

每个用户角色至少具有一个用户目标。

用户目标描述结束状态，或用户角色希望达到的目的。

此目标应该是可度量的，而且应该为用户角色可以实现的。

从用户角色到用户目标的关系称为主要目标，以强调您建模的仅是用户角色最为重要的方面。

图1.具有主要目标的用户角色

　　您可以通过创建使用子目标关系链接的用户目标层次结构来将用户目标划分为子目标，如图2中所示。

图2.将主要目标划分为子目标

　　在典型的组织中，一个用户角色可能依赖于其他用户角色来完成其目标。

例如，除非开发人员编写了代码，否则测试人员无法完成与测试软件相关的目标。

如果代码提交晚了，测试人员出色完成工作的能力将受到影响。

　　可以通过虚线箭头表示依赖关系。

确定依赖关系是在帮助了解组织内的压力所在（这在系统设计期间通常是重点关注对象）。

图3.不同用户角色的用户目标之间的依赖关系

　　通过对用户角色的目标的详细分析，可以了解使用系统的人员的动机——还可以了解可能出现协作和冲突的地方。

此分析将帮助您将解决方案的功能定为更直接地支持用户需求。

　　向关系图添加技能集

　　用户角色预计应该具有的技能归入多个组，可通过培训课程或技术鉴定获得的这些技能。

这些技能组称为技能集。

　　如果某个用户角色拥有某技能集，就表示该角色中的人员了解与该技能集关联的术语和概念。

这种了解使用从用户角色到技能集的“已获得技能”关系在用户模型中显示。

图4.“已获得技能”关系

　　用户角色必须具有一个以上技能集。

某些技能集可能代表现有知识，而其他技能集可能代表用户角色为了使用此解决方案而必须获得的知识。

图5.具有主要目标和已获得技能集的用户角色

　　您可以使用“嵌套技能集”关系表示技能集之间的关系，指示嵌套技能集是先决技能集。

在图6中，假定已获得技能集A的用户角色还将具有技能集C。

图6.“嵌套技能集”关系

　　还可以将技能集分组为规程，如图7中所示。

您可以使用“嵌套规程”关系以层次结构方式建模规程。

规程仅用于提供在模型中组织技能集的方法。

图7.层次结构中定义的规程和技能集

　　通过建模技能集关系，可以对不同用户角色的技能进行比较，或许可以帮助了解职业发展途径。

通过建模这些关系，可以确定某个用户角色是否可以替代另一个用户角色。

在图8的示例中，用户角色A，具有用户角色B具有的所有技能。

适合担任用户角色A的人可以代替用户角色B。

类似地，具有用户角色B的技能的人可以通过技能集A和技能集B的培训执行用户角色A的工作。

图8.用户角色间共享的技能集　

　　通过分析与用户角色关联的技能集，可以帮助确定哪些是高技术用户角色以及为了某个人执行某个用户角色而需要进行哪些培训。

技能集分析可以帮助项目经理对特定项目所需的资源进行预算。

　　每个技能集还具有与其关联的术语或概念词汇表。

这些术语代表了用户角色在拥有此技能集的情况下所熟悉的词汇。

您可以使用用户对象和用户构件来建模此词汇表。

　　建模用户对象和构件

用户对象是用户使用的逻辑概念，而不是编程接口中的对象。

用户构件是物理对象，如磁盘或文件。

　　您可以将“用户-属性”关系用于建模用户对象和用户构件间的关系。

此关系表明目标是源的特性或属性。

例如，在图9中，用户对象A具有用户对象B的属性或特性。

图9.用户对象间的“用户-属性”关系

　　类似地，可以将“用户-属性”关系用于用户构件和用户对象之间。

可以将这种“用户-属性”关系视为用户构件内容的定义。

如果图10中的用户构件是日志文件，用户角色C则可以为日志文件中的日志记录。

图10.建模用户构件内容的“用户-属性”关系

　　用户对象和用户构件定义技能集的概念和术语。

在用户模型中，我们使用双向关系对此加以表示。

从技能集到用户对象或用户构件的方向上，此关系称为“词汇表”关系。

而在另一个方向上，此关系称为“教授”关系。

图11.技能集和用户对象间及技能集与用户构件间的双向关系

　　通过这些关系，您可以定义每个角色所理解的术语。

用户角色将使用的任何用户界面都应该仅仅使用相应技能集中的这些术语。

如果需要其他术语，可以将其添加到用户角色的技能集之一，或将其添加到属于用户角色的新技能集。

图12.与技能集关联的用户对象和用户构件

　　通过用户任务实现目标

　　用户目标是通过执行用户任务实现的，这些任务可以是手动任务或由一个或多个IT解决方案支持的任务。

用户任务显示在用户模型中，以帮助通过从用户目标到用户任务的“支持任务”关系实现用户目标。

图13.“支持任务”关系

　　通常，用户的目标由一系列用户任务加以支持，如图14中所示。

图14.用户目标和实现此目标所需的用户任务之间的关系

　　为了实现用户目标，可以按照任意顺序多次执行用户任务。

用户任务还可以与多个用户目标关联。

因此，特定的用户任务可能会由多个用户角色执行。

可以将用户任务细分为子任务层次结构，以显示用户任务复杂的情况，或显示两个或更多用户任务之间存在相同子任务的情况。

　　您可以使用“子任务”关系来将复杂用户任务组织为包含若干简单用户任务的层次结构。

图15.“子任务”关系

　　在这种模型中，定义“支持任务”或“子任务”关系的顺序并不指示用户任务执行顺序。

使用解决方案的人员可以使用自己的技能来决定何时适合执行某个任务（如发送电子邮件）。

或者，如果存在逻辑顺序，您可以使用“后续任务”关系来记录此顺序，“后续任务”关系表明用户任务可能的完成顺序。

图16.“后续任务”关系

　　需要自动定序时，可以将用户任务处理为业务流程模型中的步骤。

　　通过其他关系，可以显示支持用户目标的用户任务的结构，如图17中所示。

图17.支持用户目标的用户任务结构

　　有很多用户的模型可能包含很多用户任务。

您可以将相关的用户任务分组为用户域，就像技能集可以分组为规程一样。

用户域可以使用嵌套域关系链接为层次结构，如图18中所示。

图18.由嵌套用户域和用户任务形成的层次结构

　　执行用户任务需要特定的技能。

每个用户任务都与执行此任务所需的技能集之间存在联系。

图19.“所需技能”关系

　　“所需技能”关系允许进行简单的检查，以确保执行特定任务所需的每个用户角色都具有相应的技能。

图20.用户角色、用户目标、技能集和用户任务之间的关系

　　“所需技能”关系可以指向直接与用户角色关联的技能集或其中的嵌套技能集。

嵌套技能集可以提供用户角色的支持任务所需的技能。

图21.嵌套技能集

　　在图22中，用户角色B具有执行用户任务4的技能。

不过，此用户角色只有在用户任务4支持此角色的一个或多个主要目标时才会执行该任务。

图22.用户角色和技能

　　通过用户模型中的关系，您可以：

　　方便地验证用户角色的用户目标可以实现。

　　验证解决方案需要支持的用户任务。

　　确定哪些用户角色需要执行每个用户任务。

　　确认执行用户任务所需的技能与将执行这些任务的用户角色的技能匹配。

　　建模用于完成任务的用户操作

　　对于每个任务，您还要建模用户完成任务时使用的用户对象和用户构件。

您可以使用从用户任务到用户对象的“操作-目标”关系对此进行建模，如图23中所示。

您可以通过在此关系上使用操作关键字建模所执行的操作。

图23.“操作-目标”关系

　　图24显示了具有三个“操作-目标”关系的用户任务。

运行此任务的人员首先选择用户对象A的一个或多个实例，然后对其（包括用户对象B的嵌套实例）进行更新。

最后，用户任务创建用户对象C的一个或多个实例。

图24.用户对象和用户任务间的关系

　　“操作-目标”关系出现在用户任务中的顺序定义其应有的执行顺序。

　　由于用户任务也与技能集关联，因此可以验证该技能集了解这些用户对象，而且二者保持了一致。

图25.验证用户对象一致性

　　创建用户模型的好处

　　完成了用户模型后，可以提供IT解决方案外部化的对象的详细清单，还能了解根据用户角色执行的任务的特征向每个用户公开的对象子集的详细情况。

　　只需要很少的UML知识就能构建用户模型（创建类关系图）。

通过分析解决方案将如何工作获得的宝贵知识的价值将远远超过构建模型所花的成本或时间。

此模型可创建用户交互的准确定义，可以方便地用于检查逻辑一致性。

模型的抽象级别（详细程度）与用户将面临的抽象级别相同。

如果模型变得难于使用或“太过复杂”而不便创建时，则明显地表明所得到的解决方案也会同样过于复杂。

　　创建用户模型的流程揭示了开发团队对用户需求不了解的领域。

而且，此过程还突出了项目定义中存在风险和不足的领域。

完成用户模型之后，可以对用例定义起到促进作用（以用户任务为基础开发），并提供了确定开发和测试规模方面有用的标准，如要支持的用户任务数量等。

　　无论用户模型是完全事先构建的，还是稍早于每个开发迭代开始前构建的，它都为项目的每个迭代提供了坚实的基础。

　　请关注本系列的第2部分，其中将说明如何为支持对Web资源进行安全访问的简单组件创建用户模型。