I have a few questions about writing a specification and they are:
When we write a software specification, under the topic "User requirements definition" we have to specify the "Functions" and "Constraints" only ?
Does "User Interface" fall into "functions" or "constraints" ?
What are the major key areas (requirements) a software can be broken into (e.g. UI ) ?
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:
http://www.volere.co.uk/template.htm
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):
The Purpose of the Project
The Stakeholders
Mandated Constraints
Naming Conventions and Definitions
Relevant Facts and Assumptions
The Scope of the Work
Business Data Model and Data Dictionary
The Scope of the Product
Functional and Data Requirements
Look and Feel Requirements
Usability and Humanity Requirements
Performance Requirements
Operational and Environmental Requirements
Maintainability and Support Requirements
Security Requirements
Cultural and Political Requirements
Legal Requirements
Open Issues
Off-the-Shelf Solutions
New Problems
Tasks
Migration to the New Product
Risks
Costs
User Documentation and Training
Waiting Room
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...
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...
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
Constraints:
Functions:
Start key is pressed, the software shall establish a TCP/IP connection to WOPR"