Requirements Engineering (English Second Language)

Learn in depth via this 4-day course how to avoid the single most common cause of project problems and failures. Excludes English language issues.

(153 Reviews)

Get Started Today

View the schedule and register your interest.

Let's Talk

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 three aspects: requirements management, requirements analysis (capture and validation) and specification writing, comprise the content of this in-depth course.

The requirements management content of this language-independent course addresses requirements traceability and change management. The requirements analysis content addresses the techniques used to capture, validate and gain a complete understanding of system requirements originating in all stages of the system life cycle. The specification writing content addresses in detail the conversion of individual requirements into effective requirements specifications. The structure and language of requirements specification are addressed in detail.

A workshop approach is used extensively in the course, 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 on projects worldwide with great success.

The course is strongly activity oriented throughout, beyond the workshops. 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.

  • This course may be credited toward the maintenance of the INCOSE Certified Systems Engineering Professional (CSEP) certification for 32 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 (32 hours)
  • This course may qualify for CPD, CLP and similar purposes with other organizations (32 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 – 30
    • Power Skills – 1
    • Business Acumen – 1

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.


Find out more about corporate training

Key Learning Objectives

At the conclusion of the requirements analysis content, participants will have the knowledge and understanding of overall concepts of, and activities within, requirements analysis (requirements capture and requirements validation), to apply in the workplace, and to develop further through on- the-job learning supported by course resources.

At the conclusion of the specification writing content, participants will have the knowledge and understanding of the principles of writing good requirements in English, including many specific language issues. Participants will also have an understanding of how to effectively structure requirements specifications, irrespective of language, and to use high-quality data item descriptions (DIDs) for different types of requirements specifications. Further on-the-job learning is supported by extensive course resources.

Training Method and Materials

You will be provided with:

  • comprehensive courses notes;
  • two workbooks containing workshop exercises
  • workshop model solutions
  • checklists, forms and charts which you can use immediately in your projects
  • access to PPI’s 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 or other requirements owner can
    express only in vague terms?
  • Do requirements that 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 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 functionally oriented 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 specified requirements?

Who Should Attend This Course?

Requirements Engineering is designed for acquirer, supplier and developer personnel who, in any capacity, deal with requirements.


1. Why Emphasise Requirements

  • issues and terminology
  • lessons from real projects

2. Requirements Within the System Life Cycle

  • the origin of requirements
  • development of system architecture and detail design, related to requirements
  • requirements traceability
  • requirements change control
  • summary of terms relating to requirements
  • baselines and their use
  • workshop – principles of requirements engineering
  • common requirements pitfalls in the system life cycle

3. Types of Requirements

  • definitions
  • why categorise requirements by type?
  • eight basic types
  • differences between requirements for hardware, software, services
  • non-requirements
  • workshop – categorising requirements by type
  • 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 (time-limited)
  • requirements parsing analysis
  • workshop – parsing analysis
  • functional analysis – needs analysis, operational analysis, use cases
  • workshop – functional analysis
  • rest of scenario analysis
  • 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

6. Tool Support to Requirements Analysis 

  • tools supporting requirements analysis
  • tools supporting requirements management
  • examples of available tools
  • common pitfalls in using tools

7. Management of Requirements Analysis 

  • management issues
  • using and managing “TBDs”
  • designing a requirements codification scheme
  • managing resolution of requirements issues
  • defining reviews and reports

8. Requirements Specification Types 

  • types of requirements specification
  • IEEE/ISO specification standards
  • score sheet for public domain specification standards

9. Structuring your Requirements Specification

  • what to put in your system requirements specification, the statement of work (or equivalent) and the conditions of contract
  • optional 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
  • functionally oriented versus design oriented requirements 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
  • placing other requirements types
  • annexes, appendices and applicable documents

10. 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
  • paragraph headings
  • use of supporting data
    • mission profiles/use cases
    • baseline designs
    • benchmarks
  • verification specifications
  • optional workshop – evaluation of example specifications

11. Bibliography

  • additional reference material


Q. What is the difference between the requirements engineering and the requirements analysis & specification writing courses?

The Requirements Engineering (RE) seminar 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. 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 course format.

In the 5-day Systems Engineering course, Specification Writing is put in context in the first two days of the course. 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 course. More general advice on specification writing is then provided on the fifth (last) day of the course, 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 course. 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. Courses are again used extensively, based on a single system, almost always a different system to the system used for the systems engineering course. There are more, and longer, courses in requirements analysis compared with systems engineering course. Overall, RA&SW5D provides greater depth in requirements analysis than does the systems engineering course.

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. 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.

Scroll to Top