File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Jobs Discussion and the fly likes Gathering requirements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Gathering requirements" Watch "Gathering requirements" New topic

Gathering requirements

Isaac Ferguson
Ranch Hand

Joined: Jun 22, 2012
Posts: 755

when I go to a client I use to sit with them and talk about their needs. I write down they needs and after that I send the report to my company.

But which is the proper way to do that? I mean I have to explain it in a job interview. But I have to do it in the proper way!

Which are the main problems you found gathering requirements?

Any advice, please?

Sai Surya
Ranch Hand

Joined: Feb 08, 2006
Posts: 463

The main thing we do in requirements gathering is to 'collect information on what users wanted'. And we build and deliver a system which fulfills users needs. You can eloborate this in any job interview based on the following points.

1. Users are not technical (business users), they will tell you their needs in terms of business, you need to convert their needs to technical specification. So your team can understand and build a system to server your users.
2. Sometimes users do not know what they need or they lack clarity, so you can suggest them a functionality or feature which works better.
3. Also it is better to prioritize the requirements, like Priority 1 features are must, Priority 2 features optional etc etc.
4. It is important to get what 'exactly' your users want, failed to do so will cause a bad system which doesn't help them.

Few problems during requirements gathering ...

1. Users sometimes asks impossible things, it may be possible to do a particular feature for them, however, considering cost and timeline it is impossible to do.
2. Users do not agree on what other users (their colleagues) have proposed. So it is better to involve all stakeholders in the requirements meetings.
3. If we ask users to prioritize requirements, they may prioritize everything as P1. (This happend to me )
4. Some requirements may be technically challenge to do, however we should be able to find a workaround if not worst case, propse alternate feature to users and get approval.

Hope this helps.

Sai Surya, SCJP 5.0, SCWCD 5.0, IBM 833 834, I believe in Murphy's law.
chris webster

Joined: Mar 01, 2009
Posts: 2295

Good advice from Sai Surya above.

Remember the old programmer's rule: the quickest way to find out what users really want, is to give them what they ask for.

This is because they will tell you what they think they need, but it's very rare for your users to understand everything about what their systems should do. So be prepared for some nasty surprises when you start to look at their requirements in detail.

No more Blub for me, thank you, Vicar.
I agree. Here's the link:
subject: Gathering requirements
It's not a secret anymore!