TWO DAY WORKSHOP

Specifying Software Requirements
for Users

The hardest single part of building a software system is deciding precisely what to build.

Fred Brooks, No Silver Bullet

Practical Skills | Who Should Attend | Requirements are Important | What is the Process? | Learning Objectives | Workshop Outline | Presenter Profile | Workshop Booking | HOME


Develop Practical Skills in:
Capturing the essential requirements of computing systems.
Analysing, organising and presenting requirements with up to date modelling techniques.
Writing clear, consistent, correct and complete User Requirements Specifications (URSs) to international standards.
Evaluating the URS using internationally recognised quality criteria.
Controlling the evolution of the requirements specification.
Project managing the requirements capture process.

Requirements capture process

Who Should Attend
End-user representatives tasked with specifying business requirements and acceptance testing software systems.
Information systems managers seeking to train users in requirements specification.
Information systems professionals responsible for documenting end-user requirements.
Designers responsible for developing designs from user requirement specifications.

Computing or non-computing professionals looking to improve their skills and marketability in the age of automation.

ACS 12 PCP

Endorsed by the Australian Computer Society

Highly rated by over 500 attendees since 1993

Participant Reaction
Les's in depth knowledge and experience provided an excellent professionally presented course which is difficult to find in many of today's training houses. I would rate this course as probably one of the best I have attended.
David Tein, CAA

In-house Presentations
C&A presents this workshop to both in-house and public forums. The workshop may be tailored for individual needs or presented in its standard format. For example, C&A trained 60 analysts in the Health Insurance Commission. The programme was also tailored to a 3 day format for BHP IT.

Extensive Notes
Included

All workshop participants receive a 100 page work book providing a User Requirement Specification Standard that can be put to work in real world projects.


Why are Accurate Requirements so Important?

Inaccuracies Cripple Projects

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems . No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Fred Brooks - "No Silver Bullet"

One of the most frequent causes of failure in software projects is a non existent or inadequate statement of what the software is supposed to do. A relatively small amount of effort spent in accurately specifying software requirements has repeatedly generated large returns in developer productivity and customer satisfaction.

Leverage Limited Resources

Improving your organisation’s competence in requirements capture will apply your limited resources at the point of greatest leverage to increase customer satisfaction and development team productivity. Research has shown that although requirements analysis consumes merely 5 percent of software production cost it affords 50 percent of the leverage to influence improved quality and productivity.

Poor Requirements Waste Money

A focus on quality requirements cuts development costs. It takes 100 times more effort to correct errors discovered in the maintenance phase than it does to correct the same errors if they are discovered in the requirements phase of a project.

Relative cost to repair bugs resulting from defective requirements by project phase.

Relative cost to repair bugs by project phase

Build Quality In

Correct requirements build quality into your product from the start. Attempting to test quality into code at the end of a project is expensive and ineffective. The probability that defects originating from defective requirements will be completely rectified decreases as they are allowed to propagate into designs and code.


What is Requirements Specification?

An Emerging Discipline

This workshop addresses this emerging discipline of software requirements specification - the orderly transformation of an end-user problem into a complete specification of the desired external behaviour of the software system to be built. It has been developed for purchasers, users and developers of prespecified software. Participants will be users with responsibility for specifying their business needs or information systems professionals charged with specifying the customer’s requirements.

An Essential Skill

On completion of the workshop the participant should be able to:
Organise ideas on the external behaviour of a software system.
Select and use requirements definition techniques and tools to support the formulation of ideas.
Structure ideas into a complete, correct and unambiguous statement of requirement.
Prepare a User Requirements Specification document in compliance with internationally recognised standards.
Establish the quality of an existing requirements specification in terms of completeness, correctness, consistency, ambiguity, maintainability, designability and testability.
Use the requirements statement in the development of acceptance test plans.
 

A Quality Managed Process

Requirements specification is a key software manufacturing process that directly effects the quality of the end product. It must therefore come under formal quality control. That is, the process must be formally defined with standards and procedures, regularly monitored and progressively improved. Our workshop materials are formatted to provide direct input into your Quality Management System. Standards and procedures provided in the notes are formatted for compliance with Australian (AS-3563) and international standards (ISO 9000-3).


Workshop Outline

1 Gaining commitment | 2 Format of the URS | 3 Introducing the case study | 4 Planning requirements capture | 5 Uncovering requirements | 6 Documenting requirements | 7 Workshop | 8 Questions and critique


1 Gaining commitment
Benefits of user driven requirements capture - Reducing waste and development cycle time, improving productivity and quality
Reinforcement of the benefits with a game

2
Format and content of the URS
The purpose and content of the preliminary User Requirements Specification (pURS)
The purpose of the User Requirements Specification (URS)
Content of the URS
Classes of requirement
Relationship to business objectives and goals
Behavioural and non behavioural requirements
External constraints
Interfaces with other systems
How to evaluate "good" and "bad" requirements

3
Introducing the case study
An introduction to the case study project
Presentation of walkthrough technique
Division of workshop participants into user, specifier and QA groups
Quality evaluation by the QA group
URS document preparation by the analyst group

4
Planning requirements capture
Interactive preparation of the requirements capture project plan
Identification of methods, background knowledge, tools, techniques and work product standards required
Scope definition
Project organisation
Management strategy
Technical strategy
Work packages, schedule and budget
Quality management

5
Uncovering requirements
Conducting effective requirements capture sessions
Deriving requirements from business objectives and goals
Problem solving with partitioning, abstraction & projection
Recording the reasoning behind statements of requirement (rationales)
Using scenario analysis
Using models to organise ideas

6
Documenting requirements
Specifying a functional requirement
Using the Data Flow Diagram
Recognising system functions from business events
Entity-relation models
Flow charts, Structured English, Nassi Shidnerman Charts, State Transition Diagrams, Decision Tables, Decision Trees, Pre/Post Conditions
Selecting relevant non behavioural requirements
Expressing capacity, performance, reliability, availability, maintainability, portability, testability, understandability, efficiency

7
Workshop
Various groups document functions of the system
Group leaders present their URS fragments for review and quality evaluation by the QA group
Elements of the sample URS reviewed by the workshop leader.

8
Questions and critique
Final questions answered
Workshop critiques completed
Close
 

Workshop Presenter Profile

Background. Les Chambers is a practising professional software engineer with extensive experience in the development of real time and commercial data management systems. As a software engineer, project manager and information systems manager with the DOW Chemical Company he developed and installed several "life-critical" process control systems in petrochemical plants in the USA, Hong Kong and Australia. In later years he has consulted on the application of software quality management techniques to the development of large commercial transaction processing systems. As principal of Chambers and Associates he provides software quality, project management and requirements definition services.

Requirements. His most recent achievements in requirements capture have been the specification of complex telecommunications systems for Telecom Australia and project support applications for Rockwell Ship Systems.

Training Skills. As a trainer his international experience in the nuts and bolts of developing reliable software provides a wealth of case studies. In past workshops he has been consistently highly rated on mastery of his subject and his ability to motivate the listener.

Education. Les holds a Bachelor of Electrical Engineering Honours Degree from Queensland University and has completed quality management system assessor training with Standards Australia.


Copyright ã 1997 Chambers & Associates Pty Ltd
Updated: July 02, 2006
HOME