1. Introduction - the Context
The requirements specification document is a deliverable in the software life cycle. The software life cycle includes all the stages in the life of a piece of software from its conception to its obsolescence. Software engineering has developed several models of the software life cycle. The mostly widely used model is called the "The Water Fall" model.
Below is Michael Berman's version of the Waterfall Model of software development (in CS204 text, Data Structures via C++: Objects by Evolution). The Waterfall Model consists of a sequence of steps which leads in an orderly manner (One hopes!) from the initial idea to the completed software system. Each activity produces one or more deliverables which are passed to the next step below.
Notice that this is an object-activity diagram where the activities are rounded rectangles and the objects, in this case the deliverables, are labeled on the arrows. Notice that object-activity diagrams have a dual, i. e., objects can be portrayed as rounded rectangles and activities as labels on arrows. Since the focus is different, rethinking and drawing the dual of a object-activity diagram may uncover us insight in to the problem. Below is a possible dual for the above diagram. Here the deliverables are rounded rectangles and the activities are labels on the arrows. I prefer the below diagram.
Here the focus is on the activities which are needed to create the deliverables. Also, I have added back arrows which reflect review activities. Observe that the "Maintenance" activity of Berman's diagram has been replaced by a "Modify" activity which better reflects reality. Testing will be added to the diagram in a later document.
2. Analyze Activity
The analyze activity attempts to determine the exact requirements of the system. Typically, a professional known as a systems analyst performs the analysis. The systems analyst often interviews the prospective users of the system. The analyst creates a document known as a Requirements Specification Document that relates, in detail, the exact functions that the system needs to provide, as well as any special requirements - such as minimum performance requirements. Often the organization, that needs the software, contracts with a software development company to develop the system. In this case, the Requirements Specification Document may form part of the legal agreement between the contractor and the customer.
3. Goals and Requirements
Given a concise statement of the refined problem from the Feasibility Report and an indication of the constraints, the team formulates preliminary goals and requirements.
Goals are targets for achievement and serve to establish the framework for a software development project. Possible goals might be:
Requirements specify capabilities that a system must provide in order to solve a problem. A requirement must be stated so that the outcome may be measured and the team can decide if the requirement was met or not. For example, one can measure the following performance requirement:
"90% of the transactions finish in one second."
Requirements include the following:
4. Functional Requirements
The bulk of the Requirements Specification Document is specifying the functional requirements of the system, i. e., WHAT the system is to do. In this context, the word "function" means what the object or process is used for. For example, the function of a clock is to show time.
The major problem with writing functional requirements is to write them in strictly functional terms, i. e., describing the WHAT the system is to do without letting some of the HOW the system will do it to creep in. For example, assume we are to produce teapots. The following is a poor functional requirement:
"The teapot will be made of brass with a wooden handle."
because this statement specifies some of the design or HOW the teapot will be made. A better functional requirement is the following:
"The teapot will hold two quarts of liquid."
5. References
I suggest you read/consult in this order.