How to Evaluate Requirement Management Tool

Author: Rami Azulay


The purpose of this article is to prepare the focus group doing evaluation for solution of Requirement Management System (RMS) and to provide the organization with the necessary information to effectively compare Requirements Management Systems solution among vendors to select the best RMS for their individual needs and cost parameters. Requirement management in software engineering is integral part of the daily work and needs to meet very specific needs by the stakeholders using it. We in Orcanos are proud to present the world our years of experience in RMS POCs and to share this with any prospect who seek to find the best solution for them. We believe in fair competition and not afraid to hear No Thank You from our prospects. There is no perfect solution but there is one that is perfect for you.


All information presented in this RFS, including any information that is subsequently disclosed by the Orcanos during the evaluation process, should be considered public and can be used by the public domain.


Orcanos ( is a software vendor since 2005, We hold blue chip customers as well small/medium companies which use our software for both ALM or/and QMS process.

Orcanos solution cover in a complete manner the requirements from RMS system and due to our presence in the regulatory industry our RMS system include some unique capabilities to address such special needs. Orcanos system is 21 CFR Part 11 compliance system and for that it can turn any organization to a paperless organization which can completely archive its data electronically. Some of the main important RMS capabilities may include Generation of document from the electronic system, prioritization of requirements, the replacement of Word and Excel documents or other systems. The objective of such SAAS system is to be able to bring all stakeholders into the same system, requirements are not easily analysed or traced from customer need through to technical specification and test plan. Changes to requirements are not well controlled or communicated. As the organization’s projects continue to grow with more complexity, the requirements documents grow correspondingly to larger scale, the number of project participants and stakeholders grows, and the need for rigorous handling of the development and maintenance of requirements becomes more critical.

Most organizations use a Stage-Gate project management process and makes use of techniques such as Quality Function Deployment (QFD), Failure Modes & Effects Analysis (FMEA), Design for Manufacture and Assembly (DFMA) and Design Validation Planning & Reporting (DVP&R) in its product development procedure. Orcanos RMS system is capable to capture all that in one single repository and by that create a transparent flow of information between R&D, Quality and Manufacturing. Other uses of legacy system such Microsoft Office Project Server for Project Portfolio Management (PPM), Atlassian JIRA for bug tracking and Agile development, and Applications for Enterprise Resource Planning (ERP) or any thing else, for that Orcanos system is using the Zapier 1000+ apps integration tool which give the freedom to collect information from satellite systems and bring them all back into the same repository.


1. Core Functionality






Requirement Rating
1.1 The RMS represents Requirements as first-class entities in the system, each with a free-form text description.
1.2 The RMS allows Requirements to be grouped into Products and Projects.
1.3 The RMS maintains a unique identifier for each Requirement.
1.4 The RMS can represent Requirements of different types, e.g. Customer Requirements, Business/Legal Requirements, Design Requirements, Validation Requirements, Production Process/Test Requirements, Project Requirements.
1.5 The RMS captures derivation relationships between Requirements, e.g. Design Requirements are derived from Customer Requirements and Business Requirements, similarly Validation Requirements and Production Test Requirements are derived from Design Requirements.
1.6 The RMS stores priority or ranking metadata for each Requirement.
1.7 The RMS can manage Requirements for multiple Products with closely related or overlapping Requirements, e.g. product variants with different performance ratings or feature combinations.
1.8 The RMS can store validation criteria or performance targets for each Requirement where relevant.
1.9 The RMS supports iterative product development, where the Requirements for a Project to develop iteration N+1 of a Product are based on the Requirements from iteration N, with additions, modifications, and deletions.
1.10 The RMS allows Requirements to be transferred between different iterations of a Project.
1.11 The RMS stores a short name or title and a detailed description for each Requirement.
1.12 The RMS supports free-form text and other content (not part of a specific Requirement) associated with a Product or Project, e.g. for frontmatter, high-level description, explanatory text, etc.
1.13 The RMS supports figures (diagrams/images) in Requirements and other content.
1.14 The RMS supports tables in Requirements and other content.
1.15 The RMS provides comment or discussion features linked to each Requirement.
1.16 The RMS supports management of standardised sets of Requirements that are reused across Products and Projects, e.g. for a product type, target country of sale, or production facility or process.
1.17 The RMS supports incorporation of sets of Requirements by reference, e.g. sub-components, or interface and protocol specifications.
1.18 The RMS supports rich text formatting (e.g. bulleted/numbered lists, bold/italics, special characters) in Requirements and other content.
1.19 The RMS can store files as attachments to Requirements.
1.20 The RMS can represent Requirements in a hierarchical structure, e.g. for sub-components of a Product.
1.21 The RMS can manage Requirements for non-NPD projects, e.g. business improvement projects.
1.22 The RMS can capture use cases for a Product alongside the Customer Requirements.
1.23 The RMS can distinguish categories of Requirement e.g. Electrical/Mechanical/Firmware, Functional/Non-Functional, etc.
1.24 The RMS supports rendering mathematical formulas (e.g. LaTeX) in Requirements and other content.
1.25 The RMS supports rendering vector drawings (e.g. block diagrams, flow charts, UML) in Requirements and other content.
1.26 The RMS can capture design concepts for a Product alongside the Design Requirements.
1.27 The RMS can capture metadata about the source of a Requirement, e.g. customer, legislative, internal standards.
1.28 The RMS can be customised to add new metadata fields to Requirements for specific needs.
1.29 The RMS can capture product design documentation e.g. design decisions or component choices, and their relationships to the Requirements.


  1. Process Control

Requirement Rating
2.1 The RMS captures the history of all changes to individual Requirements, including before/after, timestamp, and the responsible person.
2.2 The RMS captures the history of a Project, including a snapshot of all Requirements at a point in time, either continuously or at designated project milestones.
2.3 The RMS flags Requirements changes (either in content or being added to/removed from a Project) for review of impact to downstream Requirements.
2.4 The RMS captures timestamp, responsible person and a justification when adding/removing Requirements from a Project.
2.5 The RMS implements a Change Request process, where a change to the Requirements can be proposed and reviewed before being officially accepted into the project.
2.6 The RMS implements a digital sign-off process for approving Requirements at Project gates (milestones).
2.7 The RMS implements an acceptance process for Requirements that are not ultimately satisfied by the Project, allowing an unmet Requirement to be waived or deferred to a later Project.
2.8 The RMS digital sign-off process (2.6) supports requiring multiple approvers to sign off.
2.9 The RMS supports the QFD process for deriving Design Requirements from Customer and Business Requirements.
2.10 The RMS supports the (D/P)FMEA process for deriving Validation and Production Test Requirements from Design Requirements.
2.11 The RMS can track the implementation status of a Requirement, e.g. to show progress during a Project, or to show which Requirements are already satisfied by a previous Project.
2.12 The RMS supports management of the Validation process by capturing test outcomes and evidence associated with a Validation Requirement.
  1. Analysis

Requirement Rating
3.1 The RMS supports Traceability Analysis of a Project to assess the coverage (necessity and sufficiency) of the Design Requirements against the Customer and Business Requirements, similarly the Validation and Production Test Requirements against the Design Requirements.
3.2 The RMS supports storing or linking to an analysis of each Requirement, e.g. cost/benefit, technical risk, competitor analysis, conflicts with other Requirements.
3.3 The RMS supports storing or linking to an analysis of each Project, e.g. market trends, competitor offerings, project justification and ROI.


  1. Roadmapping

Requirement Rating
4.1 The RMS supports Roadmaps of future Products and Projects.
4.2 The RMS captures future Product requirements for consideration in the current Project, e.g. for provisional hardware or architectural decisions to allow for anticipated future development.
4.3 The RMS supports Roadmaps of technology and research required to deliver future product requirements.
4.4 The RMS can capture ideas and feedback for future projects, e.g. from Lessons Learned, warranty and manufacturability data, direct customer feedback, or usage data from connected products.
4.5 The RMS can track whether a given idea has received a formal response and if it was ultimately incorporated into a Roadmap or Project.
4.6 The RMS supports Roadmaps of external influences e.g. market trends, external technology development, or legislative changes.
4.7 The RMS implements graphical presentation of Roadmaps in a time-based format, e.g. Gantt charts.
  1. Integration

Requirement Rating
5.1 The RMS exports data to well-formatted PDF or Microsoft Word documents.
5.2 The RMS exports data to Microsoft Excel or CSV.
5.3 The RMS PDF or Word export function can be customised for content, reading order, and style.
5.4 The RMS PDF or Word export function can be filtered, e.g. by Requirement type, category, or other metadata.
5.5 The RMS exports data to Atlassian JIRA.
5.6 The RMS exports data to ReqIF format.
5.7 The RMS imports data from Microsoft Excel or CSV.
5.8 The RMS has an external API e.g. REST or SOAP.
5.9 If web-based, the RMS uses consistent, human-readable URLs for a given Requirement, Product and Project.
5.10 The RMS imports data from Atlassian JIRA.
5.11 The RMS imports/exports data to/from Microsoft Office Project Server.
5.12 The RMS has an Extension or Plugin API.
5.13 The RMS has a marketplace or ecosystem of third-party plugins.
5.14 The RMS exports data to IFS Engineering for product documentation.
5.15 The RMS imports data from IFS CRM for customer feedback.
  1. User Interface

Requirement Rating
6.1 The RMS supports multiple simultaneous users.
6.2 The RMS is designed with usability as a primary focus, e.g. it is easy for new users to learn and navigate, tolerant of user errors, and efficient (in time and the number of clicks/page views) to perform common operations.
6.3 The RMS supports a customisable framework (templates, checklists, or examples) for guiding users in authoring complete and correct specifications.
6.4 The RMS provides assistance (e.g. wizards, online help) for users on how to use the software effectively.
6.5 The RMS supports multiple users working on the same Project simultaneously.
6.6 The RMS supports sending email notifications for significant events, e.g. changes to Requirements that may impact a given user, Projects awaiting a user’s review or sign-off, etc.
6.7 The RMS supports mind mapping for Requirements and Roadmaps.


  1. Security

Requirement Rating
7.1 The RMS stores all Organization data within Australian legal jurisdiction.
7.2 The RMS supports backup and rollback of Organization data with at least daily granularity.
7.3 The RMS has the option to store all Organization data on Organization owned IT infrastructure (on-premise).
7.4 The RMS can use Microsoft Active Directory / LDAP for user authentication.
7.5 The RMS supports role-based access control to individual Products and Projects.
7.6 The RMS provides a complete security audit history for access to and modification of Organization data.
7.7 The RMS supports download/export of all Organization data into a non-proprietary format.
7.8 The RMS supports access via an SSL or VPN connection over the public Internet.
7.9 The RMS supports low-cost or free/unlicensed access to authenticated users for read-only usage.


Submissions should include information about the typical implementation and recurring fees, IT infrastructure requirements, and system administration overhead of the solution for a company size.


Submissions should be evaluated by the organization based on his review of the submission, response to follow-up questions, publicly available information about the solution, and customer references. This is to feel the organization ability to address future issues and to understand its level of professional team. Orcanos comes with 13 years hands on practice and has many success projects and lessons learns, we are here not only to do what you ask but also to tell what you should not do.


Please address all correspondence regarding such RFS to:

Rami Azulay

VP Marketing and Sales

[email protected]