Requirements Fundamentals

SEEK Topics

• Requirements fundamentals

  1. Definition of requirements (e.g., product, project, constraints, system boundary, external, and internal) (c) E

  2. Requirements process (c) E

  3. Layers/levels of requirements (e.g., needs, goals, user requirements, system requirements, and software requirements) (c) E

  4. Requirements characteristics (e.g., testable, unambiguous, consistent, correct, traceable, and priority) (c) E

  5. Analyzing quality (nonfunctional) requirements (e.g., safety, security, usability, and performance) (a) E

  6. Software requirements in the context of systems engineering (k) E

  7. Requirements evolution (c) E

  8. Traceability (c) E

  9. Prioritization, trade-off analysis, risk analysis, and impact analysis (c) E

  10. Requirements management (e.g., consistency management, release planning, and reuse) (k) E

  11. Interaction between requirements and architecture (k) E

k = knowledge, remembering previously learned material, c = comprehension, understanding information, a = application, using learned material

E = essential, D = desirable / time-permitting

Requirements Construct

From SWEBOK Ch. 1 Section 5.3

Software requirements are often written in natural language, but, in software requirements specification, this may be supplemented by formal or semiformal descriptions. Selection of appropriate notations permits particular requirements and aspects of the software architecture to be described more precisely and concisely than natural language. The general rule is that notations should be used that allow the requirements to be described as precisely as possible. This is particularly crucial for safety-critical, regulatory, and certain other types of dependable software. However, the choice of notation is often constrained by the training, skills, and preferences of the document’s authors and readers.

From 29148-2018 5.2.4

It is important to agree in advance on the specific keywords and terms that signal the presence of a requirement. A common approach is to stipulate the following:

• Requirements are mandatory binding provisions and use 'shall'.

• Statements of fact, futurity, or a declaration of purpose are non-mandatory, non-binding provisions and use 'will'. 'Will' can also be used to establish context or limitations of use. However, 'will' can be construed as legally binding, so it is best to avoid using it for requirements.

• Preferences or goals are desired, non-mandatory, non-binding provisions and use 'should'.

• Suggestions or allowances are non-mandatory, non-binding provisions and use 'may'.

• Non-requirements, such as descriptive text, use verbs such as ‘are', ‘is', and ‘was'. It is best to avoid using the term ‘must', due to potential misinterpretation as a requirement.

• Use positive statements and avoid negative requirements such as ‘shall not'.

• Use active voice: avoid using passive voice, such as 'shall be able to select'

From 29148-2018 5.2.4 Figure 1

[Condition] [Subject] [Action] [Object] [Constraint]

EXAMPLE: When signal x is received [Condition], the system [Subject] shall set [Action] the signal x received bit [Object] within 2 seconds [Constraint].

Or

[Condition] [Action or Constraint] [Value]

EXAMPLE: At sea state 1 [Condition], the Radar System shall detect targets at ranges out to [Action or Constraint] 100 nautical miles [Value].

Or

[Subject] [Action] [Value]

EXAMPLE: The Invoice System [Subject], shall display pending customer invoices [Action] in ascending order [Value] in which invoices are to be paid.

Or

From Easy Approach to Requirements Syntax (EARS) Details Access

<optional preconditions> <optional trigger> the <system name> shall <system response>

Or

From Alexander and Stevens (2002)

"When writing functional requirements from the user’s perspective, the following general structure works well:"

The [user class or actor name] shall be able to [do something] [to some object] [qualifying conditions, response time, or quality statement].

Or

From Software Requirements, Wiegers & Beatty, p. 208:

The system shall let (or allow, permit, or enable) the [a particular user class name] to [do something].

Following is an example of a functional requirement written from the user’s perspective:

The Chemist shall be able to reorder any chemical he has ordered in the past by retrieving and editing the order details.

Notice how this requirement uses the name of the user class—Chemist—in place of the generic “user.”

Making the requirement as explicit as possible reduces the possibility of misinterpretation."

Types of Requirements

from SWEBOK Ch. 1 Section 1

1. Product and Process Requirements

   1. A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”).

   2. A process requirement is essentially a constraint on the development of the software (for example, “The software shall be developed using a RUP process”)

2. Functional and Nonfunctional Requirements

   1. Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.

      • originate from user stories, use cases, and business rules

      • stated in the form of input to be given to the system, the operation performed and the output expected

      • Functional requirement wikipedia

   2. Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements. They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, security requirements, interoperability requirements or one of many other types of software requirements (see Models and Quality Characteristics in the Software Quality KA).

3. Layers/levels of requirements (e.g., needs, goals, user requirements, system requirements, and software requirements)

Needs vs. Goals

• Needs are mandatory binding provisions.

• Goals or preferences or goals are desired, non-mandatory, non-binding provisions.

User Requirements, System Requirements, and Software Requirements

• 1. System Requirements: In this topic, “system” means an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements, as defined by the International Council on Software and Systems Engineering (INCOSE). System requirements are the requirements for the system as a whole. In a system containing software components, software requirements are derived from system requirements. This KA defines “user requirements” in a restricted way, as the requirements of the system’s customers or end users. System requirements, by contrast, encompass user requirements, requirements of other stakeholders (such as regulatory authorities), and requirements without an identifiable human source. SWEBOK Ch. 1 Section 1

  2. User requirements can be expressed through User Stories, Use Cases, and Use Case Diagrams and don't require formal language. "As a __________ I want to _________ in order to _________"

4. Requirements characteristics

From SEBOKWIKI System Requirements Table 3

Necessary The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.

Appropriate The specific intent and amount of detail of the requirement is appropriate to the level of the entity to which it refers (level of abstraction). This includes avoiding unnecessary constraints on the architecture or design to help ensure implementation independence to the extent possible.

Unambiguous The requirement is stated in such a way so that it can be interpreted in only one way.

Complete The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.

Singular The requirement should state a single capability, characteristic, constraint, or quality factor.

Feasible The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk.

Verifiable The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exists.

Correct The requirement must be an accurate representation of the entity need from which it was transformed.

Conforming The individual requirements should conform to an approved standard template and style for writing requirements, when applicable.

5. Analyzing quality (nonfunctional) requirements (e.g., safety, security, usability, and performance)

Research

Consider public health, safety, and welfare, as well as global, cultural, social, environmental, and economic factors (ABET)

A good statement to include in ALL projects: "Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing." ACM Code of Ethics and Professional Conduct

6. Software requirements in the context of systems engineering

on home page

7. Requirements evolution

Initial understanding of problem -> Initial requirements -> Changed understanding of problem -> Changed requirements

8. Traceability

"The ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)"

• High-level requirement -> low-level requirement / Product backlog -> Sprint backlog

• Who wanted what and why

  • Stakeholder -> User Story / Use Case / Use Case Diagram -> Requirement -> Test Case

  • Stakeholder -> Business rule -> Requirement -> Test Case

  • Stakeholder -> Constraint -> Requirement -> Test Case

  • Stakeholder -> System Requirement -> Software Requirement -> Test Case

• Requirement -> Feature -> Test Case

Requirements Traceability Matrix tutorialspoint

Requirements Traceability – The What, Why, and How b2ttraining

Four Best Practices for Requirements Traceability jamasoftware

9. Prioritization, trade-off analysis, risk analysis, and impact analysis

Requirements may be ranked or weighted to indicate priority, timing, or relative importance.

1. Must be done.

2. Should be done.

3. Could be done.

May depend on which stakeholder the requirement originated from.

Think of business value.

10. Requirements management (e.g., consistency management, release planning, and reuse)

11. Interaction between requirements and architecture

SWEBOK Chapter 1 Section 4.3

At some point, the solution architecture must be derived. Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks. This topic is closely related to Software Structure and Architecture in the Software Design KA. In many cases, the software engineer acts as software architect because the process of analyzing and elaborating the requirements demands that the architecture/design components that will be responsible for satisfying the requirements be identified. This is requirements allocation–the assignment to architecture components responsible for satisfying the requirements.