Copyright © 2015 University of Alberta.
CLIENT NEEDS AND SOFTWARE REQUIREMENTS
Glossary
Word | Definition |
---|---|
Acceptance Criteria | Simple and specific conditions used to check if a user story has been implemented correctly. |
Acceptance Test | A test that verifies that a requirement has been satisfied. These can be automated or a script for a human to conduct. |
Actor | See Participating Actor. |
Alternate Flow | A sequence of events that is different than the basic flow but results in the same outcome. |
Ambiguous Requirement | A requirement that can be interpreted in more than one way or does not provide all necessary details. |
Analysis, Requirements | An activity to examine the requirements of a product to ensure, for example, that they are clear, complete, and consistent. |
Basic Flow | The sequence of events that occur during a use case. |
Boundary of the System | All the functionalities of a product or system. |
Business Requirement | Those requirements that involve the purpose of the project. |
Business Rule | Constraints on how the project will function. |
Clear, User Story | The requirement is free of ambiguities. |
Client | The person or organization engaging the professional services of the product manager and development team, in order to create a product. |
Client Interactions | Interactions between the software project manager and the development team with clients and users, in active collaboration. Also known as client interactions. |
Cognitive Limitations | A limitation imposed by human memory or thinking. |
Complete, User Story | There are no requirements missing from the backlog. |
Consistent, User Story | There are no requirements that contradict. |
Correct, User Story | A requirement that accurately represents what the product is intended to do. |
Cultural Limitations | A difference in cultural meanings. |
Customer Interactions | See Client Interactions. |
Development Constraints | Requirements which add context for design and implementation of the product. |
Elicitation, Requirements | An activity to discover requirements, by interacting with users, clients, and other stakeholders, investigating their needs, and exploring the ideas and features of a potential product. |
End-User | A person who is going to be directly using a product. |
Epic User Story | A user story which contains descriptions that are too vague or broad, rendering it difficult to estimate how long it will take to finish or how it can be done. |
Exception | Some alternate scenario to the basic flow in which alternate steps are followed. |
External Interface Requirements | Requirements related to how the product is situated within a larger system. |
Feasible, User Story | The requirement can realistically be made with the available resources. |
Functional Requirement | Behaviours that the developed product should do or support. Often expressed as inputs and outputs of the product, or description of the behaviour itself. |
Gathering, Requirements | The passive approach of simply asking the client what they would like done, without discussion or collaboration from the software development team. |
Glossary | A list of terms with definitions that relate to a specific software product. |
Goal, Use Case | The desired outcome once the flow of a use case is complete. |
Human Computer Interaction (HCI) | The science of how end-users interact with technology products. |
Information Flow Diagram | A diagram that depicts how components of a system interact, and the information that is passed among them. |
Involving the User | See Customer Interactions. |
Limitations | Circumstances that restrict the way a person is able to interact with a product. |
Manageable, User Story | The requirement is expressed in such a way that it can be changed without excessive impact on other items. |
Managing Expectations | Making clear to the client what to expect from the product, and not to over-promise what the development team can realistically deliver in the product. Involves defining scope. |
Non-functional Requirement | Requirements which describe how well a product must perform. |
Participating Actor | A role that is involved in the task for a use case. |
Perceptual Limitations | A limitation imposed by the human senses. |
Physical Limitations | A limitation imposed by the way a person physically interacts with a product. |
Physical Product Setting Requirements | Requirements which refer to how the product needs to be designed in order to function in its physical environment. |
Post-Condition | Some condition that is the result of the flow of a use case. |
Pre-Condition | Some condition that needs to occur or exist before the flow of a use case can occur. |
Primary User | A person who is going to be directly using a product. Also known as the end-user. |
Prioritization, Requirements | An activity to organize the list of requirements based upon what is of higher value and should be completed earlier. |
Product Backlog | A set or list of user stories for the product. |
Product Vision | What outlines the value of a product to the client, and its place within the wider market. |
Project Scope | What the project can realistically achieve. |
Quality, Use Case | An expectation of quality that should be met by a use case. |
Realistic | What is achievable considering resources such as time, budget, and technology. |
Requirement | A specific description of a need, such as a desired capability to be implemented in the product. |
Requirements Technical Review and Repair | An exercise where others, preferably outsiders to the project, review the requirements for all of the criteria of user stories. |
Secondary User | A person who will occasionally use a product or who uses it through an intermediary. |
Sensory Limitations | See: Perceptual Limitations |
Simple, User Story | The requirement is free of unnecessary design details and not obscured by proposed solutions to the problem. |
Stakeholder | A person who is affected by or has an effect on the success of a product. |
Story Map | A technique used to organize requirements and help structure a project, by presenting product backlogs in a visual manner, with user stories grouped and prioritized within specific functional categories. |
Storyboard | A sequential, visual representation of interacting with a product. |
Sunny-Day Scenario | The best-case scenario, or a scenario in which everything works as it is supposed to. |
Tertiary User | A person who will be affected by the use of the product or makes decisions about the product. |
Traceable, User Story | The requirement is connected to associated design and implementation artifacts. |
Trigger | An event that triggers the flow of a use case to occur. |
Use Case | A description of a task that an actor performs with the product to achieve a certain goal. |
User Friendly | Describes a product that is easy to use for the primary user. |
User Interface (UI) | Any part of a product that the end-user interacts with. |
User Requirement | Tasks that end-users can accomplish with the product, or what the product can do for the user. |
User Story | A short, structured description of a product requirement that outlines who wants the requirement, what the requirement is, and why the requirement has value. |
Verifiable, User Story | The requirement is testable (can be tested). |
Wireframe | A simple visual representation of the user interface elements of a product. |
客户需求与软件需求
中文术语
以下内容为谷歌翻译,若有纰漏,还请多多指正。
中文 | 释义 |
---|---|
验收标准 | 用于检查用户故事是否已正确实施的简单和特定条件。 |
验收测试 | 验证满足要求的测试。这些可以是自动化的,也可以是脚本供人类操作。 |
演员 | 请参阅参与演员。 |
交替流 | 与基本流程不同但导致相同结果的一系列事件。 |
模棱两可的要求 | 可以用一种以上的方式解释需求或不提供所有必要细节的需求。 |
分析,要求 | 一项检查产品需求的活动,以确保例如它们是清晰,完整和一致的。 |
基本流程 | 用例期间发生的事件顺序。 |
系统边界 | 产品或系统的所有功能。 |
业务需求 | 那些涉及项目目的的需求。 |
业务规则 | 限制项目的运作方式。 |
清除,用户故事 | 该要求没有歧义。 |
客户 | 聘请产品经理和开发团队的专业服务以创建产品的个人或组织。 |
客户互动 | 在积极协作中,软件项目经理和开发团队与客户和用户之间的交互。也称为客户互动。 |
认知局限 | 人类记忆或思维所施加的限制。 |
完整的用户故事 | 积压中没有缺少任何要求。 |
一致,用户故事 | 没有任何矛盾的要求。 |
正确,用户故事 | 准确表示产品用途的要求。 |
文化局限 | 文化意义上的差异。 |
客户互动 | 请参阅客户互动。 |
发展限制 | 为产品的设计和实现添加上下文的要求。 |
启发,要求 | 通过与用户,客户和其他利益相关者进行交互,调查他们的需求并探索潜在产品的想法和功能来发现需求的活动。 |
终端用户 | 将直接使用产品的人。 |
史诗般的用户故事 | 用户故事中包含的描述太模糊或太笼统,很难估计完成或完成需要多长时间。 |
例外 | 基本流程的某些替代方案,其中遵循替代步骤。 |
外部接口要求 | 与产品在较大系统中的位置有关的要求。 |
可行,用户案例 | 可以使用可用资源实际地提出要求。 |
功能要求 | 开发的产品应执行或支持的行为。通常表示为产品的输入和输出,或行为本身的描述。 |
收集,要求 | 被动方式,仅询问客户他们想做什么,而无需软件开发团队的讨论或协作。 |
词汇表 | 带有与特定软件产品相关的定义的术语列表。 |
目标,用例 | 用例流程完成后即可获得预期的结果。 |
人机交互(HCI) | 最终用户如何与技术产品交互的科学。 |
信息流程图 | 描述系统组件如何交互以及在组件之间传递的信息的图。 |
让用户参与 | 请参阅客户互动。 |
局限性 | 限制人与产品互动方式的情况。 |
可管理的用户故事 | 需求以这样一种方式表达,即可以对其进行更改而不会对其他项目产生过多影响。 |
管理期望 | 向客户明确说明对产品的期望,不要过度承诺开发团队可以在产品中实际交付的内容。涉及定义范围。 |
非功能性需求 | 描述产品必须表现的要求。 |
参与演员 | 用例任务中涉及的角色。 |
知觉限制 | 人类感官施加的限制。 |
身体限制 | 人与产品进行物理交互的方式所施加的限制。 |
实物产品设置要求 | 要求指的是产品如何设计才能在其物理环境中运行的要求。 |
后条件 | 用例流程的结果。 |
前提条件 | 用例流程发生之前需要发生或存在的某些条件。 |
主要用户 | 将直接使用产品的人。也称为最终用户。 |
优先顺序,要求 | 一项根据较高价值组织需求清单的活动,应尽早完成。 |
产品积压 | 产品的用户故事集或列表。 |
产品愿景 | 概述了产品对客户的价值及其在更广泛的市场中的地位。 |
项目范围 | 该项目可以实际实现的目标。 |
质量,用例 | 用例应满足的对质量的期望。 |
现实 | 考虑到诸如时间,预算和技术之类的资源,这是可以实现的。 |
要求 | 需求的特定描述,例如要在产品中实现的所需功能。 |
需求技术审查和维修 | 在此练习中,其他人员(最好是项目的外部人员)将审查用户故事的所有标准的要求。 |
二级用户 | 偶尔使用产品或通过中介使用产品的人。 |
感官限制 | 另请:知觉限制 |
简单的用户故事 | 该要求没有不必要的设计细节,并且不会被针对该问题的建议解决方案所掩盖。 |
利益相关者 | 受产品成功影响或对其有影响的人。 |
故事图 | 一种用于组织需求并帮助构建项目的技术,该技术通过以可视方式呈现产品待办事项列表,并将用户故事分组并按特定功能类别划分优先级。 |
故事板 | 与产品交互的顺序,直观表示。 |
晴天场景 | 最佳情况,或一切正常工作的情况。 |
大专用户 | 受产品使用影响或对产品做出决策的人。 |
可追溯的用户故事 | 需求与关联的设计和实现工件相关。 |
触发 | 触发用例流程发生的事件。 |
用例 | 角色为实现特定目标而执行的任务描述。 |
用户友好 | 描述主要用户易于使用的产品。 |
用户界面(UI) | 最终用户与之交互的产品的任何部分。 |
用户要求 | 最终用户可以使用产品完成的任务,或者产品可以为用户完成的任务。 |
用户故事 | 产品需求的简短结构化描述,概述了谁想要该需求,什么是需求以及为什么需求具有价值。 |
可验证的用户故事 | 需求是可测试的(可以测试)。 |
线框 | 产品的用户界面元素的简单直观表示。 |