Glossary of Terms and Activities in Requirements Determination

 

Actor

A human or non-human entity that directly interacts with the system. Non-human actors can be hardware or other systems. We model the exchange of events and information between an actor and the system. Actors are not modelled, only their interactions.
An actor participates in a scenario by sending messages to, and receiving messages from the system. Actors may also interact with each other.

 

Agent

Synonym for actor.

 

Classification

See Requirements Classification.

 

Concern

A characteristic of the system that is crucial to the success of the project. Concerns are non-negotiable.
Key stakeholders will consider a system to be a success if the concerns (as they view them) have been addressed in the eventual system realisation.
A concern may be decomposed into more specific and lower-level concerns. All stakeholder perspectives must be subordinate to at least one concern.

 

Concern Identification

The process of discovering major concerns (goals) at the outset of the project. A good way to identify concerns is to look for to the words (such as stability, performance) that the customer uses to describe what is important to him or to her. The ISO 9126 characteristics are also a good source for concern identification.

 

Concern Elaboration

Decomposition of concerns into sub-concerns, external requirements and concern questions. We decompose concerns into different viewpoints in our RD course.

 

CRS (Commercial Requirements Specification)

A document that contains the rationale for the system to be constructed. In particular, this document must explicitly state the business objectives of the system.
The CRS represents primary input to the Requirements Determination phase.

 

Domain Constraint

System requirements that arise from the system's application domain. Constraints generate system requirements and should be determined during the Requirements Elicitation phase.
There are two types of domain constraints, namely overall constraints and specific constraints.
Constraints represent 'laws of physics' and the restrictions placed on the organisation (and hence the system) by external regulators.

 

Domain Category (D. Duffy)

A domain category is a family of applications having similar compositional and behavioural characteristics. Each application or system to be developed can be seen as an instance of a domain category or assembly of domain categories. Examples of domain categories are Manufacturing, Process Control, Resource Allocation and Tracking, Interactive and Management Information Systems (MIS).
For more information, see manuscript (D. Duffy).

 

Domain Viewpoint

The viewpoint taken by considering a system to be an instance of a domain category. Once this has been achieved we are then in a position to discover structure and those requirements that are common to all systems in the same category. In other words, we can discover requirements very quickly, which helps when getting the first prototype up and running.

 

Feasibility

See System Feasibility.

 

Feasibility Report

A document that describes the System Feasibility Study activity.

 

Goal

Synonym for concern.

 

Inquiry-based Model

A technique that uses inquiry techniques to discover and improve requirements. To this end, different types of questions are used, such as: what is, what kinds of, who, when, what if, how-to, relationship and follow-on questions.

 

Interaction Matrix

A technique for discovering conflicts and overlaps between requirements. This interaction matrix is used as input for the Requirements Negotiation phase.

 

ISO 9126

A set of quality characteristics (Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability) that can be considered as system concerns. Customers often use these terms when asked what sort of system they would like to have.
You can use these characteristics or their sub-characteristics as aids in discovering key concerns.

 

Multiple Viewpoints Approach

A technique that allows analysts to view a system from different perspectives. The approach resolves some of the shortcomings of the single viewpoint approach that is seen in traditional OO methodologies. Instead, we take different views of the same subject matter in order to expose all its facets instead of a system in which many requirements are missing and only get discovered in the downstream stages of the software lifecycle.

 

Negotiation

See Requirements Negotiation.

 

Operating Environment

The environment consisting of the host computer in combination with the other hardware and software systems that will interact with the system. Attention should be paid to versions of software, interfacing between the systems and predictions of future growth and changes.
The Operating Environment corresponds to guidelines 4.5 and 7.2 (Sommerville)

 

Perspective

A perspective is one particular view taken by similar entities (for example, a group of stakeholders) in a system. It is closely related to the Viewpoint concept.
Examples of perspectives are:

The concept Perspective is broadly synonymous with the Viewpoint concept.
See also Viewpoint, Stakeholder

 

Requirement

A statement of what the system or part of the system should do. It is a statement of a customer wish without specifying how that wish will be implemented. Requirements can be grouped into 'essential', 'useful' and 'desirable'.
A requirement relates to multiple viewpoints and a viewpoint can be decomposed into multiple requirements. Several scenarios implement a requirement.

 

Requirements Analysis

The phase in Requirements Determination in which the initial set of requirements from the Elicitation phase are analysed for conflicts, overlaps, omissions and inconsistencies. Stakeholders negotiate to agree on a set of consistent system requirements.

 

Requirement Class (multi-dimensional approach)

A hierarchy of requirements sharing common characteristics. A class has many requirements while a given requirement may be a member of several classes. Typical examples of classes are System, User Interface, Database, Communication and Security.
The 'leaves' in a given class represent system requirements and these are found from the corresponding Viewpoint hierarchies. Intermediate nodes represent placeholders.

 

Requirements Classification

The process of grouping related requirements into class hierarchies.
One of the reasons for creating requirements classes is the ability to group common requirements based on well-defined expertise areas.

 

Requirements Conflict

Two requirements R1 and R2 are in conflict if the realisation of R1 implies difficulty in realising R2 and vice versa. This is a problem that must be resolved by suggesting compromises and workarounds in co-operation with stakeholders.

 

Requirements Description

The textual description of a given requirement. Similar to how viewpoints are documented.

 

Requirements Determination (code name RD)

The phase in the software lifecycle consisting of the subphases Elicitation, Analysis and Negotiation, Validation. A Commercial Requirements Specification (CRC) is transformed into a requirements document.

 

