Software Specifications (2IX20) Summary Q3 2021
Contents
Week 1 – Tuesday: Introduction and Requirements ..................................................................................... 2
Week 1 – Thursday: Use case diagrams and use cases............................................................................... 2
Week 2 – Tuesday: Object and class diagrams ............................................................................................ 4
Week 2 – Thursday: State machine diagrams .............................................................................................. 6
Week 3 – Tuesday: Sequence diagrams ...................................................................................................... 8
Week 3 – Thursday: Activity diagrams ........................................................................................................ 11
Week 4 – Tuesday: LTS and KS................................................................................................................. 13
Week 4 – Thursday: LTL ............................................................................................................................ 15
Week 5 – Tuesday: SPIN ........................................................................................................................... 16
Week 5 – Thursday: State machine diagram semantics ............................................................................. 19
Week 6 – Tuesday: MBT ............................................................................................................................ 21
1
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten
,Week 1 – Tuesday: Introduction and Requirements
This course helps us think about design, software quality, certification requirements and bugs.
We will cover three topics: informal specification, formal specification and model-based testing.
We use the V-model, which on the left hand side creates the requirements with the corresponding code
and on the right hand side verifies them. Validation refers to assessing the quality of one level while
verification refers to the quality between two different levels.
A requirement is a statement expressing a need (capability) and its associated constraints and conditions.
This is written in natural structural language, which is semi-formal. The goal of a requirement specification
is to enable an agreed understanding between stakeholders of the objectives of the system. Requirements
engineering is getting from user needs to the requirement specification/document, which is a collection of
requirements. For each requirement, we give identification, dependencies, source(s), rationale and
priorities (MoSCoW method). Steps:
1. Requirements elicitation: techniques include interview, brainstorm, analyze, prototype, etc.
2. Requirements specification: Steps: 2a) Identify actors and their goals; 2b) Specify inputs, outputs of
the system; 2c) Write requirements. (if using informal text: 2d) go through text to find more requirements).
3. Requirements verification and validation: ensures requirements are consistent, complete and feasible
4. Requirements management: to analyze, document, track, prioritize and keep track of the requirements
Good requirements are unambiguous, consistent/non-contradictory, verifiable, appropriate, necessary,
complete, singular, feasible, correct and conforming.
Semi-formal requirements should conform to ISO29148 and have the following structure:
[Condition1][Subject2][Action3][Object4][Constraint of Action5] (one can leave out the condition)
1: when is the requirement applicable. 2: actor. 3: action or verb of requirement e.g. “shall send”.
4: object of the action. 5: restriction on the action e.g. time limit.
Example: When signal x is received [Condition], the system [Subject] shall set [Action] signal x received bit
[Object] within 2 seconds [Constraint of Action].
To be avoided: - shall be able to; - negative statements; - passive voice; - superlatives (best)
- subjective language (easy); - vague pronouns (its); - ambiguous adverbs and adjectives (minimal);
- open-ended, non-verifiable terms; - comparative phrases; - loopholes (if possible).
Week 1 – Thursday: Use case diagrams and use cases
A use case diagram expresses expectations of customers/stakeholders, is used during entire analysis and
design process and can be used to answer what is being described (system), who interacts with the system
(actors) and what the actors can do (use cases). Use cases are more structured and require less
documents than requirements.
2
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten
, In the following table, one can find the different components of the use case diagram.
Notation Name Description
System Boundaries between the system and the users of the system.
Use Case Unit of functionality of the system. Describes functionality, provides
benefit for 1/ more actors, derived from collected
customer/stakeholder wishes, set of all use cases describes
functionality system shall provide (documents the functionality that a
system offers). Use cases contain: name, short description,
precondition, postcondition, error situations, system state on the
occurrence of an error, actors that communicate with the use case,
trigger, standard process, alternative processes.
Actor Role of the users of the system. Interact with the system by using
use cases or by being used by use cases, represent roles that users
adopt, are not part of the system. User data is usually administered
within system, data is modeled within system as objects and classes.
There are different types of actors: human/non-human,
primary/secondary (main benefit/no direct benefit), active/passive
(initiates execution/provide functionality for execution)
Include A includes B means required use of use case B by use case A. A is
relationship the base use case and B is the included use case (which may be
executed on its own).
Extend B extends A means optional use of use case B by use case A. A is
relationship the base use case and B is the extending use case. Both may also
be executed independently of each other. A decides if B is executed.
Extension points define at which point the behavior is integrated and
is written directly within the use case; multiple extension points can
be specified. Conditions define under which circumstances the
behavior is integrated.
Generali- Inheritance relationship between actors or use cases. (Base) Use
zation case A generalizes (sub) use case B. B inherits behavior of A and
may extend/overwrite it. B inherits all relationships from A. B adopts
basic functionality of A but decides what part of A is executed or
changed. A may be labeled {abstract} (then A cannot be executed
directly and only B is executable).
Association Relationship between use cases and actors. Solid line. An
association is always binary. Multiplicities may be specified
(min..max).
Best practices identifying actors: answer questions like who uses the main use cases? Who needs
support? Who is responsible? What are external devices? Who is interested in results?
Best practices identifying use cases: answer questions like what are the main tasks that an actor must
perform? Does an actor what to query/modify information? Does an actor want to inform about changes in
other systems? Should an actor be informed about unexpected events?
Remember that for this course we follow the UML standard. Thus for the extend and include relation:
Typical errors to avoid: use case diagrams do not model processes/workflows; actors are not part of the
system and thus should be positioned outside the system boundaries; one can use abstract and
generalization to achieve the either relation for actors; many small uses cases that have the same objective
may be grouped to form one use case; the various steps are part of the uses cases and not separate use
cases themselves (no functional decomposition).
3
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten
, Week 2 – Tuesday: Object and class diagrams
Structure is the aggregate of elements of an entity in their relationships to each other. Structural design
focusses on how to meet the requirements (design, not implementation). We require traceability (ensure
that we address all requirements). A structure diagram is a diagram that identifies modules, activities, or
other entities in a system or computer program and shows how larger or more general entities break down
into smaller, more specific entities.
An object diagram is a structure diagram that is a snapshot of objects of system and their relationships
(links) at a specific moment in time. The following table shows different components of the object diagram.
Notation Name Description
Object Instance of a class. Individual of a system.
Link Relationship between objects.
Individuals of a system (objects) often have identical characteristics and behavior: a class is a construction
plan for a set of similar objects of a system. Thus we can go from objects to classes. Attributes are the
structural characteristics of a class (different for each object) and operations are the behavior of a class
(identical for all objects). Then we have the class diagram:
Notation Name Description
Class Description of the structure and behavior of a set of objects.
Attribute syntax:
Visibility: + public, - private, # protected, ~ package. Type: e.g. String
Multiplicity: [min..max].Property: readOnly, (non-)unique, (un)ordered
Different levels of detail: Operation syntax:
Parameter: in (input), out (output), inout (combined). Type: of return.
Instance variable: instance attribute (attributes defined on instance)
Class variable: static class attribute, defined once per class
Class operation: static operation, can be used if no instance of the
corresponding class was created. Class var/op are underlined.
Abstract Class that cannot be instantiated. This can be used in combination
class with generalization. Then it is used to highlight common
or characteristics of subclasses and used to ensure there are no direct
instances of the superclass. Only non-abstract subclasses can be
instantiated. Use keyword {abstract} or italic font.
Association Relationship between classes: navigability unspecified, navigable in
both directions, not navigable in one direction.
Most common is binary association.
Navigability: an object knows its partner objects and can therefore
access their visible attributes and operations (open arrow head).
Non-navigability (indicated by cross). Navigability undefined:
bidirectional navigability assumed.
Can have multiplicity (number of objects that may be associated
with exactly one object of the opposite side) and a role (describes
the way in which an object is involved in an association relationship).
4
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten
