Software Requirements Analysis & Specification Writing
Learn via this 3-day course how to master software requirements, reducing development time by avoiding rework, and increasing stakeholder satisfaction.
Get Started Today
View the schedule and register your interest.
Whether you have a question or are looking to find out more about our training options then please get in touch with us below.
Software 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, software requirements analysis (capture and validation) and software requirements writing, producing a Software Requirements Specification in some form, are treated as separate but related topics in this workshop-oriented course.
The requirements analysis content addresses the techniques used to capture, validate and gain a complete understanding of software requirements communicated at all stages of the software life cycle, regardless of development strategy, for example, Agile, Team Software Process (TSP), Rational Unified Process (RUP), Incremental or Waterfall. The specification writing content addresses in detail the conversion of individual requirements information into effective requirements specifications. This content focuses on the language and structure of requirements specification.
The requirements analysis content provides highly effective tools for both the capture of software requirements, and for validation of those requirements, in any scenario involving the receipt of software 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 widely used with great success.
The requirements writing content provides detailed instructions on the conversion of requirements into highly effective Software Requirements Specifications, in database or document form. Issues of structure (organization of information) and the use of language (English) throughout a requirements specification are examined in considerable detail. Public domain software 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 requirements writing that are taught have been used to great effect in scenarios that include software acquisition, supply, software product definition, business analysis, software development and embedded software in diverse engineering projects, large and small.
- This course may be credited toward the maintenance of the INCOSE Certified Systems Engineering Professional (CSEP) certification for 24 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 (24 hours)
- This course may qualify for CPD, CLP and similar purposes with other organizations (24 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 - 23
- Business Acumen - 1
THIS COURSE IS AVAILABLE FOR CORPORATE TRAINING ONLY.
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
- defining terms
- context dependence
- reference to applicable documents
- use of precedence
- using success criteria to express otherwise vague requirements
- workshop 9 - using success criteria