AGILE METHODS

What is the Scrum method?

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems.  The Scrum method brings a small team together to work on a specified set of features over a period of 30-days (called a sprint).

Both the term Scrum and sprint are borrowed from the sport Rugby.  A scrum is where the two teams are engaged in a huddled to begin play following a period where play has been stopped.  The fast moving period of play from the point of the scrum until play ends again is called a sprint.

The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team comes together).  The kickoff meeting lasts a full day and the features of the system to be developed are discussed.  The outcome of the kickoff meeting is a set of features that will be developed over the 30-day sprint along with estimates of how long the analysis and development of each feature will take.

In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps due to an initial underestimation of the time required, the feature will be pushed to a later sprint.

Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up meeting).  The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.

One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size.  Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.

Product Owner – identifies the features that will be included in the next 30-sprint and set the priority of each.  This is typically a high-level stakeholder in organizations where a true Product Manger/Product Owner role doesn’t exist.

Scrum Master – acts much like the project manager.  While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the 30-day sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.

Team Member – unlike traditional software development methods, in Scrum there is little separation of duties between team members.  Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

Describe what is meant by Agile.

Agile is a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics.    Some of these characteristics include:

Iterative analysis and development Time-boxed iterations of a predefined length

Delivery of the most critical features and functions first

Delivery of a complete build with an initial set of limited features within a few months (often 1-2 months)

Small cross-functional teams usually of 6-9 team members.

Daily team communication meetings

Reduced levels of documentation

Most Agile methods begin with a prioritized feature list where features are group together into deliverable chunks and assigned to a particular iteration in which they will be developed and delivered.  Using small teams and daily communication among all team members the Agile team can achieve a high level of efficiency.

Agile methods are intended to overcome or circumvent many of the recurring challenges that are encountered during software development projects.  The iterative nature of these methods, along with the desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving requirements, unclear project stakeholder direction, and unforeseen project complexities that typically arise during the latter stages of analysis and development.    Some of the most salient advantages of Agile methods include:

Availability of working software much sooner which allows for more immediate feedback from application users.

More immediate, and therefore larger, Return on Investment from software features that are developed in short iterations and release to production immediately.

Less project overhead due to smaller team sizes.

Avoidance of large schedule overruns.

Avoidance of large budget overruns.

What is a Daily Scrum Meeting?

