 |
|
|
|
Hello,
I was a QA tester for last 3 yrs and have always been interested to work as BA.
Finally I got an interview & got seected to work as BA. I have a question:
I know the overall role and process of gathering requirememts. But on lower level.. I am confused.
For eg. You have your feature matrix and you know which requirements to work on, the second step is doing your homework... ie., performing your requirement analysis...How do u do that.
I asked my friends,they say, you tak to users...What are the right questions to ask........& not act stupid.
Can some one please explain this process with an example. That if you have a BR & how do you go from there?
THanks |
|
|
|
 | |
|
|
|
rina wrote
Hello, I was a QA tester for last 3 yrs and have always been interested to work as BA. Finally I got an interview & got seected to work as BA. I have a question: I know the overall role and process of gathering requirememts. But on lower level.. I am confused. For eg. You have your feature matrix and you know which requirements to work on, the second step is doing your homework... ie., performing your requirement analysis...How do u do that. I asked my friends,they say, you tak to users...What are the right questions to ask........& not act stupid. Can some one please explain this process with an example. That if you have a BR & how do you go from there? THanks |
Rina,
Congratulations, you have already overcome the greatest obstacle; that is to convince a hiring organization that you can transition from a quality assurance analyst to a business analyst. You may be thinking, “well of course I can”, though many hiring managers are difficult to convince.
Regarding your question; you mentioned that you have a feature matrix. I don’t think there is an industry standard for feature matrices, so this could mean a lot of different things to different people. I will assume that you have a basic list of logical features that should be supported by the system (they should NOT describe screens, controls, button, or anything physical at this stage; save that for the functional specs). It may also include a few additional attributes associated to each feature.
The feature matrix probably does not outline detailed requirements. Before going any further, if possible, you should document the business process that is being supported and/or modified by the new system being developed. This should be done by creating a business entity model (This documents the things of the business and creates a common vocabulary for the project. It also becomes a starting point for class diagrams and database modeling later in the project. You can see a slightly better explanation by referring to the interview questions ) and business process flows (These are process flows that model the business. They have no concern with which portions of the business are supported by systems. That comes later). If you aren’t afforded this opportunity, as a lot of management teams don’t understand the importance of this, then you should try to document specific requirements in greater detail. You can do this via user interviews, JAD sessions, questionnaires, etc. The goal is to understand WHAT the system needs to do to support the business process, not HOW it should do it. Your findings can be documented in a detailed requirements list, system process flows, and/or system use cases.
When creating a detailed requirements list, try to make each requirement granular and decoupled from other requirements. This eliminates the need to implement multiple functions to support a single requirement and reduces unforeseen conflicts between requirements.
Don’t get too hung up or worried about what the right questions are. Don’t even think of it as gathering requirements. Think of it as, WHAT (not how) the system should do to support the business, and document your findings. It’s always best to ask the users about the business process being supported. Users think they know what the system should do but often they are wrong. If they say this system should do “X”. Ask, why should the system do “X”? How does this support the business process? Once you understand the business process, then you will know if their requirement was a true requirement, or you may suggest a different system requirement that more accurately supports the business process.
Always listen for the users to state physical characteristics of the system. This is a warning that they are trying to solution the system instead of giving actual requirements. This is when you know you need to ask “Why”? When I gather requirements, I ask “Why” to myself after each statement the user gives me. I keep doing this until there are no more “Whys” to be asked.
After requirements you will begin to design screens and controls that support the requirements in functional specification. However, you will still want to describe things logically as much as possible. Avoid describing the system functionality in physical terms with the exception of screen design.
I know this is all a bit general, but I don’t know your situation in detail. If you have other follow up questions with some specific detail, I (and I’m sure the rest of the community) will be glad to provide answers.
-Chris
Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile |
|
|
|
| |
|
|
|
| rina wrote
Hello,
I was a QA tester for last 3 yrs and have always been interested to work as BA.
Finally I got an interview & got seected to work as BA. I have a question:
I know the overall role and process of gathering requirememts. But on lower level.. I am confused.
For eg. You have your feature matrix and you know which requirements to work on, the second step is doing your homework... ie., performing your requirement analysis...How do u do that.
I asked my friends,they say, you tak to users...What are the right questions to ask........& not act stupid.
Can some one please explain this process with an example. That if you have a BR & how do you go from there?
THanks
|
Hi Rina,
Since you are new to the BA profession, I would definitely suggest that you supplement your on the job experience with additional sources of information:
- if there are senior business analysts in your organization try to find out to mentor you,
- I would also recommend a business analysis course (see: list of training courses),
- read as much as you can about requirements, functional specifications, etc. (see the Article repository).
Regarding your specific questions, the answers depend on your organization and the expectations they have of you. Here are a couple of questions for you, which may help us better answer your questions:
- Did you sit down with your manager/supervisor to ask what your role and responsibilities are?
- Does your organization/company have established process for business analysis?
- From your question, I get the feeling that you are expected to create functional specification/design documents. Therefore, are there established templates/guidelines for creating artifacts within your team?
Since every organization is different and expectations vary on the role of the business analyst, try to find out as much as possible about current standards, processes, templates, and expectations for the BA role. If you give us more details - we will try to provide you with further guidance.
Best regards,
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
|
Thanks a lot for your advise, Chris and Adrian!
I am trying on the things suggested by you. You suggested that try answering the WHat system can do and answering all the why's but Are there any general questions where you can start from when talking to users about the requirements.....and then get into details???
Also, how can you make users to trust you and become more comfortable in your company?
Once again,thanks a lot for your suggestions. |
|
|
|
| |
|
|
|
Rina
As for building trust, that comes with time, and with you being consisent. Here is some more info on the topic.
When asking the first set of questions to stakeholders try the following
- Give a high level summary of the project's intention
- Ask how the stakeholder sees it affecting them - for example; which/how many of their staff are impacted, are there any systems and processes already dealing with the issue at hand, what are they, who are they
- Are there any existing business rules, standards and policies that need to be adhered to
- What documents exist that are relevant that you should read and where can you get them
- Are there any other stakeholders you should be aware of, and whay are they an interested party
In terms of documenting reqiremnst from a detailed perspective, appraoch it iteratvely. Think of a funnel, where things are loosely defined on the first approach and over time things get much more specific and clear. Expect to speak with the stakeholders or their representaive at least 3 times before you have a detailed view of the requirements.
And remember the magic BA Hueristic; What, When Why, How, Where. |
|
|
|
| |