I have a few questions about writing a specification and they are:

  1. When we write a software specification, under the topic "User requirements definition" we have to specify the "Functions" and "Constraints" only ?

  2. Does "User Interface" fall into "functions" or "constraints" ?

  3. What are the major key areas (requirements) a software can be broken into (e.g. UI ) ?


4 Answers 4


While I am not a big fan of gathering all requirements in detail up front (as they are subject to so much change over the course of a non trivial project), if you are writing requirements documents, the Volere requirements specification template is an excellent guide.

While it may be overkill for some projects, it provides a great checklist of things to think about, even if it's just to mentally check off the list that you don't need that item for this requirement.

Here's a link to more information about the template:


The template itself (and the book Mastering the Requirements Process - which is actually slightly less expensive than the template and contains the full template text) contains a lot of information, examples and advice within the various sections as to what should go in each section.

Here's a summary of the sections in it (quoted from the above link):

  1. The Purpose of the Project

  2. The Stakeholders

  3. Mandated Constraints

  4. Naming Conventions and Definitions

  5. Relevant Facts and Assumptions

  6. The Scope of the Work

  7. Business Data Model and Data Dictionary

  8. The Scope of the Product

  9. Functional and Data Requirements

  10. Look and Feel Requirements

  11. Usability and Humanity Requirements

  12. Performance Requirements

  13. Operational and Environmental Requirements

  14. Maintainability and Support Requirements

  15. Security Requirements

  16. Cultural and Political Requirements

  17. Legal Requirements

  18. Open Issues

  19. Off-the-Shelf Solutions

  20. New Problems

  21. Tasks

  22. Migration to the New Product

  23. Risks

  24. Costs

  25. User Documentation and Training

  26. Waiting Room

  27. Ideas for Solutions


I recommend reading Joel on software. I'm not sure if it answers your specific questions, but he has an excellent overview of what it means to write functional specifications:

The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec — describing how the program works in minute detail — will force you to actually design the program...

...when you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs. What’s worse, a programmer who’s just spend 2 weeks writing some code is going to be quite attached to that code, no matter how wrong it is...

...When you write a spec, you only have to communicate how the program is supposed to work once. Everybody on the team can just read the spec. The QA people read it so that they know how the program is supposed to work and they know what to test for. The marketing people use it to write their vague vaporware white papers to throw up on the web site about products that haven’t been created yet. The business development people misread it to spin weird fantasies about how the product will cure baldness and warts and stuff, but it gets investors, so that’s OK. The developers read it so that they know what code to write. The customers read it to make sure the developers are building a product that they would want to pay for. The technical writers read it and write a nice manual...

When you don’t have a spec, all this communication still happens, because it has to, but it happens ad hoc. The QA people fool around with the program willy-nilly, and when something looks odd, they go and interrupt the programmers yet again to ask them another stupid question about how the thing is supposed to work...

without a detailed spec, it’s impossible to make a schedule... In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end... Writing a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don’t have a spec...

  • @gnat I don't think the quote from the article is necessary. If you would like to highlight your choice of excerpts, I suggest you post your own answer to the question. Commented Mar 14, 2018 at 21:06
  • consider giving a read to Your answer is in another castle: when is an answer not an answer? "let me be clear: this sort of response is not an answer. If you see this, flag it. Moderators, if you see it flagged, delete it"
    – gnat
    Commented Mar 14, 2018 at 21:10
  • 1
    If you disagree with the excerpts quoted, please feel free to edit them. However, having an answer that is only a link is not considered a good answer and is subject to deletion under our quality policies. A post that refers to an off-site resource or reference should provide enough information to continue to add value if the link is not accessible for any reason.
    – Thomas Owens
    Commented Mar 14, 2018 at 23:53

When we write a software specification, under the topic "User requirements definition" we have to specify the "Functions" and "Constraints" only ?

A requirement is a combination of two things...

  1. What the thing does. Functional requirement.
  2. How well it does it. Non Functional requirement or "Constraint"

Does "User Interface" fall into "functions" or "constraints" ?

I would say "User Interface" would be category of requirements as you have identified in your last question.

What are the major key areas (requirements) a software can be broken into (e.g. UI ) ?

It depends on the software. You can group requirements based on parts of the system or you can group them based on use case or the business requirement that the functions are fulfilling.

Of course all of this is secondary to your actual goal which is to determine a clear, unambiguous and testable description of the software system.


The main requirement for a requirement is that it is testable. If you can't figure out how to test a requirement, the odds are that it won't be implemented the way the writer intended.

I've never seen a requirements document limited to Functions and Constraints only, but I can see some value in having a structure like this - it forces the writer to categorize the requirements into "things the software needs to do", and "rules the software needs to follow."

I think a user interface has requirements in both categories


  • "the startup screen shall display two buttons: "Start", and "Stop"
  • "The display font shall be no smaller than 10 point."


  • "When the Start key is pressed, the software shall establish a TCP/IP connection to WOPR"
  • Your examples aren't requirements, they are design. The specifics on how the requirement is to be accomplished is a design decision, not a requirement. Thus, "two buttons" is a design decision. It becomes obvious when you realize there are many other valid ways to accomplish the same goal (Start or Stop something). Thus, to make it more of a requirement you would say "The UI shall provide a means to Start and Stop something". But I'd go further, because using a UI is also a design decision. So for the system requirement it would be "The system shall provide a means to Start and Stop something"
    – Dunk
    Commented Feb 24, 2015 at 19:02

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.