捕获需求作为用况
引言
按散步来描述需求工作流
- 制品
- 工作人员
- 工作流
制品
需求不会中用到的主要致贫时用况模型，包括用况和参与者。
制品：用况模型
用况模型可以使开发人员和客户在需求方面达成用况。用况模型充当客户和开发人员之间的协议，并作为分析、设计和测试的基本输入。
用况模型使一种包括参与者、用况以及他们之间关系的系统模型。
制品：参与者
用况模型描述了系统能为每种类型的用户做些什么。参与者表示系统外部与系统进行协作的参与者，只要确定了系统的所有参与者就确定了系统的外部环境。
参与者在与之进行协作的用况中充当一个角色。一个参与者实例是与该系统进行交互的一个具体用户。
用况
参与者使用系统的每种方式都可以表示为一个用况。
一个用况是一个类元，这意味着它具有操作和属性。因此，用况说明可以包括状态图、活动图、协作图和顺序图。
一个用况实例是一个用况的行为。通过一个用况的一条路径可以描述如下：
- 用况实例被初始化并进入开始状态。
- 由参与者发出的外部消息激发。
- 通过执行一个动作序列转移到其他状态。这个序列包括内部计算、路径选择和消息输出（给某个参与者）。
- （在新的状态）等待由参与者发出的另一个外部消息。
- （再次）由新消息所激发，一次类推。可能要经理很多状态直至用况实例结束。
用况模型中唯一的交互发生在参与者实例与用况实例之间。其原因是我们希望用况模型简单、直观，以便于最终用户和其他项目给i昂贵人员进行富有成效的讨论而不至于陷入细节。我们承认在对系统的不同使用之间确实存在冲突问题。这些问题不能再用看见没中得到解决，而是要推迟到分析和设计阶段来解决。
事件流
可以将每个永康的事件流捕获为改用看的动作序列的单独文本描述。
特殊需求
特殊需求汇集了一个用况的所有需求的文本描述。他们主要是于用况有关的非功能性需求，需要再后续的工作流中进行处理。
制品：构架描述（用况模型视图）
构架描述包括用况模型的构架视图，描述了对构架重要的用况。
用况模型的构架视图应该包括描述某些重要和关键性功能的用况，或设计某些必须早软件生命周期中尽早实现的重要需求的用况。
该构架视图区分迭代中用况开发的优先次序时用作输入。
相应的用况实现可以再分析和设计模型的构架视图中找到。
制品：术语表
术语表可以用来定义分析人员再描述系统时所用的重要术语和公用术语。术语表有益于开发人员之间就各种概念和观点的定义达成一致，以便能从总体上降低由于误解而产生的风险。
术语表经常可以从业务模型或领域模型中到处。
术语表更侧重于所构造的系统而非系统的语境，业务模型或领域模型则侧重于系统的语境。
制品：用户界面原型
用户界面原型有助于再需求捕获期间理解和确定由人充当的参与者和系统之间的交互。这不仅有助于开发更好的用户界面，而且有助于更好地理解用况。
工作人员
工作人员是一个可以赋给“真正的”人的职位。每个工作人员均是对其职责和与其行为的说明
工作人员：系统分析人员
系统分析人员对模型化为用况的需求的完整集合负责，其中包括可以由用况确定的所有功能性需求和非功能性需求。系统分析人员负责界定系统，确定参与者和用况，并却博爱用况模型时完整的和一致的。出于一致性考虑，系统分析人员可以使用术语表，以便再捕获需求阶段使共用属于、观点和概念得到统一。
在需求捕获中，系统分析人员还作为建模的领导者和协调者。
工作人员：用况描述人员
系统分析人员需要其他工作人员的协助，其中每个人负责对一个或多个用况进行详细描述。这些工作人员称为用况描述人员。
工作人员：用户界面设计人员
用户界面设计人员对用户界面进行可视化定型。它可能涉及为某些用况开发用户界面原型，通常每个参与者对应一个原型。因此，比较合适的时让每个用户界面设计人员为一个或多个参与者定型用户界面。
工作人员：构架设计师
构架设计师也参与需求工作流，以便描述用况模型的构架视图。
工作流
首先，系统分析人员执行“确定参与者和用况”活动来构造包含确定参与者和用况的用况模型的最初版本。系统分析人员应却博爱所开发的用况模型捕获了作为该工作流输入的需求，即特征标和领域模型或业务模型。
然后构架设计师将确定对构架重要的用况，作为区分将在当前迭代中开发的用况（很可能还有其他需求）优先次序的输入。
然后，永康描述人员对所有确定了优先次序的用况进行描述。几乎与此同时，用户界面涉及人员根据用况为每个参与者涉及合适的用户界面。
然后，系统分析人员通过定义用况间的繁华关系重新构造用况模型，以使其尽可能易于理解。
经过该工作流的第一次迭代结果得到了用况模型、用况和所有相关的用户界面原型的最初版本。后续迭代的结果构成了这些制品的新版本。
活动：确定参与者和用况
我们确定永康和参与者的目的时：
- 从其环境中界定系统。
- 概述谁和什么（参与者）将于系统进行交互，概述从系统预期得到哪些功能（用况）。
- 捕获和定义术语表中的公用术语，它们时对系统功能进行详细说明的基础。
这个活动包括四个步骤：
- 确定参与者。
- 确定用况
- 简要描述每个用况。
- 从整体上描述用况模型。
这次活动的结果时包括新的或改变了的参与者和用况的新版用况模型。所得到的用况制品应该从表面上进行简明扼要地描述或图示。
确定参与者
确定参与者的任务依赖于起始点：
- 当开始存在一个业务模型时，确定参与者很简单。系统分析人员可以为业务中的每个工作人员建议一个参与者，也可以为每个使用该信息系统的业务参与者建议一个参与者。
- 否则，不管有没有领域模型，系统分析人员都要与客户一起来确定用户，并设法将他们组织成不同类别来表示参与者。
在这两种情况下，需要将表示外部系统的参与者与用于系统维护和操作的参与者确定下来。
在挑选候选才宇宙时由两个标准非常有用：
- 首先，应该能至少确定一个用户来扮演候选参与者，这有助于我们只获得相关的参与者而避免知识我们想象中的“幻想”的参与者。
- 其次，与系统相关的不同参与者实例所充当的角色之间的重叠应该最少。
系统分析人员为这些参与者命名，并简要描述每个参与者的角色以及参与者使用系统做什么。为参与者确定有关的名字对于表达所期望的语义十分重要。对每个参与者的简要说明应该概况其需求和责任。
确定用况
当起始点时业务模型时，需要为参与业务用况实现和使用该信息系统的每个工作人员所充当的角色涉及一个用况。另外，系统分析人员通过专题讨论会与客户机器用户共同商讨来确定用况。
系统分析人员逐个检查参与者，并为每个参与者涉及候选用况。
为每个用况选择一个名字，由此能想到为参与者增值的具体工作序列。用况的名字通常以一个同此开始，并应该反映出参与者和系统之间的交互索要实现的目标。
有时很难确定用况的范围。用户系统的交互序列可以在一个用况中确定，也可以在参与这逐个引用的几个用况中确定。在决定一个候选用况是否应作为一个单独的用况时，必须考虑它神犇是否完整，或是否总时作为另一个用况的延续。用况会产生一个对具体参与者有价值的可见结果
- 有价值的结果：每个可以成功执行的用况都应该对其参与者提供某些简直，使参与者实现预定目标。
- 具体参与者：通过确定向真正的用户提供价值的用况，可以去报用况不会变得太大。
简要描述每个用况
分析人员在确定用况时，有时候会潦草地写下一些词来说明每个用况，有时知识记下用况的名字。之后，他们首先用几句话来简要描述每个用况，概况用况的动作；然后逐步说明当用况参与其他交互时系统需要完成什么任务。
从整体上描述用况模型
我们准备用况图和说明从整体上解释用况模型，尤其是向说明用况如何彼此相关以及用况如何与参与者相关。
活动：区分用况的优先级
这个活动的目的时为区分用况优先级提供输入，以决定其中哪些用况需要在早期的碟中进行开发，以及哪些用况可以在随后的迭代中进行开发。
活动：详细描述一个用况
细化每个用况的主要目的是为了详细描述其事件流，包括用况如何开始、结束以及如何与参与者进行交互。
活动：构造用户界面原型
该活动的目的时构造用户界面的原型。
我们分几步来完成这项任务：
- 首先，从用况入手，并设法了解为使每个参与者能启动用况需要用户界面提供些什么，即进行逻辑用户界面的设计。
- 然后，在进行实际的用户界面设计并开发出一个原型，以说明用户如何使用系统来执行用况。
进行逻辑用户界面设计
当参与者与系统交互时，他们使用和处理表示属性的用户界面元素。这些属性通常是术语表中的术语。用户界面设计人员通过遍历参与者能访问的所有用况并为每个用况确定适当的用户界面元素，每次为一个参与者确定和说明这些元素。一个用户届满元素可能会参与多个用况，在每个用况中充当一个角色。每个参与者都应该对一下问题作出回答：
- 需要哪些用户界面元素来启动这些用况？
- 用户界面元素彼此之间应该如何相关？
- 如何将他们用在不同的用况中？
- 他们看起来应该像什么？
- 应该如何处理他们？
为了确定参与者可以访问的每个俑坑中需要哪些用户界面元素，我们可以询问一下问题：
- 哪些领域类、业务实体或工作单元适合作为该用户的用户界面元素？
- 参与者用哪些用户界面元素完成工作？
- 参与者可以计划哪些动作，能够做哪些决定？
- 参与者在几号发用况的动作前需要哪些指南和信息？
- 擦浴这需要像系统提供什么信息？
- 系统需要像参与者提供什么信息？
- 说输入/输出的平均值是多少？
进行实际的用户界面设计和构造原型
首先，用户界面设计人员绘制出构成参与者有效用户界面的用户界面元素集的简图。然后，他们描绘将各种用户界面元素组成完整的用户界面所需要的附件元素。
活动：构造用况模型
构造用况模型是为了：
- 提取可以由更具体的用况说明所使用的通用的和共享的功能说明
- 提取可以扩展更具体的说明的补充的或可选的功能说明
确定共享的功能性说明
在去顶并概况每个用况的动作时，还应该确定由多个用况公用的或共享的动作或者部分动作。为了减少冗余，可以将这些共享的部分提取出来并放到一个可以由原先的这些永康重用的单独用况中进行描述。
用况之间的繁华是一种集成，因为被泛化用况的实例可以执行泛化用况中描述的所有行为。
泛化可以用来简化对用况模型的处理和解释，并在整理客户所要求的完整用况时重用“半成品”用况。这样的完整用况称为具体用况。它们由参与者初始化，它们的实例组成了一个由系统执行的完整的动作序列。“版成本”用况的存在只是为了其他用况的重用，并被认为时抽象用况。一个抽象用况本身不能实例化，但一个具体用况的实例可以引用它所重用的抽象用况确定的行为。为了便于理解，我们成这种实例为整整的用况。
确定补充和可选的功能说明
用况之间的另一种关系是扩展关系。扩展模型对用况的动作序列进行了补充。扩展“表现为”补充到用况的原始说明中的内容。
确定用况之间的其他关系
用况之间还存在着其他关系，例如包含关系，为简单期间，可以将这种关系视为一种你扩展关系，对用况提供明显的和无条件的扩展。当包含一个用况时，将对所包含用况的行为序列和属性进行封装，并且进知改变或访问，即只有包含用况的而结果可以利用，这与使用泛化关系象彼时不同的。
- 用况的结果以及它们的关系应经理反应真正的用况
- 需要将每个单独的用况是为一个单独的制品
- 避免从功能上分解用况模型中的用况。
需求工作流小结