All features
Feature library
Real features from SaaS products built with CraftHQ.

Sign-in

Users & access

Customers & imports

Files

Review & records

Platform

Feature breakdown · built with CraftHQ

FilesWorkflow

Requesting documents from customers (checklist)

Whole-team time at this build's pace

Estimated ~28 h

2 people incl. the product owner, requirements to merge

Estimate at this build's pace, not a measurement of this feature

Send a customer a precise, tracked list of the documents and answers you need, and proceed only when everything required is in and verified.

Size: ~34 FP · Proxy estimate; an in-house count, not independently checked. Range 26 to 40. · How we counted 34 FP

How long a feature this size usually takes

Whole-team time — this build vs a typical team

~34 FP · FP × 6.8 to 9.4 h (ISBSG 2023)

Whole-team time at this build's pace2 people incl. the product owner, requirements to merge
~28 h21 to 32 h

Estimate at this build's pace, not a measurement of this feature

A typical team, whole lifecycleRequirements to release · middle half of 512 comparable projects (Java, Agile), ISBSG 2023
~231 to 320 habout 6–8 person-weeksmedian ~269 h
grey band = a typical team, middle halfhatched = our whole-team estimate

Both figures are whole-team time over the whole lifecycle, so they compare like for like. Ours is this build's pace — about 0.8 hours per function point across the whole build (two people, including the product owner, with requirements and review time). The industry range is an ISBSG project-level figure applied to one feature, so it is indicative.

Workflow

How it moved through the workflow

Select a stage. The build shipped, so every stage is complete; a person approved the merge.

Request

Replace chasing documents by email with an explicit, tracked list of what is needed, and gate the next step on it being in and verified.

Questions

Three decisions went to the business before building: whether the list is a stage or a page, how a conditional sub-question is shown, and whether the free-text answer is mandatory.

Approved

The product owner signs off the breakdown by moving the story into the approved state, and the build runs against that reference.

Definition of ready

The questions are answered.
The acceptance criteria are testable.
The size is estimated.
The scope is checked for splitting.
The product owner has signed off.

Building

CraftHQ's build agents write the code and the tests together, run as a loop; a failing check halts the work until it passes.

Checks

Three checks run on every pull request: one on the product owner's machine as CraftHQ builds, one on the engineer's machine before review, and a code-quality scan in CI. Merging is gated by the CI check passing and a person's approval, enforced by branch protection.

Review

An engineer reviews the pull request and merges it.

Merged

The pull request is merged to main after a person approves it. Nothing merges without that approval.

Definition of done

Every acceptance criterion is checked; where a scenario has a dedicated test it is cited, and where it was verified by review that is stated.
The three checks are green.
A person approved the merge.

Breakdown

The feature breakdown

Business first, then the engineering view. Tab through it.

Overview

The gap it closes

Chasing documents by email loses track of what was asked for and what is still outstanding, and lets work start before everything needed is in.

Who uses it

Staff build and verify the request. Customers supply the documents and answers in their own workspace.

User story

As a staff member, I want to send a customer a precise, tracked list of the documents and answers I need so that I can proceed only when everything required is in and verified.

Examples

Example 1

A staff member builds a request of items, each either a document to upload or a question to answer. The customer supplies them in their own workspace, and the staff member verifies each one.

Example 2

Required items are supplied but not yet verified. The next step stays closed until a staff member verifies them, so work never moves on incomplete.

Dependencies & risks

Depends on

The file upload and the customer workspace, and a reminder job for outstanding items.

Risk & mitigation

A request could stall if a customer forgets an item. Reduced by a reminder path and a clear tracker of what is outstanding, supplied and verified.

How it works

Simplified diagrams of the parts involved, the steps of one request, and where it runs.

Architecture

People
Staff memberbuilds and verifies
Customersupplies items
Your app
Request trackeritems and verify state
Customer workspaceupload or answer
Verify gateopens the next step
Reminder jobchases outstanding items
  • 1build and verify
  • 2send the request
  • 3supply items
  • 4staff verify or reject each item; verified items open the next step
  • 5reminder sent through the delivery service
Simplified.

Sequence

Staff browserbuilds the request
Customer browsersupplies items
App servertracker and gate
Databaserequest items
  • 1build and send the request
  • 2store the items
  • 3supply a document or an answer
  • 4record the item as supplied
  • 5verify the required items
  • 6the next step opens
Simplified.

Infrastructure

Client (untrusted)
Web apptracker and workspace
Your app
App serverrequest and verify gate; authenticates, pins the tenant
Background workersends reminders
Databaseper-tenant isolation, request items
File storageuploaded documents
  • 1build, supply, verify
  • 2read and write request items
  • 3store uploaded documents
  • 4find outstanding items to remind
Simplified.

Acceptance criteria

Each scenario is written as a Gherkin spec. The Engineering tab shows the test that covers each one, or notes where it was verified by review.

@files @requests

