Requirements Engineering Training, a 3-day hands-on training course

Requirements Engineering Training Course by TONEX. Presented over three days worldwide. Learn about effective requirements engineering and the structure of requirements specification. For complete course outline, CLICK HERE.

If you can’t explain it to a six year old, you don’t understand it yourself.
― Albert Einstein

Requirements are statements of need that define what a system will do and how well it must perform those tasks. At lower levels of the system, such as for a complex electronic device,or software the requirements will include specifics on what the device or software must do (and how well), how the device will interface to other parts of the system, and what part the device will play in overarching requirements, such as safety and reliability.

Requirements are critical key aspects of any project, or sub-section of a project. Requirements define what system or product will be built. Many problems found during design, testing, verification, validation,  or operation of a system are the result of incorrect, incomplete, or missing requirements. Needs are usually vague, implicit [unstated], or described in terms of technical solutions.  Verifying that the requirements are correct  is an important function of systems and assurance engineers.

Requirements specification is a document that clearly and accurately describes the essential requirements for items, materials, or services including the procedures by which it can be determined that the requirements have been met.

Requirements engineering includes solicitation, analysis, and management of requirements. Requirements engineering includes key elements of a successful and reliable and safe development process for any given product or system. Many costly and critical system failures can ultimately be traced back to missing, bad, vague, incorrect, misunderstood, unnecessary or incompatible requirements.

Requirements Engineering training covers many of engineering disciplines to establish user and systems requirements and specifying systems and software systems.

Learn about requirements engineering and specification writing. Specifications are the written requirements for a material, product, or service for a proposed project, like a building, bridge or machine.Specifications help avoid duplication and inconsistencies, allow for accurate estimates of necessary work and resources, act as a negotiation and reference document for engineering changes, provide documentation of configuration, and allow for consistent communication among those responsible for different functions of Systems Engineering.

Requirements can also be classified by the role they play in the system. This classification will vary, depending on the organization or project. The following list of requirements types is commonly used in many government organizations.

Functional requirements describe the capabilities of the product or system (what the system must do).

Performance requirements describe how well the product or system must perform a function. Performance requirements complement the functional requirements, and these are sometimes combined into single requirements.

Stakeholder involvement is essential to defining valid and meaningful needs. Elicitation techniques help the stakeholders clarify their needs. Stakeholder involvement is essential for validating the requirements.

Elicitation is a collection of techniques to draw out and clarify stakeholder needs and requirements. Multiple techniques are provided to address the needs from various directions.

requirements engineering Training Objective

After completing this course, the attendees will be able to:

• Identify the key principles of requirements engineering
• Describe the role of requirements analysis and successful project outcomes
• List different requirement types
• Describe requirements definition processes and stakeholder expectations analysis
• Describe activities in the requirements engineering process
• Write and manage business, operational and technical requirements
• Discuss the important considerations when planning, writing and managing requirements and specifications

Learn more about:

• Systems as they are conceptualized with many levels of structure
• Characteristics of Requirements
• Requirements Key Enablers
• System size and complexity
• Level of insight required by designers
• Requirements imposed by external organizations
• Internal organization policy
• Requirement Decomposition
• Characteristics of Requirements
• Requirements Flowdown and Traceability
• Technical reviews
• Defects, conflicts, missing, or unnecessary requirements
• Interface between the system and the outside world.
• System itself as a black box
• Role of conops and requirements and how the users and stakeholders (people or other systems) will interact with the system, and what the system will do in response to those inputs.
• Constraints as they are imposed on the system from outside entities: environment regulation, safety, security etc,.
• Systems as set of interacting elements
• Process of requirements decomposition (or derivation)
• Requirements decomposition into high level design, architecture and subsystems
• Interface requirements as they specify how the system will interact or interoperate with an adjacent system.
• Safety, Quality, Reliability, Maintainability, etc. (the “ilities”)
• Overarching system questions and stakeholders concerns

Study: 68 percent of IT projects fail

• Companies with poor business analysis capability will have three times as many project failures as successes.

Good requirements have the following attributes:

• Necessary. The product/system cannot meet the real needs of the user without it.
• Unambiguous. If a requirement has multiple interpretations, the system that is built may not match what the user wanted. Clarity is very important.
• Complete. It is impossible to know all of a system’s future requirements, but all of the known ones should be specified.
• Consistent. Requirements must not conflict with each other.
• Traceable. The source of each requirement should be identified.
• Verifiable. Each requirement must be able to be verified by test, analysis, inspection, or demonstration. Avoid negative requirements where possible.

Remember These Key Requirements Principles are The Five Cs:

• Concise – Use simple words, short sentences, active voice
• Clear – Avoid ambiguities with measurable standards. Use words that convey exact meaning.
• Complete – Is the requirement complete (without requiring a reader to look for information elsewhere to understand the requirement)?Does not require you to look at additional text to know what the requirement means.
• Correct – Be technically and grammatically correct
• Consistent Follow a Style Guide for consistency in how information is presented

Requirements Key Principles:

• Use simple, clear language without jargon (to minimize misinterpretation).
• Define terms, symbols and acronyms (include a “Glossary of Terms”).
• Be concise.
• Do not explain the same requirement in more than one section.
• Define each aspect of the requirement in one or two paragraphs where possible.
• Adopt a user-friendly format.
• Number the sections and paragraphs.
• Seek feedback from someone unfamiliar with the requirement.
• Discuss the draft and refine it.
• There are no fixed rules on formats and structures because each specification reflects a different requirement or need. A specification should list the functional, performance and technical characteristics separately.

