Key Learning Objectives

At the conclusion of this course, participants are expected to have learned:

• the overall concepts of, and activities within, software requirements analysis;
• the principles of good software requirements in English, from a sentence structure point of view as well as an understanding of many language-specific issues;
• how to effectively structure software requirements specifications, irrespective of language; and
• how to make informed decisions about the use of software requirements specification templates (DIDs).

Training Method and Materials

The course is delivered using a mixture of formal presentation, informal discussion, engagement techniques such as quizzes, and workshop activities. The result is a high degree of learning in a short time.

Each participant receives a Training Manual in hard copy form (physical delivery) or .pdf form (online delivery), a workshop workbook, relevant handouts (physical or digital) and other resources in soft copy format by email. A matched set of data item descriptions (DIDs) and corresponding example documents is provided, as follows:

• Operational concept Description (Concept of Use) template;
• Example Operational Concept Description (Concept of Use) for an enterprise system;
• Enterprise System Requirements Specification template;
• Example Enterprise System Requirements Specification for the same enterprise system;
• System Requirements Specification for a physical technology item;
• Statement of Work template (requirements specification template for a service);
• Example Statement of Work for operator training related to the same technology item;
• Software Requirements Specification template; and
• Interface Requirements Specification template.

Participants also receive free online access to PPI’s Systems Engineering Goldmine (SEG), an archive of presently 4.5GB+ of downloadable systems and software engineering documents, and a searchable database of presently 7,800+ defined terms used in systems engineering and to a lesser degree, software engineering.

Some Key Questions

• Why do requirements errors cost more to correct than any other class of error?
• How can I best deal with software 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 set of requirements?
• How can I efficiently use software requirements analysis to help prepare not only the software requirements specification, but also key development data sets?
• How can I best live with “moving goal posts”?
• How can I cope with the inevitable “missing information” without losing control of technical baselines?
• 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 software requirements specifications?
• How can I best structure my software requirements specification?
• What syntax produces the best software requirements?

Who Should Attend This Course?

This Software Requirements Analysis training is designed for business analysts, requirements analysts, acquirers, suppliers and developer personnel who, in any capacity, deal with software requirements.

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.

1. Software Requirements Analysis

• what are requirements?
• workshop 1 – principles of requirements engineering
• the origin of requirements
• types of software requirements, and how they relate to analysis, specification & design
• software requirements quality attributes
• verification requirements and their relation to software requirements
• software requirements and automated testing
• software requirements and model-based software engineering
• requirements languages other than natural: operational, formal
• software requirements analysis (SRA) – how to do it
• workshop 2 – context analysis
• workshop 3 – design requirements analysis (interactive whiteboard exercise)
• workshop 4 – states and modes analysis
• workshop 5 – parsing analysis
• requirements quality metrics
• workshop 6 – functional analysis
• ERA analysis, rest of scenario analysis, out-of-range analysis, other constraints search, stakeholder value analysis
• the Operational Concept Description (OCD) for software
• managing SRA
• requirements analysis and management software tools
• common pitfalls in performing SRA

2. Transforming Software Requirements into Software Requirements Specifications

• requirements vs requirements specifications
• the eight types of software requirements and their significance to specification writing

3. Requirements Specification Types

• the ten types of requirements specification
• score sheet for public domain software requirements specification standards

4. Structuring Your Software Requirements Specification

• principles of structuring
• dealing with variants
• workshop 7 – writing a Scope section
• dealing with states and modes
• functional versus design oriented requirements specifications
• structuring to specify function and performance
• specifying other software requirements types – environmental, resource, other qualities
• structuring the specification of any design direction in software requirements
• structuring an Interface Requirements Specification

5. Writing Software Requirements in English – Use of Language

• requirement writing template
• workshop 8 – using the parsing template – writing a software requirement of each type
• requirements constructs
• shall, should, will, and may
• syntax in general – the helpful, the problematic, work-arounds
• linking
• cross-referencing
• defining terms
• context dependence
• reference to applicable documents
• use of precedence
• using success criteria to express otherwise vague requirements
• workshop 9 – using success criteria

6. In Closing