Requirement Elicitation

The toughest part of the whole SDLC i would say is the requirement gathering stage, whereby you as a Business Analyst should be able to collect the right information on the processes that are currently handling and not to mention that you may be challenging some of the consultants who are working on their process quality and at the same time suggesting some sky high requirements on how a system should be implemented in order to help them in the so called "off-loading" their work, improve creativity and eventually bring profit to the whole organizations.Then later you as a System Analyst to start analysing for the processes that can be automated. Why BA and then SA ? what about iterations? what about misunderstanding or lacking information during Business Modeling phase?

I would really much like to comment on this "WHY", which the reason being:
1. You are expected to do all if possible all the work, so the company could even maximize more on the profit
2. You yourself doing the requirement then later system functional and best still do the QA and UAT to make sure every requirement that you gather is fulfilled. Who know the best if not you?
3. Iterative process is too time consuming and this create more change request from the customer, and hence, FIX the scope quickly, then implement it, then only consider on CHARGEABLE CR.
4. People resisting of changes made to their comfort way of implementation, SO you follow!
5. RUP just having too much, and i mean SO MUCH artifacts to deliver, and all i have is 2 days to come out with all the documents. .... alrite... 2 days is a bit exagerating, or may 2 weeks to come out with all documents for all the modules?
6. Worst still, your technical team told you, it's simply NOT doable!
7. Project Manager asks you to handle the customer expectations, make sure requirement plan and test plan is correctly deliver within the project time line, make sure all requirements are captured and documented, then come out with the right use cases or functional specs, then test cases and UAT plan, make sure all milestones meet so that he can start invoicing the client and get the money.
..... am i getting out of topic ? oopps .... get back to requirment elicitation again .... and i suppose to be a BA for now... so... this is how it goes:

1. Understand the whole project scope (if you can find anyway in the emails, or CVS or sharepoint folders)
2. Roughly identify some of the business process by ? --> your best friend - GOOGLE
3. Start getting some information on the organization structure and people you are going to meet, in RUP this is call Accessing the Organization
4. Start planning on workshop and MAKE SURE you have the right sets AND relevant questions to bring together with you, always make sure you show confidence (even you are not), and smile :)
5. Always state the context of each of the workshop, co;z you don't want to end up talking other things and wasting time collecting information that you don't even need (or not even in your scope or extending scope that may possibly increase your cost)
6. During the workshop, open your ears and start capturing some of this keyword:

• Who do this
• What is needed
• How this is ended up with
• What will be the result of doing this
  
• What are the problems doing this
• What are the problems if not doing this
  

7. Then start accessing on:

• Benefits vs. Challenges
  
• Business Values - by doing Z, can solve A, B and C
  
• Performance Index - by having Z, need to do E, F, G and H

8. After the workshop, always revise what you NEED to put into your User requirement specs. This would be the base of the business rules which will be used again later.
9. Start to link whatever you have gathered, what is more challenging here is when there always having more BAs doing the requirement with other group of users, so the puzzle must be matched to the same picture in the very beginning. I like to use mind mapping here.
10. Always go back, if linkages are broken
11. Golden rule no. 1 - NEVER ASSUME (I bet you know what assume means)
12. Start drawing the storyboard to understand the user interaction flow and identify the input and output of each processes.
13. GO BACK to the client to confirm your understanding ALWAYS!
14. Then START DOCUMENTING...