What is your approach to documenting non-functional requirements on a Salesforce project?
Suggested answer
1. Ask about them explicitly, because stakeholders almost never volunteer them. Nobody says “the page should load in under three seconds” until it does not.
2. Cover the categories systematically: performance and volume, security and access, availability, data retention and archiving, auditability, accessibility, localisation, and mobile usage.
3. Make each one measurable. “The system must be secure” is unusable; “only users with the Regional Manager permission set may view records outside their own territory” is testable.
4. Attach expected volumes to anything that scales — record counts, concurrent users, integration message rates — because Salesforce behaviour and platform limits are volume-sensitive and designs that work with 1,000 records can fail at 10 million.
5. Capture them early. Non-functional requirements shape the data model, the sharing architecture, and the integration pattern, and all three are expensive to change once the build has started.
Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.
Community comments (0)
No comments yet.
Sign in or create a free account to add a comment. Comments are moderated before they appear.