C2 wiki on functional specifications suggest that this can be facilitated by tools, how?

A Functional Specification is a list of demands and constraints intended to describe a product to be designed and built...

...tools for describing software products have been developed to the point that functional specs are no longer of any use.

Why not just type a structured Word document?


1 Answer 1


Functional specifications are typically presented as a document, but depending on your purposes, creating the specification in Word may not be the best choice. There are other options - word processors, spreadsheets, and requirements management tools (1, 2) are some common tools used to create and maintain functional specifications.

Requirements management tools (I'm familiar with IBM Rational DOORS, but there are others) are essentially requirements databases that support creating, maintaining, tracing, and generally managing requirements. Some tools support importing from documents and spreadsheets, as well as outputting into these formats. Internally, they allow you to capture requirements as unique objects (think a row in a database, where each requirement has various attributes). You can also manage changes, by tracing other items (lower level requirements, design artifacts, tests) and seeing what may have to change if a requirement changes.

Spreadsheets, to me, are a step lower than a formal requirements management tool. They support more of the requirements management functions (traceability, tracking various attributes in line with the requirement statement, managing changes).

Of course, you can always do what you suggest - start a well formatted document in your favorite word processor to capture software requirements. However, it is more difficult to ensure some aspects of good requirements. Specifically, traceability (often implemented via requirement IDs) becomes more difficult and the text associated with a requirement needs to be more verbose to capture importance and verification method.

I don't think that any tool has superseded functional specifications. I do think that processes and how tools are used have superseded the traditional idea of a functional specification document.

In agile methods, requirements are often captured as use cases and user stories. In this environment, your functional specification may be uploading your use cases and user stories in some electronic format to a file store or wiki. Even in more plan-driven methods, the use of requirements management tools have replaced the document, where a document is only generated as necessary to provide requirements to external entities.

At the end of the day, the purpose of a requirements specification (functional and non-functional) is to somehow capture what the software is supposed to do (and, after it's finished, what it does in its current state). This set of characteristics drives testing (especially system and acceptance testing). More important than creating a functional specification document is ensuring that the customer and development organization (the design team, the development team, and the test team) are on the same page when it comes to what the system is supposed to do.

  • 1
    My preference after having used DOORS and another, significantly worse one, is to put requirements in a bug tracker - these are very much geared to linking code, history and releases to 'bugs', so using a new type of bug called requirement is the easiest and most user-friendly way of handling them and getting really good traceability.
    – gbjbaanb
    Mar 24, 2015 at 8:38
  • 1
    @gbjbaanb You'd probably need to set up a separate workflow for requirements than defects, though, depending on the stages your defect is in. But that is a valid option - I should edit it into my answer. However, a downside with a bug tracker is that it may be harder to trace to both higher level requirements and lower level requirements and test procedures, depending on your tool and how much customization it offers.
    – Thomas Owens
    Mar 24, 2015 at 9:01
  • Quite true, but then we found a set of post-it notes were better than some really expensive requirements management tools we used :) I typically use a requirement 'bug' as a source that other implementation 'bugs' are associated with so they can be traced without directly being part of the workflow. Some tools are better than others in their reporting capabilities though, but if you cant afford the expensive tool then this is better than not tracing requirements at all. (and even if you can afford them, its still often better)
    – gbjbaanb
    Mar 24, 2015 at 10:25

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.