Feature: Requesting documents from customers

  As a staff member

  I want to send a customer a precise, tracked list of what I need

  So that I can proceed only when everything required is in and verified



  No more chasing documents by email. The request is an explicit, tracked list, and the next step is gated on it.



  Background:

    Given a staff member is preparing a request for a customer



  Rule: A request is a list of items, each a document to upload or a question to answer



    Scenario: Build a request of documents and questions

      Given a staff member adds request items

      When each item is set to "upload a document" or "provide an answer"

      Then the request lists both kinds of item, each tracked on its own



  Rule: Required items are verified before the next step opens



    Scenario: The next step is gated on verified required items

      Given some required items are not yet verified

      When a staff member tries to move to the next step

      Then the next step stays closed until the required items are verified



  Rule: The customer supplies items in their own workspace



    Scenario: A customer supplies an item

      Given a request has been sent to a customer

      When the customer uploads a document or answers a question in their workspace

      Then the item is recorded against the request



    Scenario: Staff supply an item on the customer's behalf

      Given a customer cannot supply an item themselves

      When a staff member supplies it on their behalf

      Then the item is recorded with the on-behalf action

      And an item supplied on behalf is flagged, so one person does not silently both supply and verify it



  Rule: Staff verify or reject each supplied item



    Scenario: A supplied item is rejected for the customer to re-supply

      Given a customer has supplied a required item

      When a staff member rejects it with a reason

      Then the item returns to the customer to re-supply

      And the next step stays closed



    Scenario: A verified item is locked against further customer upload

      Given a staff member has verified a supplied item

      When the customer tries to upload over it

      Then the upload is refused, and staff must request rework to re-open the item



  Rule: Reminders chase outstanding items and stop when complete



    Scenario: Reminders stop once everything required is in

      Given a request has outstanding required items

      When the reminder runs

      Then the customer is reminded of the outstanding items

      And reminders stop once all required items are supplied and verified



  Rule: A request belongs to one organisation



    Scenario: Another organisation cannot see the request

      Given a request belongs to one customer organisation

      When a user from another organisation tries to open it

      Then the request is not visible to them

    @edge-cases



    Scenario Outline: Request item states

      Given a required item is "<state>"

      When the request is reviewed

      Then the next step is "<result>"

      Examples:

        | state | result |

        | not supplied | closed |

        | supplied | closed |

        | verified | open |

Questions

Questions raised in planning, each with the decision taken.

Is the request list a workflow stage, or a page?

Making it a stage ties it to the step order; making it a page lets it be filled in alongside other work.

AA page or tab, so it can be worked on without being locked to one step. · recommended
BA workflow stage.
Decided: A page or tab (option A).

Should a conditional sub-question be folded into its parent, or kept as its own item?

Folding it keeps the customer's view simple; keeping it separate lets staff verify it on its own.

AFold it into the parent on the customer side, but keep it as its own verifiable row for staff. · recommended
BAlways show it as a separate item on both sides.
Decided: Folded on the customer side; a separate verifiable row for staff (option A).

Should the free-text answer field be mandatory?

Making it mandatory can block a customer who has a file instead of an answer; the real requirement is that each item has either a file or an answer.

ANon-mandatory on its own, but a file or some text is still required to save the item. · recommended
BAlways require the free-text field.
Decided: Non-mandatory, but file-or-text still required (option A).

How we sized it

A function point measures what the software does — its inputs, outputs, lookups and the data it stores — regardless of language or how many lines it took. Each counted item is weighted by complexity: a user input counts 3–6 points, an output or report 4–7, a lookup 3–6, data the feature owns 7–10, and data read from elsewhere 5–7.

  • The request-item store this feature owns
    Data the feature owns
    10
  • Generate a request for documents and answers
    User input
    6
  • Staff verify or reject a supplied item
    User input
    4
  • Customer supplies a document or an answer
    User input
    6
  • Track the request and mirror it to the customer
    Lookup
    4
  • Send the request, or supply on the customer's behalf
    Output or report
    4
  • Total
    34
34 function points (range 26–40). IFPUG-style count: each user action, lookup, output and stored data set, weighted by complexity. Technical plumbing is excluded, and a data store is counted once in the feature that owns it.

Components touched

Request items

Each item is a document to upload or a question to answer, keyed by a stable item key rather than the on-screen control.

Verify or reject

A staff member verifies each supplied item, or rejects it with a reason so the customer re-supplies. A verified item is locked against further customer uploads; staff can request rework. Required items must be verified before the next step opens.

Mirrored customer workspace

The customer supplies items in their own workspace; staff can also supply on their behalf.

Reminder job

A background job reminds the customer of outstanding items on a schedule, and stops once all required items are supplied and verified; reminders are sent through the delivery service.

Data touched

Request itemswrite

The list of items, their kind, and their supplied and verified state.

Files and answerswrite

The uploaded documents and the text answers supplied against items.

Audit logappend

Records an on-behalf supply and other sensitive actions.

Security decisions

  • The next step is gated on verified required items, so work cannot move on incomplete.
  • A customer only ever sees their own workspace.
  • An on-behalf supply by staff is recorded.

Subtasks

  • The request items, keyed by a stable item key.
  • The file-or-text save rule.
  • The verify gate before the next step.
  • The mirrored customer workspace and on-behalf supply.
  • The reminder job for outstanding items.

How each scenario is verified

  • Build a request of documents and questions
    Test over building and acting on request items.
  • A customer supplies an item
    Test over the customer workspace supplying a document or an answer.
  • A reminder path chases outstanding items
    Verified by review of the reminder path.
  • The next step is gated on verified required items
    Covered by the verify gate behaviour.

Risk tier

Logic A person approves every merge. This is a Logic-tier change; it carries automated tests for its rules.

Start here

Want this on your backlog?

Get a free baseline report on one repository, or scope a 3-month pilot measured against what your team’s work costs today.

Measured from your own git history
Every pull request tested before review
A person approves every merge
Get a baseline reportScope a 3-month pilot
Next feature: Two-step review & approval workflow →All features