o The IT Project Life Cycle o Understanding The Business o Know how to Initiate and Plan a Project o IT Project Execution o Defining and Scoping the Project o Defining a Work Breakdown Structure o Business Process Models and Domain Models o Gathering Business Requirements o Requirements Management o Know Requirements Traceability o Document Business Rules o Interviewing o Joint Applications Development Facilitation (JAD sessions) o Analyzing and Documenting Requirements o Fit-Gap Analysis o Entity Relationship Diagrams o Extract Transform Load o Data Conversions o Object Oriented Analysis o Business Intelligence o Non-Functional (Technical) Requirements o Use Case Diagrams & Narratives o Use Case Analysis, Design and Realization o Communicating Requirements o Identifying a Solution o Service Oriented Architecture (SOA) o Verifying that the Solution Meets the Requirements o Analyzing Buy vs. Build or Both o Unified Modeling Language (UML) o Rational Unified Process (RUP) o Agile Methodologies o Extreme Programming Methodology (XP) o Scrum Methodology (Scrum)
Because that is what it is going to take to stay employed, either as a Contractor or employee. Information about the above topics can be found at: http://www.businessanalysis-therealworld.com
In today's businesses, IT Business Analysts are often referred to as Technical Business Analyst, Business Systems Analyst, Systems Analyst, and other titles. No matter the title, the primary role of the Requirements Business Analyst remains the same; to examine and document the business needs and participate in recommending an appropriate solution to meet those business needs. Specifically, the Business Analyst elicits, analyzes, validates and documents business, organizational and/or operational requirements.
Notice that the word "Requirements" was inserted in front of the title of Business Analyst. This specialty type of Business Analysis is necessary because corporate America does not understand the many different types of Analyst duties. Be aware that many job descriptions will carry the title of Business Analyst but will not describe the duties of a Business Analyst that elicits and documents business requirements. Some positions with a Business Analyst title might require analysis for reporting processes only and is very narrowly focused in regards to the overall duties of a true Requirements Business Analyst.
It should be expected that the requirements for these positions would dictate that a Business Analyst have several years of business experience, in several industries, along with several years of technical IT experience to have the ability to develop business requirements and recommend automated solutions. In today's real-world of IT projects that IS NOT the case, which is why a high percentage of IT projects fail. The Analyst simply does not know how to capture and document project requirements properly.
This discipline is a relatively new role in the IT projects world of corporate America. So new in fact, that most IT Project Managers have not been trained in the processes of Business Analysis, therefore lending to the possible project failures. An experienced Business Analyst may not only have to perform the Business Analysis role but also mentor a Project Manager.
Since this is an evolving discipline, industry is and will be for years to come, in the process of defining and shaping standards and best practices for this role. Business Analysis encompasses a set of tasks and techniques required to identify business needs to determine automated solutions to business problems regardless of technical platform. Without several years of business and technical experience how can these tasks be accomplished?
Business Analysis is one of the most important steps in developing a software solution. It is crucial in identifying and documenting the business needs of customers and stakeholders in order to determine appropriate solutions and approaches to solving business problems, yet, HR departments and corporate middle-management continually staff IT projects with very inexperienced Analysts to handle the tasks.
A software solution needs to address the business requirements of a wide range of stakeholders therefore the Business Analyst often works closely with other functional areas and typically acts as a liaison between users and technical personnel to help solve business problems. Working with all the functional areas, a Business Analyst's main responsibility is to gather, organize, and document requirements in a format that is appropriate to the technical developers as well as business users. A Business Analyst provides the process, questions, and techniques to efficiently elicit and document the information needed from the business users for successful development of IT projects.
In conclusion, be prepared!
This article is about what it takes to become a true Business Analyst. Something that will definitely help is to do a ton of research on the internet about specific topics of Business Analysis. There are very few web sites that cover the entire IT project life cycle processes. To acquire all the knowledge needed would literally take several years of training programs and cost several thousands of dollars. Try to find a reference web site like http://www.businessanalysis-therealworld.com that specializes in Requirements Business Analysis.
About the Author
This author has been in the IT trenches for 41 years. This experience includes roles as a Technical Business Analyst (IT Contractor) for 11 years, 10 years of Project Lead and Management experience, and 20 years software development experience. Additionally, the author is the proud inventor and author of two different programming languages of which he holds copyright privilages, and, the author of the web site and the ebooks at http://www.businessanalysis-therealworld.com.
Topics: Business Analyst, SOA, Service Oriented Architecture. Source: goarticles.com
No comments:
Post a Comment