February 21st, 2005, 9:58 am
IT Business Analysts tend to be involved at either end of the development project lifecycle (or, of course continually if taking a prototyping / JAD approach). Their main responsibility is to define what the system is supposed to do, and ensure that the delivered system does it. Defining requirements usually involves talking to users, management and the technology teams for the "new" system, as well as those who have systems that will interface with yours. Take this mush of ideas, wish list, dreams and business process description and turn it into a coherent set of business requirements. Business requirements cover process, data, interfaces, as well as operational considerations such as performance, availability, security, volumes. Around the same time as defining the requirements, you may be involved with drawing up the user acceptance test (UAT) plan, which is aimed to ensure that all the requirements are met. Depending in your organisation, you may also be involved with executing the test as well. Different project methodologies will demand different levels of involvement from BAs through the rest of the lifecycle. In some cases, you will be writing functional requirements (that turn the business requirements into a clear system description), signing off or selling to the business the technical design, inspecting prototypes and so on. Hope this helps.