Chambers & Associates Pty Ltd A.C.N. 010944019


Modelling Software
Requirements


Workshop Specification


Prepared by : Les Chambers

C&A Ref : 04203

Version : 1.01

Date : 02 July, 2006


Contents

Introduction | Learning Objectives | Audience and Prerequisites | Job Specification | Learning Unit Summary | Unit 1 - Selecting the Model | Unit 2 - Modelling Process | Unit 3 - Modelling Data | Unit 4 - Modelling Time Dependent Behaviour | Unit 5 - Modelling with Objects | Unit 6 - Questions and Critique | Bibliography


Introduction


Abstract

As systems become more complex it becomes increasingly difficult to explain behaviour in an unambiguous manner. ... One of the reasons for this ambiguity is the inherent ambiguity in any natural language. ...

A model simply provides us with a richer , higher level, and more semantically precise set of constructs than the underlying natural language. Using such a model reduces ambiguity, makes it easier to check for incompleteness and may at times improve understandibility.

Alan Davis - "Software Requirements - Analysis & Specification"

The primary function of an analyst in the requirements capture process is to analyse and organise informal requirement statements into a form that can be verified by a user and used as input to design. User requirements specifications must also provide the sole criteria for the validation of the end software product. In achieving these goals an effective analyst must bring to a project the ability to listen to users needs and create a complete, correct, consistent and unambiguous user requirement specification. Analysis models describing functional and time dependent behaviour and data relationships are therefore an essential component of the analyst's tool box. Useful models also act as an aid to understanding complex systems, representing the essence of a system in graphical form and down playing excessive detail.

The objective of this one day workshop is to improve analyst skills in the modelling of user requirements. The latest advances in structured analysis are presented together with an introduction to object oriented analysis techniques. Extensive participant interaction is required with application of modelling techniques to a case study.


Learning Objectives

The ability of a requirements writer to specify a system correctly is primarily a function of the number of techniques that the writer knows how and when to apply. Further, as the computer industry moves toward code generation from formal specifications it is essential that today's analyst is up to date with effective modelling techniques. This workshop provides a highly condensed summary of requirements modelling techniques with an emphasis on recent advances in modelling technology. This section provides an overview of the skills developed while the following sections describe the learning objectives of each learning unit in detail.

On completion of the workshop the participant should be able to:

  1. Apply function, data and time dependent behavioural models to the formulation of ideas in requirements elicitation.
  2. Select the correct modelling technique for a given requirements elicitation scenario.
  3. Use models to verify the completeness and correctness of requirements.
  4. Evaluate the quality of a model in terms of compliance with standard notation and industry recognised "good" practice in modelling technique.
  5. Further develop modelling skills by accessing information from leading writers in the field.

Audience and Prerequisites

This workshop has been designed for professional system analysts responsible for gathering, organising, documenting and presenting user requirements specifications to end-users, subject-matter experts and customers. Participants will have a formal education in and/or extensive experience of software engineering processes and techniques.

All participants are required to read and familiarise themselves with the case study system.


Job Specification


Introduction

This section provides a job specification for the requirements modeller. The specification is presented in terms of the tasks that the incumbent is required to perform and the knowledge and skills required to effectively perform those tasks.

This specification is then used as a basis for identifying:

  1. The learning units required to develop the modeller's skills and
  2. The learning objectives of each unit.

Tasks

The requirements modeller shall be capable of performing the following tasks:

  1. Elicit requirements information from end-users, subject-matter experts and customers.
  2. Analyse and organise requirements information with appropriate modelling techniques.
  3. Integrate requirements models into a user requirements specification.
  4. Evaluate the quality of an instance of a model.
  5. Evaluate the quality of a modelling technique.

Learning Unit Summary


Overview

Learning
Unit
Title Summary
1 Selecting the Model
  • Why use a model?
  • The three dimensions of requirements modelling (process, data and time)
  • Quality attributes of requirements models
  • Choosing the correct model
  • Workshop case study
2 Modelling Process
  • Process decomposition diagram
  • Process dependency diagrams
  • Structured analysis and the Data flow diagram (DFD)
  • Extending DFDs to model time/sequence dependent behaviour
  • Workshop case study
3 Modelling Data
  • Entity-relation (ER) models
  • The data navigation diagram
  • Workshop case study
4 Modelling Time Dependent Behaviour
  • Finite state models
  • Entity lifecycles
  • Workshop case study
