Requirements Analysis & Specification Writing
Learn via this 5-day, in-depth workshop how to avoid the single most common cause of project problems and failures - requirements. Become a master!
- 5 Days
- Public delivery (Online)
- Corporate delivery (In-person or online)
- Certificate upon completion
- Professional Development Credits
Get Started Today
View the schedule and register your interest.
Let's Talk
Whether you have a question or are looking to find out more about our training options then please get in touch with us below.
This course addresses the most common cause of project problems and failures – requirements. Developing the wrong thing is a bigger problem in engineering than making errors developing the right thing! 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.
The Requirements Analysis module addresses high ROI techniques used to capture, validate and gain a complete understanding of requirements communicated at all stages of the system life cycle. The module is rich in integrated, efficient model-based techniques. The Specification Writing module addresses in detail the conversion of individual requirements into effective requirements specifications. The module focuses on the structure and language of requirements specifications for requirements expressed in natural language.
The 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 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, with examples, are provided for the specification of systems, software, interfaces and services, respectively. 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 diverse engineering projects, large and small. The course is applicable in both procurement and engineering development scenarios, and business models of entrepreneurial product development, development for internal customers and customer-contractor.
- This course may be credited toward the maintenance of the INCOSE Certified Systems Engineering Professional (CSEP) certification for 40 Professional Development Units and PDUs may be claimed for PMI’s family of certifications, including PMP
- This course qualifies for Engineers Australia and Engineering New Zealand (IPENZ) CPD purposes (40 hours)
- This course may qualify for CPD, CLP and similar purposes with other organizations (40 instructor hours)
- This course may be credited toward the maintenance of the Project Management Institute (PMI) certifications. Suggested PMI Talent Triangle® PDU allocation:
- Ways of Working – 37
- Power Skills – 1
- Business Acumen – 2
Let’s Talk
Whether you have a question or are looking to find out more about our training options then please get in touch with us below.
Upcoming Courses
Register and pay 30 days prior to the course commencement date to receive a 10% early bird discount. Or register a group of 3+ for a 10% group discount. Available for corporate training worldwide.
(Exclusive to South Africa)
(Exclusive to South America)
(Exclusive to South Africa)
(Exclusive to South America)
(Exclusive to South Africa)
Upcoming Courses
Register and pay 30 days prior to the course commencement date to receive a 10% early bird discount. Or register a group of 3+ for a 10% group discount. Available for corporate training worldwide.
(Exclusive to South Africa)
(Exclusive to South America)
(Exclusive to South Africa)
(Exclusive to South America)
(Exclusive to South Africa)
Key Learning Objectives
At the conclusion of this course, participants are expected to have learned:
- why requirements’ defects remain the single biggest cause of project problems and failures;
- why these problems are largely avoidable, and how to avoid them;
- how to determine whether requirements you receive are already good enough – measuring requirements quality;
- why requirements elicitation alone is hopelessly inadequate;
- the 14 qualities of requirements that make requirements good requirements;
- how to achieve these qualities – a very high ROI, very efficient methodology for capturing missing requirements, validating and fixing (where necessary) all requirements;
- how to write individually excellent requirements using PPI’s Parsing Template;
- the eight criteria for structuring requirements into requirements specifications; and
- how to meet these criteria, producing great requirements specifications.
Training Method and Materials
The course is delivered using a mixture of formal presentation, informal discussion, and extensive workshop activities. The workshop sessions are used extensively to reinforce learning and to contribute to the development of understanding.
You will be provided with:
- comprehensive course notes;
- two workbooks containing workshop exercises;
- workshop model solutions;
- checklists, forms and charts which you can put to use immediately; and
- complimentary access to PPI’s evolving Systems Engineering Goldmine.
Some Key Questions
- 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 I best unscramble a poor Request for Tender or requirements specification?
- How can I 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?
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.
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 – principles of requirements engineering
- common requirements pitfalls in the system life cycle
3. Types of Requirements
- definitions and views
- relationship to design
- relationship to baselines
- why categorize requirements by type?
- eight basic types
- differences between requirements for physical systems/hardware, software, services
- non-requirements
- workshop – types of requirements
- other categories – architectural design drivers, critical, global, priority, importance, stability
4. The Quality of Requirements
- correctness
- completeness
- consistency
- clarity
- non-ambiguity
- traceability
- testability
- singularity
- feasibility
- balance
- freedom from product/process mix
5. 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 in requirements 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
6. 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
7. Tool Support to Requirements Analysis
- tools supporting requirements analysis
- tools supporting requirements management
- examples of available tools
- common pitfalls in using tools
8. Verification of Requirements Analysis Work Products
- requirements reviews
- keyword search techniques
- use of metrics
9. Management of Requirements Analysis
- management issues
- using and managing “TBDs”
- designing a requirements codification scheme
- managing resolution of requirements issues
- defining reviews and reports
10. Preparing for Transformation of 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
11. Requirements Flowdown into System Element Requirements Specifications
- the specification tree
- special considerations for interface requirements
12. Requirements Specification Types
- types of requirements specification
- Institution of Electrical and Electronic Engineers (IEEE) specification standards
- United States (US) Military and other international specification standards
- score sheet for public domain specification standards
13. 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
- differences
- 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
14. Requirements Specification Writing
- review of requirements quality
- requirement structural template
- workshop – writing requirements using the parsing template
- requirements constructs
- shall, should, will, and may
- linking
- cross-referencing
- workshop – using precedence
- defining terms
- workshop – defining terms
- context dependence
- reference to applicable documents
- use of precedence
- workshop – linking and cross-referencing
- using success criteria to express otherwise vague requirements
- workshop – using success criteria
- workshop – a requirement specification in a sentence
- paragraph headings
- use of supporting data
- mission profiles/use cases
- baseline designs
- benchmarks
- linking the specification to the statement of work or conditions of contract
- verification specifications
- optional workshop – evaluation of example specifications
15. In Closing
- additional reference material
Q. What is the difference between the Software Requirements Analysis & Specification Writing and Requirements Analysis & Specification Writing course?
RASW5D is a 5-day course of broader scope than SRASW that is based mainly on physical system examples and a workshop system that is a physical system. The scope of a requirements analysis for a physical system is slightly higher than that for a software system. The range of specification writing issues is much greater for a physical system than for software. The RASW5D course also includes greater coverage of some requirements engineering issues. The RASW5D course learning can, of course, be applied to software.
The SRASW3D course is of 3 days and is confined in its coverage only to software. The workshop software is a small cellphone app. The techniques taught in this course have direct equivalence to those taught in the longer RASW5D course.
Q. 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.
Q. 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.
Q. 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.
Q. 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 participants 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, participants, 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.
Q. 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.
Q. 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.
Q. Do you offer tailoring of this course?
Yes. All courses are tailored informally verbally in delivery by selecting, where possible, examples matched to the domains of interest to the class. We can also work with you to design a formally customized curriculum for the development of your people. We have done so for many client companies, and we would love to work with you to this end. We always suggest that a client takes the corresponding standard course prior to any customization. For systems engineering, this is because systems engineering is the problem-independent and solution technology-independent principles and supporting methods for the engineering of systems, based on systems thinking. So the objectives of customization need to be very clear and focused on adding further value. In practice, customization, if performed, usually becomes the replacement of examples and possibly the main workshop system with domain-specific equivalents. Substitution of the workshop system usually involves substantial redevelopment of courseware. Out of necessity, formal tailoring of courseware is performed on a fee basis.
Featured Course Reviews
The live-online approach was highly effective. The real-time interaction, combined with Robert’s expertise, made complex topics accessible. The structured sessions and interactive workshops reinforced learning, and the flexibility of joining from any location was a major benefit. Overall, it successfully mirrored the benefits of in-person training with the added convenience of online access.
Albert Selmikat, Brazil
SIATT Engenharia Industria e Comercio SA
A long time ago I participated in your 5-days seminar on Requirements Management, you held in Israel. This was one of the most helpful and fruitful trainings I have ever had! I am still referring quite often to the lecture material and my notes.
Participant, Israel
HP Indigo
I finally know what I am doing and have been doing for the last 5 years. The course will increase productivity, efficiency and effectiveness.
Participant, United Kingdom
QinetiQ
I would like to say thank you for a really informative week. I cannot get over the amount of detail you provided, both during the week as well as for all the relevant files made available via email afterwards. I am sure there will ‘gems’ of information throughout the extra files.
Participant, United Kingdom
Mass Consultants Ltd
The instructor was very knowledgeable and brought with him lots of wonderful examples of how specification and requirements writing is being used in the workforce.
Participant, USA
JT3 LLC
I loved the wide coverage of the subject matter, in particular the use of real life examples which helped me relate to problems at work. This course should be mandatory for all engineers and related professionals.
Participant, USA
JDS Uniphase Corporation
I enjoyed having the analysis create a clear path to a clean, accurate finished product.
Participant, USA
Boeing Company
The presenter brought life to what could otherwise be a dry subject. I thoroughly enjoyed the real life examples. What an interesting and knowleagable speaker.
Participant, USA
James Hardie Building Products
Deep, deep content!!! Requirements parsing!!!!! Each company handles, packages requirements/specifications differently - but it was great to get academic best practices - to know all that is to either be considered or streamlined.
Participant, USA
Blackboard Inc.
Robert, your training was and still is the most useful training I have ever done.
Participant, USA
Medtronic
More Courses For You
Introduction to Requirements Analysis
Effectively capture requirements
Preparing Great Requirements Specifications
Learn structure & language
Requirements Analysis
Effectively capture requirements
Requirements Analysis & Specification Writing
Avoid developing the wrong thing
Requirements Analysis and Specification Writing Fundamentals
Capture, validate & specify
Requirements Engineering (English Second Language)
Avoid requirements problems
Requirements, OCD & CONOPS in Military Capability Development
Develop capability successfully
Specification Writing
Prepare great specifications
