Account

One or more accounts are created for each customer. An account contains one or more projects. Each account can have different themes (the “look and feel” of ReqMan), custom help texts and labels shown in the user interface and the default culture used that dictates localized settings, such as date and time formats.

Project

A project contains all of the ReqMan modules required to manage specifications, users, reports, tenders and so forth for the specific project.

Requirement

A requirement is the most central entity on the ReqMan platform. The content of a requirement depends on the context and industry, but it is typically used to describe an attribute to be possessed by a product, a function to be performed by a product, a performance standard or a component of an existing system. In ReqMan, there are many standard attributes that can be specified and logged for each requirement such as unique references, names, details, stakeholders, notes, attachments and change histories.

Specification

A specification is a container used to organize requirements. A specification contains individually configured table of contents, custom fields, attachment categories and note categories. Specifications are important because they contain most of the user configurations, and when you want to work with larger groups of requirements throughout the system, you typically work within the context of a specification.

Table of contents

The table of contents (TOC) is a hierarchal tree structure that can be defined by users with admin privileges for the particular specification.

You can create sections in the tree throughout the project. You can also change the order of the individual sections by moving them up and down in the hierarchy. If you delete a section and there are requirements assigned to the section or that are below the section, the effected requirements are moved to the parent section.

Each section can also contain a text introduction. This text introduction is usually included before the requirements in generate reports from the Reporting module.

Tip: Although the table of contents can be changed throughout the project, it is recommended that you create and structure as much of the table of contents as possible before you start to enter requirements.

Custom field

Custom fields are attributes that can be used to store meta-data and they can be configured by the user to be available either for specifications or requirements.

There are two different types of custom fields: free text and lists. The free text entry can be validated by using regular expressions that require the user to type in a specific kind of entry, such as integers, currencies, or other specific formats. The list definitions contain predefined selections such as Priority: High, Medium and Low. Optionally, a list selection can allow multiple selections.

Custom fields that are used for requirements are configured for each specification and are available for all requirements that belong to that specification. Typically, custom fields at this level are used to store information about priority, implementation cost, reference ID, process state and so forth.

Custom fields that are used for specifications are configured at the project level and are available for specifications that are created within the project. Typically, custom fields at this level are used to store information about approval status, project manager and other high level information.

Note category

Note categories can be configured by the user for each specification and they are used to categorize notes that are entered for individual requirements. Notes can be viewed as “Post-It” notes and the categories are used to order the notes. Typical note categories could be internal notes, technical notes, tenders notes, and so forth.

There are two system note categories that can not be changed: default and end-user dialogue. The default category is used for notes where no category is specified. The end-user dialogue is used to communicate with external stakeholders.

Notes created in the end-user dialogue category are visible to users that are assigned as stakeholders for individual requirements and the stakeholder responses are also saved within this category.

Tip: When sending out requirements, using the Invitation To Tender module notes can be included based on the category.

Attachment category

Attachment categories can be configured by the user for each specification and are used to categorize files that are attached to individual requirements. Typical attachment categories could be Internal files, Mock-ups, Test instructions, and so forth.

Tip: When sending out requirements, using the Invitation To Tender module attachments can be included based on the category.