Price: $1,699.00

Course Number: 903
Length: 2 Days
Print Friendly, PDF & Email

Requirements Writing Training

Requirements writing requires a special skill set with a clear idea of the paradigm and objectives involved. For instance, a good requirement states something that is necessary, verifiable, and attainable. To be verifiable, the requirement must state something that can be verified by examination, analysis, test or demonstration. Statements that are subjective, or that contain subjective words, such as “easy,” are not verifiable.

One of the most important decisions in requirement writing is first being sure a requirement is even necessary. Some experts on the topic recommend asking yourself what is the worst thing that can happen without a particular requirement. If the answer is “nothing much,” then a requirement probably isn’t needed.

When a specific requirement is needed, it must also be attainable. To be attainable, the requirement must be technically feasible and fit within budget, schedule and other constraints. If you are uncertain about whether a requirement is technically feasible, a study may be required to determine its feasibility.

If what you want is not technically feasible or not within budget restraints, it’s no longer a requirement but rather a goal.

In requirements writing (as in good writing in general), authors should strive for clarity. Each requirement should express a single thought, be concise and simple. It is important that the requirement not be misunderstood — it must be unambiguous. Simple sentences will most often suffice for a good requirement.

Requirements Writing Training Course

The Tonex Requirements Writing Training Course addresses the techniques used to write, validate and verify requirements and convert them to technical design specifications. It gives attendees the basic tools necessary to write effective system design specifications. Requirements are the foundation for building systems and software. They determine WHAT the system must do and drive the system development. Requirements are used to determine if the project team built the system correctly. The requirements development process identifies the activities needed to produce a set of complete and verifiable requirements.

Participants learn how to:

  • Write well-formed, validated requirements and specifications.
  • Analyze, Verify and Validate requirements into a user requirements document.
  • Create Project Plan/SEMP with various plans, such as the review plans, configuration management plans and risk plans.
  • Establish Configuration management (CM) the process to control changes to the requirements and manage the baseline documentation.
  • Plan the Risk management to monitor, control and mitigate high risk requirements.
  • Manage Technical reviews to identify defects, conflicts, missing or unnecessary requirements.
  • Manage Stakeholder involvement which is  essential for validating the requirements. Are these the correct requirements?
  • Establish Elicitation techniques to enable the discovery and understanding of the needed requirements.
  • Manage Traceability of requirements to user needs and requirements, support documentation and constraining policies (e.g., safety requirements).

The systems engineering standard (EIA 632) defines “requirement” as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” This course gives PEs 13 PDH (Professional Development Hours) approved by PIE.

Learning Objectives:

Upon successful completion of the course, attendees will:

  • Describe the way the system is intended to operate from the user’s perspective
  • Describe Concept of Operations (ConOps) process where user needs, expectations, goals and objectives are described
  • Understand how feasibility Study can produce the conceptual high-level design and requirements which can be used as a starting point for the project
  • Demonstrate the ability to capture and validate requirements throughout the requirements analysis process
  • Learn how to conduct technical reviews, manage stakeholder involvement and elicit requirements
  • Understand traceability of requirements to user needs
  • Understand the relationships among all stages of the system life cycle.
  • Describe different levels of requirements
  • Learn how to develop requirements, write and document requirements, check completeness of requirements, analyze, refine and decompose requirements, validate requirements and manage requirements
  • Describe communications techniques to elicit requirements
  • Classify requirements as functional or design
  • Demonstrate the ability to write functionally oriented and design oriented specifications
  • Understand how to convert requirements into valid design specifications
  • Learn how to separate System and Sub-system Requirements
  • Learn how to create a Verification Plan to verify each system requirement
  • Effectively produce design specification
  • Effectively perform Verification (Functional, Non-Functional and Interface reqs.) and Validation (ConOps)

Course Topics

BASICS OF SYSTEMS ENGINEERING

  • Definition of Common Terms
  • System Definition and Design
  • Design Methodologies
  • Master Plan Scope
  • Concept of Operations (ConOps)
  • Preliminary Engineering
  • Final Engineering
  • RFP versus Consultant Design versus Design-Build

REQUIREMENTS ANALYSIS

  • Introduction to Requirements
  • The Quality of Requirements
  • Description of Requirements Writing (within the larger context of system development)
  • Overview of Requirements Development

Communication Techniques for Eliciting Requirements

  • Stakeholder involvement
  • Defining valid and meaningful needs
  • Technical reviews
  • Stakeholder feedback on the needs being collected
  • Prioritization of the needs
  • ConOps to System Requirements (generic)

REQUIREMENTS SOURCES

  • Purpose of Requirements
  • Levels of Requirements
  • Understanding the different levels of requirements
  • Performance requirements
  • Conditions (e.g., environmental, reliability and availability)
  • Environmental and Non-Functional requirements
  • System
  • Sub system
  • Component / task

Types of Requirements

  • Eight basic types
  • Differences between requirements for hardware, software, services
  • Functional
  • Non functional
  • Performance, etc.
  • Non-Requirements

STRUCTURE OF A WELL FORMED REQUIREMENT

  • Definition
  • Capabilities
  • Conditions
  • Constraints
  • Operational Policies & Constraints
  • Technical and Policy Constraints
  • Properties
  • Interface
  • Human
  • Hardware
  • Software
  • Communications
  • Functional analysis — needs analysis, operational analysis, use cases
  • Design requirements analysis
  • States & Modes analysis
  • Workshop — States and modes analysis
  • Requirements parsing
  • Writing requirements versus defining a system proposed is critical

SPECIFICATIONS VS. REQUIREMENTS

  • Development of requirements
  • Description of the current environment
  • Stakeholders
  • Feedback to Stakeholders
  • Facilitation skills and techniques
  • Transforming Requirements into Requirements Specifications
  • How requirements specifications relate to requirements
  • Requirements Flowdown in Specifications
  • Specification Types and Formats
  • Types of requirements specification
  • Specification Writing
  • Review of requirements quality
  • Requirement structural template

SYSTEM TESTS (Verification and Validation)

  • Test Plans
  • Test Procedures
  • User Acceptance Testing
  • Requirements Verification Matrix
  • Traceability to user requirements (Validation against ConOps)
  • Traceability to system requirements (Verification against System Specs)
  • Verification (Functional, Non-Functional and Interface reqs)
  • Validation (ConOps)
  • System Integration
  • Standards and Policies

WORKSHOPS/EXERCISE

  • Workshop 1
  • Examples of good and poor requirements (group project)
  • Requirements constructs
  • Group presentations and discussions
  • Workshop 2- classifying requirements as functional or design
  • Workshop 3 – writing a functionally oriented specification versus a design oriented specification
  • Analysis of Conops document
  • Analysis of Test plans/procedures

Who Should Attend

SMEs, project stakeholders, users, Project and program managers, directors, project sponsors and anyone else involved in planning and writing specifications requirements for projects.

Request More Information

  • Please complete the following form and a Tonex Training Specialist will contact you as soon as is possible.

    * Indicates required fields

  • This field is for validation purposes and should be left unchanged.