Natural Language Requirements Software Verification and Validation Laboratory Requirement Elaboration Heuristic Domain Model» Requirement Relationship Natural Language is elaborated via Requirement application of follows Syntactic Requirement Pattern OCL Constraint refers to concepts from is constrained by» refers to concepts from is constrained by º is refined by is expressed in is related to is expressed in is formalized by Use Case» is augmented by» System Sequence Diagram MARTE Profile SysML Requirement Diagram follows 2 Use Case Template (RUCM) 1
Basics of NL Requirements What is a Natural Language (NL) requirement? - A natural language requirement is a requirement that is documented using a natural language (for example, English, French, German) - Also known as textual requirement Example A functional requirement in NL: If a glass break detector at the window detects that the pane has been damaged the system shall inform the security service. NL requirements mingle conceptually distinct elements: - Domain concepts: glass break detector, window, pane, system, security service - Function: detects, inform the security service - Behavior: if [ ] damaged, then inform [ ] Basics of NL Requirements II Quality properties may further be added into the mix Example A functional requirement in NL: If a glass break detector at the window detects that the pane has been damaged the system shall inform the security service within 2sec at the latest. Problem: One or more parts of the specification may be overlooked! General best practice: Separate function and quality Example RF1: The glass break detector at the window shall detect if the glass pane is damaged. RF2: If the detector detects damage to the pane (see RF1), the system shall inform the security service. RQ1: The system shall inform the security service (see RF2) within 2sec after detecting damage. 2
Advantages and Disadvantages of NL Requirements Advantages: Universal: Natural language can be used in any problem area or domain Flexible: natural language allows arbitrary abstractions and refinements during requirements documentation. Comprehensible: Requirements documented in natural language are comprehensible to many stakeholders since no training or special tools are required Disadvantages: Under-specification: if details about a requirement are not documented, different stakeholders can assume different details and thereby interpret the requirements in different ways Ambiguity: Even careful specification cannot remove the ambiguity entirely! Ambiguity in NL Lexical Ambiguity Lexical Ambiguity Caused by synonyms (different words for the same concept) and homonyms (same word for different concepts) Example of synonyms: car / automobile, small / little Example of homonyms: trunk (different meanings in botany, zoology, normal use, American English) Synonyms and homonyms a major source of ambiguity in requirements - mainly because stakeholders use different vocabularies 3
Ambiguity in NL Syntactic Ambiguity Syntactic Ambiguity When the same sentence can convey multiple different meanings Example: The navigation systems shall display the last five destinations and starting points. Interpretation 1: Display the last five items entered, be those destinations or starting points Interpretation 2: Display the last five destinations and a set of starting points Interpretation 3: Display the last five destinations and the last five starting points. Ambiguity in NL Semantic Ambiguity Semantic Ambiguity subsumes syntactic and lexical ambiguity Sentences having different interpretations due to syntactic and/or lexical ambiguity Syntactic / lexical ambiguity Semantic ambiguity Sentences having different interpretations despite having no syntactic and/or lexical ambiguity Example: (1) If a window of the car is is damaged and and the interior surveillance (2) of the car detects the interior an intruder surveillance or a door of the of the car car detects is opened an intruder without a or car key, the safety a door system of the car shall is raise opened an alarm. without a car key then (3) Interpretation 1: if (1) AND [(2) OR (3)] then (4). Interpretation 2: if [(1) AND (2)] OR (3) then (4). 4
Ambiguity in NL Referential Ambiguity and Vagueness Referential Ambiguity If a word or phrase in a sentence refers to an object and there are different interpretations regarding what this object is. Example: The customer inserts the access card into the card reader and enters a personal identification number (PIN) at the keypad. If it is invalid, the system shall deny the access. Unclear what it refers to, the access card or the PIN. Ambiguity of terms (vagueness) Example: All medium-sized vehicles shall be equipped with a navigation system. Unclear what medium-sized means Avoiding Ambiguity Glossaries Collection of technical terms that are part of the language (terminology) in a given domain. Aimed at addressing lexical ambiguity and vagueness Common structure for a glossary: Term Definition Synonyms Related terms Examples/ Counter examples name of term definition text synonym-1; term-1; references to examples / counter examples 5
Glossary Example Term Definition Route The specific instance of a direction from a starting point to a destination Synonyms Related terms Examples/ Counter examples Itinerary Alternative route (specialization) [Link to a map showing an example route] Guidelines for Building Glossaries 1. Define a structure for the glossary entries to be used by all authors editing glossary entries 2. Regularly check the structure of the glossary 3. Ask stakeholders with different backgrounds to provide their own definition of a term and align the definitions obtained 4. If you question whether a term should be defined in the glossary, it is better to define the term rather than leaving it out 5. Involve stakeholders with different backgrounds to review the glossary entries, comment on existing definitions, and identify missing ones. 6. Make the glossary available online as hypertext, if possible. 7. Provide support for managing the glossary on an intranet or the Internet, for example through a wiki 6
Requirement Elaboration Heuristic Domain Model» Requirement Relationship Natural Language is elaborated via Requirement application of follows Syntactic Requirement Pattern OCL Constraint refers to concepts from is constrained by» refers to concepts from is constrained by º is refined by is expressed in is related to is expressed in is formalized by Use Case» is augmented by» System Sequence Diagram MARTE Profile SysML Requirement Diagram follows 13 Use Case Template (RUCM) Avoiding Ambiguity Using Requirement Patterns What is a requirement pattern? A (syntactic) requirements pattern defines a syntactic structure for documenting requirements in NL and defines the meaning of each part of the syntactic structure. Aimed at addressing syntactic ambiguity Patterns are to some extent tailorable to the application domain 7
Requirement Pattern (by Rupp) Requirement Pattern (by Rupp) <When> defines conditions under which the function documented in the requirement is to be performed or provided. 8
Requirement Pattern (by Rupp) The name of the system which provides the documented function. This systems is the grammatical subject of the sentence. Requirement Pattern (by Rupp) Shall/should/will/ : indicates the importance of the requirement. 9
Requirement Pattern (by Rupp) Indicates the required functionality. Three patterns are distinguished: 1. <process>:applies to requirements that document functionality that they system offers independently of interactions with users 2. PROVIDE <whom?> WITH THE ABILITY TO <process>: applies to requirements that document functionality that the system provides to specific users 3. BE ABLE TO <process>: applies to requirements that the system performs as reactions to trigger events from other systems. Requirement Pattern (by Rupp) Describes the object for which the functionality is required. The object as well as its additional details are documented after the process. 10
Requirement Pattern (by Rupp) Example: If the glass break detector detects the damaging of a window, the system shall inform the head office of the security service. [<when>: If the glass break detector detects the damaging of a window] THE SYSTEM SHALL [<process>: inform] [<object>: the head office of the security service.] Guidelines for Application of Requirements Pattern I Step 1: Determine legal obligations Usually, the following cases are distinguished Legally obligatory SHALL Urgently recommended SHOULD Future requirement WILL Alternatively, legal obligation can be captured as a requirement attribute. Step 2: Determine the requirement core The core is the functionality that the requirement specifies Examples: print, save, paste, or calculate Corresponds to the process slot in the requirement template Processes are activities and can only be verbs 11
Guidelines for Application of Requirements Pattern II Step 3: Characterize the activity of a system Functional requirements can be classified into three types: Autonomous system activity: The system performs the process autonomously The user does not interact with the activity. User interaction: The system provides the process as a service for the user, for example through an input interface, or direct interactions Interface requirement: The system performs a process depending on a third party. Whenever messages or data are received from a neighboring system, the system must react by executing specified behavior. Relation of Step 3 to requirement template: Autonomous system activity <process> User interaction provide <whom?> WITH THE ABILITY to <process> Interface requirement BE ABLE TO <process> Guidelines for Application of Requirements Pattern III Step 4: Insert Objects Some process verbs require one or more additional objects For example, the process verb print is amended by information of what is being printed and where it is printed. Step 5: Determine logical and temporal conditions Corresponds to the <when> part of the pattern Useful to differentiate between logical and temporal conditions Recommended: Use As soon as for temporal conditions and if for logical conditions. when cannot clarify this distinction 12
Avoiding Ambiguity Controlled Languages What is a controlled language? Two major components: A grammar that imposes precisely defined constraints on the natural language A set of terms (including the term s semantics) to be used within the grammar Can be used to address all aspects of ambiguity Advantages of controlled languages Resulting requirements are easy to understand, since they are still in natural language Less proneness to ambiguity since a simplified grammar and a precisely defined vocabulary is used Semantically verifiable (due to formal grammar and predefined terms) Difference between controlled language and requirements patterns A controlled language in addition to restricting the syntax also precisely defines the semantics of the resulting requirement. Avoiding Ambiguity Controlled Languages What is a controlled language? Two major components: A grammar that imposes precisely defined constraints on the natural language A set of terms (including the term s semantics) to be used within the grammar Can be used to address all aspects of ambiguity Advantages of controlled languages Resulting requirements are easy to understand, since they are still in natural language Less proneness to ambiguity since a simplified grammar and a precisely defined vocabulary is used Semantically verifiable (due to formal grammar and predefined terms) Potential research topic for future collaboration! Difference between controlled language and requirements patterns A controlled language in addition to restricting the syntax also precisely defines the semantics of the resulting requirement. 13
Structuring NL Requirements Many recommendations exist Advantages of reference structures Proven structure defined based on experience of experts Reference for completeness Focusing on the content, not the structure Same information at the same place Tool support IEEE Std. 830-1998 a popular reference structure for Requirements Documents Part 1: Introduction Purpose, Scope, Definitions, acronyms and abbreviations, References, Overview Part 2: Overall description Product perspective, product functions, user characteristics, constraints, assumptions and dependencies Part 3: Specific requirements External interfaces, functional requirements, performance requirements, logical database requirements, design constraints, software system attributes, other requirements Organization of part 3 depends on type of system, recommendations exist Standard Structure for a Software Requirements Specification According to [IEEE Std 830-1998] 14
Possible Contents of Part 3 of an SRS According to [IEEE Std 830-1998] Organization of Part 3 of the SRS By mode (left- hand side) By user class (right-hand side) 15
References Klaus Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, 2010, Springer Klaus Pohl and Chris Rupp, Requirements Engineering Fundamentals, 2011, Rocky Nook Chris Rupp and Sophist Group, Requirements Engineering und Management, 5 th edition, Hanser, München 16