cenelec phase 2/the selred guideline - uic.org · pdf filesr7-dk sr8-dk sr9-dk sr10-dk sr11-dk...

/CENELEC Phase 2/The SELRED Guideline

Project CENELEC Phase 2

Structured English Language for Req Development

Version: 7.0

Printed by: Holter

Printed on: 22 May 2003

Generated from DOORS V5.2 Copyright (c) 2003 UIC / Euro-Interlocking

Contents

1 1SELRED1.1 2Introduction

1.1.1 2Scope of this document1.1.2 3Structure

1.2 4High-level structure of the requirements1.2.1 4Requirements content – from idea to sentence1.2.2 5Consistent and complete requirements1.2.3 5Requirements – structure view

1.3 6Term definition1.3.1 6Standardised terms 1.3.2 6Abbreviated terms1.3.3 7Understandable words1.3.4 7Terms in capital letters

1.4 7Structure of operations1.4.1 7Sentence with inputs/outputs1.4.2 7State approach

1.5 8Logic construction1.5.1 8Logic in functional requirements1.5.2 8Semantics and syntax for functional requirements1.5.3 8Logic connectives1.5.4 10Logical truth tables1.5.5 11Decision tables and sheets

1.6 11Sentence constructions1.6.1 11Sentence length1.6.2 11Adverbs and adjectives1.6.3 12Avoid weak phrases

1.7 13Definition of the verbs1.7.1 13Imperative verbs1.7.2 14Avoidable verbs and expressions

1.8 15 Examples1.8.1 15SELRED approach and Railway Interlocking

Requirements1.9 16References

Contents Copyright (c) 2003 UIC / Euro-Interlocking i

Printed 22 May 2003

The SELRED Guideline Copyright (c) 2003 UIC / Euro-Interlocking Page 1 of 17

Identifier

SR259-DK

SR2-DK

SR3-DK

SR4-DK

SR5-DK

SR6-DK

SR7-DK

SR8-DK

SR9-DK

SR10-DK

SR11-DK

SR12-DK

SR13-DK

SR14-DK

SR15-DK

SR16-DK

SR17-DK

SR18-DK

SR19-DK

SR20-DK

SR21-DK


1 SELRED

SELRED=Structured English Language for REquirements Development

GUIDELINE to more FORMAL REQUIREMENTS

QUICK GUIDE:

REQUIREMENTS STRUCTURE & PROPERTIES

Content of the requirement – ask What instead of How

Distinguish Domain Knowledge, System Requirements and System Specification

Make requirements complete and consistent

STRUCTURING OF OPERATION

TERMS

Use only standardised terms and make example sentences

Abbreviated terms

Use understandable words – write to communicate, not to impress

LOGIC CONSTRUCTION

IF…THEN implication structure

IF AND ONLY IF equivalence

NOT

AND

OR

Truth tables and sheets

SENTENCE CONSTRUCTION

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

Rationale Guidelines

Printed 22 May 2003


Identifier

SR22-DK

SR23-DK

SR24-DK

SR25-DK

SR26-DK

SR27-DK

SR28-DK

SR29-DK

SR30-DK

SR31-DK

SR32-DK

SR34-DK

SR35-DK

SR36-DK

SR37-DK


Keep sentence length no longer than 15-20 words

Avoid adverbs and adjectives alone.

Avoid weak phrases like normal, easy, adequate

DEFINITION OF THE VERBS (IMPERATIVE)

Shall

Shall provide for

Is applicable

Is responsible for

Is / are, has / have

Check

Steer

1.1 Introduction

1.1.1 Scope of this document

Expressing requirements in a natural language includes unavoidable some writers personal interpretations, which are not rigorous or transferable todifferent reader groups. Using exact notation like mathematics would giveworldwide acceptance, but not all requirements can be expressed in the formalway, even for readers fully familiar with the mathematical notation. It iscommon practice to complement a formal requirement with a less formaldescription, which provides real-world context and an overview of the formalmaterial.

