0% found this document useful (0 votes)
48 views25 pages

Slides - Week 8 - Requirement Construction Using Templates

The document discusses the effects of documenting software requirements in natural language. It notes issues like nominalization, nouns without reference indexes, universal quantifiers, incompletely specified conditions, and incompletely specified process verbs. To address these issues, it recommends using a requirements template with steps like determining the legal obligation, specifying the requirement core activity, characterizing the system activity, inserting objects, and determining logical and temporal conditions. Using templates can help reduce language effects and ambiguity when documenting requirements.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views25 pages

Slides - Week 8 - Requirement Construction Using Templates

The document discusses the effects of documenting software requirements in natural language. It notes issues like nominalization, nouns without reference indexes, universal quantifiers, incompletely specified conditions, and incompletely specified process verbs. To address these issues, it recommends using a requirements template with steps like determining the legal obligation, specifying the requirement core activity, characterizing the system activity, inserting objects, and determining logical and temporal conditions. Using templates can help reduce language effects and ambiguity when documenting requirements.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Software

Requirement
Engineering
WEEK # 8
2
Effects of Documenting Requirements in Natural
Language

 Subjective Perception

 Transformational Effects
3
Effects of Documenting Requirements in Natural
Language (Cont.)

Nominalization
 By means of nominalization, a (sometimes long-lasting) process is converted into a
(singular) event. All information necessary to accurately describe the process is
thereby lost.
4
Effects of Documenting Requirements in Natural
Language (Cont.)

Noun without Reference Index


 As with process verbs, nouns are frequently incompletely specified. Linguists call this a
missing or inadequate index of reference.

 Examples of terms that contain incompletely specified nouns are the user, the
controller, the system, the message, the data, or the function.
5
Effects of Documenting Requirements in Natural
Language

The following questions arise: What data exactly? Which user exactly? Which terminal
exactly? If this information is amended, the requirement might thus read as follows:
6
Effects of Documenting Requirements in Natural
Language

Universal Quantifiers
 Universal quantifiers specify amounts or frequencies.

 They group a set of objects and make a statement about the behavior of this set.

 It must be verified whether the specified behavior really applies to all objects
summarized through the quantifiers.

 Universal quantifiers can be easily identified through trigger words such as never,
always, no, none, every, all, some, or nothing.
7
Effects of Documenting Requirements in Natural
Language (Cont.)

In this case, the following question must be asked: Really in every submenu?
Really all data sets?
8
Effects of Documenting Requirements in Natural
Language (Cont.)

Incompletely Specified Conditions


 Requirements that contain conditions specify the behavior that must occur when
the condition is met.

 In addition, they must specify what behavior must occur if the condition is not met
(the part that is often missing).
9
Effects of Documenting Requirements in Natural
Language (Cont.)
10
Effects of Documenting Requirements in Natural
Language (Cont.)

Incompletely Specified Process Verbs


 Some process verbs require more than one noun to be considered completely
specified.

 The verb transmit, for instance, requires at least three supplements to be considered
complete: what is being transmitted, from where it is being transmitted, and to where
it is being transmitted.
11
Effects of Documenting Requirements in Natural
Language (Cont.)

 Avoid Passive Voice

 Use Active Voice


12

A requirements template is a
blueprint for the syntactic structure
of individual requirements
13
Requirements Construction using Templates

 Requirements templates provide a simple and easily understandable


approach to reduce language effects when documenting requirements.

 Templates support the author in achieving high quality and syntactic


unambiguousness in optimal time and at low costs.
14
Requirements Construction using Templates
(Cont.)

Step#1: Determine the legal obligation

Step#2: The Requirement Core

Step#3: Characterize the activity of a System

Step#4: Insert Objects

Step#5: Determine logical and temporal conditions


15
Step#1: Determine the Legal Obligation

 Distinguish between legally obligatory requirements, urgently recommended


requirements, future requirements, and desirable requirements.

 You can use the modal verbs shall, should, will, and may.

 Alternatively, the legal obligation of a requirement can be documented by a


specific requirements attribute. (Priority, Source, Comments, Difficulty, Risk)
16
Step#2: The Requirement Core

 The core of each requirement is the functionality that it specifies (e.g., print, save, paste, or
calculate).

 This functionality is referred to as the process.

 Processes are activities and may only be described using verbs.

 The process that depicts the system behavior by means of a requirement is to be described
in step 2.

 Since process words determine semantics, they must be defined as clearly as possible and
be used as consistently as possible
17
Step#3: Characterize the Activity of a System

 For functional requirements, the system activity can be classified as one of three
relevant types:
 Autonomous system activity: The system performs the process autonomously.

 User interaction: The system provides the process as a service for the user.

 Interface requirement: The system performs a process depending on a third party (e.g.,
another system). The system is passive and waits for an external event.
18
Step#3: Characterize the Activity of a System
(Cont.)
19
Step#3: Characterize the Activity of a System
(Cont.)

Autonomous system activity

 The first template type is used when requirements are constructed that depict
system activities that are performed autonomously. The user does not interact
with the activity.

 <Process Verb> depicts a process verb as described in step 2, e.g., print for print
functionality or calculate for some calculation that is performed by the system.
20
Step#3: Characterize the Activity of a System
(Cont.)

User Interaction

 If the system provides a functionality to a user (for example, by means of an input


interface), or the system directly interacts with a user, requirements are constructed
using template type 2:

 The user that interacts with the system is integrated into the requirement through
<whom?> .
21
Step#3: Characterize the Activity of a System
(Cont.)

Interface Requirement

 If the system performs an activity and is dependent on neighboring systems, the third
template type is to be used.

 Whenever messages or data are received from a neighboring system, the system must react
by executing specific behavior.

 The following template has proven itself as well suited:


22
Step#4: Insert Objects

Complete Process Verbs

 Some process verbs require one or more additional objects to be considered complete.

 In step 4, potentially missing objects and supplements of objects (adverbials) are


identified and added to the requirement.

 For instance, the requirements template for the process verb print is amended by the
information of what is being printed and where it is printed.
23
Step#4: Insert Objects (Cont.)
24
Step#5: Determine Logical and Temporal
Conditions

 Typically, requirements do not document continuous functionalities, but functionalities that are
performed or provided only under certain logical or temporal constraints.

 Use temporal conjunction as soon as for temporal conditions and the conditional conjunction if
for logical conditions.

 The conjunction when makes not clear whether a temporal or a logical condition is described
and should therefore be avoided.

 In step 5, quality requirements that describe the conditions under which a requirement is
fulfilled are added to the beginning of a requirement as a subordinate clause.
25
Step#5: Determine Logical and Temporal
Conditions (Cont.)

You might also like