& Specification Writing
A course presented over five days
presented by Mr. Robert J. Halligan FIE Aust CPEng, Mr. Michael Gainford MAEng FRAeS MSc ESEP CEng MINCOSE, Mr Alwyn Smit Pr Eng CSEP or Mr Clive Tudge CEng MIET
Requirements Analysis and Specification Writing are sciences practiced by many, mastered by surprisingly few. And yet, the payoff from achieving excellence in these areas is large. The two aspects, Requirements Analysis and Specification Writing, are treated as separate but related topics, each in a course of three and two days duration.
The three-day Requirements Analysis course addresses the techniques used to capture, validate and gain a complete understanding of requirements communicated at all stages of the system life cycle. The two-day Specification Writing course addresses in detail the conversion of individual requirements into effective requirements specifications. The course focuses on the structure and language of requirements specification.
The two courses are complementary, with little overlap. They may therefore be taken together, or taken individually. The two courses comprise Project Performance International's popular 5-day public course in Requirements Analysis and Specification Writing. The course is delivered worldwide.
Who Should Attend This Course?
Requirements Analysis and Specification Writing is designed for acquirer, supplier and developer personnel who, in any capacity, deal with requirements.
Training Method and Materials
For each course attended, you will be provided with:
- comprehensive course notes
- a workbook containing workshop exercises
- workshop model solutions
- checklists, forms and charts which you can use immediately in your projects
- a CD-Rom with extensive documents and resources
- access to PPI's Systems Engineering Goldmine.
The three-day Requirements Analysis module provides highly effective tools for both the capture of requirements, and for validation of those requirements, in any scenario involving the receipt of requirements from one or more stakeholders who have a need. A workshop approach is used extensively in this module, to maximize learning and practical application. Effectiveness of the techniques, collectively comprising a complete methodology, is independent of the domain of application, and independent of the specifics of the need. These techniques have been used with great success.
The two day Specification Writing module provides detailed instructions on the conversion of requirements into highly effective requirements specifications. Issues of structure (organization of information) and the use of (English) language throughout a requirements specification are examined in considerable detail. Public domain specification standards are overviewed and compared. High quality templates/guides are provided for the specification of systems, software, interfaces and services, respectively, with examples. The course is strongly activity oriented throughout. The techniques of specification writing that are taught have been used to great effect in scenarios that include acquisition, supply, product definition (both hardware and software), enterprise internal projects, business analysis and engineering projects of diverse types, large and small.
At the conclusion of the requirements analysis module, delegates will have the knowledge and understanding of overall concepts of, and activities within, requirements analysis, to serve as requirements analysis team members, and to develop real experience in the field through on-the-job experience supported by course resources. At the conclusion of the specification writing module, delegates will have the knowledge and understanding of the principles of writing good requirements in English, including many specific language issues. Delegates will also have an understanding of how to effectively structure requirements specifications. On-the-job experience and ongoing learning will be supported by extensive course resources.
- Why do requirements errors cost more to correct than any other class of error?
- How can I best deal with requirements which the user can express only in vague terms?
- Do requirements which are not "in the contract" have any effect in a contractual scenario?
- How can you best unscramble a poor Request for Tender or requirements specification?
- How can you efficiently use requirements analysis to help prepare not only the system specification, but also the major plans?
- How can I best live with "moving goal posts"?
- How can I cope with the inevitable "missing information" without losing control of technical baselines?
- What are the differences between functional and design specifications and when should each be used?
- Why is it necessary to deal with states and modes early?
- Why is the use of a requirements structural model the sure-fire path to producing strong requirements specifications?
- How can I best structure my requirements specification?
- What syntax produces the best requirements specifications?
Requirements Analysis Course Outline - Days 1 to 3
1. Why Emphasize Requirements?
- issues and terminology
- lessons from real projects
2. Requirements within the System Life Cycle
- the origin of requirements
- concept of the system boundary
- the modeling boundary
- the systems engineering process
- development of system architecture and detail design, related to requirements
- requirements traceability
- summary of terms relating to requirements
- baselines and their use
- the waterfall life cycle paradigm
- incremental acquisition/development
- evolutionary acquisition/development
- workshop - requirements engineering principles
- common requirements pitfalls in the system life cycle
3. What are Requirements?
- definitions and views
- relationship to design
- relationship to baselines
4. Types of Requirements
- why categorize requirements by type?
- eight basic types
- workshop - categorizing requirements by type
- other categories - architectural design drivers, critical, global, priority, importance, stability
5. The Quality of Requirements
- freedom from product/process mix
6. Requirements Analysis Methodology
- contexts within which requirements analysis is performed
- stakeholder identification
- initial assessment by document (if any) review, and planning
- measuring requirements quality
- context flow analysis
- context analysis
- workshop - context analysis
- design requirements analysis
- interactive exercise - design requirements analysis
- states & modes analysis
- workshop - states and modes analysis
- requirements parsing analysis
- workshop - parsing analysis
- functional analysis - needs analysis, operational analysis, use cases
- workshop - functional analysis
- rest of scenario analysis
- optional workshop - rest of scenario analysis
- out-of-range analysis
- optional workshop - out of range analysis
- Entity-Relationship-Attribute (ERA) analysis
- other constraints search
- stakeholder value analysis
- methods of engaging in requirements dialog
- verification requirements development
- operational concept description
- clean-up - keyword-based searching for residual requirements defects
- special issues of the human interface
- supplementary methods and notations
- common pitfalls in requirements analysis
7. Coping with the Real World
- what to do when the user "doesn't know"
- how to respond to "moving goalposts"
- protecting yourself from the communication chasm
8. Tool Support to Requirements Analysis
- tools supporting requirements analysis
- tools supporting requirements management
- examples of available tools
- common pitfalls in using tools
9. Requirements Verification
- requirements reviews
- keyword search techniques
- use of metrics
10. Management of Requirements Analysis
- management issues
- using and managing "TBD's"
- designing a requirements codification scheme
- managing resolution of requirements issues
- defining reviews and reports
Specification Writing Course Outline - Days 4 to 5
1. Transforming Requirements into Requirements Specifications
- what is a requirements specification?
- how requirements specifications relate to requirements
- how requirements specifications relate to configuration baselines
- preparing for the transition from requirements to requirements specification
- using a requirements database to automate requirements specification production
2. Requirements Flowdown into Requirements Specifications
- the specification tree
- special considerations for interface requirements
3. Requirements Specification Types
- types of requirements specification
- IEEE specification standards
- US Military and other international specification standards
- score sheet for public domain specification standards
4. Structuring Your Requirements Specification
- what to put in your system requirements specification, the statement of work (or equivalent) and the conditions of contract
- workshop - allocating requirements to solicitation documents
- structuring a statement of work
- structuring a system requirements specification
- dealing with variants
- workshop - writing a scope section to deal with variants
- states and modes
- workshop - structuring a specification to deal with states, modes and functions
- functional versus design oriented specifications
- when to use each type
- function and performance
- workshop - classifying specified requirements as functional or design
- workshop - writing a functionally oriented requirements specification
- workshop - writing a design oriented requirements specification
- other requirements types
- annexes, appendices and applicable documents
5. Requirements Specification Writing
- review of requirements quality
- requirement structural template
- workshop - writing requirements using the parsing template
- requirements constructs
- shall, should, will, and may
- workshop - linking and cross-referencing
- defining terms
- workshop - defining terms
- context dependence
- reference to applicable documents
- use of precedence
- workshop - using precedence
- using success criteria to express otherwise vague requirements
- workshop - using success criteria
- workshop - key specification for a system
- paragraph headings
- use of supporting data
- mission profiles/use cases
- baseline designs
- linking the specification to the statement of work or conditions of contract
- verification specifications
- optional workshop - evaluation of example specifications
- additional reference material
About the Presenters
Mr. Robert Halligan FIE Aust CPEng
An executive professional manager and engineering practitioner, Mr Robert Halligan is known worldwide for his role in the practice and improvement of major projects. His work was initially with government and major transnational companies. For the last 24 years, he has worked in a consulting and training capacity, delivering an extensive training program on six continents.
Robert worked extensively in the United States and the United Kingdom. He was an Australian delegate to the ISO SC7 WG7 developing the international system life cycle processes standard, ISO/IEC 15288 and was a key reviewer of EIA 632 (Engineering of Systems) and EIA 731 (Systems Engineering Capability Model). He was a member of a small team which updated IEEE 1220 (Standard for Application and Management of the Systems Engineering Process). Robert was a member of the Board of Directors of the 7000-member International Council on Systems Engineering (INCOSE).
He has worked extensively in the interests of government and industry clients, developing and implementing acquisition and development strategies which focus on cost-effectiveness and risk reduction. Robert has also conducted numerous acquisition-related studies and management audits. He has delivered IPT training and facilitation for over ten years, including very large projects such as Australia’s P3C Upgrade program and ANZAC Ships program.
Mr. Alwyn Smit B.Eng
Mr Alwyn Smit is a Principal Consultant with Project Performance International (PPI). Alwyn has a B.Eng. (Electr) degree from the University of Stellenbosch, South Africa, and is registered with the Engineering Council of South Africa (ECSA) as a professional engineer. He spent the bulk of his career working in the South African defence industry as systems engineer and project manager on technology-intensive projects, most recently as principal systems engineer with the Council for Scientific and Industrial Research (CSIR).
As a lead systems engineer, Mr Smit has contributed extensively to the development of complex technology demonstrators as well as the low volume production of weapon systems in the areas of anti-aircraft systems, radar systems, electronic warfare systems and specialised equipment for special forces application.
Mr. Michael Gainford MAEng FRAeS MSc ESEP CEng MINCOSE
Michael Gainford is a Principal Consultant with Project Performance International, contributing in both the training and consulting roles to the success of PPI's clients. Michael comes to PPI with decades of experience in systems engineering, product and process development, programme management, and business change management, applied in complex international projects, including safety-critical situations. During his career Michael has worked across all the major life cycle phases, for example research & technology, concept definition, product development, legacy product replacement and in-service support.
Michael is an active member of INCOSE (the International Council on Systems Engineering), and has achieved the status of ESEP (Expert Systems Engineering Practitioner). He is also a past employer representative to the INCOSE UK Advisory Board.
For further information on how to register, or to download a copy of the registration form, please click here.
Requirements Analysis & Specification Writing Course Schedule (Scroll to view full schedule)
How to Register
There are three simple ways to register to one of our courses.
- Online. You may register online by clicking the "register online" link next to the course of interest.
- Fax. Download a registration form by clicking the link above the schedule and fax the completed form to our offices on +61 3 9876 2664 (Australia), +1 888 772 5191 (North America) and +55 12 3212 5582 (Brazil).
- Email. Download a registration form by clicking the link next to the course of interest and email the form here.
Upon receiving a completed registration form, a course confirmation letter and invoice will be sent electronically to the email provided within 1-2 business days. Payment can made by credit card or by bank transfer.
If you need any assistance with the registration process or have any queries, please call one of our friendly team members on Australia +61 3 9876 7345, UK +44 20 3608 6754, North America +1 888 772 5174, Brazil +55 11 3958 8064 or email us.
What is the difference between the Requirements Engineering and the Requirements Analysis & Specification Writing training?
The Requirements Engineering (RE) course is primarily designed for people whose first language is not English. As such, it is not offered in most countries where English is the native language.
Which model and method will we use for analysis?
The model and method used in the course (and in real life) is illustrated and explained in the three files attached below.
What skills can be gained by attending this course
The skills you will develop are the skills to effectively transform a starting point of one or more stakeholders having a problem (documented or not) into a statement of that problem suitable for driving development of an optimum solution. The problem may be of a business need or opportunity, or of any other nature whatsoever.
What is the degree of overlap between PPI's five-day Systems Engineering course and PPI's five-day Requirements Analysis & Specification Writing course?
In that both Requirements Analysis and Specification Writing are critically important sub-disciplines within Systems Engineering, these disciplines are covered in both courses.
In the 5-day Systems Engineering course, Requirements Analysis is put in context in the first two days of the course. Then, 1.7 days is devoted to "how to do requirements analysis - capture and validation of the information content of requirements". This depth of coverage is sufficient for delegates to go away with new insights, and importantly, new skills, in performing Requirements Analysis. Courses are used extensively, based on a single system that is taken through Requirements Analysis then subsequently Design, in workshop format.
In the 5-day Systems Engineering course, Specification Writing is put in context in the first two days of the training. Specification writing is then touched upon incidentally in Requirements Analysis, especially in parsing analysis, and in the "clean-up" activity, a related handout for which lists problematic English: parts of words, words and phrases, and the checks that are done regarding adequacy of language in relation to use of these words (etc.).
In the 5-day Systems Engineering course, a revised requirements specification for the course system is distributed to, and inspected by, delegates, on the fourth day of the training. More general advice on specification writing is then provided on the fifth (last) day of the training, over 10-15 minutes.
In the 5-day Requirements Analysis and Specification Writing course, Requirements Analysis and Specification Writing are put in context in the first 0.8 days of the course. Focus is then given to the types of requirements and their significance to the roles of requirements analyst, specification writer, and designer. This session culminates in a workshop exercise. Then, 2-2.5 days are devoted to "how to do Requirements Analysis - capture and validation of the information content of requirements". This is a significantly greater depth of coverage compared with the Systems Engineering course. Course exercises are again used extensively, based on a single system, almost always a different system to the system used for the Systems Engineering training. There are more, and longer, course exercises in Requirements Analysis compared with Systems Engineering training. Overall, RA&SW5D provides greater depth in Requirements Analysis than does the Systems Engineering.
The feedback from people who have participated in both courses has been mostly that they have appreciated the revision and extra depth in Requirements Analysis. However, about 10% of people have regarded the overlap as excessive for their purposes.
In the 5-day Requirements Analysis and Specification Writing course, hugely more coverage is given to the structuring of system and software requirements specifications, and specifications of services. Similarly, almost a day is devoted to advice on the use of language (English) in expressing requirements - pitfalls and pointers. There is also substantial coverage of writing non-requirements sections of requirements specifications - scope, applicable documents, definitions (etc.), notes.
Can the Requirements Analysis & Specification Writing training be shortened for on-site delivery?
Yes it can. This is a course that can be shortened to 2-3 days and still deliver significant learning. If the training is to be shortened, we recommend Requirements Analysis two days and Specification Writing one day, for still a high level of learning, or a combined Requirements Analysis & Specification Writing 2-Day course at about 1.3 days Requirements Analysis and 0.7 days Specification Writing. Learning will be close to linearly proportional to course duration.
Another option is to split the longer course into RA-3 day and SW-2 day delivered in separate weeks.
I am an industrial engineer currently working as a business analyst. Will this training be relevant to my line of work (in the IT field), or is it more aimed at the technical design of physical products?
In its use of formal examples, the training is oriented towards physical systems of a wide variety of kinds. There are IT examples and pure software examples, however, the overall orientation of the examples is not strongly IT. The training is not oriented towards technical design at all; the training is concerned entirely with requirements capture, validation and specification, to drive acquisition or development and/or verification, as applicable, irrespective of application or technology.
Many Business Analysts (BA's) have participated in the training which has been delivered on-site to groups who have been made up of primarily BA's, such as EDS, Ericsson, CSC, LexisNexis, Sperry Univac, Nokia Siemens Networks (Poland), Alcatel-Lucent (Belgium), CISCEA (Brasil), NATS (UK), etc.
We believe that the course will be of substantial benefit to any BA's. There is much content that aligns in context and purpose with the Business Analysis Body of Knowledge® (BABOK®) Guide. This tends towards greater rigor, and some of the methods are more robust than those commonly used by BA's, but are equally applicable to BA's. So the training provides to the BA professional an opportunity for professional growth.
In summary, the BA should get a lot out of the course training as has been the history of participation of the BA's so far.
Select your region
Find out when PPI's Requirements Analysis & Specification Writing course is being presented in your region:
Closely Related Courses
- Requirements Specifications, Preparing Great (1-day)
- Requirements Analysis (3-day)
- Requirements Analysis & Specification Writing (5-day)
- Requirements Analysis, Intro to (1-day)
- Requirements Engineering - English Second Language (4-day)
- Specification Writing (2-day)
- Engineering and Scientific Presentations (2-day)
Closely Related On Site Courses
- Requirements Analysis - The Business Case For (2 hours)
"The instruction was excellent, the course materials were of a very high standard"
All courses are available on-site
Benefits of on-site training for your organisation include:
- tailored in delivery to your industry
- savings of up to 50%
- encourages teamwork
- formal tailoring possible
Quote of the Day
Always do what is right. This will surprise some people and astonish the rest. ~ Mark Twain
Systems Engineering NEWSLETTER
SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.