Therefore, the use of the formal notation must be complemented by lessmathematical, though still rigorous and coherent, descriptions of therequirements. In this guideline, a structured and exact word set approach hasbeen identified to express requirements in natural (English) language along withother semi-formal techniques. This approach builds the bridge betweenrequirements expressed in English and the absolute formal mathematicalnotation.

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR38-DK

SR39-DK

SR40-DK

SR41-DK

SR42-DK

SR43-DK

SR44-DK

SR45-DK

SR46-DK

SR47-DK

SR48-DK


1.1.2 Structure

The elements of the SELRED (Structured English Language for REquirementsDevelopment) strategy are as follows:

High-level structure (Chapter 2)

Clarity can be greatly improved by adopting a standard high-level structure forrequirements definitions. By clearly distinguishing domain knowledge fromsystem requirements, conditions from operations, one provides a consistentframework for the different sorts of requirements statements. By clearlydelimiting the context of each statement, it greatly reduces the scope forambiguous interpretation.

Good term definitions (Chapter 3)

To provide a firm foundation for expressing requirements, it is essential to havea clear definition of the terms used. It is very important to use terms consistentlyand to avoid overlapping terms, such as having more than one name for the samething. Object modelling and diagramming techniques can assist in the definitionof terms, as well as in the exploration of concepts leading to those definitions.

Structuring of operations (Chapter 4)

Just as the high-level structure provides a clear context for the different types ofrequirements, a consistent structure for defining operations focuses attention onthe essential aspects of each operation. For example, clearly identifying inputs,outputs, preconditions and post conditions, it helps to ensure that the definitionof each operation is complete and unambiguous.

Logic construction guidelines (Chapter 5)

A more productive approach is to draw up guidelines, based on experience, toavoid the most common pitfalls. A set of guidelines for expressing logicconstructions clearly in English would cover, for example, distinguishing clearlybetween ‘if’ and ‘if and only if’, the use of the conjunction ‘and’, the use of thedisjunction ‘or’ and advice on the degree of nesting acceptable.

Sentence construction guidelines (Chapter 6)

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR49-DK

SR50-DK

SR51-DK

SR52-DK

SR53-DK

SR54-DK

SR55-DK

SR57-DK

SR58-DK

SR59-DK


Similarly, guidelines for the construction of clear English sentences are required.These would include issues such as using a reduced set of imperative verbs andminimising the number of subordinate clauses. The requirement sentence shouldonly include allowed adverbs and adjectives.

Definition of verbs (Chapter 7)

One of the most important construction elements of an unambiguous sentence isthe verb. Correctly-used verbs ensure that the meaning of the sentence isunderstood in the same way as the writer intended.

The SELRED guideline also includes some common examples of expressingrequirements in SELRED. (Chapter 8)

1.2 High-level structure of the requirements

An overall structure is essential for successful requirements management.Requirement documents shall be organised so that they are usable andmaintainable. An automated management system should be used ( for exampleDOORS). The requirement structure should be based primarily on the intrinsicstructure of the requirements. Without a logical structure within each document,conflicts in particular can be very difficult to detect.

Intrinsic structure is a different kind of statement which is included with itslogical relationships. Statements have to distinguish between the domain, therequirement and the specification. These statements have quite different rolesand are related to each other according to these roles. (See REVEAL ref. toREVEAL methodology)

1.2.1 Requirements content – from idea to sentence

When stating requirements care must be taken to describe only "WHAT" a taskis to accomplish, not "HOW" it is to be accomplished. Furthermore, what mustbe taken into consideration is that requirements have to be assessable, unique,consistent, and free of hidden design decisions. The requirement document willbe used by many people for different purposes.

It is also useful to separate different kinds of requirements. This is less a matterof principle and more a matter of convenience, because different types are ofinterest to different people. For example, non-functional requirements aresystem properties and constraints under which the system has to operate.

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR60-DK

