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.
Synonym for actor.
See Requirements Classification.
A characteristic of the system that is crucial to the success of the project. Concerns
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.
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.
Decomposition of concerns into sub-concerns, external requirements and concern questions. We decompose concerns into different viewpoints in our RD course.
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.
System requirements that arise from the system's application domain. Constraints
generate system requirements and should be determined during the Requirements Elicitation
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.
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).
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.
See System Feasibility.
A document that describes the System Feasibility Study activity.
Synonym for concern.
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.
A technique for discovering conflicts and overlaps between requirements. This interaction matrix is used as input for the Requirements Negotiation phase.
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.
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.
See Requirements Negotiation.
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
The Operating Environment corresponds to guidelines 4.5 and 7.2 (Sommerville)
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
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.
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.
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.
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.
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.
The textual description of a given requirement. Similar to how viewpoints are documented.
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.
The end product or deliverable of the Requirements Determination phase. It contains information needed by several stakeholder groups (for example, OO analysts).
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.
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
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).
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.
The activity in which stakeholders meet to discuss and resolve problems related to the requirements in the Requirements Analysis phase.
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.
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.
The process of eliminating unnecessary requirements as soon as possible in the Requirements Analysis phase.
The stakeholder who wished the requirement in the first place.
The ability to trace the path of a requirement from initial Source through Elicitation, Analysis and Negotiation.
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.
Negotiation with stakeholders in order to determine if a requirement is accurate and
This step occurs in the Requirements Elicitation phase.
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.
A generic name for an interaction session between actors and the system. It has two variants, namely scenario schema and scenario instance.
Scenarios are documented in a standard fashion (guideline 4.11)
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.
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'
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.
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
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.
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.
The dividing line between those requirements that are inside and outside the system. Actors fall outside the system boundary and hence are not modelled.
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.
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.
Synonym for Scenario.
See Requirements Verification.
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.
A standard template structure for documenting a viewpoint:
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
A number of iterations may be needed before a stable set of viewpoints and corresponding requirements is found.
Daniel J. Duffy
[ Homepage | Articles ]