Conditions that a software product must satisfy to be accepted by a user, customer, or other stakeholder.

A test that evaluates anticipated usage scenarios to determine the software’s acceptability. Used in agile development both to express details about a user story and to determine whether a user story is fully and correctly implemented.

An analysis model that depicts a process flow proceeding from one activity to another. Similar to a flowchart.

A person performing a specific role, a software system, or a hardware device that interacts with a system to achieve a useful goal. Also called a user role.

A term used for software development methods characterized by continuous collaboration between developers and customers, limited documentation of requirements in the form of user stories and corresponding acceptance tests, and rapid and frequent delivery of small increments of useful functionality. Agile development methods include Extreme Programming, Scrum, Feature-Driven Development, Lean Software Development, and Kanban.

See requirements allocation.

A path through a use case that leads to success but that involves a variation from the normal flow in the specifics of the task or in the actor’s interaction with the system.

The process of classifying requirements information into various categories, evaluating requirements for desirable qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, negotiating priorities, and related activities.

See business analyst.

See product.

The structure of a system, including any software, hardware, and human components that make up the system, the interfaces and relationships between those components, and the component behaviors that are visible to other components.

A statement that is believed to be true in the absence of proof or definitive knowledge.

See quality attribute.

See requirement attribute.

See business analyst.

On an agile project, the prioritized list of work remaining for the project. A backlog can contain user stories, business processes, change requests, infrastructure development, and defect stories. Work items from the backlog are allocated to upcoming iterations based on their priority.

A snapshot in time that represents the current agreed-upon, reviewed, and approved set of requirements, often defining the contents of a specific product release or development iteration. Serves as the basis for further development work.

A collection of data that is characterized as large volume (much data exists), high velocity (data flows rapidly into an organization), and/or highly complex (the data is diverse). Managing big data entails understanding how to discover, collect, store, and process the data quickly and effectively.

The role on a project team that has primary responsibility for working with stakeholder representatives to elicit, analyze, specify, validate, and manage the project’s requirements. Also called a requirements analyst, system analyst, requirements engineer, requirements manager, business systems analyst, and simply analyst.

A software system used to convert large and complex data sets into meaningful information from which to make decisions.

A financial or nonfinancial business benefit that an organization expects to receive as a result of a project or some other initiative.

A visual representation of a hierarchy of business problems and business objectives.

A set of information that describes a business need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes. The business requirements include business opportunities, business objectives, success metrics, a vision statement, and scope and limitations.

A policy, guideline, standard, regulation, or computational formula that defines or constrains some aspect of the business.

The number of instances of a particular data entity that logically relate to an instance of another entity. Possibilities are one-to-one, one-to-many, and many-to-many.

The group of people responsible for deciding to accept or reject proposed changes on a software project, including changes in requirements.

A description of a set of objects having common properties and behaviors, which typically correspond to real-world items (persons, places, or things) in the business or problem domain.

An analysis model that shows a set of system or problem domain classes, their interfaces, and their relationships.

A restriction that is imposed on the choices available to the developer for the design and construction of a product. Other types of constraints can restrict the options available to project managers. Business rules often impose constraints on business operations and hence on software systems.

An analysis model that depicts a system at a high level of abstraction. The context diagram identifies objects outside the system that exchange data with the system, but it shows nothing about the system’s internal structure or behavior.

A software package purchased from a vendor and either used as a self-contained solution to a problem or integrated, customized, and/or extended to satisfy customer needs.

A table that correlates system actions with data entities to show where each data item is created, read, updated, and deleted.

An individual or organization that derives either direct or indirect benefit from a product. Software customers might request, pay for, select, specify, use, or receive the output generated by a software product.

A screen display or printed report that uses multiple textual and/or graphical representations of data to provide a consolidated, multidimensional view of what is going on in an organization or a process.

A collection of definitions for the data elements and data structures that are relevant to the problem domain.

An analysis model that depicts the processes, data stores, external entities, and flows among them that characterize the behavior of data flowing through business processes or software systems.

An agreed-upon way by which a body of people arrives at a decision.

An analysis model in the form of a matrix that shows all combinations of values for a set of conditions and indicates the expected system action in response to each combination.

An analysis model that visually depicts the actions a system takes in response to specific combinations of a set of conditions.

As used in requirements specification, a reliance that a project has on a factor, event, or group outside its control.

An analysis model that depicts a user interface architecture, showing the dialog elements with which the user can interact and the navigations permitted between them.

An analysis model that shows a set of systems that interact with each other and the nature of their relationships. Unlike a context diagram, an ecosystem map shows systems that have a relationship even if there is no direct interface between them.

The process of identifying requirements from various sources through interviews, workshops, focus groups, observations, document analysis, and other mechanisms.

A system that contains hardware components controlled by software running on a dedicated computer that is incorporated as part of a larger product.

An item in the business domain about which data is collected and stored.

An analysis model that identifies the logical relationships between pairs of entities. Used for modeling data.

