Requirements specify WHAT process the software must execute to create value for the buyer and WHAT outputs the process must deliver. Except in relatively rare cases, e.g. interfacing with another system, requirements do not prescribe HOW a requirement should be satisfied. HOW a requirement is satisfied is up to the Software Publisher and is handled during the implementation.

When you RATE your software product against a requirement, you record how well your product meets that requirement. Although you rate requirements through an RFP, your ratings are stored in the Navigator library. If you participate in another Wayferry RFP you don't need to rate those requirements again!

Requirement types defined

Wayferry’s requirements are organized hierarchically, and the type of requirement is determined by its position in the hierarchy.

• Root requirement. The topmost requirement in a hierarchy, e.g., “Customers”, “Sales”, “Financials”, “Reports”. Each root requirement covers a different aspect of the software being evaluated. Root requirements do not have ancestors or parents because they are at the top of the hierarchy.
• Parent requirement. A requirement that has child requirements below it. You don’t need to rate your product against parent requirements. A parent requirement is a child of the requirement above it in the hierarchy and a parent of those requirements below it.
• Leaf requirement. The lowest level of requirement, the last one on a branch of the hierarchy (hence the name “leaf”.) You only need to rate your product against leaf requirements.

Unless it is a root requirement, a requirement is a descendant of the requirement above it, and an ancestor of all the requirements below it. The immediate requirement above a requirement is its parent, and the immediate descents are its child requirements.

Note

• Requirements are organized in a hierarchy. Any requirement must be read and understood in the context of its parent, all the way up to the root requirement. The requirement rating form is shown below.
• RFP responders only need to rate leaf requirements. For example, if the parent requirement was “The system should be able to scan documents” and the child leaf requirements were “Scan to pdf”, “Scan to jpg” and “Scan to png” when you have rated your software against those 3 leaf requirements, the fit score is automatically calculated for the parent (and the calculation rolls all the way up to the overall fit score of the evaluation.)

• The only time you respond to a parent requirement is when that functionality is unsupported by your software. See "Unsupported functionality" below.

1) Name

This is a short name for a requirement.

2) Requirement ID

The Req ID always starts with an R and has 7 digits. It uniquely identifies that requirement across all evaluations. You can search on the requirement ID to find a specific requirement.