Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 ) ?

share|improve this question
Should this go in computer science instead? – Malfist Nov 8 '10 at 18:20
nope this has nothing to do with computer science and everything to do with software engineering – jk. Oct 12 '11 at 15:26
This article may be helpful: 10 Typical Mistakes in Specs – yegor256 Nov 10 '15 at 22:27
up vote 4 down vote accepted

I recently wrote a blog post about Characteristics of a Good Software Requirements Specification (SRS). There is also an IEEE standard for SRS (830-1998) and in the standard there are templates how to write good SRS document. Easy to follow and very informative.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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"
share|improve this answer
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 Feb 24 '15 at 19:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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