I've spent six full days so far working on a spec for a web-app component. Apart from personally wanting some task that doesn't involve Word, I'm wondering if there is a point at which I know that the spec I'm working on is finished (but isn't a spec a constant work-in-progress?). I feel that the spec still doesn't explain a good solution for all the requirements I have, so I'm still on it.

Is there any good heuristic or red flag that says I should stop working on a spec?

Note: As opposed to this question and it's answers, I am looking for a completion metric specific to the design, rather than how to decide when code quality is good enough to know that the implementation is complete.


1 Answer 1


What you are looking for is traceability.

Whether you use old-school waterfall or more modern iterative approaches, a unit of functionality necessarily follows a simple process:

  1. Define business requirements.
  2. Define functional requirements.
  3. Define technical requirements.
  4. Design the software. <-- You are here
  5. Implement the software.
  6. Test the software.

At each step of the process, you should be able to trace your requirements back and forth between steps.

  • Each functional requirement (the system shall have function X) must be traceable to a business requirement (we need a system to do X). Note that a business requirement is normally high level and spawns many functional requirements.

  • Each design element traces back to a functional requirement. E.g. the form elements on this screen all support functional requirement X. All of the data requirements in this functional or technical requirement are satisfied by this screen or interface.

When you have 100% coverage throughout the whole process, you know your design is functionally complete.

But wait! Can the design be implemented reasonably? The key here is collaboration. This is where design reviews come into play. Get the key players involved: customer, project management, developers, and QA. Can the design be implemented? Can it be tested? Does it really satisfy the requirements? Once the team comes to a consensus, you are likely done with the design.

  • "Once the team comes to a consensus, you are likely done with the design."That sounds like an easily identifiable goal to go by. Commented Aug 6, 2015 at 16:59
  • @RafaelCichocki Consensus is key, but it is not as simple as a bunch of people sitting around a table and nodding their heads. It is important that each team member answers the question "can I do my job with this software artifact?" affirmatively. I.e. "can I test using this" "can I develop using this" etc.
    – user22815
    Commented Aug 6, 2015 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.