requirements and boilerplates tor stålhane idi / ntnu
TRANSCRIPT
![Page 1: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/1.jpg)
Requirements and boilerplates
Tor StålhaneIDI / NTNU
![Page 2: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/2.jpg)
Content • Requirements specifications• Why are requirements specification difficult• Templates – boilerplates and guided natural
language • Guided natural language – GNL • Boilerplates • Boilerplate examples• How to communicate requirements – use
cases and beyond
![Page 3: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/3.jpg)
Requirements specification
![Page 4: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/4.jpg)
Goal tree – 1
![Page 5: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/5.jpg)
Goal tree – 2
![Page 6: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/6.jpg)
Goal tree – example
![Page 7: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/7.jpg)
Goal description
![Page 8: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/8.jpg)
Why are requirements difficult
![Page 9: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/9.jpg)
What is the problemEffects of Inadequate Requirements development – Airbus:
• Requirement: Reverse thrust may only be used, when the airplane is landed.
• Translation: Reverse thrust may only be used while the wheels are rotating.
• Implementation: Reverse thrust may only be used while the wheels are rotating fast enough.
• Situation: Rainstorm – aquaplaning
• Result: Crash due to overshooting the runway
• Problem: erroneous modeling in the requirement phase
![Page 10: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/10.jpg)
The challenge The main challenges in Requirements
Engineering for large systems are that:• There are many requirements – often several
thousands. • Several requirements are interdependent• Requirements are related to two or more of:
– Hardware – computers, sensors, actuators, machinery
– Software – control, measurement, logging– Operators – procedures, behavior
![Page 11: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/11.jpg)
Brake by Wire System – 1
moving
Requirement - Natural language:On a blocked wheel the brake shall be released
within 100ms, while the vehicle is moving.
![Page 12: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/12.jpg)
Brake by Wire System – 2
WSS = Wheel Sped Sensor
![Page 13: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/13.jpg)
TemplatesBoilerplates
and Guided Natural language
![Page 14: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/14.jpg)
Humans and machines – 1 Given the amount and complexity of RE, we
need to automate as much as possible.
Humans and machines have different strong and weak points.
We want to elicit and analyze requirements in a way that allows both parties to build on their strong sides.
![Page 15: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/15.jpg)
Humans and machines – 2 We have focused on the differences between man and machine for
requirements elicitation and formulation – understanding, observing and reasoning and requirements analysis – memory, information processing and consistency
Area Man MachineUnderstanding Good at handling large variations in
written materialBad at handling large variations in written material
ObservationGeneral observations, multifunctional patterns
Specialized observations, quantitative data
Reasoning Inductive, slow, imprecise but with good error correction capabilities
Deductive, fast, precise but with bad error correction capabilities
Memory Innovative, general access Copying, formal access Information processing Single channel, less than 10 bits
per secondMultichannel, several megabits per second
Consistency Unreliable, gets tired, depends on learning
Consistent, do not get tired, repeating several actions
Force Low level, maximum 1500 watt High level over a long time periodSpeed Slow, reaction times in seconds Extremely fast
![Page 16: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/16.jpg)
Humans and machines – 3
• Machines are – good at observing quantitative data and being
deductive, fast and precise. In addition, they are good at doing consistent repetition of several actions.
– bad at handling variations in written material and pattern recognition.
• Humans are good at handling variations in written material, being inductive. In addition, they are good at doing error correction.
![Page 17: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/17.jpg)
TDT 4242
Motivation for use of templates – 1
Text has the advantage of unconstrained expression. There is, however, a need for common
• Understanding of concepts used to express the requirements and relations between them.
• Format of presentation
Lack of common understanding makes requirement specifications expressed as free text prone to ambiguous representations and inconsistencies.
![Page 18: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/18.jpg)
TDT 4242
Motivation for use of templates – 2
Template based textual requirements specification (boilerplates) will introduce some limitations when representing requirements but will also reduce the opportunity to introduce ambiguities and inconsistencies.
Boilerplates
• Provides an initial basis for requirements checking
• Are easy to understand for stakeholders compared to more formal representations
![Page 19: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/19.jpg)
TDT 4242
Requirements – 1 There are three levels of requirements:
• Informal – e.g. Natural language (NL): free text, no rules apply
• Semiformal• Guided Natural Language (GNL): free text but
allowable terms are defined by a vocabulare• Boilerplates (BP): structured text and an ontology
– vocabulary plus relationships between terms
• Formal: e.g. state diagrams or predicate logic
![Page 20: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/20.jpg)
Requirements – 2
Req.012: The system shall enable cabin temperature regulation between 15°C and 30°C
……
Req.124: Cabin temperature shall not exceed 35°
Step 1:Capture Requirements in Natural Language
Step 2:Transfer Requirements and functions into a semi-formal requirements model
Function 1
Req 001Req 002Req 012
…Req 124
Function 2
Req 011Req 028Req 050
……
Function 1
Req 001Req 002Req 012
…Req 124
Function 1
Req 001Req 002Req 012
…Req 124
Function 2
Req 011Req 028Req 050
……
Function 2
Req 011Req 028Req 050
……
Function 1
Function 1a
Function 1b
Function 1c
Function 1
Function 1a
Function 1b
Function 1c
Req 001.01Req 001.02….
Step 3:Refine the requirements model and derive detailed requirements
Parallel Steps:Apply dictionary with common vocabulary; validate and check Requirements consistency and completeness
Step 4:Create a preliminary design model based on the requirement model (to be used and refined in SP3)
![Page 21: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/21.jpg)
BPs and GNL – 1
RMM- Refinement- Specialization
Example: The <system function> shall provide <system capability> to achieve <goal>
Template based textual Meta ModelSyntax Semantics
Guided RSL Boilerplates
Requirements expressed using a vocabulary guideUses predefined concepts, relations and axioms to guide requirements elicitation
Requirements expressed on templatesUses predefined templates based on concepts, relations and axioms to guide requirements elicitation
Keywords:Reflects requirement, system and domain concepts
Analysis-Correctness-Completeness-Consistency-Safety analysis
Ontology: General and SP specific- Requirements classification- System attributes- Domain concepts
= + +
Example:The ACC system shall be able to determine the speed of the ego-vehicle.
![Page 22: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/22.jpg)
Guided Natural Language and Boilerplates will reduce variation and thus giving the machines the opportunity to do what they are best at: to be fast, precise and consistent.
By combining humans and machines and let both do what they are best at, we get a better result than we would get if we left the job of handling requirements to just one of them.
BPs and GNL – 2
![Page 23: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/23.jpg)
Why BPs and GNL – 3
The final goal is to allow the machine to assist the developers in analysing requirements for:• Consistency – no requirement contradicts an
other requirement• Completeness – all necessary requirements
are stated • Safety implications – consider the possibility
for hazards
![Page 24: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/24.jpg)
Guided Natural language
![Page 25: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/25.jpg)
• Free text requirement elicitation with the assistance of prescribed words from a dictionary. This will give us requirements which use all terms in a uniform way, thus reducing misunderstandings
• No formal constraints• Requires minimal expertise.
What is GNL - 1
![Page 26: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/26.jpg)
What is GNL - 2
Bridge the gap between unconstrained expression and quality checking when representing requirements as free text.
• Quality measures:– Correctness– Consistency– Completeness– Un-ambiguity (reduced variability)
• Provide the basis for semantic processing and checking of requirements.
• Dictionary – Simple taxonomy or more formal ontology
![Page 27: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/27.jpg)
Ontologies – 1 Ontologies are an important part of CESAR's approach
to requirements engineering. An ontology has three parts
• a thesaurus• a set of relationships between terms in the thesaurus• rules for making interferences based on these
relationships.
The information used to build an ontology is in our case mainly found in standards and glossaries.
![Page 28: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/28.jpg)
Ontology = Thesaurus + Inference Rules• Thesaurus – Domain concepts: entities,
terms and events• Inference Rules – Relations, attributes
and axioms• Causality, similarity, reflexivity,
transitiveness, symmetric, disjoint (contradiction) …
Ontologies – 2
![Page 29: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/29.jpg)
Ontologies – 3 Required Activity• Knowledge capture: Information embedded in
domain events from domain experts and ontologist• Implementation: Formal representation of captured
knowledge. Language: OWL, Support environment: Protégé.
• Verification: Checking that represented ontology is correct using
• Classifiers/reasoners• Domain experts (semantic accuracy)• Mapping of requirement segments to ontology
concepts
![Page 30: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/30.jpg)
Ontologies – example
……Water-level……
Boiler-tankFeeding-pumpNon-return valveTank
Max-limit
Pump
infers
has
is controlledby
Min. water levelMax. water levelWater-level indicator
OnOff
Control-system
has-state
infers
is coupledwith
![Page 31: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/31.jpg)
Boilerplates
![Page 32: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/32.jpg)
What is a boilerplate – 1
The concept of boilerplates was originally suggested by Hull et al. There is one boilerplate template for each type of requirements, e.g.
• the <system> shall be able to <action> to <entity>
• the <system> shall not allow <user> to <action>.
![Page 33: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/33.jpg)
TDT 4242
What is a boilerplate – 2 Boilerplates is a set of structures that can be used to write
requirements. They use high-level concept classification and attributes
![Page 34: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/34.jpg)
Boilerplate attributes
![Page 35: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/35.jpg)
Main part – 1
![Page 36: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/36.jpg)
Main part – 2
The main thing to be achieved by the requirement, e.g.
• "…<system> shall <action>”• ”…<system> shall allow <entity> to be
<state>”
![Page 37: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/37.jpg)
Prefix – 1
![Page 38: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/38.jpg)
Prefix – 2
Prefixes are used to state:• The condition under which the action part of a
requirement should be executed, e.g. – "While <state>…“– "If <event>…“
• The rational or goal of the requirement, e.g.– “In order to <action>...”
![Page 39: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/39.jpg)
Suffix – 1
![Page 40: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/40.jpg)
Suffix – 2
A suffix is used to describe:• Sequencing – e.g. “...before <event>”• Exceptions – e.g. “...except for <action>”• Timing – e.g. “...within <number> <unit>”• Repetitions – e.g. “...at least <quantity> times
per <unit>”
![Page 41: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/41.jpg)
Using the boilerplates
The RE process is as follows:
1. Select a boilerplate or a sequence of boilerplates. The selection is based on the attributes that need to be included and how they are organized – fixed terms.
2. If needed, identify and include mode boilerplates – prefixes
3. Instantiate all attributes
A boilerplate consists of fixed terms and attributes. It may, or may not, contain one or more modes.
![Page 42: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/42.jpg)
Boilerplates in CESAR The original set of boilerplates had an ad-hoc structure
and several of them were difficult to combine into more complex requirements. The CESAR project has an on-going process where
• Project partners use the current set of boilerplates to write requirements for safety critical systems and report problems back to the boilerplate working group – NTNU, Infineon and TU Vienna
• The boilerplate working group meet when necessary to solve reported problems and issue new boilerplates and update existing ones.
![Page 43: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/43.jpg)
Boilerplate structure
A complete boilerplate requirement consist of a prefix, a main part and a suffix.
An example of a complete boilerplate requirement is shown below. Even though this requirement is in a semi-formal form it is still easy to read.
• If <temperature reaches max temperature>, the <boiler controller> shall <reduce the power to the heating unit> within <2> <seconds>.
![Page 44: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/44.jpg)
Ontologies and boilerplates The full potential of using boilerplates for requirements will only
be realized when we combine them with one more ontologies. We can then:
• Check the completeness of the requirements in relations to a given ontology.
E.g. if we are using the steam-boiler ontology and do not have a requirement for a safety valve, the tool will tell you that the requirements are not complete and, if inquired, will tell you that it expects one or more safety valve requirements.
• Enforce a consistent use of terms, just as for GNL.
E.g. in the steam boiler ontology, the terms tank and vessel will be replaced by the term boiler-tank.
![Page 45: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/45.jpg)
TDT 4242
Boilerplate examples - 1
The <user> shall be able to <capability>
Attributes:• <user> = driver• <capability> = <verb> <entity> = start the ACC system
Requirement
The driver shall be able to start the ACC system
![Page 46: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/46.jpg)
TDT 4242
Boilerplate examples - 2
The <system> shall be able to <action> <entity>
Attributes:• <system> = ACC system• <action> = <verb> = determine• <entity> = the speed of the ego-vehicle
Requirement
The ACC system shall be able to determine the speed of the ego-vehicle
![Page 47: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/47.jpg)
TDT 4242
Boilerplate examples - 3• Prefix: While <state> • Main part: <user> shall be able to <capability>
Attributes • <state> = activated• <user> = driver• <capability> = override engine power control of the ACC system
Requirement
While activated the driver shall be able to override engine power control of the ACC-system
![Page 48: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/48.jpg)
TDT 4242
Non-functional requirement example – 1
Non-functional requirements and soft goals fits into the same BPs as functional requirements
The <system> shall be able to <action> to <entity>
Suitability: The <system > shall be able to <provide an appropriate set of functions> to <the user>
![Page 49: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/49.jpg)
TDT 4242
Non functional requirement example – 2 Non-functional requirements and soft goals
fits into the same BPs as functional requirements
The <system> shall be able to <capability>…for a period of at least <quantity> <unit>
Maturity:The <system > shall be able to <operate without failure> for a sustained period of at least <quantity> <time unit>
![Page 50: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/50.jpg)
Non functional requirement example – 3 • While <state> • The <system> shall be able to <action> <entity>
While <normal state> the <system> shall be able to <tolerate> <90% of software faults of category...>
![Page 51: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/51.jpg)
Summing up
The use of boiler plates and ontologies will• Enforce a uniform use of terms• Reduce the variability of presentations –
requirements that are similar will look similar
Reduced variation in form and contents simplifies the use of automatic and semi-automatic tools for
• Checking requirement quality – e.g. completeness and consistency
• Creating test cases
![Page 52: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/52.jpg)
User stories
![Page 53: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/53.jpg)
Why user stories
User stories is another way to use templates.
• Boilerplates define the terms to use• User stories define the required content
![Page 54: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/54.jpg)
What is a User Story• A concise, written description of a piece of functionality
that will be valuable to a user (or owner) of the software.
• Stories are used as:– Descriptions of user’s needs– Product descriptions– Planning items– Tokens for a conversation– Mechanisms for deferring conversation
![Page 55: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/55.jpg)
User Story Cards have three parts
1. Description - A written description of the user story for planning purposes and as a reminder
2. Conversation - A section for capturing further information about the user story and details of any conversations
3. Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected
![Page 56: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/56.jpg)
User Story Template – 1
- As a [user role] I want to [goal] so I can [reason]
- As a [type of user] I want to [perform some task] so that I can [reach some goal]
Example: • As a registered user I want to log in
so I can access subscriber-only content
![Page 57: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/57.jpg)
User Story Template – 2 • Who (user role)
• What (goal)
• Why (reason)o gives clarity as to why a feature is usefulo can influence how a feature should functiono can give you ideas for other useful features
that support the user's goals
![Page 58: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/58.jpg)
From user story to test caseWe can use templates to write test cases for the
use stories. One tool that employs such templates is CUCUMBER:
• Scenario: a short description of the test scenario
• Given: test preconditions• When: test action – input• Then: test result – output• And: can be used to include more than one
precondition, input or output.
![Page 59: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/59.jpg)
Use stories (US) vs. boilerplates (BP)We can use boilerplates to formulate use stories• US: As a [user role] I want to [goal] so I can
[reason]BP: The [user role] shall [action] in order to achieve [goal]
• US: As a [type of user] I want to [perform some task] so that I can [reach some goal]BP: The system shall be able to [perform some task] in order to achieve [some goal]
![Page 60: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/60.jpg)
Boilerplate examples
![Page 61: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/61.jpg)
Robot rail Position switchRobot arm Robot platform
Light emitter
Light receiver
Gate B Gate A
Area A Area B
Fence
Restart switch
SafeLoc – 1
![Page 62: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/62.jpg)
TDT 4242
SafeLoc – 2 • if <state>, <system> shall <action> within <quantity>
<unit>
if <gate is opened to the zone where the robot is operating>, <robot control> shall <stop> <robot> within <10> <milliseconds>,
• <system> shall not allow <entity> to be <state>, unless <state>
<robot control> shall not allow <robot> to be <started>, unless <all gates are closed> and <reset button is pushed>
![Page 63: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/63.jpg)
SafeLoc – 3
• If <event>, <system> shall <action>
if <robot moves into an occupied zone>, <robot control> shall <stop> <robot>
![Page 64: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/64.jpg)
![Page 65: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/65.jpg)
![Page 66: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/66.jpg)
![Page 67: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/67.jpg)
ACC requirements – 1 • The minimum selectable time gap for steady state vehicle following shall be greater
than or equal 1s for all speeds. At least one time gap tau in the range 1.5s to 2.2s shall be provided
<ACC> shall not allow <driver> to <set> <time gap less than 1s> <ACC> shall be able to <select> <at least one time gap tau> within <1.5 to 2.2>
<seconds>
• The ACC system shall be able to determine the speed of the ego-vehicle
<ACC> shall be able to <determine > <the speed of the ego-vehicle> • An ACC system is not required to respond to stationary targets. If the system is not
designed to respond to stationary targets the driver shall be informed at least by a statement in the vehicle owner’s manual
<ACC > may <response> <to stationary targets>
If <ACC does not respond to stationary targets>, <ACC manual> shall <inform> < driver>
![Page 68: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/68.jpg)
ACC requirements – 2 • The ACC system shall enable steady state vehicle following on (a) straight
roads (class I, II, III and IV) and (b) curves with a radius down to 500m (class II, III and IV), down to 250 m (class III and IV), and down to 125m (class IV)
<ACC> shall be able to <steady state vehicle following> on {<straight roads class I, II, III and IV> and < curves with a radius down to 500m on roads class II, III and IV> and <curves with a radius down to 250 m roads class III and IV> and <curves with a radius down to 125m on roads class IV>}
• An ACC system shall provide means for a driver to select a desired set speed
<driver> shall be able to <select> <desired speed> • The driver shall always have the authority to override the ACC system engine
power control
<driver> shall be able to <override> <ACC engine power control>
![Page 69: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/69.jpg)
Temperaturesensor
Heating element
220V AC
Controller
I/O panel
Heating unit – system overview
![Page 70: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/70.jpg)
Natural language requirements 1. The user shall be able to use a simple panel to define time
intervals, consisting of– Starting time– Ending time– Temperature during this interval – Ta
2. The time intervals are not allowed to overlap3. The user shall be able to use a simple panel to define a
temperature tolerance value d. 4. If the user don't set a temperature tolerance, the system shall
use default value d = 2oC5. If the temperature falls below Ti – d, the heather shall be turned
on6. If the temperature exceeds Ti + d, the heather shall be turned off7. If time is outside all defined intervals the temperature shall be
set to a predefined default value T0.
![Page 71: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/71.jpg)
Boilerplate requirements – 1
1. <user> shall be able to <define> <time interval a = [ts, te]>2. <system> shall not allow <time intervals> to <overlap>3. <user> shall be able to <set> <temperature Ta for time
interval a>4. <user> shall be able to <set> <temperature tolerance d>5. If <temperature tolerance not set>, <system> shall <set>
<temperature tolerance = 2>6. <system> shall have <simple input / output panel>7. <system> shall have <heating unit>8. <system> shall have <default temperature = T0>9. In order to <measure temperature>, <system> shall have
<temperature sensor>
![Page 72: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/72.jpg)
Boilerplate requirements – 2 10. In order to <control temperature>, <heating unit> shall have
<on / off switch> 11. If <temperature sensor reading exceeds T + d>, <system> shall
<switch on heating unit>12. If <temperature sensor reading is below T - d>, <system> shall
<switch off heating unit>13. When <time in [ts, te] for interval a>, <system> shall <set> <T =
Ta>14. <system> shall <sample> <temperature sensor> at least <3>
times per <minute>15. <system> shall not allow <time intervals> to <overlap>16. If <time is outside all time intervals>, <system> shall <set> <T =
T0>
![Page 73: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/73.jpg)
How to communicate requirements
Use cases and beyond
![Page 74: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/74.jpg)
TDT 4242
Finding use cases • Describe the functions that the user
wants from the system
• Describe the operations that create, read, update, and delete information
• Describe how actors are notified of changes to the internal state of the system
• Describe how actors communicate information about events that the system must know about
![Page 75: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/75.jpg)
TDT 4242
Key points for use cases - 1
• Building use cases is an iterative process
• You usually don’t get it right at the first time.
• Developing use cases should be looked at as an iterative process where you work and refine.
• Involve the stakeholders in each iteration
![Page 76: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/76.jpg)
TDT 4242
Reuse opportunity for use cases – 1 There is duplicate behavior in both the buyer and
seller which includes "create an account" and "search listings".
Extract a more general user that has the duplicate behavior and then the actors will "inherit" this behavior from the new user.
![Page 77: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/77.jpg)
TDT 4242
Reuse opportunity for use cases – 2 Relationships between use cases:• Dependency – The behavior of one use
case is affected by another. Being logged into the system is a pre-condition to performing online transactions. Make a Payment depends on Log In
• Include – One use case incorporates the behavior of another at a specific point. Make a Payment includes Validate Funds Availability
![Page 78: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/78.jpg)
TDT 4242
Reuse opportunity for use cases – 3
Relationships between use cases:
• Extends – One use case extends the behavior of another at a specified point, e.g. Make a Recurring Payment and Make a Fixed Payment both extend the Make a Payment use case
• Generalize – One use case inherits the behavior of another; it can be used interchangeably with its “parent” use case, e.g. Check Password and Retinal Scan generalize Validate User
![Page 79: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/79.jpg)
Extend
Respond to emergency
Control centeroperator
communication down
<<extends>>
Request arrives through radio or phone
![Page 80: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/80.jpg)
Generalize
Request (re)scheduling of maintenance
Already scheduled- reschedule
Proposed timenot acceptable
Maintenance worker
Ask for new suggestion
Changes in time consumption or personnel
![Page 81: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/81.jpg)
Adding details
We can add details to a use case diagram by splitting uses cases into three types of objects.
Entity object Control object Boundary object Entity object Control object Boundary object
![Page 82: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/82.jpg)
Adding details – example • Input and output via boundary objects• Validate input and output via control objects• Save via entity objects
Web serverValidate Main page
Database Update Show Result page
Web serverValidate Main page
Database Update Show Result page
Web serverValidate Main page
Database Update Show Result page
![Page 83: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/83.jpg)
From UC to SD – 1
![Page 84: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/84.jpg)
From UC to SD – 2
![Page 85: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/85.jpg)
From UC to SD – 3
![Page 86: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/86.jpg)
Use case diagrams – pros and cons
Simple use case diagrams are• Easy to understand• Easy to draw
Complex use case diagrams – diagrams containing <<include>>> and <<extend>> are difficult to understand for most stakeholders.
Use case diagrams do not show the sequence of actions
![Page 87: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/87.jpg)
TDT 4242
Textual use cases - 1Identify the key components of your use
case. The actual use case is a textual representation
![Page 88: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/88.jpg)
TDT 4242
Textual use cases - 2Examples of alternative flow are:
• While a customer places an order, their credit card failed
• While a customer places an order, their user session times out
• While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer
Alternative flow can also be handled by using <<extend>> and <<include>>
![Page 89: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/89.jpg)
Textual use cases – 3 Most textual use cases fit the following pattern:
Request with data
Respond with result
Validate
Change
Request with data
Respond with result
Validate
Change
![Page 90: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/90.jpg)
Textual use case – example Use case name Review treatment planUse case actor DoctorUser action System action1. Request treatment plan for
patient X2. Check if patient X has this doctor3. Check if there is a treatment plan for
patient X4. Return requested document
5. Doctor reviews treatment plan
Exceptional paths
2.1 This is not this doctor’s patient2.2 Give error messageThis ends the use case3.1 No treatment plan exists for this patientThis ends the use case
![Page 91: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/91.jpg)
Textual use case <<extend>>
Use case name Respond toSystememergency call
Use case actor Operator
User action System action
System OK => Receive system signal
System Down => Use radio
Receive systemmessage
Act on message
Send response
End REC – 1
Use case name Respond to radioemergency call
Use case actor Operator
User action System action
Receive radiomessage
Act on message
Send response
End REC – 2
![Page 92: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/92.jpg)
Textual use case <<include>>Use case name Controller
Use case actor NA
Start timer
Get data
Action necessary?
Yes => Set Actuator
Timer expired ?
No => BIT
Check error status
On => Error handling
End Controller
Use case name BIT
Use case actor NA
Get test pattern A
Write test pattern
Read test pattern
Compare patterns
Difference => Set error status
End BIT
![Page 93: Requirements and boilerplates Tor Stålhane IDI / NTNU](https://reader035.vdocuments.mx/reader035/viewer/2022081511/56649e8e5503460f94b91fbe/html5/thumbnails/93.jpg)
Textual use cases – pros and cons
Complex textual use cases • Are easier to understand than most complex
use case diagrams• Are easy to transform into UML sequence
diagrams• Require more work to develop• Show the sequence of actions