Requirements Gathering Essentials

[ArticleBot]

This is an article discussion thread for discussing the SitePoint article, "Requirements Gathering Essentials"

[stonercreek]

We've found it more productive and cost effective to just have the client sign off on each phase of a project...rather than spell out or try to predict up front all the specific requirements that will be needed for a site. Sure, we go into the project with the full understanding of the ultimate goal, but they aren't looking to us to teach them what is required to get what they are asking for. They hired us because we know what they don't.

One book I would suggest for project planning: "Getting Things Done" - David Allen. His premise is simple...concentrate on the "next thing" that needs to be done.

And keep clients informed through each step.

[Geof Harries]

Stonecreek,

While this process you've described works well for smaller projects such as websites, it fails when it comes to multi-departmental software/application work where there numerous teams involved and many types of business processes and impacts. You can't just know the ultimate goal, you need to record all of the needs (both known and hidden) plus be aware of all the risks and how to mitigate those risks.

You have to do the research and requirements gathering up front or otherwise you end up with a failed project. Intense requirements gathering isn't static - you need to constantly go back and forth with new revisions - but it helps lay a solid groundwork on the really big stuff.

geof

[martyb]

There are many schools of thought on how best to gather requirements.

On one hand, there are those that don't document anything and get straight into code, there are others that cover absolutely everything in detail at the start. Both have their problems. The smaller the project, the less risk there is in not capturing requirements. In larger projects, the risk is increases dramatically.

However, develompent is not an exact science and often requirements, even if written well can change due to unknown or unforeseen circumstances which makes you wonder why you bother in the first place! This is where common sense has to prevail. The amount of detail put into the requirements will depend on the scale and nature of the project.

martyb

[Geof Harries]

I am definitely in the latter group for the big projects. The small stuff I make sure to at least get a bare bones BRD/URD together. Requirements evolve yes, but that's why you have change documents :)

geof

[Dale Wilkins]

My experience in working with clients taught me that requirements need to be developed in collaboration with clients and builders.

I learned to ask: 1) Can we build something that will meet this requirement? (Focus on the What, not the How, at this point.)

2) Can we agree, clients and builders, on a test that demonstrates the requirement has been met, if the system passes the test?

I have found that these two questions help define vague requirements such as "It needs to be faster!"

[Phil]

Publishing an article is also a project (or task if you prefer) in itself and as such needs QA too. eg. Spellchecker.

:-)

[HeshamAmiri]

For small projects it might be expected that requirmnets define every little detail expected, but from experience working on a huge project that tackles new areas in the industry requirmnets become more or less a guidline for expecations and hence several intermediate steps are required from the date you finalize the requirments to the date you finalize your archetictire. These steps will help your clients (and yourself) understand what is needed in much more detail.
Several other session of progress and alignement should be executed while implemenation and prior to initial relaese.

Don't expect a big project to close nicely like small ones usually tend to do.

[realestate]

Worst case scenarios should be considered as well. What will happen if one of the parties quits or dies. Written contacts may not be enough to fix damages. Payments should be made gradually from the start date and continue after project is finished.

[vandiike]

Most of requirements gathering articles that I read are for when you have a client. To be honest, most of my projects are not client driven, more organisational driven, if that makes sense. I.e. improve former software etc.
-Do you have any good ideas of how to make requirements gathering easier when no specific client exist.

Mike

[martyb]

Hi Mike,

This is a really good point. I find that internal projects often get treated different than commercial projects where a client is paying for the work and wants to see tangible results for their money.

The simply answer is to find a client. Or in your case, a project sponsor, ie. someone who will make the decisions for you. If there's no-one to do this, how can you assess if what you're doing is right or not? Ofcourse, finding that person might not be an easy task but there's often more than one way to get things done.

So, what you might need to do is write the requirements yourself. Literally make up what you think the organisation needs and then find someone to read it and hopefully approve it. I suggest this because often people won't give you details up front but they will give you feedback if they see something wrong. I find that there are even cases where a prototype has to be built to get people to pay attention when they won't read requirements (happens all the time).

Hope this helps.

Cheers
martyb

[Geof Harries]

A project sponsor, or what in our enterprise we call a Business Prime, is exactly what you need in cases like this.

Good suggestion also on writing your own requirements.

Writing requirements helps you as a developer (and an information architect) get a better grasp on what the real world needs of an application are - often developers think too much about the code and not enough on the business functions, processes and issues surrounding how the application could benefit or detract from everyday usage.

Start moving around the office, ask questions of appropriate personnel and gather feedback on how they do their work and what sorts of problems they encounter - this will help you realize and document opportunities. It also helps raise the profile of your work and your role in the company. This is especially important if you're looking to impress your superiors. Be polite and proactive - it can go a long way.

geof

[vandiike]

Thanks for your comments. I have now 2 sponsors that are willing to act as test-users. (both from different departments, and "head of departmetns") I have also started to make and write UML use-cases together with the head developer. I hope that this will give me the tip of the sword in the quest for a more user friendly/focused application without having a real client.

Thanks again

Mike

[Rashid]

I am interested in finding samples or examples of what methodoligies are used for requirements gathering and how does the document or output looks like..

Something that can help me in going ahead with a similar task at hand

Thanks!

[Simon Wardlaw]

Your spelling could improve:
sucess, analsying, preparess

[NetNerd85]

Good article. Objectives make sense to justify options :)

[ijese]

Client is usually not good (and not interested) at abstracting engineering details, so the communication is crucial. As Martin said, you want to accept the clients' terminology and use diagrams, pictures and such.

Another extremely usefull technique is to use static prototypes ("mockups" or "wireframes") of your application. Use the screens to resolve the requirement ambiguities and populate them with controversial data to deliberately provoke clients' response.

Check this:
http://mockupscreens.com

[abc]

How would you approach gathering requirements with an identified subject matter expert whom is not forthcoming with providing information?

[business888]

Yes this web project job will need monitoring

I suggest to use the requirements tracability chart, where each requirements is track by a start, complete dates, done by which developer, problems, modules related to, testplans completed (you can add in more)

so that its easiler to track and trace to problems

[Sajesh J]

Thank you for such an informative article.It would be great if you can discuss how requirement changes during various phases of SDLC can be handled.

[susan white]

- good content but many misspellings and wrong case of word.
- looses credibility for a requirements gathering website

[Matt]

If ewe are going to knock something for grammer, make sure yourse is OK first?

[Jackie]

Please take the time to read the entire document. I rate this author as a 10--notice the author is from Melbourne and grammar and spelling is quite different in other countries. Great information.

[Voltairecim]

Looks like an interesting article. I'll take a look at it a little later.

[nixsumi]

great info. was very useful