标签：
actor(参与者) 与产品用例交互的人或自动化系统。参与者也被称为用户或最终用户。
Adjacent development(相邻系统) 向你研究的工作系统提供信息或接收信息的系统（人、组织机构、计算机系统等）。
Agile development(敏捷开发) 利用迭代开发开开发软件的一种方式。存在许多敏捷技术，包括Scrum、极限编程和水晶开发等。我们使用术“迭代”来指所有敏捷或迭代开发。
Agile Manifesto(敏捷宣言) 一组规则，关注向顾客交付能工作的系统、协作式的工作实践和快速响应变化的能力。
Atomic requirement(原子需求) 可测试并为无需进一步分解的一项需求。
Attribute(属性) 一项数据元素，对一个类进行描述（并归属于该类）。也用于表达原子需求的一个部分。
Blastoff(启动) 一种技术，通过建立范围-利益相关者-目标并验证项目的可行性，从而为需求活动奠定基础。
Brown Cow Model(Brown Cow模型) 一种技术，用不同的系统的视角来探讨工作并建模。这些视角是Now、Future、How和What的组合。
Business analyst(业务分析师) 一个角色，负责发现需求并与项目的利益相关者沟通需求。也称为需求分析师、需求工程师和系统分析师。
Business data model(业务数据模型) 一个角色，负责发现需求并与项目的利益相关者沟通需求。也称为需求分析师、需求工程师和系统分析师。
Business event(业务事件) 业务（通常也称为工作）上发生的一些事件，要求做出响应的。例如，“顾客为发票付款”、“卡车报告所以已处理的道路”、”到读取电表读数的时间“、”用户想查找的网站“
Business process model(业务过程模型) 业务过程中过程模型，常用于理解当前的过程，以便进行改进。这样模型可以采用多种表示方法。
Business use case(BUG，业务用例) 工作对业务事件的相应。它包括一些处理过程和存储数据过程，这些是满足业务事件中隐含的需求所需要的东西。
Class(类) 研究的一个上下文范围中的一个物理或抽象实体，有一个或多个属性来存储数据。
Client(客户) 为产品开发付费的人，或者承担项目的组织负责人，也称为出资人（Sponsor）。
Constraint(限制条件) 一种需求，可以是组织上的或技术上的，对产品生产方式进行了限制。它可以是一项管理上的规定，限制了产品设计的方式（”它必须是能在3G手机上运行“），
或是一项预算规定，限制了产品的规模，或是当前的技术特点，限制了可能的解决方案。
Context diagram(上下文范围图) 工作范围的图形模式，展示了调研的工作与外界的联系。
Commercial off-the-shelf products(COTS,商业上架销售产品) 由外部组织机构开发的产品（通常是软件），实现指定范围的功能。
Customer(顾客) 购买该产品的人。
Data dictionary(数据字典) 需求规格说明书中的术语的规格说明（到元素层面）。
Data element(数据元素) 一项数据，定义了研究的上下文范围中的一组值或值的范围。也称为属性。
Dataflow(数据流) 从一个过程转向另一个过程的数据，通常一个命名箭头表示。
Data Model(数据模型) 一个模型，展示了数据的类及其关联。也称为类模型。
Design(设计) 在满足限制条件的前提下，构造满足需求的技术解决方案的行为。
Developer(开发者) 为产品开发做出贡献的人。例如，程序员（常被称为开发者）、设计师、架构师。
Domain analysis(领域分析师) 调研、记录和确定主题事务领域的一般知识的活动。
Essential viewpoint(基本观点) 一种观点，关注规则、策略和数据的任何现实。
Externalevent(外部事件) 由工作范围的相邻系统中发生的事情所触发的事件。例如，”客户想开户“
Fit Ceiterion(验收标准) 需求的量化标准或可度量标准，这样可以决定提交的产品是否满足需求。
Function point(功能点) 软件或工作的功能性一种度量。功能点的概念由Allan Albrecht首先提出来的，今天计算功能点的方法是由国际功能点用户小组(International Function Point User Group)确定的。
Functional requirement(功能需求) 产品必须完成的事情。功能需求是产品基本处理过程的一部分。
Innovation(创新) 关于问题的新思维，或不同的想法，导致发现新的、更好的工作方式。
Iterative development(迭代开发) 有助于多次、持续交付软件解决方案的开发策略。
Naming conventions(命名惯例) 利益相关者在谈论工作时使用的术语（包括缩略语和缩写）。这些术语通常记录在一个词汇表中，就像你正在读的词汇表一样。
Non-functional requirement(非功能需求) 产品必须具备的属性和质量，如外观、速度、安全性和精度属性。
Persona(假象用户) 一个作为用户原型的虚拟人物，用于帮助你发现需求。
Product(产品) 将构造的东西，也是编写需求的目的。在本书中，产品通常指软件产品，但需求也可以针对硬件、消费品、服务和其他任何需要规定的东西。
Product use case(PUC，产品用例) 业务用例中打算自动化的那一部分。你为产品用例编写需求。
Project blastoff(项目启动) 参见Blastoff(启动)
Project goal(项目目标) 做项目的理由。目标必须包括量化的预期收益。
Prototype(原型) 产品的模拟，利用软件原型工具或低保真的白板和纸模型来完成。
Quality gateway(质量关) 在需求进入规格说明书阶段之前，应用的一组测试（相关性测试、二义性测试、可行性测试、适用性测试等）来确保单项需求的质量。
Rationale(理由) 需求的理由。它用于帮助理解需求，常常能揭示出需求的真正意图。
Requirement(需求) 产品必须完成的事情，或必须具备的属性，同时也是相关者想要的东西。
Requirement Analyst(需求分析师) 负责得到需求规格说明的人。需求分析师并不一定负责所有的需求提前工作，但是要负责协调需求的工作。根据组织机构中的角色定义，此人可能被称为业务分析师，系统分析师或需求分析师。
Requirement creep(需求蔓延) 在任务需求已完整之后，无控制地向产品添加新的需求。
Requirement knowledge model(需求知识模型) 一个概念整理汇集系统（通常表示为一个数据模型），建立了沟通需求的通用语言
Requirements Pattern(需求模式) 一组内聚的需求，执行某些可识别的、可重复出现的功能。
Requirements specification(需求规格说明) 特定项目的需求知识的完整集合。需求规格说明定义了产品，并可能作为构建产品的合同。
Requirements specification document(需求规格说明文档) 根据沟通的对象和目的，全部或部分包含需求规格知识的一份文档。
Requirements specification document(需求规格说明模版) 收集和组织需求知识的一份指南。
Requirements tool(需求工具) 能够维护全部或部分需求的规格说明书的一种软件工具。
Retrospective(事后分析) 一种复查，目的是收集经验，并为改进需求过程提供输入信息。也成为”学到的经验“
Scenario(场景) 业务用例或产品用例的一种分解，划分为利益相关者可识别的一系列步骤。场景通常被用于发现和沟通工作知识。
Sketch(草图) 一件工作或建议的产品的快而脏的模型或原型。草图可以采用任何媒质（纸媒、电子或白板），目的是让利益相关者更容易理解和讨论需求。
Snow card(白雪卡) 一张纸卡，展示了原子需求的各项属性。大多数需求团体使用电子版的白雪卡。
Solution(解决方案) 实现需求的一种方式。也称为产品。
Sponsor(出资人) 参见”Client(客户)“
Stakeholder(利益相关者) 产品涉及利益的人，因此他对产品有需求。例如，开发的客户、用户或构建产品的人。某些利益相关者距离要远，如审计员、安全检查员和公司的律师。
System(系统) 业务或工作系统。
System Analysis(系统分析) 对系统功能和数据进行建模活动。系统分析可以通过多种方式来完成：利用DeMarco定义的数据流模型；利用McMenamain和Palmer的事件响应模型；利用
Jacobson的用例模型，后利用任何其他面向对象的方法，最常用的建模语言(UML)表示法。
Technological requirement(技术需求) 仅仅因为所选择的技术而要求的需要。它的存在不是为了满足业务需要。
Thinking above the line(横线上思考) 引出和讨论工作的本质。这种”思考“指的是探索（暂时）没有技术现实限制时的可能性。”横线“是Brown Cow模型中水平线，分离了物理和现实(How)和本质策略(What)。
Time-triggered event(时间触发的事件) 由某种时间相关的策略触发的事件。例如，”到了生成销售报告的时间“。
Trawling techniques(网罗技术) 发现、提取、确定、发明需求的技术。
Use case(网罗技术) 一部分功能，描述了用户/参与者与自动化系统之间的交互。参加Business use case(业务用例)和Produce use case(产品用例)
User(用户) 使用该产品来完成工作的人或系统，也被称为参与者或者最终用户。
User Story(用户故事) 一种发现需求的技术，采用的模式是”作为[.......]我想要[.......]以便能[.......]“。有时称为故事卡片。
Volere 一组规则、过程、模板、工具和技术，目的是改进需求的发现、沟通和管理。(Volere是意大利语，意思是”希望“或”想要“)
Work（工作） 产品打算改进的组织机构的一个业务领域。业务领域分析师研究工作，在决定完成部分或全部的工作的最佳产品。
Work scope(工作范围) 要调查的业务范围，以及围绕它的真实世界。通常表示为上下文范围图。
掌握需求过程(第3版)Mastering the Requirements Process:Getting Requirements Right , Third Edition ——词汇表
标签：
原文地址：http://www.cnblogs.com/HLeng/p/5685241.html
