Requirements Writing Training Course – Specification Writing Training

Requirements Writing Training Course – Specification Writing Training by 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.

Audience: This course is ideal for professionals involved in project management, business analysis, systems engineering, software development, and anyone tasked with defining and documenting requirements. It is suitable for:

• Business Analysts
• Project Managers
• Software Engineers
• Systems Engineers
• Quality Assurance Specialists
• Product Managers
• Requirements Engineers
• IT Professionals

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.

The primary reason that people write poor requirements in requirements writing is because they have had no training or experience in writing good requirements.

Tonex can help.

Requirements are the key to a project’s success. Effective requirements writing is essential to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page. Ineffective requirements management often leads to scope creep, which in turn may cause project cost overrun or project delays.

Experts in this area say one of the most important aspects of good requirements writing is making sure your requirements are attainable.

Requirements need to be technically feasible to implement the requirement within the allocated budget and timeline. A requirement is attainable if it can be practically implemented within the given schedule and budget by your team.

Requirements should also be properly categorized and prioritized. Requirements should be categorized appropriately as Business Requirements, Functional Requirements, Non-Functional Requirements, System Requirements, etc. (as per your organizational needs). This helps the stakeholders to identify and concentrate on requirements that are relevant to them.

One of the most common problems you need to avoid in requirements writing is making bad assumptions.

Bad assumptions occur either because requirement authors do not have access to sufficient information or the information does not exist. You can eliminate the first problem by documenting the information critical to the program or project, including needs, goals, objectives, constraints, missions, operations concept, budget, schedule and management/organization.

This information then must be made available to all authors. You can create and maintain a list of other relevant documents and make these easily accessible to each author. If you have automated the process, you can offer documents online and you can filter the information within the documents so that individual authors can get copies of only the data that they need.

Where information does not exist, the requirement author should document all assumptions with the requirement. When the requirement is reviewed, the assumptions can also be reviewed and problems quickly identified.

The goal of each step in the requirements writing process is to help ensure that the product development or project goals are successfully met.

According to INCOSE, it’s important to determine how to verify a requirement as it is being written. In other words, determine the criteria for acceptance. This step will help insure that the requirement is verifiable.

Ideally, every requirement statement (written from the user’s perspective) should contain:

• A user role that benefits from the requirement
• A desirable state that the user role wants to achieve
• A metric that allows the requirement to be tested, where applicable

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
• Non-Requirements

Types of Needs

• Essential
• Core requirements that must be met for the project to be considered successful.
• Desired
• Non-Essential
• Optional
• Non-Essential
• Added features or enhancements.

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

Specification 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

Workshop/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