- actor
The person or automated system that interacts with a product use case. Actors are also known as users and end users.
- adjacent system
A system (person, organization, computer system) that provides information to, or receives information from, the work that you are studying. You need to study the adjacent system to understand how it communicates as well as why it communicates with the work.
- agile Manifesto
A set of principles that focuses on the delivery of working softwareto the customer, collaborative working practices, and the ability to respond rapidly to change.
- blastoff
A technique for building the foundation for the requirements activity by establishing the scope-stakeholders-goals trinity and verifying the viabilityof the project.
- business event
Something that happens to the business (usually called "the work") that makesit respond. Examples: "Customer pays an invoice," "Truck reports allroads have been treated," "Time to read electricity meters," "Surfer wants to search Web site."
- business use case
The work's response to a business event. It includes the processes and the stored data needed to satisfy the request implicitin the business event. See also Product use case.
- client
The person who pays for the development of the product, or who has organizational responsibility for the project. Also known as the sponsor.
- constraint
A requirement, either organizational or technological, that restrictsthe way you produce the product. It may be a management edict on the way the product must be designed"It must work on a 3G mobile phone"or a budget that limits the extent of the product.
- context
The subject matter, people, and organizations that affect the requirements for the product. The context of study, or the work context, identifies the business to be studied and the adjacent systems that interact with this work. The product context identifies the scope of the product and its interactions with users and other systems.
- customer
A person who buys the product.
- data flow
Data that moves from one process to another. Usually represented by a named arrow.
- design
The act of crafting a technological solution to fit the requirements, within the constraints.
- developer
Someone who contributes to the technological development of the product. Examples: designer, tester, programmer.
- event-driven use case
The work done by the product in response to a business event. Once the desired response to a business event is established, the requirements analyst and the designer determine how much of that response will be done by the automated product. The use case is a convenient way of identifying a user and a group of requirements that carry out a specific task for that user.
- fit criterion
A quantification or measurement of the requirement such that you are able to determine whether the delivered product satisfies (fits) the requirement.
- function point
A measure of the functionality of the work or a piece of software. Functionpoints were first proposed by Allan Albrecht; today the method for countingfunction points is specified by the International Function Point User Group.
- functional requirement
Something that the product must do. Functional requirementsare part of thefundamental processes of the product.
- nonfunctional requirement
A property or quality that the product must have, such as an appearance, speed, security, or accuracy property.
- product
That which you are about to build, and for which the requirements are written. In this book, "product" usually means a software product, but the requirements can be for any kind of product.
- product use case
The part of the business use case you decide to automate. You write the requirements for the product use case. See also Business use case.
- project goal
The reasons for doing the project, including a quantification of the expected benefit.
- prototype
A simulation of the product using either software prototyping tools, low-fidelity whiteboards, or paper mock-ups. The prototype is intended to make iteasier for stakeholders to understand and describe their requirements.
- quality gateway
Application of a set of tests (e.g., relevance, ambiguity, viability, fit) to assure the quality of individual requirements before the requirements become part of the requirements specification.
- rationale
The justification for a requirement. It is used to help understand a requirement, and sometimes reveals the real intention of the requirement.
- Requirement
Something that the product must do, or a property that the product must have, and that is needed or wanted by the stakeholders.
- requirements analyst
The person who has responsibility for producing the requirements specification. The analyst does not necessarily do all of the requirements elicitation, but is responsible for coordinating the requirements effort. Depending on how roles are defined in an organization, this individual might be referred to as a business analyst, systems analyst, or requirements engineer.
- requirements pattern
A cohesive collection of requirements that carry out some recognizable and potentially recurring functionality.
- requirements specification
A complete collection of requirements knowledge for a specific project. The specification defines the product and may be used as a contract to build the product.
- Requirements specification document
A document that contains all or part of the requirements specification knowledge depending on who and why the knowledge is being communicated.
- requirements specification template
A guide for gathering and organizing requirements knowledge. See Appendix B for an example.
- requirements tool
A software tool capable of maintaining all or part of the requirements specification.
- retrospective
-
A review designed to gather experience and provide input into improving the requirements process.
- scenario
A breakdown of a business use case, or a product use case, into a series ofstakeholder-recognizable steps. Scenarios are used for discovering and communicating work knowledge.
- sponsor
See Client
- stakeholder
Any person who has an interest in the product and therefore has requirements for it, such as the client, a user, and someone who builds the product. Some stakeholders are remote, such as an auditor, a safety inspector, and the company lawyer.
- system
In the context of this book, a business system (not just the computer or the software system).
- systems analysis
The craft of modeling the system's functions and data. Systems analysis canbe done in several ways: data flow modeling, as defined by DeMarco; eventresponse modeling, as per McMenamin and Palmer; use cases, as per Jacobson;orany of the many object-oriented methods, most of which use the Unified Modeling Language notation. See the Bibliography for references.
- technological requirement
A requirement that is necessary only because of the chosen technology. It is not there to satisfy a business need.
- trawling techniques
Techniques for discovering, eliciting, determining, and inventing requirements.
- user
The person or system that manipulates the product. Also known as an actor or end user.
- volere
A set of principles, processes, templates, tools, and techniques developedto improve the discovery, communication, and management of requirements.
- work
A business area of the organization that you have to understand. Also, the work the user is intended to do. The product is to become a part of this work.
- work context
The extent of the business area under investigation, and the real world that surrounds it.
|