Course Agenda

Introduction to Requirements 

• Introduction to Systems Engineering
• What is Requirements Engineering?
• Quality of Requirements
• Stakeholder Involvement
• Requirements Lifecycle
• Requirements Traceability
• Analysis and Modeling
• Testing and Integration
• Requirements Verification and Validation
• Mapping Requirements from Problem to Solution Domains
• Effective requirements management
• Principles of requirements definition and management
• Best practices for requirements engineering
• Requirements Baselining

Introduction to Requirements Engineering

• The Requirements Engineering Process
• Requirements and the Business Context
• Hierarchy of requirements
• Stakeholders in the requirements process
• Eliciting and Documenting Requirements
• Requirements Elicitation
• Interviewing for Requirements
• Use of models in Requirements Engineering
• Requirements Documentation
• Requirements Analysis
• Analyzing and Negotiating Requirements
• Requirements Validation and Verification
• Requirements Management

Requirements Engineering and System Views

• Process View
• Deliverable View
• pertinent information for RFPs, SEMPs, ConOps, etc
• Checklist View
• Project View
• SE process applies

Activities in the Requirements Engineering

• Develop requirements
• Write and document requirements
• Check completeness
• Analyze, refine, and decompose requirements
• Validate requirements
• Manage requirements

Basic Requirements Engineering and Management

• Techniques for drawing out stakeholder needs, goals, requirements, constraints, priorities, normal operations, and preferences
• Initial needs assessment leading to the development of requirements
• .Elicitation
• Stakeholder Analysis
• Interviews and Workshops
• Observation
• Creativity
• Analysis
• Kano
• Specification
• Use Cases and ConOps
• BPMN
• Verification
• Validation
• Prototypes
• Inspection
• Testing
• Demo
• Change management
• Version control
• Customer acceptance and validation

Elicitation Techniques

• Interviews and Focus groups
• Questionnaires, surveys and Brainstorming
• Role play
• Review incident reports, enhancement requests and Joint authorship
• Benchmark – similar or competing systems
• Prototype
• Throw-away
• Evolutionary

Process for Requirements Engineering 

• Value of Systems Engineering
• Value of Requirements Engineering
• Customer Requirements
• Functional Requirements
• Performance Requirements
• Design Requirements
• Derived Requirements
• Allocated Requirements
• Concept of Operations(ConOps)
• System Requirements
• Integration and Verification
• System Validation
• Project Planning
• Project Monitoring and Control
• High-level identification of user needs and system capabilities
• Project stakeholders
• Stakeholder agreement
• Interrelationships and roles and responsibilities
• Shared understanding by system owners, operators, maintainers, and developers
• who, what, why, where, and how of the system and product
• Agreement on key performance measures
• Plan for how the system will be validated
• Developing Systems
• Input Requirements and Derived Requirements
• Acceptance Criteria and Qualification Strategy
• Generic Process Introduction
• Development in the Context of Change

System Modeling for Requirements Engineering 

• Requirements Engineering and System Modeling
• Use Cases and Actors
• Data Flow Diagrams
• Entity-Relationship (E-R) Diagrams
• Statecharts
• Object-Oriented Approaches
• DoDAF and NAF Viewpoint Methods
• The UML and SysML Notations
• Formal Methods
• Model Based System Engineering (MBSE) and Requirements Engineering

Managing, Writing and Reviewing Requirements

• System Life Cycle
• The systems engineering process
• Development of system architecture and detail design
• The Origin of Requirements
• Concept of the system boundary
• The modeling boundary
• Managing Requirements
• Validating Requirements
• Requirements traceability
• Baselines and their use
• The waterfall vs. agile life cycle paradigm
• Structuring Requirements
• Requirements Engineering in the Problem Domain
• Identify Stakeholders
• Operational and Use Scenarios
• Scoping the System
• Derive Requirements
• Allocated Requirements
• Requirements Engineering in the Solution Domain
• Stakeholder Requirements mapped to System Requirements
• System Requirements
• Requirements to Subsystems
• Traceability
• Metrics for Traceability

Requirements Engineering Management  

• Requirements Management
• Planning
• Monitoring
• Changes
• Development
• Relationship to design
• Relationship to baselines
• Types of Requirements
• Differences between requirements for hardware, software, services
• Non-functional requirements
• Quality of Requirements
• Requirements Analysis
• Context analysis
• Operational Concept Description
• Verification requirements development
• “TBDs”
• Requirements and Requirements Specifications
• Requirements Flowdown into Specifications

Requirements Engineering Gates and Cross-Cutting Activities

• Stakeholder Involvement
• Elicitation
• Project Management Practices
• Risk Management
• Metrics
• Configuration Management
• Project Process Improvement
• Decision Gates
• Decision Support/Trade Studies
• Technical Reviews
• Traceability

Requirements – Deliverable Checklist

• Are all the bases covered?
• Is there a definition of all the major system functions?
• With each function of the system, is there a set of requirements that describes: what the function does, who is assigned to do it, and under what conditions [e.g. environmental, reliability, and availability.]
• Are all terms, definitions, and acronyms defined?
• Are all supporting documents such as standards, concept of operations, and others reference
• Does each requirement have a link [traceability] to a higher level requirement of a user-specified need?
• Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent?
• Are all technology dependent requirements identified as constraints?
•  Does each requirement have a method of verification defined?                                Has the trace from requirements to hardware and software components been checked and verified?