Roles and Responsibilities of a business analystRoles and Responsibilities of a Business AnalystOne of the most favored industries to be working in is the Information Technology and ITEScompanies. A very common profile that you must have heard is Business Analyst. The namesounds enticing, but before you decide on embarking on a career as a Business Analyst, you mustbe aware of the roles and responsibilities of a Business Analyst.So how is a Business Analyst and what does he do in any organization? These are the basicquestions this article aims at answering. To begin with, a Business Analyst is one who analyses a business and aims to betterit with the use of Information Technology. He is employed by a company and he has ateam of software developers to assist him. Once a client assigns a project to the company, the Business Analyst understands thevarious nuances of the business and then attempts to solve the problems faced in thecurrent working or he may try to better the current working – whatever the clientwants to be done. The business analyst has to know the workings of the industry in which the client’sbusiness falls under so that he can fulfill his client’s needs and specifications from theproject. To understand the specifications, from a business perspective as the clientwould think of them, a Business Analyst needs to be aware of the norms, laws,working, competitors, software, technical know-how, rules, procedures of the industryand the client’s business in particular. This education about the client’s business is a must so as to draft the client’sspecifications in a format that is feasible to work upon. The Business Analyst canthen understand and envision how the client’s project can be embarked upon by thetechnical team of software developers and programmers. The Business Analyst must also have the technical know-how that is necessary forhim to understand how his technical team will go about working on the project and tosupervise them. Also, if he understands the technological nuances of the project, thenhe can understand the technical team’s problems and help in solving them. Also, hecan explain the client specifications in a format the technical team will understand.
Once the client specifications are properly drafted, and the technical team is briefedabout the project, then they can start working on the technical part of the project. TheBusiness Analyst must be around to help them and to supervise the project to check ifthe timelines assigned to the project are being adhered to. The system which is designed by the technical team of computer engineers andsoftware coders is then tested for errors and if any errors are found they are fixed.Testing of a software designed helps to check for bugs and if the system will workproperly in a live environment.Once the client is satisfied with the working, does the developers work end.The Business Analyst thus works as a bridge between the developers and the end user ( client).System AnalystSystem Analyst / System Analysis: Any system has to be designed and developed according to the requirements. More specifically, asystem has to serve the intended use in the right way. Having a plan and clear-cut idea upfront is thusvital to the entire process of design and development. The required analysis is done by the Systemanalyst. He is the one responsible for handling the overall project from a higher level of view, managingwithin it the specifics of and integrity with the lower programming level of perspective. With sufficientknowledge about the dynamics of every aspect of the system, interactions with programmers,customers and other relevant people System analyst’s job is to get the right solution in the mostefficient way. Let us see more about the role he plays.Get the requirements!Well, a solution to a problem can be really good only if the problem statement is taken in completely.Customers words are the key to figuring out the exact requirement set. As a System analyst, one has tobe the customer’s voice when he drafts out the requirements clearly. Apart from the customerinteractions, it is his job to translate the practical needs of customer into a more technical requirement.Acting as a bridge between the customer and the developers the System analyst has to give the righttranslation of customer’s terms into a programmer’s idea.So, where does the analysis come in?Stating the requirement gathering as just a “translation” can make it seem simple! The truth is that thetechnical documents that the System analysts prepare from the “Use cases” derived from the customerinteractions or marketing documents should take in all considerations of technical feasibility andprogramming aspects/technologies. To do this a reasonable knowledge from the
programming/development side is required. With interactions with the programmers he has to make sure of the feasibility of solution. Cooperation with the development team right through the development phase makes periodic validation/verification possible. Checking for conformance to use case requirements, standards of development and guiding the entire team together forward towards the goal makes the analyst’s job a very critical one for overall success of the software system under development. The Analyst is basically the Information access point for the customer and the marketers. From the design of the system to deployment, he keeps track of all the information in perspective of both the customer and the programming team. This makes him a vital part of the testing phase and deployment phase. As a person who has the best knowledge about practical needs of deployment and usage, he also plays a major role in drafting out the user manuals and other data sheets for the customers. It is pretty clear as to how important the role of system analyst is. A strong base to phase out the actions and plans gives any project a good head start. Thus, it is the System analyst who can be the starting point for having a successful development cycle and really useful system from the customer’s perspective. He can really give the entire team the comfort levels by making a good sturdy base for operations. What is SDLC? different phases of SDLC? What is SDLC (Software Development Life Cycle)? SDLC or Software Development Life Cycle is the life cycle literally of the development of a system or software. This life cycle details all the processes that a system undergoes while it is being designed. That is the basic layman understanding of what SDLC stands for. The steps of the System Development Life Cycle are detailed as below. They show the detailed working of how a system is developed for a particular project. The Software Development Life Cycle (SDLC) starts when a client expresses the need to start a new project. Once the project is in hand, the steps of the SDLC work as: Project Planning: Planning is the core of every process and only effective planning can make a Business Analyst realize if the intended system can really be developed or not. A feasibility study is conducted in this stage to determine if the actual system intended is indeed possible to work upon or not. System Analysis and Requirements Definition: Here, the requirements of the client in the system to be developed are properly analyzed and then a final requirement definition is written by the Business Analyst in consultation with the client, who will be the end- user of the project. This requirements definition is used by the software team of programmers and developers to start the project.
System Design: This is the process of SDLC where the system is actually designed as per the requirements. The process of database design, structure design, nuances of the client/server technology, defining tiers of package architecture are all defined properly in this phase. System Development: This is the phase where the actual project is made. The system‘s software is coded in this phase. Code generation makes the system machine-readable. The code is generated by the technical team of software developers and programmers. The code is generated with the help of languages like C, C++, Java, VB, SQL and tools like debuggers and compilers. System Implementation – Here, the system developed is incorporated in the design of the project. The developers assemble their creations in the previous phases of the SDLC. System Integration and Testing – The system generated is now checked for errors and bugs so to as to ascertain how workable the system developed really is. The System Testing phase shows whether the timelines of the project can be adhered to or how much work is still pending, depending on the number of errors and bugs found. System Acceptance and Installation – Testing in live conditions is an acid test for the system’s success. Testing the project in a replica of live environment will enable the software developing team to ascertain whether the software developed will actually work in live conditions and as per how it was envisioned to work. System Maintenance - Once system is implemented in live conditions, it has to be maintained properly. The software developed may face some changes due to some unexpected inputs or changes due to new personnel in the organization. Hence any problems arising need to be fixed to maintain the system well. What isUsecase diagram and its importance What is a USE CASE ? Importance of USE CASE diagrams People in the Information Technology industry and other allied industries might have heard the term “Use Case “. They might be aware of its importance and how helpful they may be in executing projects, but if you are a newbie in this industry or just have to refresh your knowledge then it might be a good idea to just read up again on Use Cases and their importance. So what is a USE CASE?
The technical definition of a USE CASE is that it is a description of a system’s behavior or aparticular scenario in which a system responds to an external request that originates. An exampleof an external request is a user input.Basically, a use case is helpful to understand the system from the end-user who is ultimately toactually use the system’s point of view. Use cases help to specify and explain the interactionbetween the actors and the system. Now the question that may arise in your head is who is anactor?An actor is the one who initiates an action with the system and the Use Case is what is used as atool to describe the sequences of the course of the action. These sequences of actions betweenactors and system are called scenarios or use case instances. Hence the Use case comprises actorsand scenarios which describe the interactions of the system.This is the simplest way to understand what Use cases are in software engineering and what theydo. Actors could be anybody from persons who are the users of the system to organizations andcomputer systems too. They are basically initiators of the system.Use cases are thus an organized way of categorizing the various system requirements. Allsystem interactions or activities that are important and should be categorized since they are ofvalue to the users of the designed system can be identified by using Use cases.Thus the Use case is nothing but a systematic sequence of requirements, actions and interactionsbetween system and users and vice versa and has some value. Use cases are easy to read andunderstand and hence they are widely used. However, it is worthy to remember that use cases donot specify details of the actions, only their intent and Use cases do not give implementationdetails. They are multi level.Importance of Use cases:Use cases are important because they are in a tracking format. Hence they make it easy tocomprehend about the functional requirements in the system and also make it easy to identify thevarious interactions between the users and the systems within an environment. They aredescriptive and hence clearly represent the value of an interaction between actors and the system.They clarify system requirements very categorically and systemically making it easier tounderstand the system and its interactions with the users. During the analysis phase of theproject’s System Development Life Cycle, use cases help to understand the system’sfunctionality.What is flow chart and its uses A flowchart is very simply a diagrammatic representation of the flow of information. Now thisflow of information could be in a Information Processing System or just an explanation of howan algorithm works. A flowchart typically shows the flow of data in a system, detailing theoperations in a pictorial format which is easier to understand than reading it in a textual format.Besides, a flowchart quite simplistically shows the sequence of the operations taking place in thesystem too.
Hence a flowchart helps in solving a problem by offering an easy to understand graphicalsolution that shows the different operations which are the steps of the solution and the sequenceof those operations. Hence a flowchart is used extensively in IT and ITES companies. Aflowchart can be compared to the blueprint of a building. It shows what the structure of thebuilding is (or algorithm or problem or the information processing system) and shows thebuilding blocks of the structure which comprise the information needed to arrive at the solutionthrough sequential blocks of data. It wouldn’t be wrong to say a flowchart is a sort of a ‘must’ todocument and explain complex and lengthy programs.A flowchart has certain rules that need to be followed while drawing it. These rules are given bya governing body known as the ANSI (American National Standard Institute). There are certainstandard ways of drawing a flowchart with the symbols prescribed by ANSI. Knowledge of thesesymbols is necessary if u want to draw a flowchart. These flowchart symbols are given below:The rectangle in a flowchart denotes processing function or a just a computationalstep while processing. - The oval is used to denote start or end of a program. - The parallelogram is used to denote the input or output steps of a program.
- Connector in a flowchart.- This is used to denote a magnetic tape.- This is used to denote a magnetic disk.- This is used to denote an off-page connector. - This is used to denote “ Display “
- These arrow lines are called flow lines. These are the basic symbols used generally. Now, the basic rules for drawing a flowchart with the above symbols are that: The flowchart is to be read left to right or top to bottom. A process symbol can have only one flow line coming out of it. For a decision symbol, only one flow line can enter it, but multiple lines can leave it to denote possible answers. The terminal symbols can only have one flow line in conjunction with them. A simple example of a flowchart of a purchase and quality inspection routine is below: