It is necessary for any business analyst to internalise certain techniques so that they do consistently well in a project. Several projects start with a clear discussion of the requirements, instead of taking into account the issues that have been faced by stakeholders. A step involving enterprise analysis should be initiated in order to do the necessary fact-finding. A business requirements statement needs to be prepared, ahead of devising a solution.
Often project teams start developing products or solutions on the basis of the briefings of the stakeholders. They often fail to understand the fact that, despite the fact as to who informs them about the requirements, the project will fall flat if it fails to satisfy the requirements of the end-users. This problem can be solved to a large extent by the application of usability engineering. It forms an integral aspect of user-centric design. It covers every aspect of the cycle right from Usability Testing to User Centred Analysis to User Centred Design. It forms an integral part of any business analysis activity.
A large number of the software systems are dependent on object-oriented technologies these days. Therefore, it is equally necessary for business analysts to be acquainted with object-oriented techniques pertaining to their field of work. It is necessary to document the requirements, more specifically the functional requirements. Therefore it becomes easier to transform the same into a technical design and finally to a code. The entire process is much less prone to errors.
It is the responsibility of the business analyst to make sure that a proper solution is delivered to the stakeholders and that it is at par with the industry standards. It is up to the business analyst to validate and verify the requirements and then validate the final solution as well. Thus, an analyst should be properly skilled at devising and carrying out user acceptance testing. This also implies that the proper stakeholders are incorporated into the scheme of things.
It has been observed that a number of the problems that surface at the time of UAT activities and system testing emerge out of inferior quality documentation. This occurs as a result of the fact that an analyst often wrongly assumes that the system development team, one that works to devise the solution based on the documentation, possesses the same level of expertise in the domain as the analyst.
It is also necessary to possess vertical specific information. For example if the analyst is working for the IT industry, then a background in the same is desirable. Therefore, if you have been working in the field for some time, like in .net jobs , then you can work as an IT business analyst in the future.
How do you build up on domain skills required for a business analyst?
Im looking for a career change and want to be a business analyst., I have 3 years technical exp. On going through requirements of a bus analyst, I belierve I have all other skills like knowledge of tools, documentation skills, good language and communication skills, experience in liasoning wiht clients etc..
But one area where I lack is th edomain knowledge… how do I build up on it?
I am not very choosy about the domain im looking for…. could be anything, but I need a clear path as to how I can build my domain skills [my current proj is purely tech and offers no scope to gather domain knowledge]
Generally, the best business analysts are domain experts such as accountants, CPAs, for many years and then they “cross over” to their respective IT departments.
They communicate the business requirements in IT-speak to the factory workers in the IT department. They communicate the IT limitations to the business units in normal-business-speak (without all that technical jargon).
You may want to look at the various domains and consider whether or not you have the educational experience to apply for an entry level position in that domain. You may take a step backward in pay, but over time you will build domain knowledge and be able to leverage both your technical and domain experience in a business analyst position.
Another job title you may want to consider is that of “Product Analyst” or “Product Manager”. While the definition of these positions vary significantly from company to company, there generally is a path for aspiring technical folks to move into these types of positions. Experience a job such as this may position you for some types of business analyst work.
The Product Analyst/Manager positions in software companies spend time gathering customer requirements and documenting them for the development team. They are usually involved heavily during the software release cycle, sometimes even leading the QA efforts.
Best wishes and good luck to you.