Requirements

User Guide

SaaSMap

1. Introduction

Requirements are a key feature in SaaSMap and form the foundation for capturing, organizing, and managing project needs effectively. The platform provides multiple ways to create requirements, giving users the flexibility to choose the approach that best fits their process and project stage. They are the foundation of your testing work in SaaSMap. Depending on how your project is configured, they appear as User Stories or RTM (Requirements Traceability Matrix) items. Each requirement captures what the business needs—title, description, acceptance criteria (User Story projects), status, fit/gap classification, and links to software pillars and epics.

This guide explains how to create, assign, review, and manage requirements in the Backlog.

Requirements can be created manually one at a time, AI-generated from a customer business discussion transcript, AI-generated from a Statement of Work (SOW), or imported from a pre-created list.

User Story vs RTM projects

  • Set at project creation: Requirement Form = User Story or RTM.
  • Both are managed as requirements in the Backlog; Acceptance Criteria appears for User Story projects.
  • Requirement IDs and workflow statuses apply to both types.

2. Where Requirements Live

  1. Open Home and select your project.
  2. Use the project workspace tabs: Backlog (master list).
  3.  
  •  
  • Optional related tabs: Plan, Sprint, Traceability, Test Cases, Test Cycles, Defects.

The Backlog tab lists all requirements for the project. The Phase tab organizes delivery by phase: you import requirements from the backlog into a phase and track build and review progress separately from the master backlog status.

3. Key Fields and Columns

Common columns in the Backlog list (visibility can be toggled via Columns):

ColumnPurpose
REQUIREMENT IDUnique identifier for the item.
TITLEShort name.
DESCRIPTIONDetailed requirement text (rich text).
ACCEPTANCE CRITERIAUser Story projects only—conditions of satisfaction.
STATUSWorkflow: Draft, Pending Review, Verified, Rejected, On Hold, Archived, Delivered.
FIT/GAPFit = in scope; Gap = gap/out-of-box need.
SOLUTION TYPEClassification from your solution type list.
HIERARCHYParent or Child; child items link to a parent requirement.
PILLARSoftware platform (main software).
EPICModule or epic within the pillar.
CLIENT REVIEWERPerson assigned for review.
TAGS, PERSONA, NOTESSupporting metadata and notes.
SOURCEHow created: Manual, Import, Transcript, SOW, etc.
INFO, CREATED ON, CREATED BYRequirement meta data

4. Creating Requirements

Click Add Requirements on the Backlog toolbar (when project is not in Draft mode).

The screen below comes up

Creation methods

MethodSummary
Manual CreationEnter metadata and description; Source is typically Manual.
Create from TranscriptUpload or paste a meeting/workshop transcript; AI analyzes and proposes requirements for review before save.
ImportUpload Excel; map columns to fields; review imported rows (Source = Import).
Create from SOWUpload Statement of Work; pre-analysis checks consistency; AI generates user stories or RTM for review (often used for Parent requirements).

Manual creation highlights

  • Required fields typically include Pillar, Module/Epic, Title, and Description.
  • Set Hierarchy to Parent or Child; for Child, select a parent requirement.
  • Set Fit/Gap, Solution Type, Status (defaulted to Draft), and optional Client Reviewer.
  •  

Pillar

The high-level software area or product suite the requirement belongs to (shown as Pillar on the Backlog and generated RTM rows—for example, HCM, SCM etc.). It comes from the project’s configured platforms and scopes which epics/modules are valid for that requirement. A project can have multiple pillars; each RTM row uses exactly one pillar, so work is grouped by major application area.

Module

The functional area or epic within a pillar where the requirement is implemented (labelled Module in RTM export and often Epic/Module). It must be an epic configured under that pillar in the project—for example, Procurement under SCM or Core HR under HCM. Module ties each RTM to a specific backlog slice.

Hierarchy

Hierarchy classifies how a Backlog requirement relates to other requirements in the same project. It can be Blank (standalone, not in a parent/child structure), Parent (a container or umbrella requirement that can have children), or Child (a sub-requirement linked to a specific Parent via the parent requirement field). Use Parent for broad capabilities or work packages; use Child for detailed items that roll up to that parent. Requirements created from SOW are typically set to Parent and hierarchy is locked for those records.

Fit/Gap

Fit/Gap is a simple classification on each Backlog requirement: Fit means the need can be met with standard product capability (configuration, setup, or expected out-of-the-box behavior), and Gap means it needs something beyond that—customization, integration work, a policy exception, or another non-standard solution.

  •  

5. Create from Transcript

  1. By default, the granularity of requirements is set to ‘High Detail’ , change it to ‘Balanced’, if you want coarse grain level requirements generated instead of fine grain ones. If the requirements transcripts are related to the Oracle software, then keep the prompt field set to ‘Oracle’ else set it to ‘Non-Oracle’. Enter any tags that you want to add to the generated requirements.
  2. Configure project software (Pillar) and epics.
  3. Upload transcript
  4.  
  5. Application supports TXT, PDF or DOCX file types. User can also use Speech to Text option. Below is a screenshot with all the values setup ready to analyse requirements.
  6.  
  •  
  • Click on ‘Analyze Transcript’
  •  
  • As part of Step 1 the model reviews the transcript and groups it into topics mapped to the Project epics and Unrelated items (with summaries and supporting quotes). The application then moves to Step 2, where you review, select, or adjust those topics before generating full requirements. It does not create backlog records yet; it only structures and classifies the transcript for the generation step that follows
  •  
  •  
  • Once the analysis is complete, user can view the topics mapped to the Project epics, and Unrelated items. Users can also select or deselect topics of interest from the generated output.
  •  
  •  
  • The Analysis also generates a list of Unrelated Topics – note that requirements cannot be generated for these topics. Users can download this list as an Excel file.
  •  
  •  
  • After review, click on the ‘Generate’ button to generate the requirements
  •  
  •  
  • The application now generates the requirements.
  •  
  •  
  • After generation, users can view the generated RTM’s as shown below.
  •  
  •  
  • Save the details to the Backlog.
  •  