SR61-DK

SR62-DK

SR63-DK

SR64-DK

SR65-DK

SR66-DK

SR67-DK

SR68-DK

SR69-DK

SR70-DK

SR71-DK

SR72-DK

SR74-DK

SR75-DK

SR76-DK

SR77-DK


Guideline:

Identify the application domain

Define the boundary (Context Diagram)

Describe the domain and all relevant properties (Domain Knowledge)

Define the needs with sources and rationale (System Requirements)

Don’t include system specifications (the "HOW") in requirements (SystemSpecification)

1.2.2 Consistent and complete requirements

A consistent requirement has no conflicts between its individual parts, it definesthe behaviour of essential capabilities and specified behaviour properties.

A complete requirement shall precisely define all the real-world situations thatwill be encountered and the capability’s responses to them. The requirementdoesn’t have to include situations that will not be encountered nor unnecessarycapability features.

Guideline:

Work through the logical thought-processes the user of the requirement willfollow.

Try to draw up an unstructured list of all the ideas (in generic terms) which needto be expressed.

Use this preliminary work to produce a structure for the whole document, listingall sections and their synopses. Use graphic presentation if possible.

1.2.3 Requirements – structure view

Guideline:

Plan the logical and visible structure of the total set of the document.

Make a full set of headings and subheadings and a short synopsis of what eachsection and subsection will be about.

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR78-DK

SR79-DK

SR80-DK

SR81-DK

SR82-DK

SR260-DK

SR84-DK

SR85-DK

SR261-DK

SR86-DK


Arrange the logical order of the whole document.

Don’t start a new sentence until you have a clear idea what it will state; thenarrange it so that its ideas are in a logical order.

Clearly describe the structure that is being used with diagrams or tables. Theseassist readers in navigating the structure

1.3 Term definition

The main guideline for expressing terms in requirements is to use alreadystandardised terms. If a vocabulary with new terms has to be created, the rulesfor the development of standardised terminology should follow internationalstandards (ISO 10241:1992). The use of terms which are not self-explanatory orcommonly known and which can be misinterpreted in different contexts shall beclarified by defining the relevant concept. An example using the term in itscontext provides an unambiguous and comprehensive way of defining that term.

The list of terms should not be exhaustive. The vocabulary shall only includenecessary terms. All other terms used in the requirements shall be interpretedas they are defined in the Oxford Dictionary.

1.3.1 Standardised terms

In an independent terminology standard or vocabulary, the concept defined shallbe restricted to the field corresponding to the scope of the requirement. Everyused term has to be defined either by a designation which is clear enough in allinstances, or by a definition grounded in terms with designation.

A “designation” is a fundamental term which forms the basic building block ofthe terms definitions. It is defined without the use of other term in thevocabulary and it serves to specify the particular meaning of a word in thecontext of the requirement.

1.3.2 Abbreviated terms

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR87-DK

SR88-DK

SR89-DK

SR90-DK

SR250-DK

SR92-DK

SR93-DK

SR94-DK

SR96-DK


Abbreviated terms shall be used with care, and their use shall be limited to thosecases where it is unlikely to cause confusion. An abbreviated term shall bespecified only if used subsequently in the requirement. If a list of abbreviatedterms is not given in the requirement, then the first time that an abbreviatedterm is used, the full term shall be given with the abbreviated term following inparentheses.

The general rule is that abbreviated terms consisting of the initial letters ofwords be printed in lower-case letters and a full-stop be placed after each letter.Where, however, an abbreviated term comprises capital letters, no full-stops arerequired. If a sentence begins with an abbreviated term consisting of severalletters, all the letters of the abbreviated term shall be capital letters.

1.3.3 Understandable words

The expressions used in requirements shall be understandable. Use words thatare in common knowledge. Express exactly what you mean, using the simplestwords that fit. This does not necessarily mean only using simple words - justwords that the reader will understand. Write to communicate, not toimpress.