5 Modelling with Objects
  • What are object oriented methods?
  • Benefits of object oriented methods
  • Comparison and contrast of popular methods
  • An OO analysis procedure
  • Reusable specifications using patterns
  • Workshop case study
6 Questions & Critique
  • Final questions answered
  • Workshop critiques completed
  • Close

Table 1. Learning Unit Summary.


Schedule

Day 1
9.00 am Unit 1 - Selecting the Model
9.30 am Unit 2 - Modelling Process
10.20 am Coffee
10.40 am Unit 2 - Modelling Process continued
12.00 pm Lunch
12.30 pm Unit 3 - Modelling Data
2.00 pm Unit 4 - Modelling Time Dependent Behaviour
2.40 pm Coffee
3.00 pm Unit 5 - Modelling with Objects
4.50 pm Unit 6 - Questions & Critique
5:00 pm Close

Unit 1 - Selecting the Model

Purpose

This unit deals with the selection of the correct model for the representation of a statement of requirement. The basic assertion is made that no one modelling technique will suit all situations and that modelling is only beneficial when it improves the understanding of a complex behavioural domain. To this end behavioural domains are petitioned into time, function and data and appropriate modelling techniques identified.

As an aid to selection, general quality attributes of effective modelling techniques are also discussed. Attributes covered include reduction in ambiguity, aids to understanding, ease of translation into design, support of requirements traceability and systematic methods for uncovering incompleteness and inconsistency.

Learning Objectives

On completion of this unit the participant should be able to:

1 Select the correct model for the representation of a requirement
2 Evaluate the quality of a modelling technique

Topics

Teaching Points Description
Why use a model? Provide a justification for modelling.
The three dimensions of requirements modelling Present models as tools to analyse complexity in process, data relationships and time dependent behaviour.
Quality attributes of requirements models Identify the general attributes of "good" models.
Choosing the correct model Provide criteria for model selection. For example, domain complexity and understandability by users and developers.
Workshop case study Participants vote on the types of models applicable to the case study

Unit 2 - Modelling Process

Purpose

Since analysis techniques were first introduced in the mid 1970s the process decomposition diagram and Yourdon et al's structured analysis tools have endured as the mainstay of the process modeller's tool box. Further, the usefulness of structured analysis has been validated by its inclusion as a component of most of the popular object oriented analysis methods.

This unit provides a rapid revision of these tools and introduces recent refinements such as process recognition and partitioning with business event analysis. The extension of the data flow diagram to the modelling of time/sequence dependent behaviour is also covered.

Learning Objectives

On completion of this unit the participant should be able to:

3 Preform process decomposition with process decomposition diagrams
4 Apply structured analysis tools to process modelling

Topics

Teaching Points Description
Process decomposition diagram Provide guidelines for development of process decomposition diagrams, describing the various elements and how they are recognised and named.
Process dependency diagrams Describe notation indicating how processes relate to one another in terms of sequence of operation, cardinality and mutual exclusivity.
Structured analysis and the Data flow diagram (DFD) Describe the tools of structured analysis - dataflow diagram (DFD), data dictionary and process specification.

For the DFD :

  • Guidelines for the graphical presentation of external entities, processes, data flows and data stores.
  • Guidelines for building DFDs (e.g. complexity and number of levels).
  • Describe the context diagram
  • Process identification with event partitioning
  • DFD timing assumptions
  • Quality criteria
  • Provide data dictionary notation with examples
Extending DFDs to model time/sequence dependent behaviour Introduce control flow diagrams describing control flows, control stores and control specifications.
Workshop case study Participants model components of the case study with DFDs and process decomposition diagrams

Unit 3 - Modelling Data

Purpose

This unit provides methods and notations for representing business rules and facts implicit in the relationships between business data entities. The entity relationship diagram is presented along with methods for recognising entities and entity subtypes. A transaction description technique employing the data navigation diagram is also discussed.

Learning Objectives

On completion of this unit the participant should be able to:

5 Identify and represent relationships between business entities with entity relationship diagrams
6 Describe transactions with data navigation diagrams

Topics

Teaching Points Description
Entity-relation (ER) models Describe:
  • When to use
  • Identifying entities and attributes
  • Relationships and cardinality (with notation)
  • Components of the entity relationship diagram (ERD)
  • The concept of subtypes
The data navigation diagram Discuss the technique of describing a transaction by annotating the ERD with read/create/update/delete actions
Workshop case study Participants model components of the case study with ERDs

Unit 4 - Modelling Time Dependent Behaviour

Purpose

