FAQ – Frequently Asked Questions about Business Analysis and BA-EXPERTS

Breaking into business analysis — like any other profession — is a non-trivial undertaking. It can become prohibitively expensive if you have to pay for it out of your own pocket, in particular if you rely exclusively on instructor-led training. To help everyone become a Business Analyst within their budget, we wrote a post with several different business analysis learning opportunities for a variety of budgets.

You can read about another way to start your business analysis career is to do a Business Analyts’s Skills Evaluation (BASE). Read more about it in this post.

One of the primary tasks of the business analyst role is helping the business community discover and express their needs in the form of requirements. In the past, many people called this activity “gathering requirements”. The problem with that nomenclature was the insinuation that requirements were just lying around, waiting for someone to pick them up. In reality, nothing could be further from the truth. To better express what the task really entailed, the concept of “eliciting requirements” was proposed and has generally been adopted by the business analyst community. What does this have to do with the magic Business Analysis hat?

One of the origins of the word “to elicit” is “to draw forth, as in magic…“. Based on our experience in eliciting requirements from subject matter experts, we decided that that definition sometimes carried the best connotation of the word. We basically created the Business Analysis hat to symbolize that you might sometimes have to do magic tricks to get the right requirements from the right people on your project.

There is a second reason for the Business Analysis hat. Although the cadre of “Business Analysts” is growing, business analysis is often performed by people with job titles such as “Product Owner”, “CEO”, “Developer”, “Product Manager”, “Project Manager”, SME, and many others. The key to ensuring that business analysis is a positive force for change is that people doing it have the appropriate skills and techniques to do it well. Whether those individuals have the title “Business Analyst” is a question of the organizational structure, as bestowing the title does not inherently ensure the quality of the outcome. We pride ourselves on being able to bestow upon anyone, regardless of job title, the ability to perform specific business analysis tasks even though it is not their primary responsibility. That is why we often refer to “anyone wearing the business analysis (BA) hat.”

According to industry reports, the most significant contributing factors to project failure could be traced directly to poor requirements understanding and definition. In a recent Sequent Computer Systems Inc. study of about 500 IT managers the most frequently named cause of project failure was poorly defined and changing requirements. A summary of other studies on the dominant reasons that projects fail indicates that the three most common failure points in developing, enhancing or changing business systems today are:

• Incomplete and/or incorrect business requirements and technical specifications
• Incomplete or ineffective testing (often due to poor requirements)
• Improperly managed projects (Either incompetent project management, or incomplete and incorrect requirements)

Improve your requirements skill set with one of our eCourses, eBooks, or Classroom training.

A large number of information technology projects start with a solution that “has to” be implemented. The solution may or may not be the right decision. Whereas it is in IT’s best interest to deliver the solution that the end-user wants, the better the analysis of the thought process behind the decision, the easier it is for them to deliver a working system. Without sufficient understanding, IT may be implementing a solution that will not work.

One good starting point to analyzing a business area is the business analysis technique Problem Analysis.

Business analysis is the evolving discipline that deals with identifying your business information technology (IT) needs. It includes expressing these needs as business requirements, processes and rules (hereafter business requirements) that the business community and information professionals both interpret the same way. Business requirements serve as the basis for development, testing, deployment, and use of your future information systems. They are the starting point for lifecycle management and business driven development. In a nutshell, these are the critical success factors for delivering information technology that the business community needs and wants.

You can get more detail in our eCourse “Business Analysis Defined”? or in our eBook with the same name or just watch our FREE KnowledgeKnugget™ “An Overview of Business Analysis for Information Technology”.

Business analysis for Information Technology projects is the process of analyzing how the business community does whatever the business community does and identifying potential areas for improvement. The improvements quite often include introducing new or updating existing IT systems, but the focus should be on helping the business community become more efficient or effective.

The primary outcome out of the business analysis process is a set of requirements at varying levels of detail that define a potential solution. Depending on the software development approach this set can be business, stakeholder, solution, and transition requirements for traditional approaches or in user story format for agile development. The tools and techniques that business analysts use in this process are also described in a KnowledgeKnugget™ by BA-EXPERTS

We have developed 5 rules for writing a requirement that is simple, well-structured, non-ambiguous, in scope of the project, and testable:

• Rule 1 Be Simple and Complete Sentences
• Rule 2 Emphasize “What” not “How”
• Rule 3 Be Relevant, Unambiguous, and Clear
• Rule 4 Be Understood by Knowledge Peers
• Rule 5 Be Objectively Measurable (Testable)

Learn more about the 5 techniques in our eBooks and eCourses.

• If you use user stories: eCourse: Writing User Stories or eBook: Writing Effective User Stories
• For natural language requirements: our eCourse Writing Requirements for IT — Simply Put! followed by: Functional AND Non-Functional Requirements – Simply Put!. If you prefer reading, our eWorkbook: How to Write Effective Requirements for IT Solutions also contains online exercises.
• If you prefer classroom training check out How to Write, Document, and Manage IT Requirements

User Stories are found mostly in the agile world but they are also very useful in a traditional software development environment. User Stories complement and supplement any other business analysis techniques that you are using. User Stories will make your requirements elicitations techniques easier and more complete without adding an extra burden of effort. As a bonus, this technique can also help in very early cost forecasting when it is too early to “estimate”.

For more watch our FREE KnowledgeKnugget™ “Business Analysis Using User Stories“. We also offer an eCourse, an eBook, and classroom training for User Story Writing.

Writing effective IT requirements is a critical skill for business analysts and anyone wearing the business analysis hat meaning they are representing the business interests on an IT project. The challenge lies in defining business IT needs that other audiences will interpret as the author intended and use to design the right solution. To improve the requirements definition process, the International Institute of Business Analysis® has defined several types of software requirements including different levels of detail. According to the IIBA® there are Business, Stakeholder, Solution, and Transition Requirements. Each of these requirement levels is useful for a different time in your project or initiative.

For an introduction to the topic, watch our FREE KnowledgeKnugget™ What Are Requirements?

A Requirements Gathering Workshop is a time-compression workshop that focuses on quickly capturing, clarifying and confirming business, stakeholder, solution and transition requirements for an information technology solution. It is attended by a cross-functional group consisting of subject matter experts, product owners, business analysts, technical experts, and project leaders.

Our training course How to Facilitate Requirements Gathering Workshops introduces participants to tools, techniques and tricks for facilitating and supporting these workshops. It will speed up the actual session if the participants have taken this course but it is not mandatory. There are no pre-requisites for a JRP session.

You should consider process modeling when you are defining functional and non-functional solution requirements. To change or automate any part of a business process (e.g., “Transact Credit Card Payment”, “Modify Customer Payment Plan”, “Reorder Products from Vendor”, etc.), you need to understand how it currently works and how it should work in the future. A process model makes this job much easier than describing the procedures in natural language.

For an introduction to the topic, watch our FREE KnowledgeKnugget™ Business Process Analysis for Requirements Discovery.

A Data Flow Diagram (DFD) is a great tool for visualizing how information is created and consumed within a business process. It shows the source of information, the transformation and transportation of data through the individual processes, and its ultimate destination. This is a prefect tool for discovering and presenting disconnects that are a very common cause of process problems.

For a short overview of DFDs watch the KnowledgeKnugget™ How to Draw Dataflow Diagrams (DFD) for Business Analysis. For a more in-depth treatment of the topic read the ebook or take our ecourse Dataflow Diagrams — Simply Put!.

An Activity Diagram (more commonly, Swim Lane Diagram) depicts the sequence of actions that ultimately deliver the desired outcome. It shows Control Flow through the process while ignoring the data transformation, transportation, and storage.

Learn about Activity Diagrams in our instructor-led business analysis training course Process Modeling to Gather Business Requirements

Either of these tools can provide invaluable insights into the inner workings of business processes. It is up to the one wearing the business analysis hat to determine which provides the most value for their particular situation. In many cases, you would be best served to create both models and bounce them off of each other to flush out non-obvious disconnects.

A data model expresses constraints that a technological solution will place on the business community. If the business experts can not identify the constraints on the model, they will have difficulty determining what it means to accept the constraints. At the very least, the business experts should be conversant with the concepts of cardinality, relationships and attribute assignment. We present these topics in our seminar Business Information Modeling to Gather Data Requirements. For a brief overview watch our KnowledgeKnugget™ Business Data Modeling – Getting Informational Requirements for IT.

An Entity-Relationship diagram (ERD) is a model of the static structure of the things about which you need to store data. A data model, technically speaking, is a broader category that encompasses ERD’s as well as several other conventions for creating diagrams of your data. The Entity-Relationship diagram, however, has become so widespread that the two terms are most often used interchangeably. Our workshop Business Information Modeling to Gather Data Requirements presents techniques for creating and using ERD’s for identifying and defining business data requirements.