Loading...
 

Requirement

Definition:

alternative 1:

anything Stakeholders require.
Note: require is a synonym with words like need, wish, demand, want, necessity, essential, necessary, prerequisite, requisite, precondition, condition, stipulation.


alternative 2:

stakeholder-valued system state, under stated conditions.

Alternative Names

Concept Number: *026
English Master: Requirement
Synonyms, Variations & Acronyms: none

Detailing

To capture the whole Concept of Requirements, I find it necessary to start with this broad definition. It is based on the Idea that if a Stakeholder has a Requirement, it is a Requirement, if no Stakeholder has a Requirement, there is no Requirement.

The Concept is based on someone or something (a Stakeholder) requiring, it is the requiring that makes it a Requirement, not what they are requiring.

We can categorize the Requirement:
into types, e.g. Function, Scalar, Solutions, Development-Resources.
and levels, e.g. Stakeholder, Product, Sub-product.

A Requirement normally has these life cycle stages.

  1. Stakeholder-Need (pre Requirement): a Stakeholder has a Need that the Stakeholder may or may not know about.
  2. Stakeholder-Wish (pre Requirement): a Stakeholder expresses an improvement or an improvement is identified, but either no money is offered or no agreement is made to deliver that Level for that price.
  3. Stakeholder-Tolerable/Goal Agreed (a Requirement): the Stakeholder Requiring and the team Delivering have agreed to Tolerable/Goal values to be delivered and for how much.
  4. Past: Delivered or failed. An historical Requirement.



Do we need to comply with all expressed Requirements?
For an expressed Requirement to be a Requirement that our project is interested in fulfilling, I consider:
1. Who/what it came from.
The people/products with an interest in our project I call Stakeholders. Does the Requirement come from a Stakeholder that we must or want to listen to?
2. Will it be profitable to fulfill the Requirement?
Is the Stakeholder requiring the Requirement willing to pay for it?
3. Is it a market we and our company want to be in?
Fulfilling a Requirement puts you in the market of people wanting that Requirement.


Illustrations

Requirement tree
Illustration: Requirement Concepts Tree

Type

System-Specification


Examples

none


Notes


From Tom Gilb Sep 2012
A ‘requirement’ is a
stakeholder-valued system state, under stated conditions.


Note September 4 2012
1. The word future was deleted, since the time for the Requirement is covered in the ‘stated conditions’
2. This advice was due to Kai Gilb, who pointed out that the required state could be Past, present or future, not just future!
3. I added ‘system’ as it seems to make the state Idea more intelligible, than having it implied. Kai also questioned the ‘state’ term and this is my response.

Note 11 June 2012 TG
1. I added the phrase “under stated conditions”
2. The ‘conditions’ can primarily be stated as a Planguage Qualifier set" rel="">qualifier set,
3. and in addition use any Planguage device that can attach to a Requirement.
4. This includes the parameters such as Goal, Stretch, Fail.
5. It includes all other parameters that inform us of the Requirement conditions, such as Sponsor, Version, Note, Issue, Risk and many others.


Some primary remarks on the definition:
Requirements are used as an input to problem-solving (the problem being ‘how to reach the requirements’) Processes; like design, Architecture, Strategy Planning,
more-detailed Requirements, more technical Requirements, and Engineering.
Requirements may be subject to ‘testing for existence’ in a system.
Requirements exist without regard to the possible or actual Means by which their future state is achieved.
• But a realistic Requirement may be determined as a Result of knowing the performance limits, and costs, of available designs.
Requirements can exist even if no known Means exist to satisfy them.
• A Requirement will not necessarily be invested in, until its totality of Complex Priority information causes us to Act on it.
• A Requirement may exist, even when a formal Requirement specification (*508) does not.


Deeper Notes:

1. Stakeholder (*233) specifically includes “any person, group or object, which has some direct or indirect interest in a system. The ‘object’ can include
any documents or specification at any Level, such as a law or a Standards specification”

2. “Stakeholder-valued”: Means that a given Stakeholder, or set of them, can give a variety of value signals regarding the relative Priority they place on
achieving that future state. These Priority signals* can be analyzed in a given development environment, so that the actual implementation of the Requirement
is either delayed, implemented in some limited way, or never implemented. The Requirement is finally ‘prioritized’ based both on several stakeholders’
several-value signals, plus other real time signals – for example a Budget cut. There is no absolute certainty that a Requirement will actually be implemented
until it is actually implemented in practice. And there is no certainty that it will remain implemented once it has been implemented. Requirements are
not absolutely ‘required’, they are conditional.

  • Priority signals: are of infinite variety, and may be analyzed in arbitrary sets, by any given analyst. They can include for example: deadlines,