A user story on an agile project that is too large to implement in one development iteration. It is subdivided into smaller stories that each can be fully implemented in a single iteration.

A trigger or stimulus that takes place in a system’s environment that leads to a system response, such as a functional behavior or a change in state.

A list of the external or time-triggered events that could affect the system and a description of how the system is to respond to each event.

A fully functional prototype created as a skeleton or an initial increment of the final product, which is fleshed out and extended incrementally as requirements become clear and ready for implementation.

A condition that can prevent a use case from concluding successfully. Unless some recovery mechanism is possible, the use case’s postconditions are not reached and the actor’s goal is not achieved.

A construct in which an alternative flow in a use case branches off from the normal flow into a separate extension use case.

An object in a context diagram or a data flow diagram that represents a user class, actor, software system, or hardware device that is external to the system being described but interfaces to it in some fashion. Also called a terminator.

A description of a connection between a software system and a user, another software system, or a hardware device.

A person who is responsible for planning and leading a group activity, such as a requirements elicitation workshop.

One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.

An analysis model that depicts the features planned for a product in a hierarchical tree, showing up to two levels of subfeatures beneath each main feature.

An analysis model that shows the processing steps and decision points in the logic of a process. Similar to an activity diagram.

A measure of software size, based on the number and complexity of internal logical files, external interface files, external inputs, outputs, and queries.

A description of a behavior that a software system will exhibit under specific conditions.

A comparison of the current state to an alternative or potential state for a system, process, or other aspect of a business situation, to identify significant differences between them.

Unnecessary or excessively complex functionality that is specified or built into a product, sometimes without customer approval.

A project in which new software or a new system is developed.

See mock-up.

A construct in which several steps that recur in multiple use cases are factored out into a separate sub-use case, which the other use cases then invoke when needed.

A type of formal peer review that involves a trained team of individuals who follow a well-defined process to examine a work product carefully for defects.

A defect, open question, or decision regarding a requirement. Examples include items flagged as TBD, pending decisions, information that is needed, and conflicts awaiting resolution.

An uninterrupted development period, typically one to four weeks in duration, during which a development team implements a defined set of functionality selected from the product backlog or baselined requirements for the product.

A partial or possible representation of a user interface for a software system. Used to evaluate usability and to assess the completeness and correctness of requirements. Could be executable or could be in the form of a paper prototype. Also called a horizontal prototype.

See dialog map.

A description of a property or characteristic that a system must exhibit or a constraint that it must respect.

The default sequence of steps in a use case, which leads to satisfying the use case’s postconditions and letting the user achieve his goal. Also known as the normal course, main course, basic flow, normal sequence, main success scenario, and happy path.

A suite of scenarios that represents the expected usage pattern of a software product.

A non-executable mock-up of a software system’s user interface using low-tech screen sketches.

An activity in which one or more persons other than the author of a work product examine that product with the intent of finding defects and improvement opportunities.

A controlled execution of a new solution (such as a process, tool, software system, or training course) with the objective of evaluating the solution under real conditions to assess its readiness for general deployment.

A keyword-oriented language developed by Tom Gilb that enables precise and quantitative specification of requirements, particularly nonfunctional requirements.

A condition that describes the state of a system after a use case is successfully completed.

A condition that must be satisfied or a state the system must be in before a use case can begin.

The act of determining which requirements for a software product are the most important for achieving business success and the sequence in which requirements should be implemented.

A step-by-step description of a course of action to be taken to perform a specified activity, describing how the activity is to be accomplished.

A sequence of activities performed for a particular purpose. A process description is a documented definition of those activities.

Items such as templates, forms, checklists, policies, procedures, process descriptions, and sample work products that are collected to assist an organization’s effective application of software development practices.

The sequential steps of a business process or the operations of a proposed software system. Often represented by using an activity diagram, flowchart, swimlane diagram, or other modeling notation.

Whatever ultimate deliverable a project is developing. In this book, product, application, system, and solution are used interchangeably.

See backlog, product.

A designated representative of a specific user class who supplies the user requirements for the group that he or she represents.

A role, typically on an agile project team, that represents the customer and that is responsible for setting the product vision, providing project boundaries and constraints, prioritizing the contents of the product backlog, and making product decisions.

A prototype that implements a portion of a software-containing system that slices through multiple layers of the architecture. Used to evaluate technical feasibility and performance. Also called a vertical prototype.

A partial, preliminary, or possible implementation of a software system. Used to explore and validate requirements and design approaches. Types of prototypes are evolutionary and throwaway; paper and electronic; and mock-up and proof-of-concept.

A nonfunctional requirement that describes a service or performance characteristic of a product. Types of quality attributes include usability, portability, maintainability, integrity, efficiency, reliability, and robustness. Quality attribute requirements describe the extent to which a software product must demonstrate desired characteristics.

See quality attribute.

A hardware and software system that must produce a response within a specified time after an initiating event.

A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.

Descriptive information about a requirement that enriches its definition beyond the statement of intended functionality. Example attribute types are origin, rationale, priority, owner, release number, and version number.

A systematic approach to specifying a particular type of requirement.

The process of apportioning system requirements among various architectural subsystems and components.

See analysis, requirements.

See business analyst.

The process of defining a project’s scope, identifying user classes and user representatives, and eliciting, analyzing, specifying, and validating requirements. The product of requirements development is a set of documented requirements that defines some portion of the product to be built.

See business analyst.

The subdiscipline of systems engineering and software engineering that encompasses all project activities associated with understanding a product’s necessary capabilities and attributes. Includes both requirements development and requirements management.

The process of working with a defined set of requirements throughout the product’s development process and its operational life. Includes tracking requirements status, managing changes to requirements, controlling versions of requirements specifications, and tracing individual requirements to other requirements and system elements.

See software requirements specification and specification, requirements.

A table that depicts logical links between individual functional requirements and other system artifacts, including other functional requirements, user requirements, business requirements, architecture and design elements, code modules, tests, and business rules.

A review in which project participants reflect on the project’s activities and outcomes with the intent of identifying ways to make the next project be even more successful.

The act of using existing requirements knowledge in multiple systems that share some similar functionality.

See peer review.

A condition that could cause some loss or otherwise threaten the success of a project.

An activity that seeks to understand the underlying factors that contribute to an observed problem.

A description of a specific interaction between a user and a system to accomplish some goal. Alternatively, an instance of usage of the system, or a specific path through a use case.

The portion of the ultimate product vision that the current project will address. The scope draws the boundary between what’s in and what’s out for a project that creates a specific release or for a single development iteration.

A condition in which the scope of a project continues to increase in an uncontrolled fashion throughout the development process.

A sequence of activities by which a software product is defined, designed, built, and verified.

A collection of the functional and nonfunctional requirements for a software product.

All of the components delivered by a project to achieve a set of business objectives specified by an organization, including software, hardware, business processes, user manuals, and training.

The process of documenting a software application’s requirements in a structured, shareable, and manageable form. Also, the product from this process (see software requirements specification).

See iteration.

See software requirements specification.

An individual, group, or organization that is actively involved in a project, is affected by its process or outcome, or can influence its process or outcome.

An analysis model that shows the sequence of states that an object in a system goes through during its lifetime in response to specific events that take place, or that shows the possible states of the system as a whole. Similar to a state-transition diagram.

An analysis model that shows in matrix form the various states that a system, or an object in the system, can be in, and which of the possible transitions between states are allowed.

An analysis model that visually depicts the various states in which a system or an object in the system can exist, the permitted transitions that can take place between states, and the conditions and/or events that trigger each transition. Similar to a state machine or statechart diagram.

See user story.

An individual who has extensive experience and knowledge in a domain and who is recognized as an authoritative source of information about the domain.

An analysis model that shows the sequential steps of a business process flow or the operations of a proposed software system. The process is subdivided into visual components called lanes, which show the systems or actors that execute the steps.

A product that contains multiple software and/or hardware subsystems. Colloquially, system also is used interchangeably in this book with application, product, and solution to refer to whatever software-containing deliverable a team is building.

A high-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware.

Abbreviation for to be determined. TBD serves as a placeholder when you know you are missing some requirements information. See issue, requirement.

A pattern to be used as a guide for producing a complete document or other item.

A prototype that is created with the intent of discarding it after it has served its purpose of clarifying and validating requirements and/or design alternatives.

The process of defining logical links between one system element (user requirement, functional requirement, business rule, design component, code module, test, and the like) and another. Also called traceability.

An abbreviation for the Unified Modeling Language, which describes a set of standard notations for creating various visual models of systems, particularly for object-oriented software development.

See scenario.

A description of a set of logically related possible interactions between an actor and a system that results in an outcome that provides value to the actor. Can encompass multiple scenarios.

An analysis model that identifies the actors who can interact with a system to accomplish valuable goals and the various use cases that each actor might be involved with.

A customer who will interact with a system either directly or indirectly (for example, by using outputs from the system but not generating those outputs personally). Also called end user.

A group of users for a system who have similar characteristics and requirements for the system. Members of a user class function as actors when interacting with the system through use cases.

A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. Use cases, user stories, and scenarios are common ways to represent user requirements.

See actor.

A format to capture user requirements on agile projects in the form of one or two sentences that articulate a user need or describe a unit of desired functionality, as well as stating the benefit of the functionality to the user.

The process of evaluating a project deliverable to determine whether it satisfies customer needs. Often stated as “Are we building the right product?”

The process of evaluating a project deliverable to determine whether it satisfies the specifications on which it was based. Often stated as “Are we building the product right?”

See proof of concept.

A statement that describes the strategic concept or the ultimate purpose and form of a new system.

A collection of the business requirements for a new system, including business objectives, success metrics, a product vision statement, and a project scope description.

A model of the software development process in which the various activities of requirements, design, coding, testing, and deployment are performed sequentially with little overlap or iteration.

A kind of throwaway mock-up prototype that is often used for preliminary webpage design.

Any interim or final deliverable created for a software project.