Glossary

This glossary gives definitions of terms and acronyms used in this book. It is in the form suggested in the "Glossary" section in Chapter 2, "The Contents of a Requirements Specification." This book introduces no acronyms of its own.

Open table as spreadsheet

Term	Definition
ACID	Properties possessed by any reliable database, in order to provide information integrity: Atomic-any change is made either completely or not at all; Consistent-whichever way you look at the data you get the same picture; Isolated-no change is affected by any other change that's in progress but not yet completed; and Durable-any completed change stays there.
Actor	A role that a person (or other autonomous entity) plays in a system. One person can play several actors (contrary to any preconceptions you might have from watching theatrical actors). An actor is portrayed as a stick figure (again, unlike thespians). "Actor" is a UML term used primarily with use cases.
Administrative data	Data used to keep a system running smoothly. Examples are counters such as the last-used customer number, and the time that month-end processing was last performed. Administrative data is either global or associated with a type of living entity (such as a customer's last order number).
Agile	A software development outlook that aims to be lean and flexible by valuing people over processes, software over documentation, collaboration over contracts, and responsiveness over plans. Being adept at reacting to the unexpected, an ability especially prized if one doesn't take the trouble to find out what to expect.
Analyst	A person responsible for gathering, analyzing, specifying, and managing changes to requirements. This book uses "analyst" to mean exclusively a requirements analyst (also sometimes called a requirements engineer). Analysts are sometimes divided into business analysts and systems analysts, mainly depending on whether or not they come from a technical background.
Archive	To archive is to move or copy a body of data from one medium of permanent storage to another. The "body of data" archived can be any subset of the available data. The backing up of a whole database is expressly excluded: it is not archiving.
Assumption	A statement that something can safely be treated as fact, as an axiom that can be depended upon (in the context of the system).
ATM	Automated Teller Machine. An example of a device that authenticates a user by means of both something they have (a bank card) and something they know (a PIN).
Authentication	The process by which a registered user says who they are and proves it to a system's satisfaction.
Authorization	An authorization grants a user or class of users permission to perform a particular action or set of actions or to access particular resources.
Availability window	A system's normal hours of operation. For a company internal system running from 9 a.m. to 5 p.m., a day's average throughput is crammed into eight hours; for an always-open Web system, it is spread over 24 hours per day. (See the availability requirement pattern in Chapter 9, "Performance Requirement Patterns.")
Back office	The behind-the-scenes people and activities of a business (unsung heroes).
Business rule	A definition of an aspect of how a business operates. For example, a business rule could define how the business should act in a particular situation (such as when a customer credit card payment is rejected) or define a constraint (such as a limit on the size of payments an employee can approve).
Check digit	A digit calculated from a number and then appended to the number. It is used as a simple way to spot most errors when the number is typed in. If any digit is keyed in wrongly, there is roughly a 90 percent chance that the check digit calculated for the number keyed in will be wrong-so the user can be prompted to correct the number.
Configuration	Parameters that control how a system behaves. Examples are sales tax rates and bank account types. See the configuration requirement pattern in Chapter 7, "Data Entity Requirement Patterns."
Constraint	A restriction on how a system can be implemented. A constraint can restrict either the way the system can be built (for example, the programming language to use) or it can restrict some aspect of the delivered system itself (such as the technology it can use in production).
Co-ordinated change	One of a collection of related changes to information that all need to be applied at exactly the same time. For example, when a retail business changes its pricing schedule-raising some prices, lowering others, modifying discount rates, introducing a range of special offers-it will want them all to happen at once in a big bang, not in dribs and drabs.
CPU	Central Processing Unit. That part of a computer that performs the real computational work and where all the worst mistakes happen.
CRUD	Create, Read, Update, Delete: the fundamental operations performed on a unit of data in a database.
CSV	Comma Separated Value. A simple file format in which a comma is used to distinguish individual values from one another, convenient for loading into a spreadsheet.
Customer	A person or organization who commissions a system. (In this context, they are the customer of the team that delivers the system.) A person who makes purchases using the system; a type of user. (In this context, they are the customer of the organization that operates the system.)
Dependency	A reliance that one requirement has upon another requirement. See "external dependency."
Derived data	Data computed from other kinds of data. Examples are daily order totals and total balances for each account type. Derived data can be identified by asking the question, "If I lost it, would I be able to regenerate it from the other data available?" In theory, you can regenerate all derived data from the data it is based on, though in practice it demands a sound database design (so there's some risk!). See the introduction to Chapter 7.
Divertive requirement pattern	A requirement pattern that attempts to divert the analyst away from an obvious-but bad or inappropriate-way of framing a requirement and towards a better way.
Domain	See "Requirement pattern domain."
Downtime	Time during which the system is unavailable to users when it is scheduled to be available. (Also a time when some users can feel down, while others nip out for a coffee or cigarette.) Note that according to this definition, scheduled routine maintenance does not count as downtime, even though users might want to use the system while scheduled maintenance is being performed.
EFTPOS	Electronic Funds Transfer at Point of Sale. A big name for a little box that lets a retailer debit a customer's credit or debit card. A candidate for the ugliest acronym widely inflicted on the general public.
External dependency	A factor that a system depends upon but which is outside the system's control. (See the "Major Assumptions" section in Chapter 2.)
Extreme programming	A lean, agile approach to software development in which "user stories" and detailed test cases take the place of traditional specifications. See the "An Extreme Requirements Process" section in Chapter 1, "Crash Course in Specifying Requirements."
Fee	An amount of money charged by one party to another for some kind of service.
Follow-on requirement	A requirement that specifies additional details for an original requirement that it follows.
Functional requirement	A requirement that defines a function that the system must possess (an activity it must be able to perform, something it must be able to do).
Gold-plating	Features that confer no practical benefit Features that a particular person wants excluded and which they wish to denigrate The second usage is the more common.
Historic data	Old, inactive data that is no longer affects current business, but needs to be retained for legal or future investigative reasons.
HTML	HyperText Markup Language. A language designed to let nuclear physicists share their research papers and that is later pumped full of steroids to carry all the information in the world.
ID	A unique identifier for some type of entity.
Infrastructure	An underlying set of capabilities needed to support one or more types of requirements.
Invisible ID	An ID that is used internally by the system in order to function, but which is not normally visible to users. For example, if we wanted to give customers the option of changing their customer ID, we could assign them a second, invisible customer ID that never changes.
ISO	International Organization for Standardization. An international standards organization. You have to pay money for copies of its standards. It lives at http://www.iso.org.
IT	Information Technology. The wide range of expertise, hardware, and software needed to manage (or to mess up or lose) large quantities of information.
JAD	Joint Application Development. An approach to specifying the requirements, user interface, and other high-level aspects of a new system through dedicated sessions involving executives, users, and developers.
LDAP	Lightweight Directory Access Protocol. A standard for components used to enable computers to find things, typically used to find organizations, people, and other computers using addresses of various kinds (such as names, email addresses, and phone numbers). The standard itself resides at http://www.ietf.org/rfc/rfc1487.txt. It is called "lightweight" because its parent, the X.500 standard, is even bigger.
Living entity	An entity that has a lifespan: it is created, might be modified many times, and is eventually terminated. Examples are a bank account and a shop customer. (Termination means purely as far as a system is concerned; physical assassination is not involved.) Any entity that is for configuration purposes should be categorized as configuration rather than as a living entity, though it can enjoy a lifespan in the same way. See the living entity requirement pattern in Chapter 7.
Middleware	Software of indeterminate extent used to tie the major components of a system together-in particular, allowing the parts of a distributed system to communicate with each other.
Nonfunctional requirement	A requirement that defines some characteristic that a system must possess, but which is not something the system must be able to do (a function). Requirements do not divide neatly into functional and nonfunctional. A high-level nonfunctional requirement could lead to the defining of functions to deliver parts of it. (For example, a performance goal might lead to functions that help to achieve it). Similarly, a requirement for a function might have a follow-on requirement that defines a nonfunctional characteristic that the function must possess (restricting access to it, say).
ODBC	Open DataBase Connectivity. A standard for an application programming interface (API) produced by Microsoft for accessing a database.
Offline storage	A permanent storage medium that can be removed from a device that produces and/or reads it and that can be placed in a secure physical container (for example, a tape that can be locked in a safe).
Organization unit	Any subset of an organization that makes it easier to manage. It is a concrete collection of people you can go and visit (such as "the finance department"). See the multi-organization unit requirement pattern in Chapter 12, "Commercial Requirement Patterns."
Organization unit type	An abstract organizational concept (such as "department") of which organization units are instances. See the multi-organization unit requirement pattern in Chapter 12.
Outage	A single continuous period of time for which a system is unavailable to users. (Not to be confused with outrage, though the two can occur at the same time.)
PDF	A file format developed by Adobe Corporation for textual-oriented documents, which are produced by the Adobe Acrobat application.
Permanent storage	A place that can be relied on to store data for long periods of time and that doesn't lose it when the power is switched off. Examples are disk drives, magnetic tapes, CDs, and DVDs.
Pervasive requirement	A requirement that applies systemwide for the purpose of defining something that applies to all requirements of a particular type. For example, "All reports shall show the date on which they were printed" is a pervasive requirement that implicitly applies to all requirements for reports.
PIN	Personal Identification Number. A numeric equivalent of a password. "PIN number" is the most widespread case of what New Scientist magazine has dubbed "RAS syndrome," where RAS stands for Redundant Acronym Syndrome.
Project	The mobilizing of a team for a temporary duration to achieve a set of stated objectives. For a system development project, its requirements define the objectives.
Recovery	The act of bringing up to date the data loaded into a database by means of a restore after a failure, by using an update log of changes made since the backup was taken.
Refactoring	The act of tidying up a piece of software that has grown untidy due to accumulated changes that were never envisaged when it was first written. (This is a term heard more in environments where comprehensive requirements are not specified.) The time and money allocated to the same.
Requirement	A single, measurable objective that a system must satisfy.
Requirement pattern	An approach to specifying a particular type of requirement.
Requirement pattern domain	A convenient grouping of related requirement patterns.
Requirement pattern group	A description of the features that a set of requirement patterns has in common. In object-oriented terms, a requirement pattern group can be regarded as an abstract base class for all the requirement patterns that choose to extend it.
Requirements specification	A requirements specification for a system is a document that states all the requirements the system must satisfy, plus any background material needed to make it readable and understandable. Note that this book spells it consistently as requirements specification (for "requirements" in the plural).
Requirements time	The phase in a project at which requirements are being specified. This expression is usually used when pointing out something that might not be known this early in the project. A happy, carefree time.
Response time	The length of time between a request being submitted to a system at a particular place and a response being perceived at the same place. (See the response time requirement pattern in Chapter 9.)
Restore	The act of copying reloading data into a database from a back-up when the main data is lost.
SMS	Short Message Service. The cool way to notify a techo that a system has crashed and they must curtail their weekend to fix it.
SOX	Sarbanes-Oxley Act, 2002. Also known as the Public Company Accounting Reform and Investor Protection Act. A U.S. law enacted to enforce a high standard of financial propriety in public companies. See the SOX example requirement in the comply-with-standard requirement pattern in Chapter 5, "Fundamental Requirement Patterns."
SQL	Structured Query Language. A specialized programming language dedicated to interacting with a database (for reading and writing data and for other activities, too). SQL is the de facto universal standard for relational database products.
Surreptitious unavailability	A fleeting amount of time for which the system is unavailable to users while it performs a background housekeeping task. It typically manifests itself as slower-than-normal response time, but usually no one notices. (See the availability requirement pattern in Chapter 9.)
System	A cooperating collection of software components and (optionally) the hardware on which it runs that achieves a useful purpose or allows people who use it to achieve a useful purpose. (A computer system.) The operational components of a business or part of a business, including computer systems, people, policies, and procedures, and all the other resources the business needs. (A business system in the broadest sense.) This book uses only the first definition.
Technology	Any externally-produced hardware or software that is used in the building, installing, and running of a system.
Tester	A person responsible for testing a software system-specifically, in this book, testing that the system complies with its requirements.
Testing	The process of finding out the extent to which a system deviates from what it should be doing.
Timed change	A change to information that needs to occur at a precise, predetermined moment in time. For example, switching to or from summer time has to happen at precisely 2 a.m. on a designated Sunday morning. Moving the Ruthenian Dinar across to the Euro must be done at midnight on a published date.
Timestamp	The date and time at which an event occurred.
Transaction	An event in the life of a living entity.
UML	Unified Modeling Language. A universally popular standard that can model every aspect of systems (and much else besides), resulting from a grand alliance between (that is, unification of- hence the name) the most revered system specification methodologists of the late twentieth and early twenty-first centuries. UML's official residence is http://www.uml.org.
URL	Uniform Resource Locator. A way of representing the location of a resource, most commonly a Web page.
Use case	A main scenario and (optionally) variants that describe the steps involved in achieving a particular user goal. Each use case is initiated by an actor (or by another use case).
Use case diagram	A high level diagram showing one user goal or more, along with relationships with actors and other use cases. See the "A Traditional Requirements Process" section in the full version of Chapter 1 for a couple of inexcusably irreverent examples.
User	A person who uses a computer system.
User interface infrastructure	A coherent set of components that together allow a user to interact with the system, excluding anything developed as part of a specific system, general underlying software (such as an operating system), and hardware. That is, a user interface infrastructure is what's left if you take away the system and everything it needs to run that isn't wholly user interfacial.
User preference	An item of information that is set by a user to indicate one aspect of how they wish the system to behave.
User response time	The length of time between a user submitting a request (hitting the button) and the response being displayed on their screen. (See the response time requirement pattern in Chapter 9.)
UTC	Universal Time Co-ordinated. The datum time zone against which all others are defined. It has no daylight saving time. It is effectively what was formerly known as Greenwich Mean Time, and is what pilots call "Zulu."
Waterfall	A way of organizing a complex task in which one phase of the work is largely completed before beginning the next phase. See the "Waterfall and Whirlpools" section in the full version of Chapter 1.
XML	Extensible Markup Language. A miraculous format for information that's capable of storing absolutely anything at all.
XP	Extreme Programming.
XSLT	Extensible Stylesheet Language Transformations. A way of specifying how to magically transform an XML document into something else even more magnificent.