This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Gathering requirements

 
Isaac Ferguson
Ranch Hand
Posts: 837
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

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?

Thanks
 
Sai Surya
Ranch Hand
Posts: 463
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
chris webster
Bartender
Posts: 2407
32
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic