Product Requirements Document (Agile)

Many Agile projects don't produce a software requirements specification in the sense of a document that lists a bunch of "shall" statements along with some assumptions and dependencies, like what is described in ISO/IEC/IEEE 29148.

Often, Agile projects will capture 'requirements' in the form of use cases, user stories, scenarios, or other user-centric forms. These requirements can be compiled into one document for regulatory or compliance purposes.

There are several "best practices" which should help you to become more agile with your requirements modeling efforts:

1. Stakeholders actively participate

2. Adopt inclusive models

3. Take a breadth-first approach

4. Model storm details just in time (JIT)

5. Prefer executable specifications over static documentation

6. Your goal is to implement requirements, not document them

7. Create platform independent requirements to a point

8. Smaller is better

9. Question traceability

10. Explain the techniques

11. Adopt stakeholder terminology

12. Keep it fun

13. Obtain management support

14. Turn stakeholders into developers

15. Treat requirements like a prioritized stack

1. Define project specifics

High-level direction at the top of the page:

• Participants: Who is involved? Include the product owner, team, stakeholders

• Status: What's the current state of the program? On target, at risk, delayed, deferred, etc.

• Target release: When is it projected to ship?

2. Team goals and business objectives

Get straight to the point. Inform, but don't bore.

3. Background and strategic fit

Why are we doing this? How does this fit into the overall company objectives?

4. Assumptions

List the technical, business, or user assumptions you might be making.

5. User Stories

List or link to the user stories involved. Also link to customer interviews, and include screenshots of what you've seen. Provide enough detail to make a complete story, and include success metrics.

6. User interaction and design

After the team fleshes out the solution for each user story, link design explorations and wireframes to the page.

7. Questions

As the team understands the problems to solve, they often have questions. Create a table of "things we need to decide or research" to track these items.

8. What we're not doing

Keep the team focused on the work at hand by clearly calling out what you're not doing. Flag things that are out of scope at the moment, but might be considered at a later time.

More information and an example atlassian