Skip to main content

The Needs/Requirements Life Cycle

Specifying what the project should accomplish is not an easy task and is not to be taken for granted that everything is clear. It's easy to misunderstand requirements and transform the whole project into a tragedy.

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 tha a legal company expands its offices throughout the nation, and as a result they need to enhance their information system and improve communication perfomance. 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: ours and the customer) 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 called 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. Articularing the need has a practical side too: it serves as the basis for the developement 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,
(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 accordinly.

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....

Hence, project requirements are important for two reasons
(i) They are a tangible embodiment of the customer's needs (needs emerge, needs recognition, needs articulaton, 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) Requirements are important because they define the project team's obligation to the customers.

They also describe the team's responsibilites. 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.

Popular posts from this blog

The differences between Project, Operation and Program

We said that a project is defined as a temporary endeavor that consumes resources, incurs cost and produce deliverables over a finite period of time to achieve a specific goal. They come in all shapes and sizes and can vary in length or complexity.

Operation type activities are similar to project activities in that they too produce deliverables, consume resources and incur cost. However they are on-going or repetitive in nature, hence they are not project activities or tasks. Some examples of operation activities are weekly maintenance of databases, paying invoices or help desk operations activities.

Programs are much larger than projects. They are made up of many projects and on going activities such as operation type activities and are similar to projects as they consume resources, incur cost and produce deliverables. However programs are more complex and include repetitive operation type activities such as maintenance work, facility administration etc, and are funded typically on a…

Forecasting Project Costs using Variance Analysis

One way to report on cost control and forecasting during project execution is to use the Variance Analysis method, that is, explaining the difference (or variance) between actual costs and the budgeted costs with numbers and make new estimates for completing the work. Please consult this link Earned Value Management for related literature and references.
For the purpose of making these calculations, I will use an hypothetical project example (but it could also be a task or phase). "A company has contracted a service provider to deliver a project in 10 working days (80 hours) for the estimated cost of $10,000 and a work effort of 200 hours. The contract is Time and Material, this means that the company pays the provider for the number of hours actually required to perform the service. So, the provider has no incentive to minimize the number of hours expended on the service. The less efficient the provider is, the more money it makes!"
Summary of Time and Material Contract (re…

Using PERT for estimating tasks

A simple way for estimating tasks is to use the PERT (Program Evaluation review technique) weighted average method. This method uses a weighted average duration estimate to calculate task duration, it gives the opportunity to take into account information based on different types of estimates values (such as poorly defined areas, probabilistics, and ranges for the schedule). This method is based on the Beta distribution model because it can model events which are constrained to take place within an interval defined by a minimum and maximum value. (For this reason, the Beta distribution is used extensively in PERT, CPM and other project planning/control systems to describe the time to completion of a task).

The term weighted average means that the equation uses weighted factors to calculate the expected task duration.
The equation and process modelling a task for PERT is the following:  E=(O+4M+P)/6 (equation)  E= Expected Value  O= Optimistic Value (this is equivalent to a minimum val…