(Solved Homework): I need research paper on this topic and that should be almost 4-5 pages. Business Analyst Role…

Business Analysis is the task of understanding business change needs, assessing the business impact of those changes, capturing, analysing and documenting requirements and supporting the communication and delivery of requirements with relevant stakeholders. A business analyst is someone who analyzes an organization or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology.

The importance of a IT business analyst in software industry, in a modern managed development team is hard to overstate. This person helps to shape the project from its very inception by facilitating communication between development team and upper management and executives. This effective communication is what in many ways makes managed teams work. It allows customers to save management resources, while teams are able to deliver on time and within budget.

Being a business analyst is a bit like being an architect but instead of building a house, they develop or update a computer system. A business analyst takes responsibility for talking to the business users of the computer system to understand their needs. Instead of producing plans, the business analyst produces ‘requirements’ which clearly state the business needs and align with business processes. The requirements are then used by the IT team or an external supplier to build or modify the system. While the system is being built the business analyst is on hand to deal with issues and questions, and to support the business in implementing the required changes to make effective use of the new system.

The business analyst role is often seen as a communication bridge between IT and the business stakeholders. Business analysts must be great verbal and written communicators, tactful diplomats, problem solvers, thinkers and analysers – with the ability to engage with stakeholders to understand and respond to their needs in rapidly changing business environments. This can often involve dealing with very senior stakeholders and can often involve challenging and questioning to ensure that value for money is achieved from IT developments.

History of evolution of business analysts:

Throughout the late 1980s and 1990s, organisations evolved their IT systems to take further advantage of computer technology – but many projects failed to deliver the desired benefits often because of a focus on delivering ‘technology’ at the expense of business needs. During this period, the role of the “Business Analyst” emerged requiring a deeper understanding of the business and the development of relationships with stakeholders at all levels. As business stakeholders became increasingly technology aware, the business analyst role evolved to support them in achieving their goals while constantly balancing conflicts between business needs and limited IT resources.

After 2000’s or millinium, increasing use of the internet placed even greater demands on IT departments which were increasingly outsourced or off-shored. Organisations themselves became increasingly globalised and more complex as did their IT infrastructures, often containing hundreds (even thousands) of different systems. Agile emerged as a more flexible way of developing and updating IT systems in rapidly changing business environments. During this period, ‘Business Analyst’ has earned a lot of importance for many project and business change roles. Different views emerged of the business analyst role, from being a strategic thinker driving change within the organisation, through acting as a process improvement expert and being responsible for eliciting and documenting requirements for IT systems.

However, the world of software outsourcing has caught up to the practice of providing business analyst services only after millenium. And while majority of larger companies include business analysts as part of their managed teams, some clients still have certain misconception about their role and importance. People sometimes are not sure whether they need a business analyst for their project at all and if they do, whether they should try to hire one or try to outsource.

Responsibilities of Business Analyst :

A business analyst is one of the key members of the project. From the very beginning, a business analyst should closely work with stakeholders to understand their vision of the project and translate it to all sides. So, exactly what does a business analyst do?

Typical business analyst responsibilities on a research and development project in IT companies include:

• Defining the scope of the project
• Gathering project requirements
• Translating requirements to the team
• Performing acceptance testing

Defining the scope of the project

A business analyst should define an ultimate vision of what the project should look like early on, effectively limiting the scope of the development. A precisely defined project scope will help the team to prioritize features in order to deliver a minimum viable product as early as possible. It also allows to assess required resources and potential risks of the project and produce approximate estimates.

In order to determine scope of the project and gather all the necessary requirements, business analyst also needs to research information, related to the project. This can include competitor research, document analysis, brainstorming, prototyping, and other methods, and allow business analyst to gain clear understanding of business needs related to the project, thus facilitating requirement gathering.

Gathering project requirements

Requirement gathering is what people think about when they hear the words business analysis. This task takes a unique blend of expertise that simply cannot be completed by any other person on the project.

The source of business requirements is project stakeholders. Stakeholder is a term used to describe everyone who will be affected by the final product, therefore having a stake in how it will turn out. This includes customers, sponsors, senior managers, end-users, etc. With a research and development outsourcing project, the requirements are usually gathered directly from outsourcers.

People, who consider formal requirement gathering to be unnecessary, will often cite the ease and importance of verbal communication as their main argument. However, even in Agile methodology, where verbal communication is the king and the amount of written material is reduced in order to facilitate face-to-face discussions, business analyst takes a prominent role on a development team.

In an ideal Agile world development team and stakeholders should be co-located, allowing them to efficiently discuss every requirement face-to-face at every step of the development. In this case, the role of business analyst in software development is to bring them together for meetings and facilitate discussion between them.

However, this is never the case in software research and development outsourcing where developers and stakeholders are geographically distributed. In this case, agile business analyst is reverted to a more traditional role of gathering and translating requirements.

Business analyst carefully evaluates the needs of stakeholders based on their objectives and concerns. He or she needs to understand how stakeholders expect the system to work and formulate requirements based on those expectations. By acting as a bridge between stakeholders and developers, business analyst brings understanding of not only “how” the work needs to be done, but also “why” it needs to be done in that particular way, providing essential understanding for an agile team.

Requirement specification

After requirements have been gathered, the next step is to formalize them by creating a written specification. This means that requirements should be written in a document that can be shared with stakeholders. This requires a specific set of skills and techniques that will allow to present requirements in a precise manner that will be clear to stakeholders and useful to developers.

Translating requirements to the team

After a requirement specification is written and reviewed by stakeholders, it needs to be presented to the development team. The team needs to understand all requirements correctly and get answers to all questions that they might have. From the way business analyst understands the team, their strong and weak points, and their level of understanding of business domain, largely depends how well he or she will be able to communicate the necessary information.

Agile projects often operate on a basis of user stories – small written representations of particular user needs or ways in which they should be able to use software, coupled with face-to-face discussions on a subject. User stories can be used on their own, however, in an outsourced project, it is more efficient to couple them with a more standard full-fledged functional specification. This combined approach allows the team to get a better understanding of what is required with user stories describing core features, functional specification covering all the edge cases and outlining formal requirements of the client, and business analyst being always available to clarify any questions and discuss features if needed.

Performing acceptance testing

Business analyst needs to check whether an implemented feature meets all requirements. In order to do this, software should be tested to make sure that it can correctly perform all required activities and is suitable for regular business use. Acceptance testing is usually performed at the last stages of feature development and signifies that the product is complete and ready to be put on the market.

Business analysts also often accompany requirement specifications with diagrams that serve as a means to visualize complex requirements and ensure that both the team and stakeholders are on the same page. Diagrams often serve as a visualization of various processes and data flow. There are two standard sets of notations, that business analyst use for creating diagrams: UML or BPMN. The former is great for developers, while the latter allows to effectively visualize a business process, which is useful for stakeholders and executives. Each of these sets of notations can be used to create various diagram types in order to describe a product from different perspectives.

One of the most frequently used diagram types are process flow diagrams, which are also called Swimlane Diagrams. They split parts of the process by actors, making it clear who participates in the process and what roles they perform. Such diagrams may be hard to read at first, but if all parties know how to read them, they can serve as a very useful guide helping to understand the relation between different components of the system and how they interact with the user to create a single, continuous process.

In some cases, business analysts can also produce prototypes and mock-ups, allowing them to directly visually represent how user interface should look like. These types of deliverables allow to confirm and elicit requirements and give better understanding of what needs to be done to the team.