The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team (ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be completed next.   It provides an update to the entire team while providing a daily refocus for each team member as they deliver their status.

The daily scrum meeting is led by a Scrum Master.  The scrum master leads the scrum meetings, measures progress, identifies obstacles that are slowing or stopping the progress of work, and makes decisions about how to move forward when necessary. The Scrum Master should be someone who has been given the authority to make immediate decisions whenever possible.

During each meeting the Scrum Master asks each team member 3 questions:

1. What did you do since the last meeting? 2. Were there any obstacles that impeded your work?

3. What will you do before the next meeting?

The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes.  Standardizing the time and place of the meeting results in increased efficiency by eliminating overhead associated with finding rooms to schedule and team members determining where they should be each day.  It also tends to decrease the number of late arrivals. A primary key to the Daily Scrum Meeting is to keep it short.  Any topics unrelated to the 3 questions asked of each team members should be tabled during the meeting and handled at a later time.

What are User Stories?

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories.  They are short descriptions of functionality the system should provide.  The initial descriptions are often created or written by the users or customers of the system.  The user stories are used during the iterative planning and development cycles to determine a unit of work and estimate how long it will take.  Most practitioners strive to make a user stories fit into a 1-3 week span of development

User stories do not end at a 2-3 line description of functionality.  Each user story consists of three parts:

The Card: Named for the standard index cards on which a user story is often captured.  The cards are used for planning the work that will be completed during each iteration of development.

The Conversations:  Discussions about each user story are had with the users/customers of the system to flesh out details.  The conversations are captured and documented as part of the user story.

The Confirmation: Test scenarios that capture details about the user story that can be used to verify that the user story has been successfully implemented.

Using these three parts, the goal of the user story is to provide enough detail that a developer can understand what needs to be done while providing a means to verify that they have achieved the goal.  User stories are often equated to a single use case scenario, such as the main use case scenario or an alternative path.  The “Card” portion of the use case scenario is written in a manner similar to a brief description of a use case.

What is a Burndown Chart?

A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work completed.  It compares the amount of work remaining (typically measured along the vertical axis) against time (measured along the horizontal axis).  The amount of work remaining can be measured in whatever way works best for the project, i.e., work-hours, work-days, story points, or any other work unit. Similarly the time axis can be measured using a variety of units, the most common being days or iterations.  The burndown chart gives a quick view of the amount of work that is completed over time. 

When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level (a specific iteration of development) or at the release level (multiple iterations that deliver the total functionality for a product release). After the amount of work completed has been measured over several units of time, the burndown chart can be used to forecast the completion of an overall release or project.

ANALYTICAL AND PROBLEM SOLVING SKILLS

What is the PDCA method and how is its application by the Business Analyst beneficial?

PDCA is a 4-step, iterative method commonly used for Business Process Improvement.  PDCA stands for Plan, Do, Check, Act.  It was popularized by Dr. W Edwards Deming in the 1950s during his work in Japan where he taught top management how to improve product design, quality, testing and sales. 

The process is originally attributed to Walter A. Shewhart and was referred to by Deming himself as the

Shewhart Cycle.  The Shewhart Cycle steps were listed as Specification, Production, and Inspection.  However, over time, the steps were shortened to the more easily remembered Plan, Do, Check, Act (also referred to as PDSA—Plan, Do, Study, Act) where the Act step emphasized the need to take action on the knowledge gained from the prior step.

PDCA (or PDSA) is firmly rooted in the Scientific Method—Hypothesis, Experiment, Evaluation.  A fundamental principle of these methods is iteration.  Once the result of a process is confirmed (or negated) the cycle is repeated and the new knowledge can be acted upon.   It is this process of taking action, measuring the results, and utilizing those results to develop the next course of action that make the PDCA method and others like it, such as the Six Sigma DMAIC process (Define, Measure, Analyze, Improve and Control), so powerful and beneficial as a tool for the Business Analyst.

These methods, and others like them, which employ and iterative feedback loop embody two key points:

Creating a feedback loop based on measurable results Making incremental changes and improvements over time

What techniques do you use to ensure that you have identified the principle problem or requirement?

Problem solving and problem resolution is a common part of a business analyst’s role.  But before you spend time figuring out resolutions to the problem, you should be sure that you’re solving the right problem or that you have the true requirement.

Problem Restatement is one category of techniques that can be used to determine that the principle problem has been identified.  Some problem restatement techniques are:

1. Problem Paraphrasing – Alter the wording of the problem statement just slightly resulting in a new problem statement which is very similar in meaning.  Repeat the process until you have arrived at the principle problem.

2. 5W + 1H (Who, What, When, Where, Why, + How) – Create multiple variations of the problem statement beginning each statement with one of the 5W + 1H keywords.

3. Repeatedly Ask Why – Starting with the original problem statement, ask ‘Why’ to identify a new problem statement.  Continue to ask why to each new problem statement until you arrive at what is clearly the principle problem.

Give an example of how you would use the problem restatement technique of ‘Repeatedly Ask Why’.

The Repeatedly Ask Why technique starts with the original problem statement and asks ‘Why’ to identify a new problem statement.  The Business Analyst continues to ask why to each new problem statement until he or she arrives at what is clearly the principle problem.

This technique is so natural that all of us have used it as toddlers.  Using the ‘Repeatedly Ask Why’ technique allows the Business Analyst to overcome any assumptions that may have been made when developing the original problem statement.  So revert back to that 2 year old kid and ask ‘Why’.

Example:

We need a new cafeteria vendor at our company campus.  – Why? Because the quality of the food continues to get worse.  – Why?

Because they keep reusing leftovers and using lower quality products.  – Why?

Because they are trying to make enough money to be profitable.  – Why?

Because over the last few months fewer people have been going to the cafeteria.  – Why?

Because we had layoffs and there are less people on our company campus.

At this point we can identify that the principle problem is the layoffs resulting in fewer people using the cafeteria.  No matter what vendor you hire, they will have troubles being profitable under these conditions.  So the original problem statement stating that a new vendor is needed is incorrect.

Give an example of how you would use the problem restatement technique of ‘5W + 1H’.

The ‘5W + 1H’ technique (Who, What, When, Where, Why, + How)  is used to create multiple variations of the problem statement beginning each statement with one of the 5W + 1H key words.

Example:

Should we alter our current customer service procedures? Who should alter their current customer service procedures?

What should our current customer service procedures be?

When should we change our current customer service procedures?

Why should we alter our current customer service procedures?

How can we alter our current customer service procedures?

Rewriting the statement using the ‘5W + 1H’ technique broadens the focus of the Subject Matter Experts and Business Analysts. This technique can be used at anytime, but is particularly important if the initial problem statement is close ended phrase requiring a simple yes or no answer. This often constrains the thought process of the Subject Matter Experts and Business Analysts.  The resulting statements often shed new light on the problem and help the group determine the principle issue.

Give an example of how you would use the problem restatement technique of ‘Problem Paraphrasing’.

Problem Paraphrasing is altering the wording of the problem statement just slightly resulting in a new problem statement which is very similar in meaning.  The process is repeated until you have arrived at the principle problem.

Example: 

Drivers keep cutting me off. Drivers keep passing me and pulling in front of me.

Drivers keep changing lanes to pass me and then pulling back in front of me.

Drivers keep pulling around me.

Drivers keep pulling around me while going the speed limit.

I’m driving to slow!

A Subject Matter Expert can tell you if each new statement still reflects a valid scenario.  It’s important that each statement be valid and correct.  However, this technique is useful because a Subject Matter Expert may not be able to jump directly to the principle problem.  The paraphrasing technique helps the group gradually arrive at the principle problem.

Describe Convergent and Divergent Thinking as a Problem Solving Technique

Divergent and Convergent thinking when used together can help an analyst arrive at better and more creative solutions than he or she otherwise might have.  Divergent thinking is the process of breaking a topic down and generating many ideas that branch out from the original concept while Convergent thinking is the process of focusing on a fewer set of ideas and evaluating them based on selection criteria.

Divergent and Convergent thinking can be used together in a three step process:

1. Brainstorming2. Reducing and Categorizing

3. Ranking and Selecting

The first step, brainstorming, is a divergent thinking process and is most effective when a couple of guidelines are followed.  When using divergent thinking to generate a list of potential solutions, remember the following:

1. The more ideas that are generated the better2. Generate new ideas by building on previous ones

3. There is no such thing as bad ideas (even off-the-wall ideas can help generate other more viable ones)

4. Don’t evaluate ideas during the divergent thinking process

Once a list of potential ideas has been generated, the second step of reducing and categorizing can take place (a convergent thinking process).  During this step the most impractical ideas will now be eliminated and the remaining ideas can be grouped together into different categories based on their similarities.

Finally, the remaining list of ideas can be ranked based on the pros and cons of each (another convergent thinking process) and a final solution selected.

Consider the following example of using Divergent and Convergent thinking for problem solving.

A manufacturer of jumbo hard pretzels always experiences a certain amount of broken product on their manufacturing lines.  They have initiated projects in the past to reduce the amount of breakage from 7% to 4% measured by weight.  However, is would not be cost effective to try and reduce breakage further via other projects.  Each week all of the pieces of broken pieces are collected and discarded.  What other options might the company have to reduce or eliminate their losses due to broken product?

Step 1: Brainstorm

Sell the broken product to a dog food company as a filler ingredient for dog food Sell the broken product to a mulching company to be used as mulch

Sell the broken product to a shipping company as packaging filler

Sell the broken product to a bird food manufacturer

Season the broken product and market and sell it as a new product of its own

Give the broken product to a food shelter and take it as a tax write off

Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for skeet shooting

Step 2: Reducing and Categorizing

Category: Sell to another company

Sell the broken product to a dog food company as a filler ingredient for dog food Sell the broken product to a mulching company to be used as mulch (impractical)

Sell the broken product to a shipping company as packaging filler (impractical)

Sell the broken product to a bird food manufacturer

Category: Develop another product internally

Season the broken product and market and sell it as a new product of its own Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for

skeet shooting

Category: Tax write off

Give the broken product to a food shelter and take it as a tax write off

Step 3: Ranking and Selecting

1. Season the broken product and market and sell it as a new product of its own (Selected for maximum revenue)

2. Give the broken product to a food shelter and take it as a tax write off

3. Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for skeet shooting

4. Sell the broken product to a dog food company as a filler ingredient for dog food

5. Sell the broken product to a bird food manufacturer

What is Cost Benefit Analysis (CBA)?

Cost Benefit Analysis is a technique used to determine if the financial benefit s of a project outweigh the associated cost of undertaking the project in the first place.  For a short term project where the benefit may be an immediate one-time cash windfall this may be as simple as subtracting the total of all the project cost from the total of all of the project benefits.  If the total is positive, then the project may be worth completing.

Project Duration = 2 monthsProject Costs = $50,000

Immediate Project Benefits = $75,000$75,000 - $50,000 = $25,000

However, project costs and benefits rarely result in such a simple example.  Project costs and benefits often occur over time.   For this reason, Cost Benefit Analysis should consider all project cost and benefits in terms of the present value (PV) of money. 

To determine the present value of a future cost or benefit we discount the value of the dollars to account for time.  To calculate the Present Value we use the formula PV = FV /[(1 + i)^t].

PV = Present ValueFV = Future Valuei = Discount Ratet = time

In our example, if the $50,000 cost was incurred immediately and the $75,000 benefit was realized 3 years in the future, using a 5% discount rate would result in the following:

PV = $75,000 / [(1 + .05)^3] = $64,787.82$64,787.82 - $50,000 = $14,787.82

The net benefit of this project is now clearly less than originally thought.

Taking this a step further, consider the example where we have multiple cashflows (costs and benefits) over time. 

@ T0, Cost = -$25,000@ T1, Cost = -$25,000, Benefit = $15,000@T2, Benefit = $30,000@T3, Benefit = $30,000

By subtracting the present value of future costs from the present value of future benefits, we can arrive at the Net Present Value (NPV) of the costs and benefits for each year of the project.   The sum of all NPV calculations will give us the NPV of the entire project. 

NPV = FVben – FVcost / [(1 + i)^t]NPV0 = $0 - $25,000 / [(1 + .05)^0] = -$25,000NPV1 = $15,000 - $25,000 / [(1 + .05)^1] = -$9,523.81NPV2 = $30,000 - $0 / [(1 + .05)^2] = $27,210.88NPV3 = $30,000 - $0 / [(1 + .05)^3] = $25,915.13

For a total of $18,602.20 in benefit.

What is Joint Application Development (JAD)?

JAD stands for Joint Application Development. JAD is a requirements-definition and software system design methodology in which stakeholders, subject matter experts (SME), end-users, business analysts, software architects and developers attend collaborative workshops (called JAD sessions) to work out a system's details.

The JAD approach, in comparison with more traditional practices, is thought to lead to faster development times and greater client satisfaction, because the client is involved throughout the development process

The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives,

SME’s, end-users, business analysts, software architects and developers. It is essential that the roles, responsibilities, and rules for the JAD sessions are well defined and communicated in advance to all participants.

Some typical roles found in a JAD session include: 

Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules, Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,

End users – 3 to 5, attend all sessions,

Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,

Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,

Subject Matter Experts, 

Observers – 2 or 3 - junior BAs, testers, etc. - do not speak. 

BUSINESS ANALYSIS

What is PEST Analysis?

PEST is an acronym that stands for Political, Economic, Social, Technological. PEST analysis is one way that a business can analyze the environment in which it operates.

Political Environment: refers to government laws, regulations, and policies. These are things that impact the business either directly or indirectly.  This may include trade laws, tariffs, labor laws, taxes, environmental regulations, zoning restrictions, etc.  Some of these, if passed recently, may have a long term affect on the economy as well.  While PEST covers the economic environment, some political environment considerations, such as leadership changes that come from elections, may not have impacted the economy yet (this is an example of an indirect impact).  So the analyst should watch for how new government regulations may impact the economy longer term and assess its impact on the business.

Economic Environment: refers to the forces at play within the economy that the business has little control over.  These may include interest rates, inflation rate, exchange rates, increase in Gross Domestic Product (GDP), the financial and stock markets, the job market, etc.  All of these have impacts on the business from the ability to generate revenue to the cost of borrowing money to the salaries they will need to pay employees.

Social Environment: refers to the demographics of the environment that the company operates within. Since demographics are nothing more than characteristics of a human population this could include a nearly infinite number of groups.  Some common demographics that are considered are gender, race, age, income, disabilities, educational attainment, employment status, and religion. Ultimately, if the strategic plans of a business affect a particular group, they may react positively or negatively.  A business may face criticism, negative publicity or even protests based on the decisions it makes. These factors could have an enormous impact on the operations and revenue of the business. 

Technological Environment: refers to the technology that currently exists that the business has accessible to them.  This could include servers, computers, networks, software and software frameworks, database technologies, wireless capabilities, availability of Software as a Service (Saas), and more.  The rate of technological progress should also be considered, particularly if the business has plans to develop a system or product that takes advantage of cutting edge technology.

What is meant by Forming, Storming, Norming, and Peforming?

The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce Tuckman.  He described that most teams follow a consistent path from the point when they are first assembled to the time when they become a highly proficient, highly effective group.  This path leads them through four distinct stages; Forming, Storming, Norming, and Performing.

The “Forming” stage begins when new team members are first brought together.  Initially everybody is very positive and polite to one another.  Some people are anxious, some are excited.  The team members are fairly unaware of the details of the work ahead (blissfully naïve perhaps) and they look for clear direction from the leader.  Formal processes and project frameworks are not yet established. This stage is usually short in comparison to the others.

Next is the “Storming” stage.  At this stage team members become clear about their roles and what is expected of them.  Processes and project structures are put into full effect. The team may feel frustrated and overwhelmed by the work as they become more aware of the realities of the job.  They may be stressed by how much there is to accomplish and they may have uncertainties about their ability to do the assigned work. Or, they may simply be uncomfortable with the approach that is laid out by the leader.  Team members still don’t know each other that well as they continue to form opinions of one another.  They may be jockeying for position within the team or even challenging the leader’s authority.  Conflicts arise more often during this stage.  A great deal of oversight is needed by the team leader to ensure the processes are followed and the work is completed to expectations.

The “Norming” stage is where the team begins to catch their stride.  The pecking order of the team is established and team processes and workflow are beginning to solidify.  Each team member understands the strength of the other members and they all begin to work more as a team.  They help each other and provide peer reviews and constructive criticism.  At this point, the team is following the processes and project framework but may not be working as efficiently as they could be.  They still need oversight but significantly less than in the storming stage.

Finally, the “Performing” stage is reached.  The team has a solid understanding of the processes and project framework that have been put into place and follow them efficiently.  The team has become efficient and productive and it reaches its goals with regularity.  At this stage if a team member joins or leaves it will have little impact on the rest of the team’s performance.  The team leader can delegate to team members with confidence and provide minimal oversight.

What is Function Point Analysis?

Function Point Analysis (FPA) refers to the practice of using function points to size and estimate the cost of work on systems.  Function Points are a normalized unit of measure used to:

Quantify the amount of business functionality a system provides business users Estimate the cost to develop a system or set of features based on the number of function points it

supports

Determine how costly a system is to maintain based on the number of function points it supports

To state things differently, Function Points are good for answering questions like:

How big is system “A”? Is system “A” bigger than system “B” and by how much? (It answers these in terms of features)

How much will it cost me to build system “A”?

If I’m paying $500,000/yr to maintain system “B” is that cost effective?

Function Points, being a normalized unit of measure, provides an apples-to-apples comparison of systems and the costs associated with building and supporting them.

This method of measuring systems was first developed in 1979 by Allan Albrecht of IBM.  Today it is supported by a group called the International Function Point User Group (or IFPUG for short).

To count the number of function points that a system possesses, a skilled practitioner first categorizes each feature into one of five types (outputs, inquiries, inputs, internal files, and external interfaces).  Then a complexity is assigned to each feature.  Finally, a number of function points can be assigned to each feature.  Certain types of system also have additional function point adjustment factors that are used.  The end result is a single number for the entire system called a Function Point Index.  Based on this value and historical function point data, the cost to develop the system can be estimated.

FPA brings structure and rigor to a process that is often very subjective.  However, there are a number of potential challenges that are often voiced when discussing the merits of FPA.

Counting Function Points can be a tricky task to do well.  Getting consistent results is a challenge unless you are a skilled practitioner at counting function points.  There is a sizable “Function Point Counting Practices Manual” available to direct the practitioner in this exercise.

FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.

While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try to compensate for these challenges.

What is the H-Method?

The H-method is an analysis tool that aids the BA in organizing a fact finding interview with a business representative or system user. 

Before discussing the benefits of the H-Method and how it works, let’s consider a typical interviewing process.  Without the use of a framework for organizing an interview, an analyst and business representative will often participate in a relatively unstructured dialogue in which the analyst asks questions such as:

Tell me what you do? What does your system do?

Who do you interact with?

Why is “x” important?

Then based on the answers given the analyst will continue to ask follow up questions.  The success of the fact finding is typically dependent upon the experience level of the analyst.  While this method can work,

the analyst will often walk away with several pages of unstructured notes.  The important information must then be extracted and organized into something meaningful and useful.  Only then will the analyst be able to determine if they have discovered all of the necessary pieces of information or if there are still gaps in their understanding.

The H-method uses the following “H” shaped diagram to provide a structured framework to guide the interview and to allow the analyst to captured information in an organized way from the start.

This diagram also asks the business representative questions is a business friendly manner. As information is gathered, the analyst can document it in the appropriate area of the “H” shaped diagram. 

Finally, the information gathered using the first diagram can be mapped to more business analysis centric concepts on the following revised diagram.

The H-method is successful because it provides both a structured framework to guide the interview process and because it reminds the business analyst to avoid business analysis jargon that may confuse the business representative.  Instead it asks questions that align more closely with how the business representative views their world.

What is a Use Case Realization?

A use case realization provides a construct to organize artifacts which shown how the physical design of a system supports the logical business behavior outlined by a used case.  To show this traceability between the logical and physical design, in the use case diagram each use case is depicted as an oval shown with a solid-line border.  Then for each use case can you may show a use case realization as an oval with a dotted-line border.  The use case and its corresponding use case realization are linked using a realization dependency which is shown in UML as a dashed line with a triangular arrowhead at the end corresponding to the realized element (the use case). 

Each use case realization will define the physical design in terms of classes and collaborating objects which support the use case.  Therefore, each use case realization typically is made up of a class diagram

and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or interaction between physical objects.

Use case realizations allow the analyst to clearly separate the concerns of the logical and physical design.  Since a logical design (the business behavior and requirements) can be implemented or realized via a number of different physical implementations, if a physical design changes the logical use case can remain unaffected.  Also, a use case realization is an excellent form of requirements traceability from the logical business requirements down to the physical implementation of the solution.

What is a RACI Matrix?

RACI Matrix is the name given to a table which is used to describe the type and degree of involvement that stakeholders have in completing tasks or deliverables for a project or business process.  Also sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool used by business analysts and project managers for establishing roles and responsibilities early on in a project.  In this way it reduces project risk and sets expectations about the level of involvement that is expected by various stakeholders.

RACI is an acronym which stands for Responsible, Accountable, Consulted, Informed.  Since using an acronym makes for easier recollection, the term RACI Matrix tends to be the most commonly used name for this tool

The RACI Matrix displays deliverables or tasks along one axis:

Project Charter Business Requirements Document

AS-IS Process Flow

Functional Specifications

Requirements Traceability Matrix, etc.

Then it displays project roles or stakeholders along the other axis

Project Champion Project Manager

Analysis Lead

Analyst/Analysis Team

Development Manager, etc.

Finally, at each intersecting cell the type or degree of involvement is documented (Responsible, Accountable, Consulted, Informed).

Ultimately, each organization varies a bit in how they define each level of participation in a task or creation of a document.  The following are some commonly accepted definitions.

Accountable – This is the person who is ultimately on the hook to ensure that the deliverable or task has been completed and is thorough and correct.  This is usually a lead or manager of some kind.  The accountable person may be directing the work of the responsible person, but in the end the buck stops

here.  There can only be one truly accountable person.  This avoids finger pointing when something doesn’t get done or is done incorrectly.

Responsible – The responsible person(s) is the worker bee.  It can be one person, or a team of people.  They will be the ones getting their hands dirty finding the information they need and putting it to use to complete the task or create the deliverable.  They may be reporting to a lead or manager who is accountable for the task or deliverable.  However, for smaller tasks or deliverables, when there is only one responsible person listed, they may ALSO be listed as the accountable party.

Consulted – The consulted person(s) is a subject matter expert.  They are the person whose opinions or knowledge of a particular system or process is sought.  They don’t usually participate in completing a task or deliverable other than by providing the information that the responsible person needs to achieve their task or deliverable.

Informed – These are the people who need to be kept up to date on a task or deliverable.  They may need to track the amount of progress being made, but usually these people care only about the completion of a task or deliverable.  Typically they are either reviewers of the completed document and provide formal sign-off and approval, or they may be dependent on the information that results from the task or deliverable.

What strategies might a business analyst consider when planning for a company's growth?

If a company is to ensure its growth, it needs to plan for it.  There are a number of growth strategies that can be used.  Deciding which is the right growth strategy for a company depends on it current success and position within the marketplace in which it operates.  Four of these growth strategies are:

Market Penetration (Existing Products/Existing Markets) Market Development (Existing Products/New Market)

Product Development (New Products/Existing Market)

Diversification (New Products/New Market)

Market Penetration focuses on getting more out of the current markets serviced by an organization while offering the same products. New products and new markets can mean additional unknowns which, in turn, increase risk and chances of failure.  For this reason, a company may choose to select a growth strategy of market penetration.  The goal of market penetration is to increase the percentage of market share that the organization possesses through pricing, marketing, loyalty programs, incentives, advertising, etc.

Market Development is used to describe the growth strategy of an organization which chooses to venture into new markets or new customer segments with their existing products.  Their existing products are likely proven which provides a degree of stability, but moving into new markets increases risk.  This may still be viewed by some organizations as a fairly conservative strategy and is often adopted by companies as they feel their current markets getting squeezed tighter and tighter by competition.  Entrance into new markets often requires skilled marketing professionals to ensure a company receives the attention it is looking for.

Product Development describes the growth strategy of creating new products for existing markets.  An organization may have the benefit of understanding the intricacies of their market but this can create a false sense of security.   Not all new products carry the same risk.  However, for certain types of product,

especially those in fast moving technology markets, projecting the outcome of a new product launch can be very difficult.   To overcome some of this risk organizations should be prepared to continuously adapt their products after launch to ensure marketplace success.

Diversification is the term given to the strategy of delivering new products to entirely new markets.  The growth strategy accepts the risks of two unknowns; the product and the market.  Diversification is high-risk but, as with many things, high risk often can mean high reward.  Organizations with a track record of innovation will have the greatest success with this strategy.  With diversification as a growth strategy, everything will be new and the company will need to be prepared to quickly eliminate any risks that manifest themselves.

The four growth strategies described here are based on a simple 2 x 2 matrix called Ansoff’s Matrix which considers markets and products along its two axis.

Ansoff’s Matrix

  Existing Products New ProductsExisting Markets Market Penetration Product Development

New Markets Market Development Diversification

What is Benchmarking?

When companies want to improve, they first need to have an accurate means of measuring performance.  Without accurate measurement, determining process improvement is not feasible.  Measurement establishes a baseline against which the organization can determine the degree of improvement that has been made.

However, improvement alone may not be enough.  If an organization doesn’t know what the standard is it cannot compare itself against it. For example, if an organization obtains a customer satisfaction rating of 80%, but its competitor receives 90%, they will lose ground in the long run.  Benchmarking is the key to understanding how an organization measures up against others.

Benchmarking is the process of determining how an organization stacks up against industry leaders by measuring its performance across a series of standard metrics and then comparing the performance against other best-of-breed organizations within the same industry or service line. Companies may measure and compare policies, practices, philosophies, and other performance measures.

Benchmarking is usually part of a larger process re-engineering or quality improvement initiative such as Six Sigma or Total Quality Management.

What is Balanced Scorecard?

Balanced Scorecard is a strategic planning and management system that was formalized in the 1990s by Dr. Robert Kaplan (of the Harvard Business School) and Dr. David Nortan.  The goal of Balanced Scorecard is to implement a performance measurement framework which provides strategic non-financial

performance measures that when coupled with traditional financial metrics provides a more “balanced” view of the organization.  Using Balanced Scorecard a company can align daily business activities to the vision and strategy of the organization effectively transforming their strategic plan from a passive document into a plan which provides clear and measurable goals for all areas of the organization.

As described by Kaplan and Nortan, Balanced Scorecard retains the traditional financial measures, but financial measures reflect past events.  This alone is inadequate for guiding and evaluating a company’s future direction.  A company’s future success is driven through customer relationships, supplier relationships, employee development, process improvement, technology improvement, and innovation.

To improve in these areas Balanced Scorecard organizes the development of metrics and the tracking of progress against these metrics into four perspectives.

The Learning and Growth Perspective The Business Process Perspective

The Customer Perspective

The Financial Perspective

The Learning and Growth Perspective focuses on the development of metrics around training of employees and education of the organization as a whole.  These metrics should be structured in a way to guide managers to focus their training funds where they will help most.  They should also drive other methods of learning such as mentoring and ensuring that knowledge can easily be communicated and shared throughout the organization.

The Business Process Perspective focuses on the development of metrics that allow managers to know how well the internal business processes are running and how well they meet the needs of the organization’s customers.

The Customer Perspective focuses on the development of metrics around customer satisfaction.  This perspective cannot be underestimated as it has been found that customer satisfaction is a leading indicator of the future performance of the company.  Over time, dissatisfied customers will seek out other organizations that can meet their needs better.

The Financial Perspective focuses on traditional financial metrics.  Companies often already place a heavy emphasis on financials which can lead to an unbalanced view of a situation.  While this perspective is very important, Balanced Scorecard aims to balance this perspective by considering it in conjunction with the metrics and data of the other perspectives.

What is Document Analysis?

Document Analysis is a technique used to gather requirements during the requirements elicitation phase of a project.  It describes the act of reviewing the existing documentation of comparable business processes or systems in order to extract pieces of information that are relevant to the current project, and therefore should be consider projects requirements.

Business analysts can elicit requirements in many ways, and eliciting them from stakeholders using questionnaires, interviews, or facilitating sessions are most common.  However document analysis is particularly valuable when replacing one or more existing systems with a new system that will offer increased functionality or a better overall user experience.  Existing documentation can be scoured for an understanding of key functions, business rules, business entities, and business entity attributes.  Document analysis may also be necessary when stakeholders are not available to offer insight into existing business processes or systems.

Some forms of documents that are useful in document analysis may be obvious, while others less so.  Here is a list of potential documents that an analyst should consider reviewing based on their particular project type.

Benchmarking studies Business plans

Business process and procedure documentation

Company memos

Competing product literature and reviews

Customer contracts

Customer suggestions

Requests for proposals

System defect reports

System specifications (of existing systems)

Training guides

Vision documents for related projects

How is the Business Analysis Planning and Monitoring (BABOK v2.0) knowledge area defined?

The Business Analysis Planning and Monitoring knowledge area describes the process of how a business analyst determines which activities will be needed to complete the business analysis effort.  The tasks within this knowledge area govern the business analysis tasks in all of the other knowledge areas.  These tasks include:

1. Plan Business Analysis Approach2. Conduct Stakeholder Analysis

3. Plan Business Analysis Activities

4. Plan Business Analysis Communication

5. Plan Requirements Management Process

6. Manage Business Analysis Performance

What is BPMN?

BPMN stands for Business Process Modeling Notation. BPMN is an industry standard that provides businesses with the capability of visualizing and communicating their internal business processes and their external business to business processes in a standard manner. Beyond the obvious use of modeling business processes, BPMN has been created with the key goal of creating a bridge between the business process modeling notation (BPMN) and IT-oriented execution languages that will implement the modeled business processes within a business process management system. This is done by maintaining and supporting a strict internal model that maps the rich set of graphical objects and object attributes of

BPMN to executable languages such as the Business Process Execution Language for Webs Services (BPEL4WS) or Business Process Modeling Language (BPML) to support immediate execution of modeled buiness processes.

NOTE: From the business systems analyst perspective, BPMN is a modeling notation which provides the analyst with a rich graphical notation for modeling business processes, sub-processes, and activities.

Many business analysts use BPMN diagrams instead of UML activity diagrams.

In addition, BPMN is a visual notation used by many of today's business process modeling and management tools.

Name a few of the industry standards, methodologies, or best practices used by business analysts and systems analysts?

-UML

-BPMN

-RUP

- Agile

- SDLC