229
Glossary
agile development: class of “lightweight” software development methodologies that
emphasize people over processes and feature a series of short development
increments.
antipattern: a situation involving an identifiable and non-unique pattern of nega-
tive behavior. e solution to an antipattern is called a refactoring.
assertion: a relation that is true at that instant in the execution of the program.
brainstorming: requirements elicitation technique that uses informal sessions with
customers and other stakeholders to generate overarching goals for the
systems.
card sorting: requirements elicitation technique that has stakeholders complete a
set of cards that include key information about functionality. e require-
ments engineer then groups the information logically or functionally.
client: see customer.
COCOMO: a tool that estimates software project effort and duration based on a
set of parameters that characterize the project. COCOMO is an acronym
for COnstructive COst MOdel.
customer: the class (consisting of one or more persons) who is commissioning the
construction of the system. Also called client or sponsor.
design constraint requirement: a requirement related to standards compliance
and hardware limitations.
designer as apprentice: a requirements discovery technique in which the require-
ments engineer “looks over the shoulder” of the customers to enable him
to learn enough about the customer’s work to understand their needs.
discounted payback period: the payback period determined on discounted cash
flows rather than undiscounted cash flows.
divergent goals: an antipattern in which two or more major players in a situation
are working against each other.
domain analysis: any general approach to assessing the “landscape” of related and
competing applications to the system being designed.
domain requirements: requirements that are derived from the application domain.
Extreme Programming (XP): an agile software development methodology.
230 Glossary
ethnographic observation: any technique in which observation of indirect and
direct factors inform the work of the requirements engineer.
feature points: an extension of function points that is more suitable for embedded
and real-time systems.
formal method: any technique that has a rigorous, mathematical basis.
function points: a duration and effort estimation technique based on a set of proj-
ect parameters that can be obtained from the requirements specification.
goal-based approaches: any elicitation techniques in which requirements are rec-
ognized to emanate from the mission statement, through a set of goals that
lead to requirements.
goal-question-metric (GQM): a technique used in the creation of metrics that can
be used to test requirements satisfaction.
group work: a general term for any kind of group meetings that are used during
the requirements discovery, analysis, and follow-up processes. JAD is a
form of group work.
GQM: see goal-question-metric.
informal method: any technique that cannot be completely transliterated into a
rigorous mathematical notation.
internal rate of return (IRR): a way to calculate an artificial “interest rate” for
some investment for the purposes of comparing the investment with
alternatives.
introspection: developing requirements based on what the requirements engineer
thinks” the customer wants.
IRR: see internal rate of return.
JAD: see Joint Application Design.
Joint Application Design (JAD): elicitation technique that involves highly struc-
tured group meetings or mini-retreats with system users, system owners,
and analysts in a single venue for an extended period of time.
laddering: a technique where a requirements engineer asks the customer short
prompting questions (“probes”) to elicit requirements.
metrics abuse: an antipattern in which metrics are misused either through mis-
understanding, incompetence, or malicious intent.
model checker: a software tool that can automatically verify that certain properties
are theorems of the system specification.
negative stakeholders: stakeholders who will be adversely affected by the system.
net present value (NPV): a calculation to determine the value, in todays dollars,
of some asset obtained in the future.
NFR: see non-functional requirement.
non-functional requirement (NFR): requirements that are imposed by the envi-
ronment in which the system is to operate.
NPV: see net present value.
performance requirement: a static or dynamic requirement placed on the soft-
ware or on human interaction with the software as a whole.

Get Requirements Engineering for Software and Systems now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.