The buttons at the top of the generated requirements allow you to

  1. Go back to application Home screen
  2. Save the generated requirements to the Backlog
  3. Download the generated requirements as a Excel file
  4. Re Start/New Analysis

The generated requirements have the following attributes

  1. ID
  2. Title
  3. Description
  4. Pillar
  5. Module
  6. Persona
  7. Notes
  8. Source
  9. Solution Type

Persona
The primary business role that owns or performs the capability described by the RTM row (for example, “Payroll Specialist” or “AP Clerk”). It is one role per requirement—so ownership and testing context stays clear.

Notes
Supporting detail tied to the source material: for transcript-based RTMs, a short excerpt or paraphrase from the conversation that backs the requirement; for SOW-based RTMs, contractual references such as section, table, page, and interface/conversion IDs. Use Notes for traceability and audit context without repeating the full Description.

Source
Where the requirement came from — Manual or Transcript. It helps reviewers jump back to the exact moment or person in the recording or transcript that led to the RTM.

Stored valueTypical meaning
ManualCreated via Manual Creation (user entered the requirement directly).
TranscriptCreated via Create from Transcript (AI from meeting/text).
SOWCreated via Create from SOW (AI from statement of work).
ImportCreated via Import (spreadsheet/upload).

Solution Type
A single category from your tenant’s configured list (for example, Functional Setup, Workflow, Configuration, Conversion) that describes the nature of the work—not the epic/module. Each RTM row must pick exactly one allowed value so reporting and planning can group requirements by delivery type. Some examples are Configuration, Enhancement, Integration, Migration etc.

All the saved requirements are visible under the Backlog tab of the Project

6. Create from SOW

Requirements can also be generated from a Statement of Work (SOW) document. Such generated requirement are set as ‘Parent’ requirements. So the ‘Hierarchy’ value in such requirements is set to ‘Parent’. One or more Child requirements can be linked to a Parent requirement.

Selecting the ‘Create from SOW’ option, brings up the screen below

User can change the ‘Detail Level’ depending on the level of granularity needed in the generated requirements. Continue to use the default ‘Prompt’ value of Oracle is you are working on Oracle based projects. By default, all the Pillars and Epics in the Project will be selected and will be used to check the SOW content during the Requirements Analysis.

After uploading the SOW file, click on the “Analyze SOW” button to start the analysis.

The application does a Pre-Analysis check first.

Pre-Analysis in ‘Create from SOW’ runs right after you submit the SOW and settings, and before the main AI topic analysis starts. It is a quick validation step so to ensure analysis is not run on mismatched inputs.

The check compares three things: the prompt mode you chose (Oracle or Non-Oracle), what your project software/epics (pillars and modules) imply as the primary platform, and what the SOW document itself is mainly about. It also summarizes scope—pillars/modules, detail level, RTM vs User Story, and approximate SOW size.

If all three align, the flow continues automatically into full SOW analysis. If they do not, generation is blocked and user must change the prompt selection, adjust pillars/modules, or upload a SOW that matches your intended platform—avoiding poor or inconsistent requirements from the wrong template.

If Pre Analysis check succeeds, then the application starts the Analysis of the SOW

Once the Analysis completes, it generates a list of matching Project Topics and any Unrelated areas. This is similar to the output we have seen earlier in “Create from Transcript”.

Click on the Generate button as shown below to start the requirements Generation.

The application then completes the requirements generation

Once done, you can view, save or download the generated requirements. The output is similar to what we get in “Create from Transcript” except that all the generated requirements are set as ‘Parent’ requirements. This is if they are auto generated from a SOW.

The application also displays the time savings – using the manual mode vs. the automatic requirements generation. In most cases there is a significant amount of time savings and improved accuracy.

SOW-sourced items default Fit/Gap to Fit.

7.Import

This option to create requirements is by uploading a Excel sheet with pre-filled requirements. This is available for both RTM’s and User Stories.

Click on the ‘Download Sample File’ icon (shown below) to download a sample file. This can be used to fill out the requirements and then uploaded into the application.

After successful import of requirements, you will find the new requirements created under the Backlog tab

 

8.      Client reviewer and approval

  1. Assign Client Reviewer on a row or via bulk update.
  2.  
  •  
  • Assign for Approval (toolbar) moves Draft items into client review: pick a Client Approver, status becomes Pending Review.
  •  
  • Client Approver / Client Reviewer roles use Verify/Reject or Approve/Reject Selected on pending items.
  •  

9.      Bulk update

Select one or more rows, then use the bulk update bar to change Status, Fit/Gap, Solution Type, Tags, Hierarchy, Pillar & Epic and Client Reviewer fields.

10. Review Workflow and Backlog Lifecycle

Status values

Draft, Pending Review, Verified, Rejected, On Hold, Archived, Delivered.

Typical approval flow

  1. Author creates or imports requirement in Draft.
  2. Assign for Approval: select Client Approver; status becomes Pending Review.
  3. Client reviewer verifies or rejects (rejection requires a reason).
  4. Verified items may be imported into a Phase.
  5. Rejected items can return to Draft or Pending Review for rework.
  6.  

11. Views

  • List View, Grid View, and Kanban View (Kanban columns align with status values).
  • Full Screen for focused list work.
  •  
  • Example of a Kanban View
  •