ERP SRS (Software Requirements Specification)

From ERPEDIA, the independent ERP knowledge base

The Software Requirements Specification (SRS) is a detailed document that defines what an ERP system must do and how it should perform. It translates business needs (captured in a BRD) into technical requirements for developers, configurators, and testers. A well‑written SRS is the foundation for successful ERP implementation.

Contents

1. What is an SRS?

The SRS is a formal document that specifies:

  • Functional requirements: What the system must do (e.g., "The system shall calculate VAT automatically based on customer location").
  • Non‑functional requirements: How the system performs (e.g., response time, security, availability).
  • Constraints: Technical, regulatory, or business limitations.
  • Interfaces: Integration with other systems.

It serves as a contract between stakeholders and the implementation team.

Purpose: Ensure all parties have a shared understanding of what will be built, and provide a basis for design, development, testing, and acceptance.

2. BRD vs SRS

AspectBRD (Business Requirements Document)SRS (Software Requirements Specification)
AudienceBusiness stakeholders, sponsorsTechnical team, developers, testers
FocusBusiness needs, processes, goalsSystem behavior, technical specifications
LanguageBusiness languageTechnical / functional language
ContentHigh‑level requirements, user storiesDetailed, measurable requirements

In ERP projects, the BRD is created first during discovery. The SRS is derived from the BRD and elaborated by the implementation team.

3. Typical SRS structure

1. Introduction
  1.1 Purpose
  1.2 Scope
  1.3 Definitions
2. Overall Description
  2.1 Product perspective
  2.2 User characteristics
  2.3 Assumptions & dependencies
3. Functional Requirements
  3.1 Module: Finance
  3.2 Module: Sales
  3.3 ...
4. Non‑functional Requirements
  4.1 Performance
  4.2 Security
  4.3 Usability
5. Interface Requirements
6. Constraints
7. Appendices

4. Functional requirements (by module)

Functional requirements describe specific system behaviors. They are often organised by ERP module:

ModuleExample functional requirement
FinanceThe system shall support multi‑currency transactions and automatically calculate exchange rate differences.
SalesThe system shall allow sales orders to be created with automatic pricing based on customer price lists.
InventoryThe system shall generate reorder suggestions when stock falls below minimum level.
HRThe system shall calculate end‑of‑service benefits according to UAE labour law.

Each requirement should be testable and use consistent language (e.g., "shall" indicates a mandatory requirement).

5. Non‑functional requirements

These specify quality attributes and constraints:

  • Performance Response time < 2 seconds for 95% of transactions.
  • Security Role‑based access control with audit logging.
  • Availability System uptime 99.5% during business hours.
  • Scalability Support 500 concurrent users.
  • Compliance Adhere to IFRS, VAT regulations, and local labour laws.

6. How to write a good SRS

  • Involve both business and IT: Collaborative workshops.
  • Be specific and measurable: Avoid vague terms like "user‑friendly".
  • Use consistent identifiers: e.g., REQ‑FIN‑001.
  • Prioritise: Must‑have, should‑have, nice‑to‑have (MoSCoW method).
  • Keep it alive: Update as requirements evolve (change control).
Tip: Use user stories for agile projects, but ensure acceptance criteria are detailed enough for testing.

7. Validation & sign‑off

The SRS must be reviewed and approved by all stakeholders before development begins. Validation steps:

  • Peer review: Technical team checks feasibility.
  • Business walkthrough: Confirm requirements match BRD.
  • Formal sign‑off: Steering committee approves baseline.

Changes after sign‑off go through change control.

8. Common pitfalls

  • Too vague: "The system should be fast" → not testable.
  • Missing non‑functional requirements: Leads to performance or security issues.
  • Gold‑plating: Including unnecessary features.
  • No traceability: Can't link requirements to design or tests.

Key Takeaways

  • SRS translates business needs (BRD) into detailed technical requirements.
  • Includes functional (what) and non‑functional (how well) requirements.
  • Well‑structured SRS (by module) improves clarity.
  • Requirements must be testable, measurable, and approved.
  • A good SRS reduces misunderstandings and rework during implementation.

Who writes the SRS? Typically a business analyst or functional consultant, in collaboration with business users and technical leads.

How detailed should an SRS be? Detailed enough to design, build, and test. For ERP, this often includes screen mockups, field definitions, and business rules.

Can we use agile without a full SRS? Yes, but you still need a product backlog with detailed user stories and acceptance criteria – the agile equivalent of an SRS.

Continue Reading in ERPEDIA

ERPEDIA is maintained by Professionals Lobby as an independent ERP knowledge initiative focused on reducing ERP implementation risk in the UAE and GCC.
For structured, vendor‑neutral ERP advisory → Speak with an independent ERP advisor.