The Essential Guide to Requirements Management and Traceability
Chapters
- 1. Requirements Management
- Overview
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Status Request Changes
- 6 Conquering the 5 Biggest Challenges of Requirements Management
- 7 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- Overview
- 1 Functional requirements examples and templates
- 2 Identifying and Measuring Requirements Quality
- 3 How to write system requirement specification (SRS) documents
- 4 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence
- 5 Adopting the EARS Notation to Improve Requirements Engineering
- 6 Jama Connect Advisor™
- 7 Frequently Asked Questions about the EARS Notation and Jama Connect Advisor™
- 8 How to Write an Effective Product Requirements Document (PRD)
- 9 Functional vs. Non-Functional Requirements
- 10 What Are Nonfunctional Requirements and How Do They Impact Product Development?
- 11 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 12 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- Overview
- 1 Requirements Engineering
- 2 Requirements Analysis
- 3 A Guide to Requirements Elicitation for Product Teams
- 4 Requirements Gathering Techniques for Agile Product Teams
- 5 What is Requirements Gathering?
- 6 Defining and Implementing a Requirements Baseline
- 7 Managing Project Scope — Why It Matters and Best Practices
- 8 How Long Do Requirements Take?
- 4. Requirements Traceability
- Overview
- 1 What is Traceability?
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 Change Impact Analysis (CIA): A Short Guide for Effective Implementation
- 4 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 5 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency
- 6 Unraveling the Digital Thread: Enhancing Connectivity and Efficiency
- 7 The Role of a Data Thread in Product and Software Development
- 8 How to Create and Use a Requirements Traceability Matrix
- 9 Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 10 Live Traceability vs. After-the-Fact Traceability
- 11 How to Overcome Organizational Barriers to Live Requirements Traceability
- 12 Requirements Traceability, What Are You Missing?
- 13 Four Best Practices for Requirements Traceability
- 14 Requirements Traceability: Links in the Chain
- 15 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- Overview
- 1 Selecting the Right Requirements Management Tools and Software
- 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn
- 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development
- 4 Application lifecycle management (ALM)
- 5 Is There Life After DOORS®?
- 6 Checklist: Selecting a Requirements Management Tool
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- Overview
- 1 Understanding ISO Standards
- 2 Understanding ISO/IEC 27001: A Guide to Information Security Management
- 3 What is DevSecOps? A Guide to Building Secure Software
- 4 Compliance Management
- 5 What is FMEA? Failure Modes and Effects Analysis
- 6 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide
- 8. Systems Engineering
- 9. Automotive Development
- 10. Medical Device & Life Sciences Development
- Overview
- 1 The Importance of Benefit-Risk Analysis in Medical Device Development
- 2 Software as a Medical Device: Revolutionizing Healthcare
- 3 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 4 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry
- 5 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 6 What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
- 7 ISO 13485 vs ISO 9001: Understanding the Differences and Synergies
- 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 9 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)
- 11. Aerospace & Defense Development
- 12. Architecture, Engineering, and Construction (AEC industry) Development
- 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy
- Glossary
Chapters
- 1. Requirements Management
- Overview
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Status Request Changes
- 6 Conquering the 5 Biggest Challenges of Requirements Management
- 7 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- Overview
- 1 Functional requirements examples and templates
- 2 Identifying and Measuring Requirements Quality
- 3 How to write system requirement specification (SRS) documents
- 4 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence
- 5 Adopting the EARS Notation to Improve Requirements Engineering
- 6 Jama Connect Advisor™
- 7 Frequently Asked Questions about the EARS Notation and Jama Connect Advisor™
- 8 How to Write an Effective Product Requirements Document (PRD)
- 9 Functional vs. Non-Functional Requirements
- 10 What Are Nonfunctional Requirements and How Do They Impact Product Development?
- 11 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 12 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- Overview
- 1 Requirements Engineering
- 2 Requirements Analysis
- 3 A Guide to Requirements Elicitation for Product Teams
- 4 Requirements Gathering Techniques for Agile Product Teams
- 5 What is Requirements Gathering?
- 6 Defining and Implementing a Requirements Baseline
- 7 Managing Project Scope — Why It Matters and Best Practices
- 8 How Long Do Requirements Take?
- 4. Requirements Traceability
- Overview
- 1 What is Traceability?
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 Change Impact Analysis (CIA): A Short Guide for Effective Implementation
- 4 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 5 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency
- 6 Unraveling the Digital Thread: Enhancing Connectivity and Efficiency
- 7 The Role of a Data Thread in Product and Software Development
- 8 How to Create and Use a Requirements Traceability Matrix
- 9 Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 10 Live Traceability vs. After-the-Fact Traceability
- 11 How to Overcome Organizational Barriers to Live Requirements Traceability
- 12 Requirements Traceability, What Are You Missing?
- 13 Four Best Practices for Requirements Traceability
- 14 Requirements Traceability: Links in the Chain
- 15 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- Overview
- 1 Selecting the Right Requirements Management Tools and Software
- 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn
- 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development
- 4 Application lifecycle management (ALM)
- 5 Is There Life After DOORS®?
- 6 Checklist: Selecting a Requirements Management Tool
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- Overview
- 1 Understanding ISO Standards
- 2 Understanding ISO/IEC 27001: A Guide to Information Security Management
- 3 What is DevSecOps? A Guide to Building Secure Software
- 4 Compliance Management
- 5 What is FMEA? Failure Modes and Effects Analysis
- 6 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide
- 8. Systems Engineering
- 9. Automotive Development
- 10. Medical Device & Life Sciences Development
- Overview
- 1 The Importance of Benefit-Risk Analysis in Medical Device Development
- 2 Software as a Medical Device: Revolutionizing Healthcare
- 3 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 4 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry
- 5 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 6 What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
- 7 ISO 13485 vs ISO 9001: Understanding the Differences and Synergies
- 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 9 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)
- 11. Aerospace & Defense Development
- 12. Architecture, Engineering, and Construction (AEC industry) Development
- 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy
- Glossary
Product Development Terms and Definitions
From Analysis of Alternatives (AoA) to Verification Cross Reference Matrix (VCRM) – there are a lot of terms and acronyms used in complex product, software, and systems development. It gets even more complicated when you add in industry-specific vernacular like ISO 26262 and Failure Mode and Effects Analysis (FMEA).
Luckily we’ve created this handy guide to common product development terms, acronyms, and definitions. We’ll keep adding to this as we go, but for now, check scroll down to see a list of common product development terms – and what they mean.
ACRONYM | TERM | DEFINITION |
---|---|---|
Allocation | The process by which requirements defined at one level (such as system, subsystem, component) are assigned to the parts of the architecture at the next lower level. | |
AoA | Analysis of Alternatives | AoAs provide a framework to consistently evaluate and compare the value of different solutions for providing a needed capability to specific end users. |
Acceptance Training | Acceptance criteria define the boundaries of a user story and are used to confirm when a story is completed and working as intended. Acceptance criteria are written in simple language, just like the user story. Including acceptance criteria as part of your user stories has several benefits:
1: They get the team to think through how a feature or piece of functionality will work from the user’s perspective. 2: They remove ambiguity from requirements. 3: They form the tests that will confirm that a feature or piece of functionality is working and complete. | |
ALM | Application Lifecycle Management | Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of computer programs. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management. |
API | Application Programming Interface | Application programming interfaces, or APIs, simplify software development and innovation by enabling applications to exchange data and functionality easily and securely. |
Atomic Requirements | Atomic requirements (ATRs) are indivisible “well-formed requirements” (ANSI/IEEE-Std-1233-1996) that enable control over software design, test planning, and work management with an ease and accuracy not previously attainable. | |
Backlog | Product Backlog: A list of desired features for the product.
Sprint Backlog: A list of tasks to be completed in a sprint. | |
Baseline | An approved version of items (requirements, tests). A Baseline can be changed only through a change control process. | |
BAT | Build Acceptance Test | A set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. This test is generally a short set of tests, which exercise the mainstream functionality of the application software. |
BVT | Build Verification Test | A set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. This test is generally a short set of tests, which exercise the mainstream functionality of the application software. |
BA | Business Analyst | Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. |
BCSD | Business Critical Software Development | Business critical systems are programmed to avoid significant tangible or intangible economic costs; e.g., loss of business or damage to reputation. This is often due to the interruption of service caused by the system being unusable. |
BI | Business Intelligence | Business intelligence comprises the strategies and technologies used by enterprises for the data analysis of business information. |
BPMN | Business Process Model and Notation | BPMNs provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. |
BR | Business Requirement | The purpose of business requirements is to define a project’s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. |
BRD | Business Requirement Document | A business requirements document describes the business solution for a project (i.e., what a new or updated product should do), including the user’s needs and expectations, the purpose behind this solution, and any high-level constraints that could impact a successful deployment. |
CMM | Capability Maturity Model | A five level staged framework that describes the key element of an effective software process. The Capability Maturity Model covers best-practices for planning, engineering and managing software development and maintenance. |
CMMI | Capability Maturity Model Integration | A framework that describes the key elements of an effective product development and maintenance process. The Capability Maturity Model Integration covers best-practices for planning, engineering and managing product development and maintenance. CMMI is the designated successor of the CMM. |
CoE | Center of Excellence | A Center of Excellence or COE (or CoE) is a team, shared facility or entity that provides leadership, best practices, research, support and/or training for a focus area. |
CRQ | Change Request | A change request is a formal proposal for an alteration to some product or system. In project management, a change request often arises when the client wants an addition or alteration to the agreed-upon deliverables for a project. |
Code | The implementation of a software system, usually represented by source code files. | |
CAPA | Corrective Action Preventative Action | Corrective actions are intended to determine the cause of non conformances that have been detected, while preventive actions are the plan put in place to stop the problem from happening again in the future. |
CCA | Clinger-Cohen Act | Formerly the Information Technology Management Reform Act, the Clinger-Cohen Act is a United States federal law, designed to improve the way the federal government acquires, uses and disposes information technology. |
CFR | Code of Federal Regulations | The Code of Federal Regulations (CFR) is the codification of the general and permanent rules published in the Federal Register by the executive departments and agencies of the Federal Government. It is divided into 50 titles that represent broad areas subject to Federal regulation. Example: 21 CFP pt. 11, 21 CFR 820.x |
COTS | Commercial Off-The-Shelf (As Opposed to Custom-Built) | COTS solutions almost always involve changes and adaptions in workflow dictated by the COTS product design. A custom-build can cater to the specific environment of organizations where the workflow is unchangeable. |
CPSD | Complex Products System Development | Complex systems development and construction projects, collectively referred to here as “complex systems” projects, have challenges that otherwise may not require as much attention in projects of smaller scale or complexity. |
Complex Systems | See entry for Complex Products System Development (above) | |
Compliance and Compliance Management | Compliance can refer to a variety of different laws, guidelines, standards, processes, procedures, or other controlling documents, including contracts. Compliance management refers to the intentional process by which designated team members or compliance officers monitor and control design, development, launch, and fulfillment to ensure that all legal, contractual, and procedural requirements are met. | |
Critical System | A critical system is a system which must be highly reliable and retain this reliability as they evolve without incurring prohibitive costs.
There are four types of critical systems: 1: Safety critical. | |
DID | Data Item Description | It is a completed document that defines the data required of a contractor. The document specifically defines the data content, format, and intended use.
Important specifically for Department of Defense (DoD) standards in particular. |
Derived Requirement | Derived requirements aren’t directly traceable to a parent requirement or that introduce behavior beyond the specified scope of the system. | |
DFMA | Design for Manufacture and Assembly | A system that allows you to systematically analyze your product designs with the goal of reducing manufacture and assembly costs, improving quality and speeding time to market. |
DFMEA | Design Failure Mode and Effects Analysis | Is the application of the Failure Mode and Effects Analysis method specifically to product design. It is a paper-and-pencil analysis method used in engineering to document and explore ways that a product design might fail in real-world use. A DFMEA documents the key functions of a design, the primary potential failure modes relative to each function and the potential causes of each failure mode. The DFMEA method allows the design team to document what they know and suspect about a product’s failure modes prior to completing the design, and then use this information to design out or mitigate the causes of failure. |
DMSC | Digital Metrology Standards Consortium | DMSC is responsible for the development, maintenance and support of the QIF standard, as well as the Dimensional Measuring Interface Standard (DMIS). The DMSC is an ANSI accredited Standards Developing Organization as well as an A-Liaison to ISO. The DMSC invites participation within the consortium of other standards groups and activities that seek to resolve technological inefficiencies and other issues related to digital metrology. |
DMIS | Dimensional Measuring Interface | Created by the DMSC (Digital Metrology Standards Consortium) – Dimensional Measuring Interface Standard (DMIS) is an internationally recognized standard, and one of the most widely used standards related to dimensional metrology in the world. This standard has contributed to significant improvement of interoperability between CMMs, and traceability of measurement processes. |
EARS | Easy Approach to Requirements Syntax | The Easy Approach to Requirements Syntax (EARS) uses a few keywords and a simple underlying ruleset to gently constrain natural language (NL) requirements. The EARS approach can improve product requirements and align teams, processes, and technology by enabling more effective and efficient communication within and across teams. This alignment creates better synergy allowing teams to focus on the quality of output, thereby reducing overall project risk. |
EAR | Export Administration Regulations | The Export Administration Regulations (EAR) are a set of regulations found at 15 C.F.R. § 730 et seq. They are administered by the Bureau of Industry and Security, which is part of the US Commerce Department. In general, the EAR govern whether a person may export a thing from the U.S., reexport the thing from a foreign country, or transfer a thing from one person to another in a foreign country. The EAR apply to physical things (sometimes referred to as “commodities”) as well as technology and software. |
Failure | Is the inability for the system to perform its intended function. | |
Failure Condition | Sometimes called Failure Mechanism or Failure Cause. States or conditions described by nouns and adjectives, associated with deviant physical condition or physical state. The Failure Condition is caused by failures or errors. Example Cause: Improper application of corrosion protection layer. | |
FMEA | Failure Mode and Effect Analysis | An inductive failure analysis used in product development, systems engineering, reliability engineering and operations management for analysis of failure modes within a system for classification by the severity and likelihood of the failures. A successful FMEA activity helps a team to identify potential failure modes based on past experience with similar products or processes or based on common failure mechanism logic, enabling the team to design those failures out of the system with the minimum of effort and resource expenditure, thereby reducing development time and costs. It serves as a form of design review to erase weakness out of the design or process. It is widely used in development and manufacturing industries in various phases of the product life cycle. Effects analysis refers to studying the consequences of those failures on different system levels. |
Function | Intended behavior of the system, agnostic of implementation details. | |
FR | Functional Requirements | In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements are typically phrased with subject/predicate constructions, or noun/verb. Example, “the system prints invoices.” |
Functional Safety | Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, hardware failures and operational/environmental stress. | |
GTM | Go-to-Market | A go-to-market strategy (GTM strategy) is an action plan that specifies how a company will reach target customers and achieve competitive advantage. |
HARA | Hazard Analysis and Risk Assessment | Risk assessment is a term used to describe the overall process or method where you:
1: Identify hazards and risk factors that have the potential to cause harm (hazard identification.) |
IV&V | Independent Verification and Validation | In the process of authoring computer software, its standards or documentation, or other technical standards, deprecation is a status applied to features, characteristics, or practices to indicate that they should be avoided, typically because they have been superseded.
Although deprecated software features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated — rather than immediately removed — in order to provide backward compatibility, and give programmers who have used the feature enough time to bring their code into compliance with the new standard. |
ILT | Instructor-Led Training | Instructor-led training (ILT) is facilitated by an instructor, either online or in a classroom setting. |
INCOSE | International Council on Systems Engineering | The International Council on Systems Engineering (INCOSE; pronounced in-co-see) is a not-for-profit membership organization and professional society in the field of Systems engineering. |
IEC | International Electrotechnical Commission | The Code of Federal Regulations (CFR) is the codification of the general and permanent rules published in the Federal Register by the executive departments and agencies of the Federal Government. eg, IEC 62304 |
IIBA | International Institute of Business Analysis | The International Institute of Business Analysis (IIBA) is a non-profit professional association formed in October 2003 with the purpose of supporting and promoting the discipline of business analysis. IIBA helps business analysts develop their skills and further their careers by providing access to relevant content. |
ISO | International Organization for Standardization | (ISO) The International Organization for Standardization (ISO) is an international nongovernmental organization made up of national standards bodies; it develops and publishes a wide range of proprietary, industrial, and commercial standards and is comprised of representatives from various national standards organizations. |
ITSM | IT Service Management | Information technology service management are the activities that are performed by an organization to design, build, deliver, operate, and control information technology services offered to customers. |
JAD | Joint Application Development | Joint Application Development (JAD) is a process that accelerates the design of information technology solutions. JAD uses customer involvement and group dynamics to accurately depict the user’s view of the business need and to jointly develop a solution. Before the advent of JAD, requirements were identified by interviewing stakeholders individually. The ineffectiveness of this interviewing technique, which focused on individual input rather than group consensus, led to the development of the JAD approach. |
JIT | Just-in-Time | The just-in-time (JIT) inventory system is a management strategy that aligns raw-material orders from suppliers directly with production schedules. Companies employ this inventory strategy to increase efficiency and decrease waste by receiving goods only as they need them for the production process, which reduces inventory costs. This method requires producers to forecast demand accurately. |
Kanban | Kanban is was David Anderson coined with respect to an agile development approach to driving change based on lean principles. It represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station. | |
KPI | Key Performance Indicator | Key Performance Indicators (KPIs) are the critical (key) indicators of progress toward an intended result. |
LOE | Level of Effort | In project management, level of effort (LOE) is a support-type project activity that must be done to support other work activities or the entire project effort. It usually consists of short amounts of work that must be repeated periodically. Examples of such an activity may be project budget accounting, customer liaison, or oiling machinery during manufacturing. |
Live Traceability™ | The ability for any engineer at any time to see the most up to date and complete up and downstream information for any requirement, no matter what stage of development it is in or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real time. | |
MR | Market Requirement | A market requirements document (MRD) in project management and systems engineering, is a document that expresses the customer’s wants and needs for the product or service. It is typically written as a part of product marketing or product management. The document should explain:
1: What (new) product is being discussed. |
MRD | Market Requirement Document | A market requirements document (MRD) is a document that describes the overall market opportunity — the size of the market, the types of customers you will target, and competitors in the space. It helps product managers consolidate market research so you can succinctly explain what customers want and need from your product or service.
An MRD is often confused with a product requirements document (PRD), but they have distinct purposes. While an MRD defines what customers need and how the product will provide this, a PRD describes how the product should actually be built. Think of the PRD as a guide for broader cross-functional teams (such as design and engineering) to understand what the product should do. Because the MRD informs the PRD, you should create the MRD before the PRD — this ensures that the product team clearly understands customer needs before defining actual product requirements. |
Metrology | Metrology is the science of measurement and its application. | |
MBSE | Model-Based Systems Engineering | Model-based systems engineering (MBSE), according to INCOSE, is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.
It is a systems engineering methodology that focuses on creating and exploiting domain models as the primary means of information exchange, rather than on document-based information exchange. MBSE methodology is commonly used in industries such as aerospace, defense, rail, automotive, industrial, etc. |
MPD | Modern Delivery / Modern Product Delivery | Modern delivery is a model that helps CIOs and the entire technology organization more rapidly deliver value, reduce failed deployments, and create a culture of continuous improvement while helping the business win in the market. |
NPI | New Product Introduction | New Product Introduction (NPI) is the process of establishing a clear plan to take your product from concept to its final form. The steps involved in this process vary from project to project, but the end goals are the same: reduce waste, avoid miscommunication, speed up production, and save money. |
NFR | Non-Functional Requirements | Non-functional requirements are global constraints on a software system e.g. development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.
A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability and portability. In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Non-functional requirements may be found in adverbs or modifying clauses, such as “The system prints invoices quickly” or “The system prints invoices *with confidentiality.” |
NRE | Non-Recurring Engineering | Non-recurring engineering (NRE) cost refers to the one-time cost to research, design, develop, and test a new product or product enhancement. |
OKR | Objectives & Key Results | Objectives and key results (OKR, alternatively OKRs) is a goal setting framework used by individuals, teams, and organizations to define measurable goals and track their outcomes. |
OOTB | Out-of-the-box | OOTB used to refer to the immediate usability or functionality of a newly purchased product, typically an electronic device or a piece of software. |
PD | Product Delivery | Overview of Managing Product Delivery:
The team manager will accept a work package, execute it, and then deliver it, and the trigger from delivery back to controlling the stage is completed work package. The objective of the Managing Product Delivery process is to ensure that: The work on products allocated to the team is authorized and agreed. The team manager may be doing the work him or herself and he may indeed have a whole team working for him or her. The planned products are delivered to expectations and within tolerance. Accurate progress information is provided as an agreed frequency to ensure that expectations are managed. |
PDP | Product Delivery Platform | Sometimes also called a content distribution platform, digital distribution platform or electronic software delivery system, a digital content delivery platform is the way you distribute or deliver digital content to users. Content can include media like audio, video, images, text, or even delivering new software to customers. |
PLE | Product Line Engineering | Systems and software product line engineering, often abbreviated as product line engineering (PLE), refers to the disciplined engineering of a portfolio of related products using a common set of shared assets and a common means of production. |
PLM | Product Lifecycle Management | PLM is the process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products. PLM integrates people, data, processes and business systems, and provides a product information backbone for companies and their extended enterprise. |
PM | Product / Project / Program Manager | Project/Program/Product Managers are responsible for planning and overseeing projects to ensure they are completed in a timely fashion and within budget. Project managers plan and designate project resources, prepare budgets, monitor progress, and keep stakeholders informed the entire way. |
PMI | Project Management Institute | PMI stands for the Project Management Institute, a not-for-profit professional membership association for project managers and program managers. |
PRD | Product Requirements Document | A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product. |
PPM | Project Portfolio Management | Project Portfolio Management is defined as a process and method designed to manage groupings of related projects so as to maximize value and benefits for the organization. A PPM strategy needs to be designed to fit the organization’s unique needs and features. It should be continuously monitored, evolved, and optimized over time. |
QA | Quality Assurance | Quality assurance can be defined as “part of quality management focused on providing confidence that quality requirements will be fulfilled.” |
QC | Quality Control | A system of maintaining standards in manufactured products by testing a sample of the output against the specification and finding defects. |
QIF | Quality Information Framework | The Quality Information Framework (QIF) – created by The Digital Metrology Standards Consortium – is a unified XML framework standard for computer-aided quality QIF systems, available free to all implementers. |
QMS | Quality Management System | A quality management system is a collection of business processes focused on consistently meeting customer requirements and enhancing their satisfaction. It is aligned with an organization’s purpose and strategic direction. |
RAD | Rapid Access Development | In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.
RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include the adaptive, agile, spiral, and unified models. |
Refactor | “Refactoring” essentially is “cleaning up” an existing code base to enable changes to be made more efficiently, or to improve the performance of the existing system. Refactoring usually involves restructuring or rewriting portions of code which are convoluted, difficult to understand, poorly documented, or unnecessarily complex. Refactoring, the engineers argued, is often essential to add future features, so developers should be given time to “refactor” existing code – even if nothing else is in that sprint or release. | |
REST API | Representational State Transfer API | An API, or application programming interface, is a set of rules that define how applications or devices can connect to and communicate with each other. A REST API is an API that conforms to the design principles of the REST, or representational state transfer architectural style. |
Regression Testing | Regression testing is that testing that is performed after making a functional improvement or repair to the program. Its purpose is to determine if the change has regressed other aspects of the program. It is usually performed by rerunning some subset of the program’s test cases.
Selective testing to verify that modifications have not caused unintended adverse side effects or to verify that a modified system still meets requirements. | |
REQ | Requirement | A condition or capability needed by a user to solve a problem or achieve an objective. |
ReqIF | Requirement Interchange Format | RIF/ReqIF is an XML file format that can be used to exchange requirements, along with its associated metadata, between software tools from different vendors. The requirements exchange format also defines a workflow for transmitting the status of requirements between partners. |
Requirements | That which an object should do and/or characteristics that it should have. Requirements are arbitrary but they must still be consistent, reasonably complete, implementable, and most important of all, falsifiable. | |
Requirements Gathering | The process of understanding what you are trying to build and why you are building it. | |
RM | Requirements Management | Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform. |
Requirements Traceability | The tracking of requirements throughout the product development lifecycle. | |
RTM | Requirements Traceability Matrix | A table that shows the relationship between two documents by marking components that relate. Used to judge completeness of relation (e.g., comparing a requirements document and a test plan to make sure all user stories are covered.) |
R&D | Research and Development | Research and development (R&D, R+D), known in Europe as research and technological development (RTD), is the set of innovative activities undertaken by corporations or governments in developing new services or products and improving existing ones. Research and development constitutes the first stage of development of a potential new service or the production process. |
ROI | Return on Investment | Return on investment (ROI) is a performance measure used to evaluate the efficiency or profitability of an investment or compare the efficiency of a number of different investments. ROI tries to directly measure the amount of return on a particular investment, relative to the investment’s cost.
To calculate ROI, the benefit (or return) of an investment is divided by the cost of the investment. The result is expressed as a percentage or a ratio. |
RM | Risk Management | Risk management is the identification, evaluation, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities. |
SOA | Service Oriented Architecture | Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
A service has four properties according to one of many definitions of SOA: 1: It logically represents a repeatable business activity with a specified outcome. |
SaaS | Software as a Service | SaaS is a method of software delivery and licensing in which software is accessed online via a subscription, rather than bought and installed on individual computers. |
SCCM | Software Change and Configuration Management | Software Change and Configuration Management (SCCM) solutions permit IT organizations to manage the changes that they make to software during development and maintenance. It can also be called Software Configuration Management (SCM). |
SDLC | Software Development Life Cycle | In systems engineering, information systems and software engineering, the systems development life cycle, also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. |
SPICE | Software Process Improvement and Capability Determination | A Software Requirements Specificiation (SRS) is a description of a software system to be developed. It is modeled after business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction. |
SRS | Software Requirements Specification | A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction. |
SOUP | Software of Unknown (or uncertain) Pedigree (or provenance) | A term often used in the context of safety-critical and safety-involved systems such as medical software. SOUP is software that has not been developed with a known software development process or methodology, or which has unknown or no safety-related properties. |
SPEC | Specification | A tangible, usually partial expression of requirements. Examples: document, list of features, prototype, test suite. Specifications are usually incomplete because many requirements are understood. For example, “the software will not crash or corrupt data.” The biggest mistake a tester can make is to assume that all requirements are expressed by the specification. |
Specs | Shorthand for Specification | |
Spiral Model | The spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, revolutionary prototyping. | |
Standard | Rules and guidance to increase the quality of a process. | |
SOP | Standard Operating Procedure | A standard operating procedure (SOP) is a set of step-by-step instructions compiled by an organization to help workers carry out routine operations. SOPs aim to achieve efficiency, quality output and uniformity of performance, while reducing miscommunication and failure to comply with industry regulations. |
SOW | Statement of Work | A statement of work (SOW) is a document routinely employed in the field of project management. It is the narrative description of a project’s work requirement. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client.
The SOW typically also includes detailed requirements and pricing, with standard regulatory and governance terms and conditions. It is often an important accompaniment to a master service agreement or request for proposal (RFP.) |
Story (or User Story) | A small, digestible artifact that can be completed in 2-4 weeks usually during a Sprint (see Agile)
Example: As a [role] I want [something] so that [benefit]. | |
SQL | Structured Query Language | Structured Query Language (SQL) is a standard Database language which is used to create, maintain and retrieve the relational database. |
SME | Subject Matter Expert | A subject-matter expert (SME) is a person who is an authority in a particular area or topic. |
SSR | Sub-System Requirement | The System / Subsystem Requirements Specification establishes the functional, performance, design, development, and verification requirements for this project. |
System Architecture | A specific architecture item that is part of an Airborne system. System Requirements are allocated to System Architecture Item(s).
High-Level and Low-Level Requirements are assigned to one specific Item. Also refered to as System, Hardware Item, Software Item, Architecture Item. | |
SRS | System Requirement Specification | A System Requirements Specification is a structured collection of information that embodies the requirements of a system. |
SEBoK | Systems Engineering Body of Knowledge | The Systems Engineering Body of Knowledge (SEBoK), formally known as Guide to the Systems Engineering Body of Knowledge, is a wiki-based collection of key knowledge sources and references for systems engineering. The SEBoK is a curated wiki meaning that the content is managed by an editorial board, and updated on a regular basis. This wiki is a collaboration of three organizations:
1: INCOSE. |
TIH | Tasktop Integration Hub | TIH is an integration platform for customers to connect to other application lifecycle management (ALM) software. |
TSO | Technical Standard Order | A minimum performance standard for specified materials, parts, and appliances used on civil aircraft. When authorized to manufacture a material, part, or appliances to a TSO standard, this is referred to as TSO authorization. Receiving a TSO authorization is both design and production approval. Receiving a TSO Authorization is not an approval to install and use the article in the aircraft. It means that the article meets the specific TSO and the applicant is authorized to manufacture it. |
TP | Test Plan | A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. |
TTM | Time-to-Market | In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. |
TTV | Time-to-Value | The time-to-value (TTV) measures the length of time necessary to finish a project and realize the benefits of the solution. |
TCO | Total Cost of Ownership | Total cost of ownership is the purchase price of an asset plus the costs of operation, representing the complete cost through its entire lifecycle. |
Traceability | Relationships between items to show evidence of requirement decomposition and verification coverage. | |
UAT | User Acceptance Testing | Test Cases that apply to higher level Use Cases, rather than more granular functional requirements. A broad test to prove that the feature that was built satisfies the customer’s needs, rather than simply passing QA tests. |
Unit Testing | The testing of individual software components / programs, or a collection of components, as they are written. | |
UC | Use Cases | They’re sometimes regarded as the heavyweight cousin of user stories – the requirements technique favored by Agile teams. |
UML | Unified Modeling Language | UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. Example, Enterprise Architect. |
Validation | The process of determining that the requirements are the correct requirements and that they are complete. Example: Are we building the right system / function / item? | |
Validation Testing | The process of evaluating software at the end of the development process to ensure compliance with requirements. | |
VSM | Value Stream Management | Value stream management is a lean business practice that helps determine the value of software development and delivery efforts and resources. It also helps to improve the flow of value to the organization, while managing and monitoring the software delivery life cycle from end-to-end. |
Verification | The evaluation of an implementation of requirements to determine that they have been met.
Example: Did we build the system / function / item right? | |
VCRM | Verification Cross Reference Matrix | The most common Cross Reference Matrix. It is used to show the relationship between the user’s requirements and the test or analysis which proves (or otherwise) that the requirement has been met. |
V&V | Verification and Validation | Verification and validation (also abbreviated as V&V) are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose.These are critical components of a quality management system such as ISO 9000.
The words “verification” and “validation” are sometimes preceded with “independent,” indicating that the verification and validation is to be performed by a disinterested third party. “Independent verification and validation” can be abbreviated as “IV&V.” In practice, as quality management terms, the definitions of verification and validation can be inconsistent. Sometimes they are even used interchangeably. |
VCRI | Verification Cross Reference Index | To provide traceability from the requirements or defining documentation, into the Projects plans and specifications through to the acceptance and ‘sell of’ for all requirements.
The Verification and Cross Reference Index will be derived from the requirements documentation, the Projects plans, procedures, specifications, the design documentation, test specification and Phase Completion Reports. |
Versioning | Versioning is the creation and management of multiple releases of a product, all of which have the same general function but are improved, upgraded or customized. The term applies especially to operating systems (OSs), software and Web services. | |
YTD | Year-to-Date | Year-to-Date (YTD) refers to the period of time beginning the first day of the current calendar year or fiscal year up to the current date. YTD information is useful for analyzing business trends over time or comparing performance data to competitors or peers in the same industry. |