A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.
At UC Berkeley there has been an increasing awareness of the importance of business analysis (BA) and user experience (UX) in the software development lifecycle. In this article we will discuss the advantages of involving BA and UX practitioners in your development process, when and how to involve them, and the similarities and differences between the two professions.
The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.
These are the main documents produced by a BA over the course of a project...
Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments.
Is documentation a blessing or a curse? If you’re working on an agile project does it get in the way? If you’re updating a core system that runs your company’s business, are you cursing the analyst who didn’t adequately document all the business functionality? Is today’s agile project tomorrow’s core system?
A user of almost any given software system or business application will require precise analytics in order to objectively measure its effectiveness, or the effectiveness of an associated product. These analytics –or reports—therefore, must measure the right criteria at the right time(s) in the right way in order to be useful to the user. For that reason, any newly proposed reporting function requires careful, measured, thoughtful and thoroughly vetted requirements in order to ensure its efficacy.
Business analysis is an important aspect of agile software development projects, but the agile approach is significantly different than the traditional, serial approach of yesteryear. Because the agile approach to business analysis is different the approach to requirements specification is also different, for many traditionalists this will prove to be a significant cultural shock to them at first. In this article I briefly overview how business analysis activities fit into an agile approach, question some of the dogma around documentation within the traditional community, summarize some of the evidence showing that agile approaches are more effective in practice than traditional approaches, and end with strategies for specifying requirements on an agile project.
Defining specifications for the design and development of systems and software is a lot like this classic Gershwin song and what I personally regard as the biggest cause of confusion in the Information Technology field for as long as I can remember, which is over 30 years in the industry. Some people say specifications should be based on the inherent properties of information, others believe it is based on a screen/report or file layout, yet others adamantly believe it should be based on process and data specifications. Interestingly, all are absolutely correct. The difference lies in the perspective of the person and the work to be performed. For example, how we define specifications for the design of an automobile is certainly different than how we specify a skyscraper. The same is true in the I.T. field where we have different things to be produced by different people.
Author: Tim Bryce
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us