What causes the need for requirements?
Well, something has to happen to trigger it...maybe a cause-effect situation, or a change request for something or an action that causes some changes.
For example, let's suppose that a company expands its offices throughout the country, and as a result of this expansion they need to enhance their information system and improve communication performance. From this situation a need emerges and, in order to meet these needs (system and human), it must be recognized through conscientious effort. Asking questions, from both points of views (company and customers), on the cause and, consequently, on the need will help, and it might be best to establish procedures for identifying these needs in a systematic way. Also, it's important to give special attention to focusing on anticipating needs, and not just on the existing needs. Anticipating needs can be accomplished with a two-hour brainstorming session. This session is useful to develop ideas of what future needs might be. This forecasting is the scenario building.
Once the need is recognized, it must be clearly articulated. This entails an in-depth scrutiny of the recognized need. Look also underneath the surface, so as not to lose sight on reality. The face value is fine, but don't neglect the rest. Articulating the need has a practical side too; it serves as the basis for the development of functional requirements, by stipulating in concrete terms what has to be done to achieve it.
To minimize the risk of doing a poor job in articulating the need, it's best to:
(i) ask those who have the need to define it as clearly as possible,
(i) ask those who have the need to define it as clearly as possible,
(ii) ask a full set of questions about the need (information, curiosity, data,...),
(iii) carry out whatever research is necessary to better understand the need,
(iv) in view of insights gained in the first three steps, try to formulate the need the best way you can,
(v) ask the customer to respond to the formulation of the need and revise accordingly.
Carry out the above steps only by working closely with the customers, getting their reactions to the newly articulated needs, and revising the needs statement to reflect customers desire.
After the needs have been carefully defined, it's possible to use them as the basis for developing a project plan. This is done by formulating the needs as functional requirements.
Functional requirements describe the characteristics of the deliverable in ordinary non-technical language, i.e., what emerges from the project. Here it's possible to use graphic images to strengthen its contents.
They should be understandable to the customers, and customers should play a major direct role in their development.
While functional requirements are designed to assure that customers know what they are getting out of a project, technical requirements are written for the technical staff. They describe the features of the deliverable in detailed technical terms (such as physical dimensions and performance specifications). They offer project staff guidance on what they should be doing on the project. Because of their technical nature, technical requirements are often incomprehensible to the customers, who lack the training to know what they mean.
In a software project, for example, the functional requirements may stipulate that a data base system will be developed to allow access to a finacial data through remote access; the corresponding technical requirements would spell out the architecture of the data structure, the language in which the data in which the data base management system will written, the hardware on which the system will run, telecommunications protocol that should be used, and so forth....
Project requirements are important for two reasons:
(i) They are a tangible embodiment of the customer's needs (needs emerge, needs recognition, needs articulation, and then they are translate into requirements, which serve as the basis for the project plan). This will reduce the effort of determining how best to meet requirements.
(ii) They define the project team's obligation to the customers.
Requirements also describe the team's responsibilities. Projects that run under contracts, the requirements may be written as a statement of work (SOW), and compliance or non compliance with the contract is determined by resolving whether the contractor has fulfilled the SOW.