Glossary Flashcards
(101 cards)
1
Q
Actor
A
Part of a use case diagram. A role, thing, event/timer, or external system that interacts with the proposed system. The actor either stimulates the system (provides input) or receives output. An actor is outside the system documented in the use case diagram.
2
Q
Analysis
A
Taking elicited information and making sense of it, bridging from the existing situation to the new requirements. Deriving and refining elicited requirements in a repetitive, systematic way.
3
Q
Association
A
Part of a use case diagram. Actors are connected to use
cases by associations. They are lines between the two, showing which actions (use cases) each actor is involved with.
4
Q
Business requirements:
A
High-level considerations applicable at the client’s
organizational or department level that describe their overall goals, objectives, scope, justification, constraints, and stakeholders.
5
Q
Capability
A
Something the new system needs to do. Capability equates to functionality.
6
Q
Capability Maturity Model Integrated (CMMI)
A
A road map to process improvement, originated by the Software Engineering Institute located at Carnegie Mellon University (Pittsburgh, Pennsylvania, U.S.). Has five levels or stages that organizations go through to improve their processes.
7
Q
Champion
A
A stakeholder who ensures the project goes through. Pushes through and resolves any barriers.
8
Q
Configuration control board (CCB)
A
A group of people, including project
manager, developers, end users, quality assurance representatives, and configuration management representatives, who meet periodically to assess
all change (enhancement, defect/bug) requests. The CCB determines whether the changes will be made, deferred, or not addressed based on business, technical, and user criteria.
9
Q
Configuration Management (CM)
A
A documented procedure and process applied to control changes in functional and physical characteristics applied to all project and product deliverables, including the requirements. Prevents
unauthorized changes to the baselined requirements, and preserves revisions to the requirements documents.
10
Q
Constraint
A
A type of non-functional requirement that puts limits or bounds on something. For example: “System must handle at least 300 queries an hour.” “System must cost no more than $100,000.”
11
Q
Customer
A
The individual or organization that pays for the project results or system. May or may not be the sponsor, end user, or champion.
12
Q
Developer
A
Anyone involved on a project on the IT (information technology) side, including (but not limited to) business analysts, requirements elicitors, system analysts, designers, programmers, testers, quality assurance and
configuration management experts.
13
Q
Elicitation
A
The concept that gathering requirements involves more than just holding out your arms and expecting the stakeholders to throw you the requirements. Gathering the requirements involves really probing the users
and really understanding what they need and why they need it.
14
Q
End user
A
A stakeholder that directly or indirectly interacts with the system by providing input or using output.
15
Q
Functional requirement
A
What the system must do from the user’s perspective; i.e., capabilities provided to users and other interested parties.
16
Q
Gap analysis
A
The process of identifying the difference (“gap”) between where your client is today, and where the client wants to be in the future, and of then identifying the new functionality to minimize or eliminate the gap.
The “gap” is best described in terms of a measurable quantity with units, such as time, but not as a percentage.
17
Q
JAD
A
Joint Application Development
18
Q
Joint Application Development
A
A formal technique involving stakeholders and developers working in a team environment to gather and document the requirements via an intense workshop. Also known as an accelerated and collaborative requirements development process.
Developed by IBM Canada. (This term is sometimes used informally for any accelerated team approach to requirements capture.)
19
Q
CMMI
A
Capability Maturity Model Integrated
20
Q
CCB
A
Configuration control board
21
Q
CM
A
Configuration Management
22
Q
Kano’s requirements
A
Look at both the spoken and unspoken user’s
requirements for a product, service, or process. Focus on the positive aspects of quality as perceived by the user: normal, expected, and exciting requirements. Part of Quality Function Deployment (QFD).
23
Q
Key process areas (KPAs)
A
The main component of the CMMI. The
processes that an organization needs to focus on. For example, to move to Level 2, an organization focuses on six KPAs, then on seven more KPAs to move to Level 3. The KPAs are split between software engineering (e.g.,
software quality assurance, requirements management) and project
management. Requirements management is a Level 2 KPA.
24
Q
KPAs
A
Key process areas
25
Non-functional requirement
Define characteristics of the system or product as a whole. Non-functional requirements support the functional requirements in areas including security, performance, availability, reliability, and resistance to failure, capacity, and more. Constraints are a major type
of non-functional requirement.
26
PRINCE, PRINCE2
Projects In Controlled Environments is a project
management method covering the organization, management, and control of projects. PRINCE was first developed in 1989 in the UK for IT project management. The latest version of the method, PRINCE2, enhances the method toward a generic, best-practice approach for the management of all types of projects.
27
Product scope
Product scope defines the features and functions that
characterize a product or service. The product requirements define the scope of the product, starting with the problem to be solved and the vision to be achieved through the solution of that problem.
28
Project scope
Project scope is defined by the work that must be done to deliver a product with the specified features and functions. Project scope is stated in a set of project requirements that include the product requirements,
the developers, the language used, the deadline imposed on the project, and the testers. Project requirements incorporate the full development life
cycle, of which the requirements development is one phase.
29
Prototype
An interactive model of a system that allows users to try out features before they are actually implemented in the system. Involves users and developers interacting to refine the model. Prototypes may be paper based or computer-based.
30
QFD
Quality Function Deployment
31
Quality Function Deployment (QFD)
A methodology to develop or refine a product, service, or process. Started in Japan in the 1960s, it is
implemented in both manufacturing and service industries. The work is carried out by a cross-functional team within the organization, focusing on what features matter most to the customer or user of the product or service.
32
Real requirements
Reflect the derived needs of users after structured and
| collaborative analysis is finished.
33
Requirement
A requirement is a thing that is needed or wanted; a
statement defining a capability, characteristic, or constraint for a product, service, or event. Requirements define capabilities needed by a user to solve a problem to achieve an objective. These capabilities must be met or possessed by a product to satisfy a contract, standard, specification, or other formally imposed documentation.
34
Reverse engineering
Starting with code and working backward through
the life cycle to derive the design, then the analysis models, and finally the requirements for a project. Used on legacy systems that have no (or inadequate) documentation.
35
Role
The traits that an actor in a use case undertakes. Roles, not individual people or things, are modeled in use case diagrams. For example, an adult in the role of a parent, puts a child to bed, makes lunches, and drives to sporting events. That same adult in the role of employee goes to work and earns a paycheck.
36
Scope
Defines the boundaries for the proposed project, the sum of the products and services to be provided as a project. Scope definition sets the framework for the subsequent requirements development activities.
37
SWE
Software engineering
38
Software engineering (SWE)
The application of proven engineering principles to software development. Applies the laws of computer science to solving business problems.
39
Software Engineering Institute (SEI)
A group at Carnegie Mellon University (started in the 1980s) was funded by the U.S. Department of Development to identify best practices in organizations that were delivering quality software. Led to the CMM and CMMI, which the SEI still oversees.
See the website: www.sei.cmu.edu/.
40
Software requirement
Provide a detailed definition of the software components of a system. “The software shall …”
41
Specification
Formally documenting written, well-formed requirements using organizational templates and checklists for structure and content. Written for an intended audience for a specific purpose relative to the
scenarios in which the documents will be used.
42
Sponsor
A type of stakeholder such as the one who oversees and supports the project, often at the executive management level.
43
Stakeholder
Anyone with a vested (substantive) interest in the project. Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They exercise influence over the project and its results and contribute to requirements development activities.
44
Stated requirements
Provided by the users at the beginning of our requirements elicitation and analysis efforts.
45
System requirement
Define what is needed from the system’s perspective: “The system shall…”
46
Traceability
The degree to which a relationship can be established between two or more products of the development process.
47
Traceability matrix
A table or mapping between two statements, two requirements, two paragraphs, two “chunks” (sections) of code, etc. If downward traceability is complete through the entire life cycle, no requirements are dropped. If upward traceability is complete, no unneeded capabilities (requirements, design statements, code, test cases, etc.) have been added.
48
Use case
A set of capabilities that define the user’s needs. One passes through a system. A transaction, process, or set of steps in a logical order. Each use case, written as a verb phrase (e.g., pay for phone calls, withdraw
money from ATM, process inventory) is a set of functional requirements grouped into logical scenarios from the user’s perspective. Use cases only capture functional user requirements—not system or software requirements, nor non-functional requirements of any type. A set of use cases + actors + associations + system boundary make up a graphical use case diagram of the system.
49
Use case description
A paragraph of text explaining the details of any one use case and the source of the actual user functional requirements.
50
Use case diagram
A graphical set of use cases, actors, associations, and a system boundary to capture the user’s requirements for a system.
51
User persona
An instantiation of a user profile describing one or more
| mythical users for each user group. Based on information gathered during requirements elicitation.
52
User profile
A free-form description of user attributes as deemed relevant by the analysts for each identified user group. Based on information gathered during requirements elicitation.
53
User requirements
A generic term encompassing the functional and nonfunctional requirements that come directly from researching the stakeholders (as in Method 503F). “The user shall…”. The user requirements are refined into the system and software requirements during the analysis phase (which follows the user requirements phase of a project).
54
Validation
Confirming with the stakeholders and the team that the
documented requirements are consistent, complete, and accurate. Getting formal agreement that the real requirements are present in the requirements specification.
55
Part of a use case diagram. A role, thing, event/timer, or external system that interacts with the proposed system. The ____ either stimulates the system (provides input) or receives output. ______ is outside the
system documented in the use case diagram.
Actor
56
Taking elicited information and making sense of it, bridging from the existing situation to the new requirements. Deriving and refining elicited requirements in a repetitive, systematic way.
Analysis
57
Part of a use case diagram. Actors are connected to use
| cases by _____. They are lines between the two, showing which actions (use cases) each actor is involved with.
Association
58
High-level considerations applicable at the client’s
organizational or department level that describe their overall goals, objectives, scope, justification, constraints, and stakeholders.
Business requirements
59
Something the new system needs to do. ____ equates to functionality.
Capability
60
A road map to process improvement, originated by the Software Engineering Institute located at Carnegie Mellon University (Pittsburgh, Pennsylvania, U.S.). Has five levels or stages that organizations go through to improve their processes.
Capability Maturity Model Integrated (CMMI)
61
A stakeholder who ensures the project goes through. Pushes through and resolves any barriers.
Champion
62
```
A group of people, including project manager, developers, end users, quality assurance representatives, and configuration management representatives, who meet periodically to assess
all change (enhancement, defect/bug) requests. The _____ determines whether the changes will be made, deferred, or not addressed based on business, technical, and user criteria.
```
Configuration control board (CCB)
63
A documented procedure and process applied to control changes in functional and physical characteristics applied to all project and product deliverables, including the requirements. Prevents unauthorized changes to the baselined requirements, and preserves revisions to the requirements documents.
Configuration Management (CM)
64
A type of non-functional requirement that puts limits or bounds on something. For example: “System must handle at least 300 queries an hour.” “System must cost no more than $100,000.”
Constraint
65
The individual or organization that pays for the project results or system. May or may not be the sponsor, end user, or champion.
Customer
66
Anyone involved on a project on the IT (information technology) side, including (but not limited to) business analysts, requirements elicitors, system analysts,
designers, programmers, testers, quality assurance and
configuration management experts.
Developer
67
The concept that gathering requirements involves more than just holding out your arms and expecting the stakeholders to throw you the requirements. Gathering the requirements involves really probing the users and really understanding what they need and why they need it.
Elicitation
68
A stakeholder that directly or indirectly interacts with the system by providing input or using output.
End user
69
What the system must do from the user’s perspective; i.e., capabilities provided to users and other interested parties.
Functional requirement
70
"Term X"
is the process of identifying the difference (" term y") between where your client is today, and where the client wants to be in the future, and of then identifying the new functionality to minimize or eliminate the gap.
"Term y" is best described in terms of a measurable quantity with units, such as time, but not as a percentage.
Gap analysis
| "gap"
71
A formal technique involving stakeholders and developers working in a team environment to gather and document the requirements via an intense workshop. Also known as an accelerated and collaborative requirements development process.
Developed by IBM Canada. (This term is sometimes used informally for any accelerated team approach to requirements capture.)
Joint Application Development (JAD)
72
Look at both the spoken and unspoken user’s
requirements for a product, service, or process. Focus on the positive aspects of quality as perceived by the user: normal, expected, and exciting requirements. Part of Quality Function Deployment (QFD).
Kano’s requirements
73
The main component of the CMMI. The processes that an organization needs to focus on. For example, to move to Level 2, an organization focuses on six ____s, then on seven more ____s to move to Level 3. The ___s are split between software engineering (e.g., software quality assurance, requirements management) and project management. Requirements management is a Level 2 ___
Key process areas (KPAs)
74
Define characteristics of the system or product as a whole. Non-functional requirements support the functional requirements in areas including security, performance, availability, reliability, and resistance to failure, capacity, and more. Constraints are a major type
of non-functional requirement.
Non-functional requirement
75
Projects In Controlled Environments is a project
management method covering the organization, management, and control of projects. ______ was first developed in 1989 in the UK for IT project
management. The latest version of the method, ____, enhances the method toward a generic, best-practice approach for the management of all types of projects.
PRINCE, PRINCE2
76
_____ defines the features and functions that characterize a product or service. The product
requirements define the scope of the product, starting with the problem to be solved and the vision to be achieved through the solution of that problem.
Product scope
77
_____ is defined by the work that must be done to
deliver a product with the specified features and functions. _______ is stated in a set of project requirements that include the product requirements,
the developers, the language used, the deadline imposed on the project, and the testers. Project requirements incorporate the full development life cycle, of which the requirements development is one phase.
Project scope
78
An interactive model of a system that allows users to try out features before they are actually implemented in the system. Involves users and developers interacting to refine the model. ________s may be paperbased or computer-based.
Prototype
79
A methodology to develop or refine a product, service, or process. Started in Japan in the 1960s, it is implemented in both manufacturing and service industries. The work is carried out by a cross-functional team within the organization, focusing on what features matter most to the customer or user of the product or service.
Quality Function Deployment (QFD)
80
_____ reflect the derived needs of users after structured and collaborative analysis is finished.
Real requirements
81
A _____ is a thing that is needed or wanted; a statement defining a capability, characteristic, or constraint for a product, service, or event. Requirements define capabilities needed by a user to solve a problem to achieve an objective. These capabilities must be met or possessed by a product to satisfy a contract, standard, specification, or other formally imposed documentation.
Requirement
82
Starting with code and working backward through
the life cycle to derive the design, then the analysis models, and finally the requirements for a project. Used on legacy systems that have no (or inadequate) documentation.
Reverse engineering
83
The traits that an actor in a use case undertakes. _____s, not individual people or things, are modeled in use case diagrams. For example, an adult in the _____ of a parent, puts a child to bed, makes lunches, and drives to sporting events. That same adult in the ____ of employee goes to work and earns a paycheck.
Role
84
Defines the boundaries for the proposed project, the sum of the products and services to be provided as a project. _____ definition sets the framework for the subsequent requirements development activities.
Scope
85
The application of proven engineering principles to software development. Applies the laws of computer science to solving business problems.
Software engineering (SWE)
86
A group at Carnegie Mellon University (started in the 1980s) was funded by the U.S. Department of Development to identify best practices in organizations that were delivering quality software. Led to the CMM and CMMI, which the _____ still oversees.
Software Engineering Institute (SEI)
87
Provide a detailed definition of the software components of a system. “The software shall …”
Software requirement
88
Formally documenting written, well-formed requirements using organizational templates and checklists for structure and content. Written for an intended audience for a specific purpose relative to the
scenarios in which the documents will be used.
Specification
89
A type of stakeholder such as the one who oversees and supports the project, often at the executive management level.
Sponsor
90
Anyone with a vested (substantive) interest in the project. Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They exercise influence over the project and its results and contribute to requirements development activities.
Stakeholder
91
Provided by the users at the beginning of our requirements elicitation and analysis efforts.
Stated requirements
92
Define what is needed from the system’s
| perspective: “The system shall…”
System requirement
93
The degree to which a relationship can be established between two or more products of the development process.
Traceability
94
A table or mapping between two statements, two
| requirements, two paragraphs, two “chunks” (sections) of code, etc.
Traceability matrix
95
A set of capabilities that define the user’s needs. One passes through a system. A transaction, process, or set of steps in a logical order. Each ____, written as a verb phrase (e.g., pay for phone calls, withdraw money from ATM, process inventory) is a set of functional requirements grouped into logical scenarios from the user’s perspective. Use cases only capture functional user requirements—not system or software requirements,
nor non-functional requirements of any type. A set of use cases + actors +
associations + system boundary make up a graphical use case diagram of
the system.
Use case
96
A paragraph of text explaining the details of any one
| use case and the source of the actual user functional requirements
Use case description
97
A graphical set of use cases, actors, associations, and
| a system boundary to capture the user’s requirements for a system
Use case diagram
98
An instantiation of a user profile describing one or more
| mythical users for each user group. Based on information gathered during requirements elicitation
User persona
99
A free-form description of user attributes as deemed relevant by the analysts for each identified user group. Based on information gathered during requirements elicitation.
User profile
100
A generic term encompassing the functional and nonfunctional requirements that come directly from researching the stakeholders (as in Method 503F). “The user shall…”. The user requirements are refined into the system and software requirements during the analysis phase (which follows the user requirements phase of a project).
User requirements
101
Confirming with the stakeholders and the team that the
documented requirements are consistent, complete, and accurate. Getting formal agreement that the real requirements are present in the requirements specification.
Validation