Binary constraints, target levels, Constraint levels, specification qualifiers, dependencies, risks, uncertainties, willingness to fund, formal Authority,
value, market willingness to pay, current and projected profitability, laws, regulations, and cultural values.

3. A Requirement (*026) is quite distinct from a ‘need’ (*599): A ‘need’ is something desired by a defined Stakeholder. The implication is that
satisfying that need would have some value (*269, ‘perceived benefit’ ) for some Stakeholder. A need might not be agreed as a formal
Requirement, and it might not be prioritized such that it is actually acted upon (designed and implemented). ‘Need’ is a term often used as a
Stakeholder view of a problem Before Requirements specification is carried out.

4. Requirements are the Baseline for deciding which design ideas (*047) to use to satisfy them.
In practice, a set of Requirements will be needed to reasonably optimize (discover, define, evaluate, prioritize) a practical set of designs
needed to meet Requirements.

5. “Future State”: refers to any observable (testable) Attribute (like Function, performance Level, Constraint compliance*) of a defined
system in the future. This does not imply that the system does not already, at present, already have the state, but just that it must (also)
have it in, or by, a defined future time.

  • Constraint (*218) compliance: can include compliance with design constraints, negative constraints, and positive constraints, as

well as performance and resource Scalar Constraint levels.



Mil_Std 498:
Requirements are what the acquirer cares enough about to make conditions
for acceptance (may be "what" or "how")

Design is the set of decisions made by the developer in response to
Requirements (may be "what" or "how")
(Solutions plus decisions)
Pointed out by Niels Malotaux May 18 2005. He also helped simplify the main definition *026.

Given below are some IEEE definitions:

Requirement: a Condition or capability needed by a user to solve a problem or achieve an objective. <- IEEE 610.12-1990.
Example of an IEEE definition of ‘requirement’: The term ‘user’ is probably not broad enough to capture the Scope of all Stakeholders.
Another danger of this definition is that it inadvertently includes all designs, and so does not successfully made a sufficiently clear
distinction between Requirement and design.

Requirements: Statements, which identify the essential needs for a system in order for it to have value and utility. Requirements may
be derived or based upon interpretation of stated Requirements to assist in providing a common understanding of the desired
operational characteristics of a system. <- IEEE P1220. IEEE Standard for Systems
Engineering, Preliminary, 1993 in SEI-95-MM-003.
Example of an IEEE definition of ‘requirements’: Better than the previous 1990 Standard, as all designs are no longer ‘in the picture’.

The IEEE 830:1998 definition, states
A Requirement is:

1. A Condition or capability needed by a user to solve a problem or
achieve an objective.
2. A Condition or capability that must be met or possessed by a system
or system Component to satisfy a contract, Standard, specification, or
other formally imposed Document.
3. A documented representation of a Condition or capability as in items
1 or 2.
Notes on IEEE 830: Definition 3 is covered in Planguage by ‘Requirement Specification’
Concept *508. The 2nd part is included due to the fact that the Planguage definition of Stakeholder specifically includes
inanimate things such as documents.
IEEE 830: Pointed Out by Erik Simmons, May 18 2005.

Other Notes:
1. Stakeholders should determine their own Requirements; they certainly should be involved in discussions about the relative
values, costs, and priorities of their Requirements.
A systems engineer may be needed to specify the Requirements in a suitable way for use by systems Engineering projects.
Also, there may be a need for building, aggregating and analyzing a set of project Requirements across a range of disparate Stakeholders.

2. Not all Requirements, initially specified, are necessarily accepted for actual delivery: some Requirements may not ultimately
be feasible or economic. The key practical Idea is to try to identify, and understand the relative Priority of, the most critical, or
most profitable, Stakeholder values.

3. A Requirement specification is an input to a design Process. Requirements give information to the designer about the
necessary and satisfactory nature of their design. A design, whether a design specification or an actual design implementation,
can be judged (using such Means as Specification Quality Control (SQC), test, Impact Estimation tables, Evolutionary step
feedback, or operational use) in terms of how well it satisfies the Requirements.

4. Requirements, at different levels of abstraction, can be viewed as inputs to a defined Level of design Process. In a series of
systems Engineering Processes, one engineer’s output (‘design’, ‘architecture’) may become another engineer’s inputs, or
‘requirements’. The conclusion of this is that specifications, no matter what we name them, are Requirements, only when they
are used as input to such a systems Engineering Process. So, we need to explain a particular Concept of ‘requirement’ by first
specifying the systems Engineering Process Type, or Level, at which they apply, as ‘input to’, or ‘output from’. For example,
Stakeholder value analysis, Product line Architecture, or Component Engineering Processes.

