Glossary

Question 1

Acceptance

Answer 1

Precisely defined condition that a system must meet in order to be accepted; a component of a requirement

Question 2

Affordance

Answer 2

A requirement that affords an option or freedom to a user, whether or not the user chooses to exploit it

Question 3

Capability

Answer 3

In a system specification, a function that a system is capable of but performs only when requested to by a user or another system. Functions not exposed to agents outside the system are not capabilities. However, the term is often used loosely to mean no more than “system function”. In user requirements, a capability means something a user wants to be able to do, so in this sense it is a synonym for affordance.

Question 4

Constraint

Answer 4

A statement of restriction, modifying a requirement or set of requirements by limiting the range of acceptable solutions. Sometimes used to indicate physical limitations such as size, shape, weight. Constraints may be imposed either by users (in user requirements) or by developers with specialist knowledge, such as of safety standards (in system requirements)

Question 5

Design constraint

Answer 5

Constraint describing an existing interface, presumably part of the design of some existing legacy system that must be complied with

Question 6

Exception (event)

Answer 6

It may be caused by something inside or outside the system. Exception events need to be handled by appropriate exception scenarios

Question 7

Exception Scenario

Answer 7

The desired response (Sequence of actions) to an exception event. It results in an end-state which is safe, and which is, if possible, back at some step in a normal scenario, so that users can continue with their work. In other words the goal for an exception scenario is to handle the exception event safely

Question 8

Functional Requirement

Answer 8

Something that a system or subsystem does, presumably because a requirement made it necessary

Question 9

Goal

Answer 9

A desired result, often at a high and abstract level. Goals are useful as the names of scenarios or use cases used to structure requirements

Question 10

Inquiry cycle

Answer 10

A structured sequence of activities, designed to be repeated as necessary, often in a workshop, to achieve consensus among a group of stakeholders on a set of requirements

Question 11

Non-functional requirement

Answer 11

Constraint; any requirement other than a function

Question 12

Requirement

Answer 12

1.) A user requirement
2.) A system requirement

Question 13

Scenario

Answer 13

A time-ordered sequence of events used to structure a set of requirements according to their actual or predicted pattern of usage

Question 14

Specification

Answer 14

The precise definition of the required behavior and qualities of a system in a form suitable for inclusion in a contract

Question 15

System requirement

Answer 15

Either an affordance or a constraint, forming a structured element of a system specification

Question 16

User requirement

Answer 16

A structured statement of user or other stakeholder need (in the world), written as either an affordance or as a constraint, imposed by a user. Compare: system requirement

Question 17

Validation

Answer 17

Checking that the requirements as documented are indeed the right ones, namely the ones that the stake-holders actually want

Question 18

Verification

Answer 18

Demonstrating that:
1) a system meets its system specification;
2) a system in use meets its user requirements.

Verification is most often by test but can also be by inspection, analysis, or simulation

Question 19

Fault Tree Analysis uses

Answer 19

Fault tree analysis can be used to:

understand the logic leading to the top event / undesired state.

show compliance with the (input) system safety / reliability requirements.

prioritize the contributors leading to the top event- creating the critical equipment/parts/events lists for different importance measures

monitor and control the safety performance of the complex system (e.g., is a particular aircraft safe to fly when fuel valve x malfunctions? For how long is it allowed to fly with the valve malfunction?).

minimize and optimize resources.

assist in designing a system. The FTA can be used as a design tool that helps to create (output / lower level) requirements.

function as a diagnostic tool to identify and correct causes of the top event. It can help with the creation of diagnostic manuals / processes.

Question 20

Where is the most likely place for an exception to occur?

Answer 20

Any place that can be effected by users, other systems, state transitions

Question 21

Good questions to discover exceptions

Answer 21

Can anything prevent you from reaching this goal?
Can anything go wrong here?
What else could when you’re in the state?

Question 22

Requirements vs Constraints

Answer 22

Functional vs Non-Functional

Requirements – Capture Features and Functions of a system or component. Constraints – Define the Non-Functional aspects of a system or component, such as restrictions on technology, resources or techniques to be used.

Question 23

Goal Headings

Answer 23

Goal
>Sub Goal
»Primary Scenario
»Exceptions
»Trigger

Question 24

Examples of Non-Functional Requirements

Answer 24

Cost
Reliability
Safety
Usability
Environment

Question 25

Potential System Project Documents

Answer 25

User Requirements
System Specifications
System Design
Development Plan
Maintenance Plan

Question 26

Widely used structure for user requirements documents

Answer 26

General Description
>Product Perspective
>General Capabilities
>General Constraints
>User Characteristics
>Operational Environment
>Assumptions and dependencies

Specific Requirements
>Capabilities - The Scenarios/Functional Requirements
>Constraints - Applying to the whole system/Non-Functional Requirements

Question 27

3 ways to write constraints

Answer 27

1) Top level - all constraints are in one place
2) Mid level - constraints are pertaining to midlevel goal (not recommended)
3) Bot Level - constraints are associated with goals at the lowest level

Question 28

Dangerous Let-out Clauses

Answer 28

if, when, but, except, unless, although, always

Question 29

Dangerous signs of Vague terms

Answer 29

user-friendly, versatile, flexible, approximately, as possible, efficient, improved, high performance, modern

Question 30

Dangerous signs of requirement mixing (mixing user requirements, system specifications, design elements, test cases, development guidelines, and installation instructions)

Answer 30

system, design, testing, installation

Question 31

Dangerous signs of mixing plans and requirements

Answer 31

dates, project phases, development activities

Question 32

Dangerous signs of wish lists

Answer 32

vagueness: usually, generally, often, normally, typically

Question 33

Dangerous signs of possibilities

Answer 33

may, might, should, ought, could, perhaps, probably