What is a Business Analyst (BA)? A Business Analyst is the person on a software project who is the liaison between the business people and the technical people in a company. This is a very important job on a software project. The business people who are the stakeholders of the project understand what they need, but are not trained to develop software. The technical team is trained to develop software, but may not really understand the business side of the company. As a Business Analyst, your job is like that of an interpreter. You explain the business needs to the technical team, and you explain the technology needs to the business team. You are the one person on the team who must understand both groups of people, and be able to explain them to each other. This becomes even more important when the project team is geographically distributed. The Day-to-Day Job If you work as a Business Analyst, you will typically be asked to do the following tasks on a software project team: • Elicit project requirements, especially the business requirements • Write the project requirements in a clear, concise manner • Manage the project requirements • Lead requirement reviews • Create and maintain analysis or domain models for the requirements • Work with the project designers and architects to make sure their designs conform to the project requirements • Work with the test team to make sure the tests adequately cover the requirements. • Run the User Acceptance tests Elicit means to call forth or draw out. You are not expected to know all of the requirements of a software project; rather you are expected to know how to get the requirements from people or other sources. This may involve research and reading of documents, running a survey of a group of people, or conducting personal interviews. Usually you will be working to elicit business requirements, but you may also be responsible for finding and documenting the technical requirements of the software project. After the requirements are elicited, you have to write them down. They are no good in your head where no one else can see them. In Information Technology (IT), there are usually two categories of requirements – Use Cases and Non-Functional Requirements. These are typically recorded using company standard templates. Once the requirements are written, they have to be maintained and managed. You may combine requirements, divide requirements, add requirements, or delete requirements. Also, your project manager may want a variety of reports about the requirements. These often concern items such as which requirements are assigned to which iteration or work group, the state of completion of the requirements, or the priorities of the requirements. You may also be in charge of (or very involved with) a group that manages change to the requirements. You are the writer of the information, but other people are ultimately responsible for deciding if the requirements are correct or useful for the project. You will lead reviews of the requirements to gain approval for the requirements. Once the requirements are approved, you may be asked to create analysis or domain models for the requirements. This involves identifying and documenting the business objects that are indicated by the requirements. At some point, a software architect or lead designer will create software designs from the requirements. You may need to work with them to verify that the designs they create actually implement all the requirements. At some point, a test team will create software tests from the requirements. You may need to work with them to verify that the tests they create actually verify all the requirements. Finally, the software is nearly complete. The users of the software want to test it before it is deployed to make sure it meets their needs. This is called a user acceptance test. You will be in charge of designing the test session, scheduling, and running the session when the users test the software. You will also report the results back to the project team.
Article Source: http://www.kokkada.com
Geri Schneider Winters is the primary author of the popular book Applying Use Cases: A Practical Guide, and the President/CEO of Wyyzzk, Inc., a software engineering consulting firm at www.wyyzzk.com Her blog and website for Business Analysts can be found at www.writingusecases.com
Please Rate this Article
5 out of 54 out of 53 out of 52 out of 51 out of 5
# of Ratings = 1 | Rating = 4/5
Powered by Article Dashboard