Previously used only in the realm of real-time control system specifications, models describing time/sequence dependent behaviour have been effectively applied to all manor of commercial data processing systems. The finite state machine and its implementation with the state transition diagram can be applied to describing the behaviour of a washing machine or to precisely document the lifecycle of a business entity.

This topic is also introduced here as an understanding of finite state machines is essential to the synthesis of object models.

Learning Objectives

On completion of this unit the participant should be able to:

7 Represent time/sequence dependent behaviour with state transition diagrams

Topics

Teaching Points Description
Finite state models Discuss:
  • When to use
  • Mealy and Moore variants of the finite state machine
  • The state transition diagram
  • State transition tables
Entity lifecycles Discuss application to the description of the behaviour of an entity whose processing depends on the state of the system.
Workshop case study Participants model state dependent behaviour of entities within the case study with state transition diagrams.

Unit 5 - Modelling with Objects

Purpose

Object oriented methods are not new. They had their genesis in the late 60s with the development of the SIMULA language. They where further developed by researchers at Xerox who developed a language that came to be known as Smalltalk-80. It wasn't until 1988 however that the first significant book on object oriented analysis (OOA) was published by Shlaer and Mellor. Other notable writers in the field are Coad/Yourdon and Rumbaugh.

It is widely agreed that all the current published OOA methods are incomplete in that no one method can be applied to all situations. Practical experience with "industrial strength" implementations in large systems is also limited. Immaturity aside it is evident however that the holy grail of reusable specifications and code and low cost extensibility of production systems will guarantee OO methods a place in the modern analyst's tool box.

It has also become clear that object methods do not have to be used in their entirety to be useful. For example, in the context of a purchasing system, representing a purchase order as an object with a lifecycle and representing its behaviour as a function of its current and previous lifecycle states enhances understanding in both the user and the analyst.

This unit explains the basic concepts of OOA and provides a cook book method for carrying it out focussing on James Rumbaugh's Object Modelling Technique (OMT).

Learning Objectives

On completion of this unit the participant should be able to:

8 Understand the basic concepts of OOA
9 Perform an OOA procedure
10 Evaluate OOA methods

Topics

Teaching Points Description
What are object oriented methods? Discuss the basic terminology and ideas behind object oriented methods. Define:
  • Object
  • Class
  • Encapsulation
  • Messages
  • Inheritance
  • Polymorphism
Benefits of object oriented methods Discuss the impact of OO methods on:
  • Reusable specifications and code
  • System extensibility
  • Improved comprehension by users
  • Maintainability
An OO analysis procedure Discuss the generic object oriented analysis procedure focussing on James Rumbaugh's Object Modelling Technique (OMT). Describe analysis deliverables such as :
  • Inheritance hierarchy
  • Object communications model
  • Composition structure
  • State model
Reusable specifications using patterns Briefly visit the future where analysts and designers seldom specify and design a system from "scratch". Systems are specified from combinations of standard patterns expressed in terms of object classes and class hierarchies that can be purchased in a manual.
Workshop case study Participants model components of the case study with object oriented techniques

Unit 6 - Questions and Critique

Purpose

In this session final questions are answered and workshop critiques are completed.


Bibliography

Davis90

Davis, Alan M., "Software Requirements - Analysis and Specification"

Dorfman90

Dorfman, Merlin & Thayer, Richard H., "Standards, Guidelines, and Examples on System and Software Requirements Engineering", IEEE Computer Society Press.

Gane90

Gane, Chris, "Computer-Aided Software Engineering"

Graham93

Graham, Ian, "Object Oriented Methods", Addison-Wesley 1993

Hatley88

Hatley, Derek J. and Pirbhai, Imtiaz A., "Strategies for Real-Time System Specification", Dorset House 1988

Martin90

Martin, James, "Information Engineering - Planning and Analysis ", Prentice-Hall 1990.

Rumbaugh 91

Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William , "Object-Oriented Modeling and Design", Prentice hall 1991.

Shlaer92

Shlaer, Sally & Mellor, Stephen J., "Object Lifecycles - Modelling the World in States", Yourdon Press 1992.

Thayer90

Thayer, Richard H. & Dorfman, Merlin, "System and Software Requirements Engineering", IEEE Computer Society Press.

Yourdon89-1

Yourdon, Edward, "Modern Structured Analysis", Prentice-Hall 1989.


Copyright 1997 Chambers & Associates Pty Ltd
Module: 2000 mod_reqw.htm
Updated: July 02, 2006