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

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

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.)

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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