5. Requirements can have different Priority Attributes. Priority is conveyed in a variety of ways, using a useful variety of Priority signals, for example:
• for Scalar Attributes, by stating any relevant Constraint levels using {Fail, Survival}
• for Binary Attributes, by stating any relevant constraints using Constraint parameters
• for Scalar Attributes, by setting relevant target levels using {Goal/Budget, Stretch, Wish}
• by specifying different Qualifier conditions for time, place, event (Alternatively known as when, where, if)
• by specifying other parameters, like Authority, Dependency, Priority and Risk, which provide additional information

6. Requirements are, usually, assumed to be written in Requirement specifications (*508). However, many documents, which
have ‘requirements’ in their title, may contain little or no real Requirements: it is unfortunately commonplace to find a high density
of design specification (*586) in so-called ‘requirements’, instead of their corresponding ‘real’ Requirements. A ‘password’ may
be ‘required’, but no security defined as a Basis. Frequently, the most important, high-level and critical Requirements are not
stated clearly at all. http://www.gilb.com/tiki-download_file.php?fileId=180
You must be prepared to look for real and critical Requirements in other documentation, and to ask questions of many Stakeholders.

7. A design Idea (*047) is not usually a Requirement, at the same systems development Process Level as the Requirements it was
designed to satisfy. However, once a design Idea is ‘fixed’ at a project development Process Level, it becomes a ‘design constraint’
(which is a Requirement Type) for the next development Process Level. In other words, a design Idea usually becomes ‘valid as a
requirement’ at the next Level of the development Process, After the Level it was ‘designed.’ It is then a valid ‘requirement’ for all future, ‘lower’ levels.

8. Alan Ashton-Jeanes has a particularly well thought out notion of Requirement.
1. The people whose ends a system (*145) serves are one Class of Stakeholders. They value the actual results, or receive benefit (*009) .
2. The people who consider the future of a system and/or agree to the suggestions of others, are a different Class of Stakeholders.
They perceive potential value (*269).
3. If these people take ideas forward (deciding to Act or persuading others to decide to Act, or considering the desirability of Action),
they can be described as “Founders ” of the resultant system or course of Action.
4. The arena within which Action may occur is variously described as the “problem domain”, “scope” (*419) or “context” .
5. A perception of value within a particular Context for Action is a potential Requirement.
6. A potential Requirement coupled with Authority (*005) or discretion to pursue its satisfaction is a Requirement. The person who
confers the Authority is the requirement’s “Sponsor”.
7. So, a Requirement is a perception of value, in a particular Context ,for Action coupled with the Authority to pursue its satisfaction: the
authorized and contextualized pursuit of value.
8. The substance of a Requirement (what is required) is the value. That of which it is a Requirement is a future system. The Context
within which it is a Requirement includes the project or endeavor (“development environment”) and the anticipated operating environment.
Explicit or implicit Authority to pursue the Requirement (within a particular Context ) is a Status of the Requirement (in that Context).
Source: Email Oct 10 2006, revised Feb 14 2007. [email protected]

9. I often use the term ‘objective’ (*100) to express a high Level of performance Requirement. For example, ‘Usability’,
which is often a Complex Requirement (consisting of 5 to 10 sub-requirements, like Intelligibility and Intuitiveness).
Admittedly I tend to use ‘requirements’ more as a term when speaking to engineers, and ‘objectives’ when dealing with managers.



Keyed Icons

[@]
Note: “A combination of target and Constraint.”

[@] is a Generic icon. It is not used much in practice. In practice we use the specific icons such as Goal or Budget ( O-->---> ).


Drawn Icons


End-State Requirements: Functions, Stakeholder-Values, Product-Qualities & Development-Resources.
Means-Requirements, or Solution-Constraints.

Requirement-Specification *508: A written artifact containing a set of Requirements, which may include additional Background information.
Need *599
Problem-Definition *598
Problem *270
Design-Problem *654
Target *048
Constraint *218
Stakeholder *233
Objective *100: An Objective is not a pure synonym for a Requirement. Objectives are performance Requirements.
Value *269
Benefit *009
Client-Stakeholder *650
Server-Stakeholder *651
Priority *112
State *174


History of Concept







Created by system. Last Modification: Tuesday 13 of November, 2018 23:21:58 CET by Admin (Kai).