Gathering software requirements for begining business analysts

Posted on March 8, 2007 at 9:21 am

Working as a Business Analyst for the last 4 years has taught me a few things about gathering user and software requirements that I thought I would share! There are a couple of things you need to do and keep in mind when you are trying to design a system or application for a particular set of users:

1. What the user ask for may not be exactly what they want! They may ask you to do X, Y, and Z because that’ll make things a lot easier, but if you just go ahead and do that blindly, you will more than likely find that later on the users will complain and say that it’s not working in the best possible way or the way it “should”. In order to figure out what the users REALLY need, you must sit down with them and WATCH while they work. Meetings are great and they will try to remember how they do things (50% of the stuff they will not remember they do) and give you some warped view of their work. Not that they do this on purpose, but once you go sit down and see how people work, you’ll find there are tons of small little, but importants steps that they didn’t think were worth mentioning! Once you see the flow with your own eyes, then sit down with everyone and have a meeting about what they want and WHY.

2. Always ask WHY people are doing things the way they are…usually you’ll find that some problems can just be solved by telling someone to do it another way! Someone else told Person X to do it this way and so now they just keep doing it that way even though the process may have changed! People don’t like to change, even if it’s good for them! When you start asking why, people will begin to actually think about it and may figure out for themselves that they are wasting time or doing it in a complicated way that’s not necessary.

3. Always try to get a general view first! People will immediately begin to tell you about this problem with this particular feature or this step in the process, etc, etc, but you want to first get a clear understanding of the entire process from a higher level. If you get right into the details, you’ll end up making software or a process that might be overly complicated! It’s amazing how many times I’ve looked at processes and determined that the entire step can be eliminated!!! Always try to get the BIG PERSPECTIVE!

4. Make sure to document everything, so people don’t think you are wasting time. If you’re spending a lot of time with the people who actually do the work (which you should), then make sure you write everything down because you don’t want your boss to think you’re not getting anything done! It’ll also be easier to convince others that your solution is the best solution if you have lots of supporting evidence on paper.

5. Get sign off from all the top people, plus the users! If management wants it one way and users want it another way, those issues need to be resolved quickly and jointly! Don’t ever say you’ll do one thing before making sure it’s ok with the boss. Otherwise you’ll have to backtrack on your promise and people will get annoyed!

6. Lastly, but MOST IMPORTANTLY, TEST TEST TEST!!! Write out test scripts and test cycles. Don’t have to do anything fancy, use Excel to write it out. One column for the particular feature or function you are testing, one column for the expected outcome, one column for the inputs and one column for the expected outputs. You should always have expected inputs and outputs. And try to use varied data sets, small sets, large sets, and sets you know will cause errors (but hope to catch).

Hope this helps!

» Filed Under IT Job Stuff