Course Number: 903
Length: 2 Days
Requirements Writing Training
Good requirements writing can save an organization a fortune.
In requirements writing (as in good writing in general), authors should strive for clarity.
The primary reason that people write poor requirements is that they have had no training or experience in writing good requirements.
An effective Requirements Management process is crucial for the success of a product or project and involves collecting, documenting, analyzing, refining, and prioritizing the requirements, building end-to-end traceability, providing a means to track requirements changes, and foster communication among the stakeholders.
The goal of each step in this process is to help ensure that the product development or project goals are successfully met.
Requirements Specification Documents (RSDs) are the primary means of communication between users and developers and should be prepared as carefully as when writing out a contract. The RSD should be considered a binding agreement which contains the conditions governing whether the proposed solution will be acceptable or not.
Crafting requirements is not difficult and can be improved through continuous learning and practice. There’s no substitute for good requirements, however. Analysts should pay attention to every little detail ranging from the style, structure and presentation to content, to increase the chances of delivering successful systems.
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
It’s especially important to avoid ambiguity. Poor or unclear communication is highly frustrating for all parties working on your product. Developers may have to call the client back several times asking for more explanations or spend much time designing features and functionalities that do not meet the client’s expectations.
Also, the client may end up with a product that doesn’t fit his requirements and will not serve his business as it should. All that may quickly lead to business disruption – and lost revenue.
In other words, be explicit. To be explicit means more than mention the feature you want to implement. You must be specific, detailed, and avoid assuming that the reader knows what you mean.
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.
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)
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
- 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)
- 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
- Sub system
- Component / task
Types of Requirements
- Eight basic types
- Differences between requirements for hardware, software, services
- Non functional
- Performance, etc.
STRUCTURE OF A WELL FORMED REQUIREMENT
- Operational Policies & Constraints
- Technical and Policy Constraints
- 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
- 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 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.