Introduction #
How comprehensive a requirements document ends up being has less to do with experience than you’d think. People who’ve written dozens of PRDs still miss things. The difference usually comes down to whether you have a system that forces you to cover every point, rather than relying on memory alone.
This checklist grew out of accumulated lessons. Getting caught in review meetings, discovering gaps after the评审, forgetting data tracking until after launch. Every mistake added another item to the list. Now I run through it before I start writing, and again after I’m done.
If you’re dealing with similar frustrations, hope this helps.
Basic Elements #
Start by filling in the document’s basic information.
Document Format: Word, Markdown, or annotations directly on high-fidelity prototypes—decide upfront, keep the team aligned.
Version Naming: Major releases bump the first digit (e.g., 1.0 → 2.0), minor iterations bump the middle digit (e.g., 1.1 → 1.2), and bug fixes bump the last digit (e.g., 1.1 → 1.1.1). Your team probably has a standard; just make sure it’s written down so everyone’s on the same page.
Requirements Directory: What does this release cover? List it out by module. Like a book’s table of contents—it gives readers a clear picture of the overall structure and lets them find specific sections quickly.
Update Log: Who changed what and when. Every update gets recorded. This is how the team knows which version everyone’s working from.
Global Position: Where does this feature sit within the product’s bigger picture? What are its relationships with other modules? Sometimes a requirement looks fine in isolation but conflicts with existing logic when viewed holistically.
Business Description #
This section gets skipped too often. Many junior PMs jump straight into feature details, only to have developers build something that doesn’t match what was actually intended.
Write a concise paragraph explaining: what this feature is, who it serves, why it’s needed now, and how it might evolve. If the feature involves cross-role collaboration (e.g., operations needs to configure something in the backend), spell out each party’s responsibilities. When developers understand the business goal, they can make many decisions independently—without ping-ponging back to the product team.
Business flowcharts are essential. A picture saves a thousand words and significantly reduces the chance of requirements being misunderstood. One extra diagram can replace pages of textual description.
Standards and Global Specifications #
Before launching a new project, teams typically establish a set of design standards. Future iterations then simply reference these standards instead of redefining everything from scratch.
These standards usually cover:
- State names and transitions: What states exist, how do they transition, how are edge cases handled
- Data dictionary: Field definitions, enumerated values, business rules
- Global shared components: Modal styles, button states, notifications, loading states, error messages, animations—these globally consistent interaction patterns are defined once
With standards in place, requirements documents become shorter—just reference “per standard” without repeating the same descriptions across every page.
Requirements Body #
This is the document’s core. The common format is interleaved screenshots and text: screenshot on one side, written explanation on the other. If a screenshot contains many elements, use wireframe markers with numbered callouts first, then explain each element one by one.
Page Description #
Start by clarifying what this page is, which business it belongs to, and where it sits in the user journey. Clear context is what lets readers correctly interpret all the details that follow.
Preconditions #
This is where things get dropped most often. What must be true before this page displays?
- Permissions: Does the user need to be logged in? Are there feature-level or data-level permissions?
- Data sources: Is data configured in the backend or returned via API? If it’s backend-configured, does that backend module already exist?
- Data loading: Does the backend push or does the frontend pull? What’s the loading strategy—preload, lazy load, real-time? How many items load at once and what triggers the load? What do loading, success, and error states look like?
Leave these undefined, and developers have to guess. Wrong guesses mean rework for the whole team.
Display Issues #
For what’s shown on the page, clarify:
- Data scope: Are there time ranges or permission limits? Which database table and fields are being queried?
- Empty states: What displays when there’s no data—blank space or a guidance message?
- Field display: What happens if content exceeds length limits? How are special characters handled—filtered or escaped? What about measurement units?
- Element explanations: Every element on the page needs explanation. For dense list views, use callout lines or corner markers with numbered annotations to identify each element in the screenshot, then explain them individually.
Sorting and Caching #
What’s the default sort order? What actions trigger a sort change?
For caching: what data gets cached? When is the cache cleared? When does it refresh?
Interaction Design #
Pre-interaction: Where does the user trigger an action? How—tap, swipe, long press? How large is the hit area and is it prone to accidental touches? What does the focused state look like? The disabled state?
Validation rules: Real-time validation or on-submit? What does a validation failure message look like? Is there guidance to help users correct errors?
Cascading logic: Do options trigger dependent selections? Selecting A reveals B, but selecting C doesn’t—these conditions need to be enumerated explicitly.
Post-interaction: What happens after an action succeeds or fails? Is there a loading indicator or countdown? Where does the user land—previous page, home, or does a record get created while staying on the current page? For example, an abandoned payment usually creates an “unpaid order” entry rather than simply returning to the cart.
Postconditions #
After an operation completes, where does the data flow?
- Database writes: For creates, updates, and deletes—which tables and fields are affected? Soft delete or hard delete? Is an operation log needed?
- Data processing: Real-time or asynchronous? Any time sensitivity? What algorithm is involved and how are results derived? How are errors reported?
- Post-action pages: What does the user see after the operation completes? If they continue from there, do they need to re-satisfy the preconditions?
Common Features #
Search, filter, and sort are high-frequency features and the easiest to leave underspecified.
Search: Local or cloud-based? Exact match or fuzzy? Are there scope limits?
Filter: Compound or single-select? What are the default and available filter options?
Sort: What’s the default sort order? Is personalized ranking supported?
Other Considerations #
These are easy to overlook but become major headaches post-launch:
Version constraints: Minimum version requirements? Forced updates needed? Backward compatibility with legacy data?
Onboarding: Are there launch screens or feature tutorials needed?
Data tracking: Which events need to be tracked? This must be thought through during the PRD phase—can’t add it post-launch.
Push notifications: Content, timing, delivery channel (vendor SDK vs. self-built).
Native device capabilities: Camera, gyroscope, contacts, calendar—any native APIs being called.
External redirects: To other apps or web pages? Is there a cache-clearing mechanism?
Dark mode: Is a dark mode adaptation needed?
Future products: If desktop widgets, browser extensions, or other derivative products are on the roadmap, does the current technical approach leave room for them?