Requirements Gathering and Documentation


Very few people doubt it nowadays: The gathering of requirements and its appropriate documentation is a fundamental step in the success of any project. Yet, many people still disregard it.

Requirements are described as a condition or capability a customer needs to solve a problem or achieve an objective. If you don’t have this clear, how can you meet those requirements and make your project successful? No wonder the astonishing claimed figures ranging from 60% to 80% of projects failed just in the IT industry alone. Although what a “failed project” is has to be better defined, and this is a topic for another article, and there are many causes for project failures (even subjective), lack of requirements gathering and documentation is certainly one of them.

The process of gathering requirements and documenting them can take several forms but they all have to include all the project stakeholders, no exceptions. You can gather and document requirements one time for small projects or several times for larger projects. You can have everybody present in the same room for complex projects or remotely for less complex ones. You can interview each of the stakeholders for separate. All these forms have advantages and disadvantages depending on the nature of the project and it is the PM’s responsibility to guide the business analyst and stakeholders to a consensus on the proper method.

Now, every participant has its own agenda. This is a challenge that must be broken from the start! What are the challenges of gathering requirements?

o Stakeholders

Have a pre-conceived idea of the solution

Do not know what they really want

Are unable to articulate what they want

Think they know what they want but do not recognize it when delivered

Meant something else

o PMs / business analysts

Think they understand problems better than users

Have done it before

o Everybody

See things from their own point of view

Believe everyone is politically motivated

It is indispensable, and terribly important, to have the best requirements you can get. When gathering and documenting requirements ensure that at a minimum these are captured:

o Functions – Example: the house has to have 4 bedrooms and 2 bathrooms

o Constraints – Example: outdoor paint cannot be water based and has to have a light shine

o Other elements that must be present to meet the needs of each stakeholder – Example: one bedroom has to have a bathroom inside

What do you do with a requirement:

o Obtain it

o Anticipate it

o Document it

o Clarify it

o Quantify it

o Qualify it

o Manage it

o Satisfy it

o Meet it

Document the requirements in a readable, user friendly way without assuming anything. Release the documentation, review it, obtain feedback from all stakeholders and update it if necessary.

It is known that the use of effective requirements gathering and documentation practices lead to successful projects, satisfied customers and increased professionalism. There are benefits to a good requirements gathering and documentation process:

o A clear understanding of the needs of users, customers and stakeholders

o A collaborative relationship between the users, customers and stakeholders and the technical team

o A strong commitment of the requirements from development team members to project objectives

o Use of a repeatable requirements process that is continuously improved

o A system architecture that supports current and planned needs of users, customers and stakeholders

o The ability to accommodate changes in requirements as they are progressively elaborated

o High quality deliverables

o Development cost savings, accurate schedules, customer satisfaction

Establish a good change management plan because requirements may change. Now, the big question: why do requirements change?

o Our understanding of the problem or objective improved

o The problem being solved or the objective changed

o We failed to ask the right people the right questions at the right time

o We failed to create or follow a process to help manage change

o The users changed their minds or their perceptions

o The external environment changed

Avoid changes and follow all steps from the beginning or someone will miss something. Don’t you think so…? Well, I do.


Source by Jorge Dominguez

Leave a Reply

Your email address will not be published. Required fields are marked *