Requirements Package Before Development Starts: What Discovery Should Produce

By the Smartym Pro team | July 2026

Series: Discovery & documentation (3 parts):

1. Requirements package (this article) — what must be ready before estimate and code
2. Discovery process and D1–D11 artifacts — how you get there
3. AI for documentation drafts — prompts, workflow, consistency

---

Introduction

This article explains the document types that typically appear at the end of discovery — before development starts: what each contains, why it matters, and what it is for in conversations with your team. It is not a formal gate to "bring twelve PDFs." It is a shared vocabulary that reduces uncertainty between client and engineering.

The package is built in the discovery process from a brief and workshops. Here we focus on what you end up with and why those artifacts matter for phase-one scope and estimation.

---

Where the package sits in the lifecycle

Idea / brief
     ↓
Discovery (workshops)     ← part 2
     ↓
Requirements package (this article)
     ↓
Estimate and budget (D10)
     ↓
Sign-off → contract
     ↓
Development

Stage	Package	What you discuss
Before discovery	None	Ballpark only
After discovery	Documents below	Phase-one estimate
After sign-off	Signed scope	Sprint 0, delivery

---

Documents in the package: what, why, what for

Document	D#	Why it matters	What it is for
Project brief	D2	Without "why," teams price visible features only	Goals, users, MVP, metrics
SRS (by module)	D1, D4	One picture of functional scope	Phase scope, backlog, contract
Roles matrix	D4	Hidden admin/permission complexity	Security, cabinet estimates
User flows	D4	SRS prose does not replace the user path	UX gaps, testability
Wireframes	D11	Removes UI ambiguity	UI-heavy products without full design
Sitemap / IA	D1	Screen count and navigation	UI scope boundaries
Data model (lite)	D7	Backend is often harder than it looks	API, migrations, admin
Integrations	D6	Main schedule and risk driver	Realistic phase estimate
NFRs	D5	"Works" ≠ fast / secure	Architecture, compliance
MVP scope (MoSCoW)	D3	Without priorities, everything gets priced	Phase one, not full roadmap
Out of scope	D1	Stops scope creep	Phase boundary
Risks & assumptions	D8	Makes unknowns explicit	When estimates change
Roadmap / phasing	D9	Products evolve in iterations	Planning phases 2, 3…
Technical constraints	D7	Feasibility	Stack, legacy, hosting

---

SRS: structure and modules

The SRS is grouped by modules so requirements are easier to read and align — that is document structure, not a call for fixed price on every module across the full product roadmap.

Recommended SRS sections:

1. Introduction
2. Product overview
3. User roles
4. Functional requirements (by module)
5. Non-functional requirements
6. Integrations
7. Business rules
8. Data requirements
9. Security
10. Acceptance criteria
11. Constraints and assumptions
12. Out of scope

Example modules: Authentication → User Profile → Dashboard → Admin → Payments → Notifications → Reports → Integrations.

Per module: description, roles, requirements, business rules, edge cases, acceptance criteria, dependencies.

---

Roles matrix

Role	View	Create	Edit	Delete	Approve
Guest	Public pages	—	—	—	—
User	Own data	Requests	Own data	—	—
Manager	Team data	Yes	Team data	Limited	Yes
Admin	All data	Yes	Yes	Yes	Yes

Without this matrix, admin panel and permission work is almost always under-estimated.

---

User flows

Describe key journeys step by step, for example registration:

1. User opens registration page
2. Enters email and password
3. System validates input
4. Confirmation email sent
5. User confirms email
6. User completes profile
7. Access to dashboard

Minimum flows: registration/login, core business process, payment (if any), approval, admin, notifications, error/rejection paths.

---

Integrations

For each integration document:

• name and purpose
• direction (in / out / both)
• data exchanged
• authentication method
• API docs / sandbox link
• frequency, webhooks, retry
• client-side owner
• [UNKNOWN] where details are missing — do not invent

---

NFRs (summary)

Category	Examples
Performance	Page load, API latency, concurrent users
Availability	Uptime target, backup/DR
Security	HTTPS, RBAC, audit log, OWASP baseline
Compliance	GDPR, consent, retention — flag "legal review needed"
Scale	Users, RPS, file volume, data growth

Prioritize Must / Should / Could as in part 2.

---

Minimum vs full package

Minimum for a meaningful estimate:

1. Project brief
2. SRS (at least top MVP modules)
3. Roles and permissions
4. User flows
5. Wireframes or Figma (low-fi)
6. Integration list
7. MVP scope (MoSCoW)
8. Out of scope
9. NFR priorities
10. Estimate request format

For a tighter estimate add: detailed AC, data model, UI states, edge cases, legacy migration, deployment, SLA, documentation requirements.

---

Example folder layout

/project-docs
  01-project-brief.md
  02-srs.md
  03-user-roles-permissions.md
  04-user-flows.md
  05-sitemap.md
  06-data-model.md
  07-integrations.md
  08-non-functional-requirements.md
  09-acceptance-criteria.md
  10-mvp-scope.md
  11-out-of-scope.md
  12-estimation-request.md
/design
  figma-link.txt
  wireframes.pdf
/assets
  logo, brandbook, screenshots
/legal
  privacy-policy.md, terms.md

AI can speed up drafts and help keep artifacts consistent across files — see part 3.

---

Phased estimation, not fixed price for the whole product

These artifacts help everyone understand what is being discussed. The commercial number usually applies to phase one (MVP), not a multi-year roadmap priced as one lump sum.

Principle	Practice
MoSCoW Must	Boundary of the current phase for estimation
Iterations	After phase-one release — refined scope and a new estimate for phase two
Do not expect fixed for everything	Fixed price fits a signed phase when uncertainty is low
Otherwise	Range, T&M with a cap, or hybrid

See engagement models pros and cons. For discovery process and ballpark → fixed phase levels, see part 2.

Reasonable ask after the package: assumptions, open questions, phase-one estimate, options for later phases, risks, out of scope, recommended engagement model — not one number "for the entire SRS."

---

Next in the series

• Part 2 — discovery as a process: RACI, D1–D11, MVP/tenders, ballpark vs fixed phase
• Part 3 — AI: drafts, prompts, consistency and impact review

Need a discovery workshop or help turning a brief into this package? See our approach or tell us about your project.

---

General guidance on software delivery practice — not legal or procurement advice.