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
Endorsed by the Australian Computer Society
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 organisations 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.
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 customers 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).
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|
|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|
|Work packages, schedule and budget|
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|
|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|
|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|
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