1. Models Modelling can help us to understand the requirements thoroughly
Ambiguous behaviour is revealed by holes in the models
Inconsistencies in requirements are revealed by multiple, conflicting outputs to the same input

2. Requirements Modelling
Consists of:
Decomposition
the process by which a problem is broken down into parts
Abstraction
a description of the problem at some level of generalisation that allows us to concentrate on the key aspects of the problem without getting involved in the difficulties of the details.
Separation of concerns
the process of breaking a program into distinct features that overlap, as little as possible, in functionality

3. Purposes of Decomposition
Requirements specification is decomposed along separate concerns to simplify the resulting model and make it easier to read and to understand
In contrast , decomposition of a design improve the system’s quality attributes (modularity, maintainability, performance, time to delivery, etc.)

4. Unified Modelling Language
UML is a collection of notations used to document software specifications and designs
Represents a standard notation for modelling, documenting, and communicating decisions
Modelling
helps us to understand requirements
reveal inconsistencies in requirements (conflicting outputs to same input)

5. Notations - ERD Entity-Relationship Diagrams
Represents conceptual model and decomposes by entity
Popular for describing database schema
Mostly static, structural view and says nothing about how entities are to behave
Three core constructs, which are combined to specify a problem’s elements and inter-relationships:
Entities (collection of real-world objects)
Attributes (annotation that describes data or properties associated with the entity)
Relations

6. Notations – UML class diagram
ER diagram in which
entities are called actors
Class is a collection of similarly typed entities
Class has a name, set of attributes and operations
Primarily for design notation but is used for conceptual modelling, in which classes represent real-world entities in the problem
e.g. Conceptual model – Customer class which corresponds to CustomerRecord class in program class in implementation

7. Notations – Event Traces
Describes system’s behavioural requirements decomposed by scenario
Not used to provide a complete description of required behaviour as number of scenarios can become unwieldy
Graphical depiction of a sequence of events that are exchanged between real-world entities
Vertical line represents timeline for an entity, whose name appears on top of the line
Horizontal line represents and event or interaction between two entities bounding the line, i.e. a message passed
Time progresses from top to bottom, i.e. an upper event happens before a lower event
Each graph represents a single trace, i.e. only one of the several possible behaviours

8. Notations – State Machines
Used to represent a collection of event traces in a single model decomposed by control state
Used for specifying dynamic behaviour and for describing how behaviour should change in response to the history of events that have already occurred
Graphical depiction of all dialog between the system and its environment
Each node (state) represents a stable set of conditions that exist between event occurrences
Each edge (transition) represents a change in behaviour or condition due to the occurrence of an event
Labelled with a triggering event and possibly an output event generated when transition occurs

9. Notations – UML Statechart Diagrams
Depicts dynamic behaviour of objects in a UML class
Shows how class instances should change state and how their attributes should change value as the objects interact with each other
UML model is a collection of concurrently executing statecharts – one per instantiated object – that communicate with each other via message passing
Each class in a UML class diagram has an associated statechart diagram that specifies the dynamic behaviour of objects of that class

10. Notations – Data-Flow Diagrams
Promotes decomposition by functionality
Models functionality and the flow of data from one function to another
Representations:
Bubble  process or function that transforms data
Arrow  data flow, into bubble represents an input and out of bubble represents an output
Data store is a formal repository or database of information used to store data that persist beyond their use in a single computation
Actors (data sources or sinks) are entities that provide input data or receive the output results

11. Notations – UML Use-case Diagrams
Similar to top-level data-flow diagram that depicts observable, user-instantiated functionality in terms of interactions between the system and its environment.
Components:
Large box represents system boundary
Stick figures outside box portray actors (humans and systems)
Each oval inside box is a use case that represents some major required functionality and its variants
Line between actor and use case indicates that actor participates in the use case

12. Notations – UML Use-case Diagrams
Use cases are not meant to model all the tasks in the system but used to specify user views of essential system behaviour
Model only system functionality that can be initiated by some actor in the environment

13. Formal Methods/Approaches
Mathematically based specification and design techniques
Encouraged by software developers who build safety-critical systems

14. Advantages of Formal Methods
Mathematical models are more precise and less ambiguous than other models
Mathematical models lend themselves to more systematic and sophisticated analysis and verification
Many formal specifications can be checked automatically for consistency, completeness, non-determinism, reachable states, type correctness

15. Functions and Relations
Some formal paradigms model requirements/ software behaviour as a collection of mathematical functions or relations
When function and relations are composed together, they map the system inputs to system outputs
Functions
Specify state of a system’s execution
Specify outputs
Relations
Used instead of a function whenever an input value maps to more than one output value

16. Function
Systematic and straightforward test for consistency and completeness
Because it maps each input to a single output, by definition it is consistent
If it specifies an output for every distinct input, total function, and is by definition complete

17. Logic
Is a descriptive notation, which better expresses global properties and constraints
Descriptive notation describes a problem or proposed solution in terms of its properties or its invariant behaviour
Consists of:
a language for expressing properties
a set of inference rules for deriving new, consequent properties from the stated properties

18. Logic Used to express a property of a software problem/system
This property is an assertion about the problem or system that should be true
As such, a property specification represents only those values of the property’s variables for which the property’s expression evaluates true

19. First-order logic Typed variables Constants Function
Predicates < and >
Equality
Logical connectives  (and),  (or), ¬ (not), (implies), (logical equivalence)
Quantifiers   (there exists) and  (for all)

20. Temporal logic
Introduces additional logic connectives for constraining how variables can change value over time
More precisely over multiple points in an execution
The following (linear-time) connectives constrain future variable values, over a single execution trace:
 f  f is true now and throughout the rest of the execution
f  f is true now or at some future point of the execution
f  f is true in the next point of the execution
f W g  f is true until a point where g is true, but g may never be true

21. Properties may be often used to augment a model-based specification either to:
Impose constraints on model’s allowable behaviour
Property specifies behaviour not expressed in model and the property
Simply express redundant but non-obvious global properties
Property does not alter specified behaviour but may aid in understanding the model by explicating otherwise implicit behaviour
Also aids in requirements verification, by providing expected properties of the model for the reviewer to check

22. Algebraic specifications
Used to specify the behaviour of operations by specifying the interactions between pairs of operations rather than modelling individual operations
Multi-operational view – viewing system in terms of what happens when combinations of operations are performed
Execution trace – a sequence of operations that have been performed since the start of execution

23. Algebraic specification axioms
Specify the effects of applying pair operations on an arbitrary sequence of operations that has already been executed

24. Disadvantage of Algebraic specification
For a collection of operations, it can be tricky to construct a concise set of axioms that is complete and consistent, and correct

25. Prototyping Requirements
One way to elicit details
It solicits feedback from potential users about what aspects they would like to see improved
which features are not so useful, or what functionality is missing
help determine whether customer’s problem has a feasible solution
Assist in exploring options for optimising quality requirements

26. Rapid prototyping
Involves building software to answer questions about requirements
Partial solution that is built to help us understand the requirements or evaluate design alternatives
Different from prototyping, in which prototype is a complete solution
Whose purpose is to test and design product before automating / optimising manufacturing step for mass production

27. Types of Rapid Prototyping
Evolutionary
Developed not only to help us answer questions but also to be incorporated into the final product
As such, more careful development is undertaken, because this software has to eventually exhibit quality requirements (e.g. response rate, modularity) of the final product
These qualities cannot be retrofitted
Throwaway
Developed to learn more about a problem or a proposed solution, and is never intended to be part of delivered software
Allows “quick-and-dirty” software to be built to be written, i.e. poorly constructed, inefficient, with no error checking

28. Validation and Verification
Requirements validation
Checks that our requirements definition accurately reflects all the stakeholder’s needs
Requirements verification
Check that one document or artefact conforms to another
Verifies that:
Code conforms to design
Design conforms to requirements specifications
Requirements specification conforms to requirements definition

29. Requirements Validation
Uses the following characteristics as the criteria for validating requirements:
Correctness
Consistency
Unambiguity
Completeness
Relevance
Testability
Traceability

30. Requirements Validation Techniques
Checklist
Common errors can be recorded in a checklist, which reviewers can use to guide their search for errors
Reading
Reading document and report errors
Walkthrough
One of the document’s authors presents the requirements to the rest of the stakeholders, and asks for feedback
Formal Inspection
Reviewers take on specific roles and follow prescribed rules (when to meet or take breaks, when to schedule follow-up inspection)

31. Requirements Validation Techniques
Review
Representative of developer’s staff and customer’s staff examine the requirements document individually
Then they meet to discuss identified problems
Customer’s representatives may include those who will:
be operating the system
prepare the system’s inputs
use the system’s outputs
manager of these employees who attend
Developer’s representatives include:
design team
test team
process team

32. Requirements Verification
Checking our requirements-specification document correspond to our requirements-definition document
Ensures a system ca be implemented that
meets the specification
satisfies customer’s requirements
Most often, it is a check of traceability

33. Requirements Verification
For critical systems, we may want to demonstrate that the specification fulfils the requirements
prove that the specification realises every function, event, activity and constraint in the requirements
To do this we need to make assumptions about how the environment behaves
Assumptions about what inputs the system will receive
Assumptions about how the environment will react to outputs
We rely on our environment to help us satisfy the customer’s requirements
If our assumptions about how the environment behave is wrong, then our system may not work as the customer expects