1.3.4 Terms in capital letters

Terms specified to be inside the Requirements Context (Diagram) boundary areexpressed with capital letters. Example: The CONTROL is the traffic control part of the system.

1.4 Structure of operations

1.4.1 Sentence with inputs/outputs

The conditional sentence includes inputs, outputs and logical operations betweenthem. The sentence shall be constructed so that the inputs and the outputs areclearly noticeable. Standardised terms shall be highlighted and links to thevocabulary shall be used (DOORS).

1.4.2 State approach

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR97-DK

SR99-DK

SR100-DK

SR101-DK

SR103-DK

SR104-DK

SR105-DK

SR106-DK

SR107-DK

SR108-DK


When expressing the functionality in a system with a set of different states, theoperations shall be able to identify pre- and post-condition of a state. Thepre-condition shall be expressed with the abbreviation (pre) and the postcondition with (post). This ensures that the definition with context of a statedescription is complete and unambiguous.

1.5 Logic construction

1.5.1 Logic in functional requirements

The functional requirements are often validated and therefore the sentencestructure can be more strict. It is possible to specify sentences with well definedsyntax and semantics. The syntax defines the rules and configurations of thesentence and semantics determines the facts in the world to which sentencesrefer. Semantics checks the meaning of sentences. When the natural languageused in a functional requirement expression has well defined syntax andsemantics, it can be used to express propositional logic and its rules. This is asemi-formal way to express logical sentences.

1.5.2 Semantics and syntax for functional requirements

The functional sentence shall be in the form of implication, equivalence or plainstatements. The input condition is expressed as a form of one or more logicalconnectives. The resulting output of the functional sentence is expressed in alater part of the sentence.

An implication includes IF… THEN – structure, where the input conditionsare in the IF-part and the output results on the THEN-part.

An equivalence includes the expressions in the input part and the resultingoutputs in the last part of the sentence. The sentence structure is: input … IFAND ONLY IF… output.

A plain statement sentence is expressed with only a specified set of words(terms, verb, nouns with adjectives/adverbs).

1.5.3 Logic connectives

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR109-DK

SR110-DK

SR111-DK

SR112-DK

SR263-DK

SR113-DK

SR114-DK

SR115-DK

SR116-DK

SR117-DK

SR118-DK

SR119-DK

SR120-DK


The semantics of the functional requirement sentence in propositional logic isdefined by interpreting the proposition symbols and constants, and by specifyingthe meanings of logical connectives. Natural language equivalencies for logicalconnectives are expressed in parenthesis.

Negation: NOT

A negation reverses the value of the input.

Example: Switch1 is not activated.

Example: Switch1 shall not turn.

Conjunction: AND

(but, although, however, both ,also)

A conjunction is true if and only if both inputs are true.

Example: If Switch1 and Switch2 are activated, then the system shall bereleased.

Disjunction: OR

(Either .. or, unless, alternatively, otherwise)

A disjunction is false if and only if both inputs are false

Example: If Switch1 or Switch2 is activated, then the system shall be released

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR121-DK

SR122-DK

SR123-DK

SR124-DK

SR125-DK

SR126-DK

SR127-DK

SR128-DK

SR129-DK

SR130-DK

SR131-DK

SR132-DK


Equivalence: IF AND ONLY IF

(is equivalent to, necessary and sufficient)

An equivalence is true if and only if both inputs agree in the sentence.

Example:

Implication: IF…THEN

(provided that, only if, given that, implies, is a sufficient condition, is a necessarycondition)

A conditional statement is false if and only if the antecedent is true and theconsequent is false, otherwise it is true

Example: If Switch1 is activated, then release the system

1.5.4 Logical truth tables

Constants : True, False

Proposition Symbols: P, Q (sentences)

Logical Connectives: negation, conjunction, disjunction, implication,equivalence

P Q NOTP

PAND

P OR Q

P => Q P <=> Q

False False True False False True True

False True True False True True False

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR174-DK

SR175-DK

SR177-DK

SR178-DK

SR179-DK

SR180-DK

SR181-DK

SR182-DK

SR183-DK

SR184-DK


True False False False True False False

True True False True True True True

1.5.5 Decision tables and sheets

A decision table is a matrix representation of the logic of a decision, whichspecifies the possible conditions for the decision and the resulting actions. Thecolumns and rows of a decision sheet shall only contain specified terms. Thelogical value of an element shall be expressed in terms TRUE or FALSE(abbreviated T / F). If enumerated terms are used, they shall be specified with allseparate sheets.

1.6 Sentence constructions

1.6.1 Sentence length

A sentence expressing requirements shall be no longer than 15-20 words. Shortsentences are more comprehensive. Long sentences should be able to be brokenup into two or more short sentences. The basic principle is to express only onemain idea in one sentence. Complex sentence constructions with multiple subsentences shall not be used. Keep sentences simple and short.

1.6.2 Adverbs and adjectives

Adverbs and adjectives shall only be used if they are defined together with theircorresponding nouns. Otherwise it could lead in misunderstandings. Use pairs ofadverbs as enumerated values. A general rule is to use a negation value e.g. anadverb with prefix not.

Example: Occupied / not occupied (don’t use vacant)

Activated / not activated

Right / left (exception for common rule)

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR185-DK

SR186-DK

SR187-DK

SR188-DK

SR189-DK

SR190-DK

SR191-DK

SR192-DK

SR193-DK

SR194-DK

SR195-DK

SR196-DK


1.6.3 Avoid weak phrases

"Weak phrases" is a category of clauses that are apt to cause uncertainty andleave room for multiple interpretations. Use of phrases such as “adequate” and“as appropriate” indicate that what is required is either defined elsewhere or,worse, that the requirement is open to subjective interpretation. Phrases such as“but not limited to” and “as a minimum” provide a basis for expanding arequirement or adding future requirements. Weak phrases are an indication ofextent that the requirement is ambiguous and incomplete.

List of Weak phrases:

adequate

as a minimum

as applicable

easy

as appropriate

but not limited to

effective

if practical

normal

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR197-DK

SR262-DK

SR198-DK

SR199-DK

SR200-DK

SR201-DK

SR202-DK

SR203-DK

SR205-DK

SR206-DK

SR207-DK

SR208-DK


timely

wrong

1.7 Definition of the verbs

1.7.1 Imperative verbs

Imperatives are those verbs that command that something must be provided.The SELRED list of imperative verbs is presented in descending order oftheir strength as a forceful statement of a requirement. The verbal formspresented shall strictly be used to indicate requirements to be followed in orderto satisfy the requirement and from which no deviation is permitted. OnlySELRED verbs shall be used to confirm unambiguity.

Shall - is used to dictate the provision of a functional capability

Example: The system shall be modular

Shall provide for – is used to dictate functional capability in case of conditions that can be contradictory

Example: The system shall provide for the use of an internal HMI or an external data connection.

Is applicable- is used to include, by reference, standards or other documentation as an addition to the requirements being

specified

Example: EN50126 is applicable for the system

Is responsible for- is used as an imperative in requirementsdocuments that expresses systems whose architectures arealready defined

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR209-DK

SR210-DK

SR211-DK

SR213-DK

SR214-DK

SR215-DK

SR216-DK

SR218-DK

SR219-DK

SR220-DK

SR221-DK

SR222-DK

SR223-DK


Example: The operator is responsible for organising maintenance.

Is / are – is used to inform qualitative capability

Has / have – is used to include functional capability

Check – is used instead of the verb "control" for purpose to find outinput states

Example: The system checks the status of the Interface1.

Steer – is used instead of the verb "control" for purpose to steer theoutput

Example: The system steers Interface Relay1.

1.7.2 Avoidable verbs and expressions

"A avoidable expression" is a category of clauses that are apt to causeuncertainty and leave space for multiple interpretations. The total amount ofweak expression found in a requirement is an indication of the extent that therequirement is ambiguous and incomplete. These verbs are ambiguous and areused in many sentences against their original (English) meaning.

Be able to –

Be capable -

Provide for -

Can -

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR224-DK

SR225-DK

SR226-DK

SR227-DK

SR228-DK

SR229-DK

SR248-DK

SR230-DK

SR231-DK

SR232-DK

SR233-DK

SR234-DK


May -

Must - is used to establish performance requirements or constraints

Is required to – is used as an imperative in requirements statementswritten in a passive voice.

Will – is used to cite things that the operational or developmentenvironments are to provide to the capability being specified.

Should – is used as a weak imperative in requirements statements. Use instead;"shall be".

Control – use instead; "check" or "steer".

1.8 Examples

1.8.1 SELRED approach and Railway Interlocking Requirements

As an example of the SELRED approach outlined in previous chapters, considerthe following statements as hypothetical requirements for railway interlocking functional requirements.

A set of points shall be locked if it is part of a locked route.

A route shall be locked if and only if a lock command is received and theconditions for locking are satisfied.

A route is released if and only if the conditions for release are satisfied.

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier

SR235-DK

SR236-DK

SR237-DK

SR238-DK

SR239-DK

SR240-DK

SR241-DK

SR255-DK


These statements use basic domain terms such as ‘set of points’, ‘route’, ‘lockcommand’ and the concept of ‘locked’ and ‘released’ points and routes. Theseterms should be fully defined in a separate section, together with definitions ofany significant relationships between terms (for example, a set of points may be‘part of’ a route). The terms and relationships should also be shownschematically in the form of an object model diagram to provide an overview anda starting point for the reader.

Logic constructions are restricted to a well-defined set of basic connectives suchas ‘if and only if’. The actual conditions for locking and release are defined infurther statements to avoid over-complex sentence structure.

The conditions for locking a route are that the route is set and obstacle freeand conflict free and not being manually released.

Clarity is further enhanced by adopting a consistent typographical convention toshow the reader which words are to be interpreted as basic terms or as logicalconnectives. For example, here it has been chosen to write terms underlined.

This style of writing requirements in natural language assists in developing andunderstanding the mathematically formal expression of the requirements, sincethe transformation between the natural language statements and theirexpression in the formal notation is relatively small. The basic objects appear inthe formal notation as variables while relationships between objects and changesin the state of objects are expressed as predicates. For example, the firststatement might have an equivalent formal form of

1.8.1.1

It is interesting that even here the formal expression is more precise than theEnglish statement. Note how the indefinite article ‘a’ set of points has produced auniversal quantifier (ALL pt) whereas ‘a’ route has produced an existentialquantifier (SOME rt).

1.9 References

1.Internal Regulations Part 3: "Rules for the structure and drafting of EuropeanStandards", CENELEC

2.ISO/IEC Directives Part 3: "Rules for the structure and drafting of

Status

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Approved

Applicable to

All

All

All

All

All

All

All

All


Printed 22 May 2003


Identifier Structured English Language for Req Development

International Standards", ISO/IEC

3.W.M.Wilson/NASA: "Writing effective Requirements Specifications", NASA

4.Guide to Technical Writing:(1) "The Document Lifecycle", Praxis CriticalSystems LTD5.Guide to Technical Writing:(2) "Writing Good English", Praxis Critical SystemsLTD

6.Plain English Campaign: "How to write reports in plain English", PlainEnglish Campaign7. REVEAL methodology:"Reveal requirements engineering course", PraxisCritical Systems LTD

Status Applicable to Rationale Guidelines

cenelec phase 2/the selred guideline - uic.org · pdf filesr7-dk sr8-dk sr9-dk sr10-dk sr11-dk...

Documents