Requirements Document

The end product or deliverable of the Requirements Determination phase. It contains information needed by several stakeholder groups (for example, OO analysts).

 

Requirements Elicitation

The phase of Requirements Determination in which an initial set of requirements for a system are discovered. This set is 'unoptimised' in the sense that it may contain duplicate requirements, ambiguities, omissions and inconsistencies.

 

Requirements Harmonisation

The activities in which the requirements from the Requirements Analysis phase are integrated with Datasim's domain model(s). In this way different subsystems can be independently developed.
Furthermore, we achieve loose coupling between subsystems and tight coupling within each subsystem, an issue that has been prevalent since the 1970's (for example, in the work of David Parnas).

 

Requirements Management

The activities, processes and change control techniques in order to ensure that requirements keep in step with the operational system. System changes must be reflected as requirements changes and vice-versa.

 

Requirements Negotiation

The activity in which stakeholders meet to discuss and resolve problems related to the requirements in the Requirements Analysis phase.

 

Requirements Overlap

Two requirements R1 and R2 are overlap if they contain sub-requirements that are common to both of them. In other words, they both contain common functionality.

 

Requirements Prioritisation

The process of giving each requirement a priority. We thus distinguish between high-priority, medium-priority and low-priority requirements, thus making the tasks of analysts and project leaders easier to schedule and execute. Furthermore, each requirement should be given a risk value. Hint: watch out for high-risk, high-priority requirements.
See also Risk Management.

 

Requirement Scoping

The process of eliminating unnecessary requirements as soon as possible in the Requirements Analysis phase.

 

Requirement Source

The stakeholder who wished the requirement in the first place.

 

Requirements Traceability

The ability to trace the path of a requirement from initial Source through Elicitation, Analysis and Negotiation.

 

Requirements Validation

The phase in which the requirements document is reviewed and formally validated. Concerns are omissions, conflicts and ambiguities and ensuring that the document follows quality standards.

 

Requirement Verification

Negotiation with stakeholders in order to determine if a requirement is accurate and correct.
This step occurs in the Requirements Elicitation phase.

 

Risk Management

Each requirement in the Analysis phase is examined and an estimate is made of the risk associated with it (for example, high, medium and low). Explicit risk assessment is a good way to identify requirements that will cause downstream development problems.
Requirements that have both high risk and high priority deserve special attention.

 

Scenario

A generic name for an interaction session between actors and the system. It has two variants, namely scenario schema and scenario instance.

 

Scenario Description

Scenarios are documented in a standard fashion (guideline 4.11)

 

Scenario Schema

A scenario in which all entities (actors, events) are generic. A schema describes the scenario for all actors and event instances but it can be difficult to understand, especially in the early stages of requirements analysis.
Example of a schema: 'Withdraw funds from an account in the bank'
A scenario schema corresponds to a use case in UML. We prefer the name 'scenario schema' because it is generic and is used by many researchers.

 

Scenario Instance

A scenario in which some (or all) entities are instantiated. Comparing with object-oriented technology, we liken a scenario schema to a class while a scenario instance is similar to an object.
Example of a scenario instance: 'Withdraw 200 guilders from account 12345678'

 

Scoping

The first phase in Requirements Analysis. Requirements that are outside the scope of the system are eliminated. This corresponds to an initial partitioning step and it is closely related to the Operating Environment phase.

 

Stakeholder

Any entity that directly or indirectly benefits from the introduction of the system. This group includes potential stakeholders.
The types of stakeholder are: human/nonhuman, past/current/future, and direct/indirect

 

System Architecture

This is the architectural model for the system. This is similar to the way the system is partitioned into subdomains (domain categories). The advantage of creating a system architecture is that many requirements can be associated with specific subsystems. Furthermore, in some cases the system architecture may be a requirement itself.
Examples of system architecture are layers, client-server, blackboard, repository and pipeline.

 

System Attribute and Metric

An attribute describes a requirement quantitatively. This is particularly true for non-functional requirements, such as reliability and performance. Once an attribute has been found it is possible to use a number of metrics to describe the attribute. Finally, each metric can be given a (numeric) target value.
This target value must be achieved in the realised system.

 

System Boundary

The dividing line between those requirements that are inside and outside the system. Actors fall outside the system boundary and hence are not modelled.

 

System Feasibility Study

The activity during Requirements Elicitation that is executed in order to determine if the system should be constructed. Attention should be paid to current technology, the organisation and recommendations on whether the system should be constructed.

 

System Modelling

The process of decomposing a system into several loosely coupled subsystems.
A number of abstract models can be created, such as Duffy's domain models, classification models, composition models stimulus-response and process models. Some of these activities that are executed in order to create these models border on OOA.

 

Use Case

Synonym for Scenario.

 

Verification

See Requirements Verification.

 

Viewpoint

A viewpoint represents an encapsulation of partial information about a system's requirements from a particular perspective.
The categories of Viewpoint are Interactor, Stakeholder, and Domain.
Viewpoints are intermediate-level techniques during the Requirements Elicitation phase.

 

Viewpoint Description

A standard template structure for documenting a viewpoint:

 

Viewpoint Identification (difficult!)

The process of finding the most important viewpoints in a system. In order to identify viewpoints the analyst must develop a good understanding of the system's operational and organisational environments.
A number of iterations may be needed before a stable set of viewpoints and corresponding requirements is found.

 

Daniel J. Duffy
February 1999

 

[ Homepage | Articles ]