Sr. Business Analyst
Closing date :31-01-2023
- Experience 5 years and above
Please share the resume to firstname.lastname@example.org
Contact number 8943032098
"•Knowledge in current computer hardware and software / OS
•Documentation and Prototype Designing
•Application specific Database design understanding
•Software Engineering & Quality Assurance
•Critical thinking / Problem Solving Skills
All the requirements are to be completely documented and explained to all the team members/client/stakeholders and is to be completed as per agreed template shared by Business Analysis Lead. Creation of Use Cases, User Stories, Business Requirement Document, Requirement Traceability Matrix, Functional requirement specification (FRS)/ Functional Specification Document (FSD), System requirement specification (SRS)/ System Requirement Document (SRD) etc. are some relevant documents to be prepared by BA.
•Creating Charts / Diagrams
As a part of documentation, certain aspects has to be expressed graphically for business related information. Diagrams such as Activity Diagrams, Use Case Diagrams, Data Flow Diagrams, Flow Charts etc. need to be part of it. Overall as and when required the UML diagrams need to be part of the graphical representation.
One of the core part of the BA is to identify the Risk involved with the projects and getting them resolved. This will also include legal aspects.
As a BA, it is a good practice to have a BA check on quality before forwarding it to QC/QA Department.
As a Business Analyst, to determine a project’s requirements by extracting them from business or government policies, as well as from current and future users, through interaction and research. Incomplete or improper requirements usually lead to project failure.
Baseline plans are subject to modification, and anticipating requirements that will be needed in the future or that have not yet been considered is essential to successful outcomes.
While complete requirements are essential to project success, the focus must remain on core business needs, and not users’ personal preferences, functions related to trends or outdated processes, or other non-essential modifications.
Requirements often originate from disparate, sometimes opposing sources. Business Analyst must organize requirements into related categories to effectively manage and communicate them. Requirements are sorted into types according to their source and applicability. Proper organization prevents project requirements from becoming overlooked, and leads to optimum use of time and budgets.
Business Analyst must be adapt at translating business requirements to technical requirements. This includes using powerful analysis and modeling tools to match strategic business objectives with practical technical solutions.
At regular intervals in the project life cycle, Business analyst should be safeguarding or protecting the business and user’s needs by verifying functionality, accuracy and completeness of the requirements against the original initiating documents. Safeguarding minimizes risk by ensuring requirements are being met before investing further in system development.
Business Analyst should emphasize on simplicity and ease of use at all times, especially during project implementation. Should be able to meet business objectives which is the goal of every IT project. Should be able to identify and avoid extraneous activities that do not solve the problem or help reach the objective.
Business Analyst should be able to continually verify the requirements and reject implementations that do not advance business objectives. Verifying requirements is accomplished through analysis, test, demonstration and inspection.
Typically, a formal requirements presentation, review and approval session occurs, where project schedules, costs and duration estimates are updated and the business objectives are revisited. Upon approval, the