SQL Server Interview questions :- Find the second highest ?

Visual Models Used by Business Analysts

Visual Models Used by Business Analysts

Today we’re going to go through 22 different models BAs use in their work. You may not be aware of all 22 of them, so even if you’re familiar with a few, keep your eyes open for new ones you can use.

While it will be unnecessary to use every model for every project (the samples are drawn from experience across 10 years of BA work in 6 difference companies), the more models you know, the more likely you’ll be able to apply the best model to keep the requirements process moving faster in the situation you find yourself in.

#1 – Activity Diagram

What They Do: Activity Diagrams break the process down in detail and are great for being sure you don’t miss any steps. They are good complements to use cases since they provide a visual picture of the text describing the basic, alternate, and exception flows.

What They Look Like: An Activity Diagram illustrates the steps a system undertakes to deliver an outcome and the procedural logic required to proceed through those steps. Activity Diagrams can be completed as a workflow diagram or in a more formalized version in UML notation.

#2 – Business Domain Model

What They Do: Business Domain Models clarify the information created and managed by an organization without diving deep into the database structures. Creating and walking through a model like this can often clear up misunderstandings and get everyone speaking the same language.

What They Look Like: In a Business Domain Model, each key concept gets a box. Important attributes for each concept are listed within each box. Lines connecting the boxes show the relationships between concepts.

#3 – Competitive Comparison Matrix

What They Do: Competitive Comparison Matrices compare the current state or a potential future state of a product or system to that of an organization’s competitors. This kind of understanding can help significantly with prioritization as it clears up what requirements are important to gain a competitive advantage or simply catch up in the marketplace.

What They Look Like: Competitive Comparison Matrices can be presented in many different forms. They often include a list of competitors on one axis and a list of features on the other. Then each box in the matrix is filled in to identify the competitor’s offering for each feature. In the real-world sample provided in the Pack, we developed a matrix/roadmap combination that fits easily on one PowerPoint slide.

#4 – Data Flow Diagram

What They Do: A Data Flow Diagram illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.

What They Look Like: Data Flow Diagrams show the data sources, data processes, and data stores. The BABOK® Guide identifies two formal notations for representing data flow diagrams: Yourdon and Gane-Sarson. It’s possible to create an informal data flow diagram as well, which typically takes the form of a workflow diagram.

#5 – Data Model

What They Do: While the Business Domain Model illustrates a high-level representation of the information managed by an organization, a Data Model goes deep into the database structure. Mapping data and creating new tables or attributes often has a direct impact on reporting and other system functionality. Even while this is a more technical model, your business stakeholders often have many relevant concerns.

What They Look Like: Most Data Models contain a matrix of attributes that helps your development team know exactly what data fields to create, along with their associated data types and allowable values. In other situations, a Data Model includes a mapping from one information source to another.

#6 – Evaluation Criteria and Recommendation Summary

What They Do: Evaluation Criteria and Recommendation Summaries are useful when evaluating off-the-shelf software, comparing potential vendors to engage, or even in preparing to interview job candidates. They will help you gain clarity on what your options are and make decisions from the information instead of untested opinions.

What They Look Like: Evaluation Criteria list specific ways that a potential solution will be evaluated to determine if it’s desirable or acceptable to stakeholders. A Recommendation Summary provides supporting detail to back up a recommendation, ideally made based on previously agreed to Evaluation Criteria. Both Evaluation Criteria and a Recommendation Summary are often organized visually for ease of scanning, review, and comparison.

#7 – Feature Brainstorming Mind Map

What They Do: You know that early stage of the project when everything is fuzzy but you absolutely need to get something down on paper? You need a way to keep ideas organized while keeping it easy to add new ideas and other relevant information. That’s a perfect scenario in which to create a Feature Brainstorming Mind Map – this visual model captures ideas from your stakeholders when it’s not yet time to invest in a detailed scope statement.

What They Look Like: A Feature Brainstorming Mind Map contains a central node for the project or product under discussion and a branch for each high-level area of exploration. Ideas, concerns, and feature requests can be captured and linked back to each branch.

#8 – Feature Matrix

What They Do: Have a complex set of features to track against? Looking for a simple requirements tracking tool to manage your BA work? A Feature Matrix can be used to analyze, rank, and assess the architectural impact of multiple features, or track other attributes that are important to your project.

What They Look Like: A Feature Matrix lists each high-level feature in a row of a spreadsheet. Then, columns are added to capture critical pieces of information, such as a feature description, priority, state, and risk. Each box is filled in with appropriate information for each feature.

#9 – Feature Prioritization and Stakeholder Matrix

What They Do: Oftentimes different stakeholders are needed for different parts of the project. They may also have competing priorities that need to be reconciled. AFeature Prioritization and Stakeholder Matrix is a specific type of Feature Matrix that addresses both concerns.

What They Look Like: For this type of Matrix, each feature is listed as a row in the spreadsheet with columns for each corresponding stakeholder and individual priority assessment. An additional column can be used to roll up priorities and with a simple calculation you’ll have useful information for establishing an organization-wide priority assessment.

#10 – Feature Roadmap

What They Do: A Feature Roadmap can be used to show how your project investments have and will yield demonstrable value to the business. They are useful for high-level summaries given to top executives and boards of directors.

What They Look Like: A Feature Roadmap contains 4 boxes – one for your past state, one for your current state, one for your target future state, and one listing the benefits of attaining the future state. Each box contains 2-3 short bullet points. Graphics can be added to emphasize key elements.

#11 – Navigation Map

What They Do: A Navigation Map helps you keep the big picture perspective on how the user interface flows. I often review a Navigation Map before starting a wireframe for a new screen. With stakeholders, a Navigation Map is a useful tool to set the stage for user interface or use case reviews.

What They Look Like: Essentially, each screen in the system is represented by a box. Lines with arrows connect the boxes together and show how the user can navigate through the screens.

#12 – Organizational Chart

What They Do: An Organizational Chart represents the organizational hierarchy in place for an organization or a part of an organization. Organizational charts can be used as part of stakeholder analysis or to model new work groups to be created as part of responding to organizational change.

What They Look Like: Organizational Charts typically contain a box for each employee. Lines are used to connect managers to direct reports and show the functional hierarchy in place within the organization. Organizational Charts can be created at multiple levels of granularity and may show departments, teams, functions, or individuals filling specific roles.

#13 – Performance Report

What They Do: A Performance Report shows the results from a project, project phase or business activity. Looking at past data can help stakeholders make faster and more informed decisions about next steps, ensuring that the organization is learning from its own activities and results.

What They Look Like: Most typically, a Performance Report is captured as a matrix. Each line represents an important element of the project, phase, or activity. Columns are used to identify appropriate metrics. Boxes are filled in with measures for each element.

#14 – Process Flow Diagram

What They Do: Process Flow Diagrams are an intuitive way for stakeholders to understand the organization’s fundamental processes, get clarity on how work gets done, and appreciate how value is delivered. They also put other requirements activities in context. For example, a business process diagram can help facilitate more effective use case reviews by providing context for how the system functionality will support the business process.

What They Look Like: Like Activity Diagrams, Process Flow Diagrams exist in multiple forms. Most BAs create simple workflow diagrams that show the end-to-end business process.  A smaller subset of BAs use BPMN (Business Process Modeling Notation) to create more formalized diagrams. (We’ve included examples of both in the Visual Model Sample Pack.)

#15 – Process Improvement Progress Report

What They Do: When we improve a business process, we expect to see results. But how do you communicate the changes and results to executives? Commonly, a list of bullet points is created to identify changes and improvements. Taking a more visual approach, a Process Improvement Progress Report visually shows improvements made to a business or technical process as the result of a project.

What They Look Like: A Process Improvement Progress Reports contains models of the past, present, and target future states of the process and uses visual cues, such as color codes, to show the changes.

#16 – Scope Model

What They Do: The fundamental question to answer in many projects is what is in vs. out of scope. A Scope Model is a visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.

What They Look Like: Scope models can take many forms and how you decide to put one together is typically driven by what project factors are driving scope. Technical integration requirements are typically represented by a System Context Diagram (more on that below).  Business needs are typically represented by a high-level business process. Feature-driven projects, such as a product for an end user, are often accompanied by a visual representation of functionality.

#17 – Stakeholder Map

What They Do: A Stakeholder Map is a visual diagram that depicts the relationship of stakeholders to the solution and to one another. Stakeholder Maps visualize the temporary structures put in place for a project to show who is responsible for what and how different artifacts get reviewed, approved, and ready for implementation.

What They Look Like: A Stakeholder Map is a lot like an Organizational Chart, except that it lays out the temporary team structure put in place to run a project instead of a permanent structure to run an organization. It can be very useful in clarifying stakeholder roles and responsibilities and identifying gaps in your business analysis plan.

#18 – SWOT Analysis

What They Do: When stakeholders are stuck figuring out how to solve an issue, whether that’s a minor issue in the project or a strategic issue facing the organization, a SWOT (Strengths, Weaknesses, Opportunities, and Threats) Analysis can clear the air and pave the way toward improved decisions.

What They Look Like: A SWOT Analysis contains 4-boxes, one for each of the four elements (Strengths, Weaknesses, Opportunities, and Threats). Within each box, bullet points are used to list appropriate information.

#19 – System Architecture Diagram

What They Do: A System Architecture Diagram identifies the system components and how they interact as part of the solution. This can help you figure out how to best organize the detailed requirements. It can also help you communicate the constraints of the solution to business stakeholders or help them see why particular requirements need to be addressed.

What They Look Like: A System Architecture Diagram contains an element for each key piece of technology. Lines are used to connect interconnecting or integrated components. Visual hierarchies can be used to link technical components to user-facing features.

#20 – System Context Diagram

What They Do: In today’s world of integrated components, it’s difficult to work on one system without impacting others. A System Context Diagram is a useful tool for confirming scope with business and technical stakeholders and ensuring you address all necessary integration requirements in your analysis.

What They Look Like: A System Context Diagram contains a central box for the primary system and additional boxes or circles for each potentially impacted system. Lines are drawn to identify integration points and specify what type of information is passed from one system to another.

#21 – Use Case Diagram

What They Do: A Use Case Diagram is useful on a project with many use cases to get the big picture of who is using the system and what functionality they can execute. The diagram can be used to establish context before an individual use case review meeting or to confirm the functional scope of a system.

What They Look Like: A Use Case Diagram is a UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them. Actors are represented by stick figures, use cases by ovals, and relationships by connecting lines.

#22 – User Interface Wireframe

 What They Do: A User Interface (UI) Wireframe is a visual rendering of how a specific screen to be implemented as part of a software solution will be laid out. They are useful in generating “yes, but” conversations and eliciting information stakeholders don’t think of until they see what an application might look like.

What They Look Like:  UI Wireframes, also often called Prototypes or Mock-Ups, can vary in fidelity, or the degree to which the presentation of the UI is intended to be realized in the final application.

A low-fidelity UI prototype may show the general layout of the screen but not the specific UI elements.

A medium-fidelity UI prototype will show the UI elements on the screen but may not represent the actual look.

A high-fidelity UI prototype, often called a rendering, will represent exactly how the UI should look and feel once implemented.

 In last exam covered the below

Ø  Athematic & Reasoning  

Ø  SQL

Ø  Design

Ø  May ask Testing scenarios

You can also prepare the below….

Ø  Prepare on SQL ….

Ø  Puzzles to check your analytical skills...

Ø  You might be given a scenario and asked to gather requirements and use cases...

Ø  You might be asked questions on UI of any application they are aware of...

For SQL basics ( Complete the list given in left side of the page)

http://www.w3schools.com/sql/

for Design:

Please check attached zip file

 Install Visual Paradigm from… http://www.visual-paradigm.com/download/vpuml.jsp

Use this for the floating license setup…

Server : trott

Port:1999

Password:Tech

now check the g drive for the other documents

BA Technical _process

BA technical – process

 

First, take a look at this process flow below which shows how the 8 steps fit together and how you might iterate through them on a typical business analyst project.

The difference between Requirement and specification

First, take a look at this process flow below which shows how the 8 steps fit together and how you might iterate through them on a typical business analyst project.

Step 1 – Get Oriented

Often as business analysts we are expected to dive in to a project and start contributing as quickly as possible to make a positive impact. Sometimes the project is already underway. Other times there are vague notions about what the project is or why it exists. We face a lot of ambiguity as business analysts and it’s our job to clarify the scope, requirements, and business objectives as quickly as possible.

But that doesn’t mean that it makes sense to get ourselves knee-deep into the detailed requirements right away. Doing so very likely means a quick start in the wrong direction.

Taking some time, whether that’s a few hours, few days, or at the very most a few weeks, to get oriented will ensure you are not only moving quickly, but also able to be an effective and confident contributor on the project.

Your key responsibilities in this step include:

Clarifying your role as the business analyst so that you are sure to create deliverables that meet stakeholder needs

Determining the primary stakeholders to engage in defining the project’s business objectives and scope, as well as any subject matter experts to be consulted early in the project

Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.

Understanding the existing systems and business processes so you have a reasonably clear picture of the current state that needs to change

This is where you learn how to learn what you don’t know you don’t know, so to speak. This step gets you the information you need to be successful and effective in the context of this particular project.

Step 2 – Discover the Primary Business Objectives

It’s very common for business analysts and project managers to jump right in to defining the scope of the project. However, this can lead to unnecessary headaches. Uncovering and getting agreement on the business needs early in a project and before scope is defined is the quickest path forward to a successful project.

Your key responsibilities in this step include:

Discovering expectations from your primary stakeholders – essentially discovering the “why” behind the project. (Our BA Essentials Master Class covers 7 different business analysis techniques that can be used as part of this discovery.)

Reconciling conflicting expectations so that the business community begins the project with a shared understanding of the business objectives and are not unique to one person’s perspective

Ensuring the business objectives are clear and actionable to provide the project team with momentum and context while defining scope and, later on, the detailed requirements.

Discovering the primary business objectives sets the stage for defining scope, ensuring that you don’t end up with a solution that solves the wrong problem or, even worse, with a solution that no one can even determine is successful or not.

Step 3 – Define Scope

A clear and complete statement of scope provides your project team the go-forward concept to realize the business needs. Scope makes the business needs tangible in such a way that multiple project team participants can envision their contribution to the project and the implementation.

Your key responsibilities in this step include:

Defining a solution approach to determine the nature and extent of technology and business process changes to be made as part of implementing the solution to the primary business objectives

Drafting a scope statement and reviewing it with your key business and technology stakeholders until they are prepared to sign-off or buy-in to the document.

Confirming the business case to ensure that it still makes sense for your organization to invest in the project

Scope is not an implementation plan, but it is a touchstone guiding all of the subsequent steps of the business analysis process and tasks by other project participants.

Step 4 – Formulate Your Business Analysis Plan

Your business analysis plan will bring clarity to the business analysis process that will be used to successfully define the detailed requirements for this project. Your business analysis plan is going to answer many questions for you and your project team.

Your key responsibilities in this step include:

Choosing the most appropriate types of business analysis deliverables, given the project scope, project methodology, and other key aspects of the project context

Defining the specific list of business analysis deliverables that will completely cover the scope of the project and identifying the stakeholders who will be part of the creation and validation of each deliverable.

Identifying the timelines for completing the business analysis deliverables

In the absence of defining a credible and realistic plan, a set of expectations may be defined for you, and often those expectations are unrealistic as they do not fully appreciate everything that goes into defining detailed requirements.

Step 5 – Define the Detailed Requirements

Detailed requirements provide your implementation team with the information they need to implement the solution. They make scope implementable.

Without clear, concise, and actionable detailed requirements, implementation teams often flounder and fail to connect the dots in such a way that delivers on the original business case for the project. 

Your key responsibilities in this step include:

Eliciting the information necessary to understand what the business community wants from a specific feature or process change.

Analyzing the information you’ve discovered and using it to create a first draft of one or more business analysis deliverables containing the detailed requirements for the project.

Reviewing and validating each deliverable with appropriate business and technology stakeholders and asking questions to fill in any gaps.

Effective business analysts consciously sequence your deliverables to be as effective as possible in driving the momentum of the project forward. Paying attention to the project’s critical path, reducing ambiguity and complexity, and generating quick wins are all factors to consider when sequencing your deliverables.

Step 6 – Support the Technical Implementation

On a typical project employing a business analyst, a significant part of the solution involves a technical implementation team building, customizing, and/or deploying software. During the technical implementation, there are many worthwhile support tasks for you to engage in that will help drive the success of the project and ensure the business objectives are met.

Your key responsibilities in this step include:

Reviewing the solution design to ensure it fulfills all of the requirements and looking for opportunities to meet additional business needs without increasing the technical scope of the project.

Updating and/or repackaging requirements documentation to make it useful for the technology design and implementation process.

Engaging with quality assurance professionals to ensure they understand the business context for the technical requirements. This responsibility may include reviewing test plans and/or test cases to ensure they represent a clear understanding of the functional requirements.

Making yourself available to answer questions and help resolve any issues that surface during the technical design, technical implementation, or testing phases of the project.

Managing requirements changes to ensure that everyone is working from up-to-date documentation and that appropriate stakeholders are involved in all decisions about change.

When appropriate, leading user acceptance testing efforts completed by the business community to ensure that the software implementation meets the needs of business end users

All of these efforts help the implementation team fulfill the intended benefits of the project and ensure the investment made realizes a positive return.

Step 7 – Help the Business Implement the Solution

Your technology team can deliver a beautiful shiny new solution that theoretically meets the business objectives, but if your business users don’t use it as intended and go back to business-as-usual, your project won’t have delivered on the original objectives. Business analysts are increasingly getting involved in this final phase of the project to support the business.

Your key responsibilities in this step may include:

Analyzing and developing interim and future state business process documentation that articulates exactly what changes need to be made to the business process.

Training end users to ensure they understand all process and procedural changes or collaborating with training staff so they can create appropriate training materials and deliver the training.

Collaborating with business users to update other organizational assets impacted by the business process and technology changes.

This step is all about ensuring all members of the business community are prepared to embrace the changes that have been specified as part of the project.

Step 8 – Assess Value Created by the Solution

A lot happens throughout the course of a project. Business outcomes are discussed. Details are worked through. Problems, big and small, are solved. Relationships are built. Change is managed. Technology is implemented. Business users are trained to change the way they work.

In this flurry of activity and a focus on delivery, it’s easy to lose track of the big picture. Why are we making all these changes and what value do they deliver for the organization? And even more importantly, are we still on track? Meaning, is the solution we’re delivering actually delivering the value we originally anticipated?

Nothing creates more positive momentum within an organization than a track record of successful projects. But if we don’t stop and assess the value created by the solution, how do we know if we are actually operating from a track record of success?

Your key responsibilities in this step may include:

Evaluating the actual progress made against the business objectives for the project to show the extent to which the original objectives have been fulfilled.

Communicating the results to the project sponsor, and if appropriate, to the project team and all members of the organization.

Suggesting follow-up projects and initiatives to fully realize the intended business objectives of the project or to solve new problems that are discovered while evaluating the impact of this project

After completing this step, it’s likely you’ll uncover more opportunities to improve the business which will lead you to additional projects. And so the cycle begins again!