Skip to content

📚 Docs | Functional Requirements #11

@sreffler

Description

@sreffler

To Do

  • 1. Write a rough draft. Include both user stories and detailed behaviors for each and every feature in the app. Add visuals like flowcharts, screenshots, iconography to add clarity. Use the attached template to get started.

  • 2. Peer review. Work with your teammates and mentors to make sure the spec is clear enough for the developers and other team members to work on the project by themselves (in case you're unavailable). You need 1 strategy member and 1 programmer to help. A mentor would be cool too.

    • a. Read through it with another strategy member and identify parts of the design that are unclear or either of you are uncertain about.
    • b. Ask a programmer to read through the draft as if they were going to build it based on the technical spec alone. Have them comment, highlight, explain any concerns they identified.
  • 3. Write a "final" draft. Update based on the feedback from your peer review. Don't worry if it's not perfect. It will likely still need updates during the dev process as bugs, issues, and other technical limitations are uncovered.

What are Functional Requirement Documents (FRD)?

Functional requirements are crucial in translating user expectations into tangible, functional experiences. They spell out exactly what the product needs to do, feature by feature, giving developers clear direction and instructions to bring the product to life. A well-defined FRD will include a clear and detailed description of each feature's intended behavior, the conditions under which this behavior is expected, and the specific inputs and outputs involved.
(Source)

For example, a social app's FRD will give a detailed explanation of the user registration process, such as the necessary form fields and any age restrictions. It will also list any error messages or success messages the end-user should see, depending on different use cases.
(Source)

Some of the most common specs included in an FRD are:

  • If/then behaviors
  • Data handling logic
  • System workflows
  • Administrative functions
  • Performance requirements
  • Details of operations conducted for every screen
  • User interface interactions
  • External integrations (databases, libraries, supported device types, etc.)
    (Source)

In a nutshell, the FRD is what’s given to developers so they know what to build, what’s given to testers so they know what to test, and what’s given to stakeholders so they know exactly what’s being created.
(Source)

Key points to remember when creating a UX to dev FRD:

  • Clarity and Conciseness: Use simple language and avoid ambiguity in requirements.
  • Testable Acceptance Criteria: Define clear criteria to verify if each requirement is met.
  • Prioritization: Indicate which features are essential for the initial launch and which can be added later.
  • Visual Aids: Utilize wireframes, mockups, and user flows to visually communicate design concepts.

Figma's Dev Mode, makes the transition from design to development, and the collaboration of both designers and developers faster and more seamless, especially when working with prototypes. Dev mode includes the option for adding measurements and annotations which can clarify interactions, edge cases, and intent. However, it likely won't outline every feature nor edge case so creating a separate document can still be helpful for the dev process.

FRD Example

Section 1: User Authentication and Profile Management

  • Requirement 1.1: Users must be able to create an account by providing their email address, password, and optional personal details (name, shipping address).

    • Acceptance Criteria:
      • A new user can successfully register with a valid email and password.
      • The system sends a confirmation email to verify the new account.
      • Users can update their personal details in the "My Account" section.
  • Requirement 1.2: Users must be able to log in using their email address and password.

Note: This is a simplified example. A comprehensive FRD would include detailed specifications for user interactions, data validation rules, accessibility considerations, and potential edge cases.

Resources

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    Projects

    Status

    Todo

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions