business analyst
TRANSCRIPT
Document on Business
Analyst
Table of Contents
1.0 Topics list……………………………………………………………………
1.1 Principles of Business Analysis……………………………………………
1.2 Requirement Document techniques-BRD, FSD, TSD………………………
1.3 UML designing- Usecase diagram, Activity diagrams…………………….
1.4 Usecase creation……………………………………………………………
1.5 Wireframes techniques like - Prototype, Wireframes, Mockups using tools like
SnagIT, Visio, Excel, MS Paint and MS Word……………………………
1.6 Life Cycle Models - Waterfall, Agile, SCRUM, XP, Kanban……………
1.7 Practical workshops - Gathering requirements, documentation, uml diagrams,
mockups……..
1.8 Requirements Traceability Matrix
1.9 Test Case creation
1.10 Change Management - Change Request creation and process
1.11 UAT - Techniques of conducting user acceptance testing
1.12 Techniques of managing user expectations
1.13 Baseline - What is Baseline?
1.14 Defect Management
1.15 Analysis techniques like - SWOT, GAP and 'As Is - To Be' analysis.
1.16 BA Fundamentals
1.17 Scope Identification and management.
1.18 Requirement Elicitation techniques
1.0 Topics covered till date
Till now we have covered some concepts/scenarios in the class of Business Analyst, conducted by
Sasidhar Swarna
1.1 Principles of Business Analysis
As a business analyst, you are the liaison between the business stakeholders and the technical
solutions providers. Gain skills to fully communicate requirements to the technical team before solutions
are designed and implemented. Develop leadership and facilitation skills needed to glean the right
information to understand the business environment and the user needs. Create key deliverable documents
that are actionable by the development team. Define the key changes needed for an organization to
develop lean processes.
1.2 Requirement documentation
We did practices on the requirement documentation like BRD, FSD and TSD
BRD: An acronym of Business Requirements Document is widely accepted structured document
for project requirements which defines what should be delivered in order to gain value in the
project. This document is designed to assist with the project management and the implementation
during the entire life cycle of the project. Business requirements are consist of both functional and
non-functional requirements which lead to creation or update of product, system or a software.
BRD mainly emphasize on what should be the end result and it doesn’t bother how the objective
is achieved.
FSD: FSD stands by Functional Specification Document. It is a formal document used to
describe in detail for software developers a product’s intended capabilities, appearance and
interactions with users. The functional specification is a kind of guideline and continuing
reference point as the developers write programming code.
TSD: The Technical Specification Document lays out the requirements for the project; it
contains great details of the project, such as screen shots, menus, and a detailed
description of the purpose of the project. A project could consist of multiple programs
which all work for some common purpose, such as Windows Office and Open Office.
Both these projects contain multiple programs. The author(s) of such technical
specifications may find that it is necessary to split it up into multiple specification
documents, such as one for Word, another for Excel, etc.
1.3 UML diagrams
UML (Unified Modeling Language) is a standard notation for the modeling of real-world objects as a first
step in developing an object-oriented design methodology.
We discussed about these diagrams, they are Usecase diagram, Activity diagrams
Usecase diagram: A use case is a methodology used in system analysis to identify, clarify, and
organize system requirements. The use case is made up of a set of possible sequences of
interactions between systems and users in a particular environment and related to a particular
goal. It consists of a group of elements (for example, classes and interfaces) that can be used
together in a way that will have an effect larger than the sum of the separate elements combined.
The use case should contain all system activities that have significance to the users. A use case
can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use
case and goal are sometimes considered to be synonymous.
Example:
Customer
System
Admin
Login/Register
Provide details
Make a booking
Select the type ofcar
Select the type ofservices
Select theinventories
Update the accountdetails(customer)
Print a receipt
Logout
«uses» «uses»
«uses»*
*
*
*
**
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Activity diagram: Activity diagram is another important diagram in UML to describe dynamic
aspects of the system. Activity diagram is basically a flow chart to represent the flow form one
activity to another activity. The activity can be described as an operation of the system. So the
control flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent. Activity diagrams deals with all type of flow control by using different elements like
fork, join etc.
Example:
1.4 Usecase creation
Create a blank use case diagram by clicking UML in toolbar and selecting Use Case
Diagram from the drop down menu.
Enter the name of diagram: Hotel Reservation.
Select Actor in the diagram toolbar. Click on the diagram to create an actor and name
it Customer.
A customer can make a hotel reservation, which is a use case of the system. Let's create a
use case from the Customer actor. Move the mouse pointer over the Customer actor. Press
on the Association -> Use Case resource icon and drag it out.
Release the mouse button to create the use case. Name it Make Reservation. The
association between actor and use case indicates that the actor will interact with the system
to achieve the use case associated.
Complete the design to make it look like this:
1.5. Wireframes
A wireframe is a visual guide that portrays how a page or screen of a website or system may
look. Wireframes can range from very unfinished and ‘sketchy’ in appearance, to very polished
looking and reflective of how the system will look at 100% completion. Using wireframes can
help determine:
The structure of a page or screen
The layout of content
The functionality available
Calls to action
Blocks of text
User interface elements
Graphic design touches
The beauty, and power, of a wireframe is that almost every single one is different. Some are used
for broadly outlining the structure of a page, and nothing more. Others might consist of a piece
of paper with rectangles on it. At the other end of the scale, a very polished wireframe could
indicate structure, content, functionality, and even elements of graphic design.
Wireframes are extremely useful in the following situations:
To quickly get ideas down on paper for soliciting feedback. This is the real ‘back of a napkin’
use of a wireframe, and can it can be useful in a workshop to document ideas (Use a whiteboard
or computer screen, and draw up something rough). The very act of creating this image, this
basic wireframe, will prompt people in all kinds of useful ways.
This type of wireframe is often referred to as ‘lo-fidelity’. It can be a few boxes drawn in felt tip,
a pencil approximation of a full page, or a computer drawn illustration. The idea though is it
doesn’t look finished, because invariably, it isn’t.
To communicate the specification of a system or website. This is the ‘a picture paints a thousand
words’ concept. Communicating how a proposed system, website, or even simple page of
content, should work and look is never as easy as it seems at first. Drawing a wireframe, with the
various states outline and suitable annotations, can save a lot of time writing complex
paragraphs.
This type of wireframe is often referred to as ‘hi-fidelity’. It normally looks like a recognizable
page and can often be very ‘designed’, but still sticks to the core of idea of being an
approximation
For the users better experience and quick idea and it can be useful in a workshop to document
ideas. Prototype wireframes mockups using tools like SnagIt, Visio, Excel, MS paint and MS
Word.
1.6 SDLC Models
There are various software development life cycle models defined and designed which are
Followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development. Following are the most
Important and popular SDLC models followed in the industry:
-Model
The other related methodologies are Agile Model, RAD Model – Rapid Application
Development and Prototyping Models.
Water Fall Model:
The Water Fall Model has the planning, analysis, implementation and testing phase.
This model is different from traditional model in such a way that testing phase comes after the
implementation phase.
In such model after the complete software is produced and implemented onto the application the testing is
carried out.
Pros:
All the phases are completed at one time
It has a rigid structure which is easy to use and each phase has review process.
Good for small project
Cons:
Future adjustments in the project are not possible.
No prototypes are produced
Not suitable for projects with moderate requirements, long projects, and for the projects which may
undergo future changes
ITERATIVE MODEL:
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which can then be
reviewed in order to identify further requirements. This process is then repeated, producing a new version
of the software for each cycle of the model.
For example:
In the diagram above when we work iteratively we create rough product or product piece in one iteration,
then review it and improve it in next iteration and so on until it’s finished. As shown in the image above,
in the first iteration the whole painting is sketched roughly, then in the second iteration colors are filled
and in the third iteration finishing is done. Hence, in iterative model the whole product is developed step
by step.
Pros:
In iterative model we can only create a high-level design of the application before we actually begin
to build the product and define the design solution for the entire product. Later on we can design and
built a skeleton version of that, and then evolved the design based on what had been built.
In iterative model we are building and improving the product step by step. Hence we can track the
defects at early stages. This avoids the downward flow of the defects.
In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of
the product to users for their feedback, we are effectively asking them to imagine how the product
will work.
In iterative model less time is spent on documenting and more time is given for designing.
Cons:
Each phase of an iteration is rigid with no overlaps
Costly system architecture or design issues may arise because not all requirements are gathered up
front for the entire lifecycle
SPIRAL MODEL:
The spiral model has four phases planning, risk analysis, engineering and evaluation.
It emphasis more on risk analysis.
In this model the project undergoes each phases repeatedly called spirals.
The planning phase is the baseline spiral and each subsequent spiral is built on spiral model
These type of model is used in risk analyzing projects for eg in space crafts.
Pros:
Importance is placed more on risk analysis
Software is produced in the early stage.
Cons:
Not suitable for small projects
It is very costly
Needs expertise for such model
V MODEL:
It explains the relationship between each phase and the associated testing phase.
In this type each phase undergoes testing i.e for each phase a test deign is created and testing is carried on
the corresponding designs and undergoes coding phase if defect is determined.
Since it does not follow a linear path and bends after coding phase this model is termed as V-model.
Pros:
Since each phase has its own test design it can produce good results.
Simple and easy to use
It can be used for small projects and the requirements are clearly understood.
Cons:
No prototypes are produced.
Do not have the clear path the problems found after each testing phase.
Adjustment in future is less or not possible.
Big Bang Model
The Big Bang model is SDLC model where there is no specific process followed. The development just
starts with the required money and efforts as the input, and the output is the software developed which
may or may not be as per customer requirement.
Big Bang Model is SDLC model where there is no formal development followed and very little planning
is required. Even the customer is not sure about what exactly he wants and the requirements are
implemented on the fly without much analysis. Usually this model is followed for small projects where
the development teams are very small.
Big Bang Model design and Application
Big bang model comprises of focusing all the possible resources in software development and coding,
with very little or no planning. The requirements are understood and implemented as they come. Any
changes required may or may not need to revamp the complete software. This model is ideal for small
projects with one or two developers working together and is also useful for academic or practice projects.
It’s an ideal model for the product where requirements are not well understood and the final release date
is not given.
Big Bang Model Pros and Cons
Pros:
This is a very simple model
Little or no planning required
Easy to manage
Very few resources required
Gives flexibility to developers
Good learning aid for new comers or students
Cons:
This is a very simple model
Very high risk and uncertainly
Not a good model for complex and
Object-oriented projects.
Poor model for long and ongoing projects.
Can turn out to be very expensive if requirements are misunderstood
Agile Methodology Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross
functional teams working simultaneously on various areas like planning, requirements analysis,
design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is
displayed to the customer and important stakeholders.
Scrum Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because
of this popularity, many organizations claim to be “doing Scrum”
Scrum has only three roles: Product Owner, Team, and Scrum Master. The responsibilities of the
traditional project manager role are split up among these three Scrum roles. Scrum say it should be
five meetings i.e. Backlog Grooming (aka Backlog Refinement),Sprint Planning, Daily Scrum (aka
15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting.
The Roles of Scrum
Scrum has three roles: Product Owner, Scrum Master, and team member
Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the
product to the development team. He or she must also represent the customer’s interests through
requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s
also the role with the most responsibility. The Product Owner is the single individual who must face the
music when a project goes awry.
Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum
Master does not manage the team. Instead, he or she works to remove any impediments that are
obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and
productive, while making sure its successes are visible to the Product Owner. The Scrum Master also
works to advise the Product Owner about how to maximize ROI for the team.
Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally,
teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a
typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers,
and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to
be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation,
that freedom is accompanied by a responsibility to meet the goals of the sprint.
Find this URL for introduction to Scrum:
http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm
Kanban: Kanban is a new technique for managing a software development process in a highly efficient way.
Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a
creative activity and therefore different to mass-producing cars, the underlying mechanism for managing
the production line can still be applied.
A software development process can be thought of as a pipeline with feature requests entering one end
and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process
to a highly formal phased process. In this article, we'll assume a simple phased process of:
(1) analyses the requirements, (2) develop the code, and (3) test it works.
The Effect of Bottlenecks
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the
throughput of the bottleneck.
Using our development pipeline as an example: if the testers are only able to test 5 features per week
whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of
the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.
If the analysts and developers aren't aware that the testers are the bottleneck, then a backlog of work will
begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up
investment, creates distance from the market, and drops in value as time goes by.
Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into
production cause problems for the users and waste future pipeline capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it.
For example, the analysts could help with testing and the developers could work on test automation.
But how do we know where the bottleneck is in any given process? And what happens when it moves?
Kanban reveals bottlenecks dynamically
Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a
Kanban system consists of a big board on the wall with cards or sticky notes placed in columns with
numbers at the top.
Limiting work-in-progress reveals the bottlenecks so you can address them.
The cards represent work items as they flow through the development process represented by the
columns. The numbers at the top of each column are limits on the number of cards allowed in each
column.
The limits are the critical difference between a Kanban board and any other visual storyboard. Limiting
the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals
bottlenecks dynamically so that you can address them before they get out of hand.
Worked Example
The board below shows a situation where the developers and analysts are being prevented from taking on
any more work until the testers free up a slot and pull in the next work item. At this point the developers
and analysts should be looking at ways they can help relieve the burden on the testers.
Notice that we've split some of the columns in two, to indicate items being worked on and those finished
and ready to be pulled by the downstream process. There are several different ways you can layout out the
board. This is a fairly simple way. The limits at the top of the split columns cover both the "doing" and
"done" columns.
Once the testers have finished testing a feature, they move the card and free up a slot in the "Test"
column.
Now the empty slot in the "Test" column can be filled by one of the cards in the development "done"
column. That frees up a slot under "Development" and the next card can be pulled from the "Analysis"
column and so on.
1.7 Practical workshops - Gathering requirements, documentation, uml
Diagrams, mockups
Gathering Requirements:
The most difficult part of requirements gathering is not the act of recording what the user wants, it is the
exploratory development activity of helping users figure out what they want.
Here are a few best practices that can reduce the chances of getting stuck in your tracks or ending up with
incomplete requirements in an evaluation.
1. Choose your interview group wisely.
This can be a challenge for any corporation as too many interviewees and you will have an extremely
long assessment phase, however too few and you can miss vital requirements or enormous
opportunities. Things to consider when picking this group are:
Is there a good cross section of users from all lines of business using the new solution?
Are regions, offices, or at different levels of tenure in the organization represented?
Do these users have different levels of technical maturity, as your end users will?
How much time do you have to spend on an evaluation?
2. Have a Briefing Packet and Purpose.
A large challenge with stakeholder interviews occurs when the interviewee has only a vague
understanding of why they are being questioned. Creating a summary of the project including why it is
beginning, the type of the questions they will be asked, software jargon and acronyms, along with who
will be affected. This will typically avoid false starts with interviewees asking all the questions or
becoming defensive.
3. Ask Open Ended Questions and Follow Through.
When creating a list of the questions, keep the first tier simple, high level, and extremely open-
ended. Although it can be quite tempting, leading the witness is a major cause for missed opportunities or
bad data. Behind each first tier question, follow up with a set of clarifying questions that dig into the
negative outcomes of the situation, who else is affected indirectly, and optimal solution requirements.
4. Take a Collaborative Approach.
Interviewing one person at a time may not provide the same creativity or results that collaborative
methods can bear. Beginning with a survey can provide enormous insight into the as is situation and help
refine your deeper questions. Brainstorming sessions or workshops are a great way to take advantage of
synergies between needs and ideas, and are sometimes called Joint Application Development (JAD)
sessions in software development. Another simple technique, which many times are overlooked, is
simply observing an employee perform their job functions.
5. Reverse Engineer Requirements.
Existing software packages typically have reporting mechanisms in place that will give you not only a
list of features or existing capabilities, but also their adoption levels. This provides an understanding of
the baseline requirements you will need in a new system, and which are most popular. There are many
reasons why beneficial features are not used such as bad data, user experience, or lack of training. Make
sure to question users on existing systems and what they find most valuable or lack in addition to looking
at reports.
6. Ask Vendors for a List of Requirements.
Vendor requirements, although always biased to their own product capabilities, can be a good
benchmark at this point to understand how well defined your requirements are, and if there are key gaps
in your overall plan.
7. Create a List of Cutting Edge Requirements.
With the rate of change in the software world, no one at your company may be aware of new capabilities
or integrations that can provide enormous value. Set up a meeting with vendors and ask them about their
new capabilities in the past few releases, along with ones that are coming out in the next version. This
consolidated list of “cutting edge” requirements may not all be added to your list, however gives you an
understanding of the speed of innovation, how vendors stack up to their competition in innovation, and
whether they are heading in your direction.
8. Poll Users on Requirements and Prioritize.
Although you already can assign requirements a weight of how many times you have heard a particular
need, this alone will not give you a clear picture of importance of needs. After you have compiled
requirements, have users rank these based upon their level of need (no need to critical), and have a place
to get feedback and let them ask questions. Also, it’s beneficial to flag unique or complex requirements
for cost / benefit analysis based on interviews and further evaluation.
9. Review Results and Get More Feedback.
Sometimes the best feedback can come from a presentation and report of the findings from the activities
to date. Although you have spoken to everyone prior, a group presentation with data helps reaffirm your
outcomes, allows people to ask questions they may not have had the chance to in the past, and can bring
out some creative ideas people did not think of in the interviews.
10. Use Proof of Concepts (POC)’s .
Often, when people cannot articulate a need in the abstract, they can quickly assess if a particular
approach would address the need if they can see it work. Prototypes are most efficiently done with
mockups of interfaces and storyboards, or live technology. This can be helpful as a hand off to the
individual vendors later to replicate in their software.
UML Diagrams:
UML stands for Unified Modeling Language which is used in object oriented software engineering.
Although typically used in software engineering it is a rich language that can be used to model an
application structures, behavior and even business processes. There are 14 UML diagram types . They
can be divided into two main categories structure diagrams and behavioral diagrams. All 14 UML
diagram types are listed below with examples, brief introduction to them and also how they are used
when modeling applications.
List of UML Diagram Types
Class Diagram
Component Diagram
Deployment Diagram
Object Diagram
Package Diagram
Profile Diagram
Composite Structure Diagram
Use Case Diagram
Activity Diagram
State Machine Diagram
Sequence Diagram
Communication Diagram
Interaction Overview Diagram
Timing Diagram
Note: for description of UML diagrams, please refer topic number 1.3.
1.8. Requirement traceability Matrix
Requirements tracing, a process of documenting the links between the requirements and the work
products developed to implement and verify those requirements. The RTM captures all requirements and
their traceability in a single document delivered at the conclusion of the life cycle.
RTM - Workflow
The Matrix is created at the very beginning of a project as it forms the basis of the project's scope and
deliverables that will be produced.
The Matrix is bi-directional, as it tracks the requirement forward by examining the output of the
deliverables and backward by looking at the business requirement that was specified for a particular
feature of the product.
Requirement traceability Matrix - Parameters:
Requirement ID
Risks
Requirement Type
Requirement Description
Trace to Design Specification
Unit Test Cases
Integration Test Cases
System Test Cases
User Acceptance Test Cases
Trace to Test Script
1.9. Test Case creation
The definition of test case is “Documentation specifying inputs, predicted results, and a set of
execution conditions for a test item.” The aim is to divide the software function into small units of
function that is testable with input, and producing result that is measurable.
What information would the test manager want out of testcase document?
The test cases provide important information to the client regarding the quality of their product. The
approach to test case writing should be such as to facilitate the collection of this information.
Which features have been tested/ will be tested eventually?
How many user scenarios/ use cases have been executed?
How many features are stable?
Which features need more work?
Are sufficient input combinations exercised?
Does the app give out correct error messages if the user does not use it the way it was intended to
be used?
Does the app respond to the various browser specific functions as it should?
Does the UI conform to the specifications?
Are the features traceable to the requirement spec? Have all of them been covered?
Are the user scenarios traceable to the use case document? Have all of them been covered?
Can these tests be used as an input to automation?
Are the tests good enough? Are they finding defects?
Is software ready to ship? Is testing enough?
What is the quality of the application?
Approach to testcase writing
The approach to organizing test cases will determine the extent to which they are effective in finding
defects and providing the information required from them
Function: Test each function/ feature in isolation
Domain : Test by partitioning different sets of values
Specification based: Test against published specifications
Risk based: Imagine a way in which a program could fail and then design tests to check whether
the program will actually fail.
User: Tests done by users.
Scenario/ use case based: Based on actors/ users and a set of actions they are likely to perform in
real life.
Exploratory: the tester actively controls the design of tests as those tests are performed and uses
information gained while testing to design new and better tests.
Since the goal should be to maximize the extent to which the application is exercised, a combination of
two or more of these works well. Exploratory testing in combination with any of these approaches will
give the focus needed to find defects creatively.
Test case writing procedure
Study the application
Get as much information about the application as possible through available documentation
(requirement specs, use cases, user guides) , tutorials, or by exercising the software itself
(when available)
Determine a list of features and different user roles.
If it’s a special domain, try to obtain as much info about how the users might interact with the
application.
Standardize an approach for test case writing
Write test cases for different features into different documents (usually excel sheets) and name
according to the feature. In case a particular application has well defined user roles, differentiate the test
cases based on a combination of user role and feature. Write tests involving interaction between different
user roles and modules separately for complex applications.
Further as a check, make sure that the entire application flow has been covered. For example, for an
ecommerce application, the application flow will begin at registration and end at the point the user gets an
order confirmation or does a successful order cancellation. Trace this flow to the set of test cases.
Identify sets of test cases
Identify logical sets of test cases based on individual features/ user roles or integration between
them.
Create separate test cases for special functional tests e.g. browser specific tests (using browser
specific functions like back button, closing the browser session etc), UI tests, usability tests,
security tests, cookie/ state verification etc. to ensure that all tests under these categories are
covered.
Effective test cases verify functions in isolation. If a particular feature has a lot of input
combinations, separate the test into subtests. For e.g. to verify how the registration feature works
with invalid input, write sub tests for different values.
Main test case:
Register_01- Verify user cannot register with invalid inputs in registration form
Sub test cases:
Register_01a- Verify with invalid email id.
Register_01b- Verify with invalid phone number
Register_01c- Verify with large number of characters in password field.
Decide on a structure
The test case format given below serves well for functional test case writing. Some of the information
may be redundant if written for each test case e.g references, in which case it can be mentioned only once
in the beginning of the test case. In some cases when the use cases or requirement specs are well written,
there could be a perfect mapping of each test case to a particular section of the document.
Test case name
Decide on a test case naming convention based on the approach used. The idea is to use such a convention
so that one look at the set of test cases will inform the feature being tested or the user role/ scenario being
tested. For e.g. using “Seller_Register_xx” for all test cases on seller registration will immediately
indicate the number of test cases written for that user role and feature.
The test case name should be unique, so that when test cases document is used as an input to the
automation scripts, all/combination of test cases can be included in a single suite of tests.
For e.g. consider the example of an auction site like eBay, buyer and seller are distinct user roles. So, the
most effective approach would be to write test cases separately for buyer and seller, addressing different
features that the user roles execute. (E.g. Buyer_Register_01 – Verify that inserting valid values for all
fields on the registration page, registers the buyer successfully) could be one of the test cases where a
buyer registers with eBay. Similarly “Buyer_bids_01 – Verify that buyer can bid for items where the bid
period has not yet expired” could be one of the test case for the bid feature for a buyer. Another set of test
cases will address features for a seller. Another set of test cases should address the interaction between
buyer and seller and will be scenario based.
Description
Explain the function under test. Clearly state exactly what attribute is under test and under what condition.
Prerequisites
Every test needs to follow a sequence of actions, which lead to the function under test. It could be a
certain page that a user needs to be on, or certain data that should be in the system (like registration data
in order to login to the system), or certain action. State this precondition clearly in the test case. This helps
to define specific steps for manual testing, and more so for automated testing, where the system needs to
be in a particular base state for the function to be tested.
Steps
Sequence of steps to execute the specific function.
Input
Specify the data used for a particular test or if it is a lot of data, point to a file where this data is stored.
Expected result
Clearly state the expected outcome in terms of the page/ screen that should appear after the test, changes
that should happen to other pages, and if possible, changes that should happen to the database.
Actual result
State the actual result of the function execution. Especially in case the test case fails, the information
under ‘actual result’ will be very useful to the developer to analyze the cause of the defect.
Status
Write status separately for tests done using different environments, e.g. various OS/browser
combinations. Test case status could be-
Passed – The expected and actual results match.
Failed- The actual result does not match the expected result.
Not tested- The test case has not been executed for the test run, maybe is a lower priority
test case.
Not Applicable- The test case does not apply to the feature any more since the
requirement changed.
Cannot be tested – May be the prerequisite/ precondition is not met. There could be a
defect in one of the steps leading up to the function under test.
Comments
Write additional information under this column. For e.g. the actual result occurs only under a particular
condition or a defect is reproducible only sometimes. This information gives the developer/ client
additional info about the feature behavior which can be very useful in determining the root cause of a
problem. It is especially useful for “failed” cases, but also serves as a feedback if additional observation is
mentioned in the “passed” cases.
References
Refer / map a test case to the corresponding requirement spec or use case or any other reference material
that you used. This information helps gauge the test coverage against the documented requirements.
1.10. Change management
The change management process is the sequence of steps or activities that a change management team or
project leader would follow to apply change management to a project or change. Based on Prosci's
research of the most effective and commonly applied change, they have created a change management
process that contains the following three phases:
Phase 1 - Preparing for change (Preparation, assessment and strategy development)
Phase 2 - Managing change (Detailed planning and change management implementation)
Phase 3 - Reinforcing change™ (Data gathering, corrective action and recognition)
Phase Change Management Process
Defining change management
It is important to note what change management is and what change management is not, as defined by the
majority of research participants.
Change management is not a stand-alone process for designing a business solution.
Change management is the processes, tools and techniques for managing the people-side of
change.
Change management is not a process improvement method.
Change management is a method for reducing and managing resistance to change when
implementing process, technology or organizational change.
Change management is not a stand-alone technique for improving organizational performance.
Change management is a necessary component for any organizational performance improvement
process to succeed, including programs like: Six Sigma, Business Process Reengineering, Total
Quality Management, Organizational Development, Restructuring and continuous process
improvement.
Change management is how we drive the adoption and usage we need to realize business results.
Prosci's definition of change management: Change management is the application of a structured
process and set of tools for leading the people side of change to achieve a desired outcome.
Readiness assessments
Assessments are tools used by a change management team or project leader to assess the organization's
readiness to change. Readiness assessments can include organizational assessments, culture and history
assessments, employee assessments, sponsor assessments and change assessments. Each tool provides the
project team with insights into the challenges and opportunities they may face during the change process.
Assess the scope of the change, including: How big is this change? How many people are
affected? Is it a gradual or radical change?
Assess the readiness of the organization impacted by the change, including: What is the value-
system and background of the impacted groups? How much change is already going on? What
type of resistance can be expected?
Assess the scope of the change, including: How big is this change? How many people are
affected? Is it a gradual or radical change?
Assess the readiness of the organization impacted by the change, including: What is the value-
system and background of the impacted groups? How much change is already going on? What
type of resistance can be expected?
Assess the strengths of your change management team.
Assess the change sponsors and take the first steps to enable them to effectively lead the change
process.
Communication and communication planning
Many managers assume that if they communicate clearly with their employees, their job is done.
However, there are many reasons why employees may not hear or understand what their managers are
saying the first time around. In fact, you may have heard that messages need to be repeated 6 to 7 times
before they are cemented into the minds of employees. That is because each employee’s readiness to hear
depends on many factors. Effective communicators carefully consider three components: the audience,
what is said and when it is said.
For example, the first step in managing change is building awareness around the need for change and
creating a desire among employees. Therefore, initial communications are typically designed to create
awareness around the business reasons for change and the risk of not changing. Likewise, at each step in
the process, communications should be designed to share the right messages at the right time.
Communication planning, therefore, begins with a careful analysis of the audiences, key messages and the
timing for those messages. The change management team or project leaders must design a communication
plan that addresses the needs of front-line employees, supervisors and executives. Each audience has
particular needs for information based on their role in the implementation of the change.
Sponsor activities and sponsor roadmaps
Business leaders and executives play a critical sponsor role in change management. The change
management team must develop a plan for sponsor activities and help key business leaders carry out these
plans. Sponsorship should be viewed as the most important success factor. Avoid confusing the notion of
sponsorship with support. The CEO of the company may support your project, but that is not the same as
sponsoring your initiative.
Sponsorship involves active and visible participation by senior business leaders throughout the process.
Unfortunately many executives do not know what this sponsorship looks like. A change agent's or project
leader's role includes helping senior executives do the right things to sponsor the project.
Coaching and manager training for change management
Supervisors will play a key role in managing change. Ultimately, the direct supervisor has more influence
over an employee’s motivation to change than any other person at work. Unfortunately, supervisors as a
group can be the most difficult to convince of the need for change and can be a source of resistance. It is
vital for the change management team and executive sponsors to gain the support of supervisors and to
build change leadership. Individual change management activities should be used to help these
supervisors through the change process.
Once managers and supervisors are on board, the change management team must prepare a coaching
strategy. They will need to provide training for supervisors including how to use individual change
management tools with their employees
Training and training development
Training is the cornerstone for building knowledge about the change and the required skills. Project team
members will develop training requirements based on the skills, knowledge and behaviors necessary to
implement the change. These training requirements will be the starting point for the training group or the
project team to develop training programs.
Resistance management
Resistance from employees and managers is normal. Persistent resistance, however, can threaten a
project. The change management team needs to identify, understand and manage resistance throughout
the organization. Resistance management is the processes and tools used by managers and executives
with the support of the project team to manage employee resistance .
Data collection, feedback analysis and corrective action
Employee involvement is a necessary and integral part of managing change. Managing change is not a
one way street. Feedback from employees is a key element of the change management process. Analysis
and corrective action based on this feedback provides a robust cycle for implementing change.
Celebrating and recognizing success
Early successes and long-term wins must be recognized and celebrated. Individual and group recognition
is also a necessary component of change management in order to cement and reinforce the change in the
organization.
The final step in the change management process is the after-action review. It is at this point that you can
stand back from the entire program, evaluate successes and failures, and identify process changes for the
next project. This is part of the ongoing, continuous improvement of change management for your
organization and ultimately leads to change competency.
Summary
These eight elements comprise the areas or components of a change management program. Along with
the change management process, they create a system for managing change. Good project
managers apply these components effectively to ensure project success, avoid the loss of valued
employees, and minimize the negative impact of the change on productivity and a company's
customers.
1.11. UAT - Techniques of conducting user acceptance testing
User Acceptance Testing (UAT) is one sure way to reduce or eliminate change requests, and drastically
reduce project costs. If your organization does not practice UAT or does not have a mature process of
UAT, this article provides information to hopefully persuade you to re-consider. UAT is an effective
process with a high rate of return for those who take the time to implement and follow its discipline. If
missing from the software development life cycle, your organization is missing a great opportunity to
improve project success.
Testing accomplishes a variety of things, but most importantly it measures the quality of the application.
Testing presupposes there are defects in the software waiting to be discovered and this view is rarely
disproved or even disputed. Several factors contribute to the importance of making UAT testing a high
priority of any software development effort; these include:
Reducing the cost of developing the application. Minimal savings that might occur in the early
stages of the development cycle by delaying testing efforts are almost certainly bound to increase
development Costs later.
Ensuring that the application behaves exactly as expected. For the vast majority of programs,
unpredictability is the least desirable consequence of using an application.
Reducing the total cost of ownership. By providing software that looks and behaves as shown in
your documentation, your customers require fewer hours of training and less support from
product experts.
Developing loyalty and word-of-mouth market share. Finding success with a program that offers
the kind of quality that only thorough testing can provide is much easier than trying to build a
customer base on buggy and defect-riddled code.
What is User Acceptance Testing?
User Acceptance Testing (UAT) - also called beta testing, application testing, and/or end user testing - is
a phase of software development in which the software is tested in the "real world" by the intended
audience or a business representative. Whilst the technical testing of IT systems is a highly professional
and exhaustive process, testing of business functionality is an entirely different proposition.
The Goal of UAT Testing
If you ask somebody the question “What is the goal of a software test?'' you might get an answer
like: “The goal is to prove that a system does what it is supposed to do''. This answer is not exactly correct
and demonstrates the necessity to define some fundamentals about software testing. Another response
would be, “The goal is to find faults or defects''.
The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user
scenarios and ensure the system is sufficient and correct for business usage.
Where does Testing Fit In?
When a software developer writes code, it is common for mistakes to occur, such that requirements are
not adequately implemented or they are forgotten. It is during this process that errors are introduced into
the system. It is also possible that the business had not communicated their requirements correctly, or they
could have insufficient details, which could result in a system working as designed, but not as expected.
UAT tests are created to verify the system’s behavior is consistent with the requirements. These tests will
reveal defects within the system. The work associated with UAT begins after requirements are written and
continues through the final stage of testing before the client/user accepts the new system.
The “V” Model for Testing
The “V” model is a methodology where development and testing takes place at the same time with the
same kind of information available to both teams. It is good practice to write the UAT test plan
immediately after the requirements have been finalized.
The "V" model shows development phases on the left hand side and testing phases on the right hand side.
Why is Testing Important?
Most of us have had an experience with software that did not work as expected. Software that doesn’t
work can have a large impact on an organization, and it can lead to many problems including:
Loss of money – this can include losing customers right through to financial penalties for non-
compliance to legal requirements
Loss of time – this can be caused by transactions taking a long time to process but can include staff not
being able to work due to a fault or failure
Damage to business reputation – if an organization is unable to provide service to their customers due
to software problems then the customers will lose confidence or faith in this organization (and probably
take their business elsewhere)
It is important to test the system to ensure it is error free and that it supports the business that depends on
it. The later problems are discovered the more costly they are to fix.
The later problems are discovered the more costly they are to fix.
Some Common Testing Problems
If you make a list of some of the most common test problems, you will realize that in many cases the
majority of problems are nontechnical. More often than not, they are consequences of the test process
itself, including the overall composition of the test team and whether the company follows well-integrated
processes for formal requirements handling and change management. The results indicate the huge
discrepancy in the level of importance that different organizations give to testing. Some of these problems
are more common to younger organizations; others are pitfalls that anyone can encounter.
The Cost Multiplier
An informal survey of the relative cost of finding defects throughout the software development lifecycle
was conducted several years ago. It was found that a problem that goes undetected and unfixed until an
application is actually in operation can be 40 – 100 times more expensive to resolve than resolving the
problem early in the development cycle.
In traditional testing methodologies, most defects are discovered late in the software development
process. Finding and fixing these defects cost much more than if they had been found earlier. Another
survey of the relative cost of testing software compared with the overall cost of developing software gives
a range of estimates, from 10% in smaller organizations to 70% in some larger and mature organizations.
Lessons Learned/Best Practices
In order to avoid mistakes that may impact the process, cost, and quality of the software testing phase, it
is a good idea for testers to get involved with the project as early as possible and consider the following:
Focus testing on requirements
Poorly written requirements account for the majority of project failures, so it is important to have the
testers involved with the review and test plan creation at the beginning of the project
Design systems for testability
Systems should be designed and coded with testing in mind. Testers should emphasize the
importance of error logs, interfaces and smaller, standalone components which can greatly
improve the testability of a system once testers become involved
Consider usability testing
One of the most overlooked requirements is “usability”. Testers should promote the importance
of ease of use and schedule usability tests as early as possible
Traits of a Good UAT Tester
A UAT Tester is one of the most important testing roles since they are validating the system meets the
business needs. UAT is usually the final activity before the system goes “live” and this role requires
multi-faceted skills. These qualities allow the person playing that role to perform this important activity.
Without these qualities one may not be able to conduct a proper UAT test. These four core qualities of a
UAT Tester are:
Background: Experience of user operations, Not involved in the overall IT project, Experience in the use
of IT facilities, and respected as an independent thinker
Skill: A good communicator, avoids politics, Expects the system to fail
Independence: Not involved in user specifications, Has an independent reporting structure, and is a self-
starter
Attitude: Lateral thinker, tenacious, analytical
The Role, Activities, and Deliverables of the Business Analyst during UAT
Business Analysts make good UAT testers because they are independent from the developers; therefore
arguably more objective. In most cases they also understand the business requirements, and can prepare
test scenarios and test data, which are realistic. This allows them to better define the context in which the
system will be used and better assess its fit for purpose. Finally Business Analysts have a vested interest
in ensuring the system is of high quality so are motivated to perform rigorous testing.
Tasks of User Acceptance Testing
When performing UAT, there are seven (7) basic steps to ensure the system is tested thoroughly and
meets the business needs.
Analyze Business Requirements
Identify UAT Scenarios
Define the UAT Test Plan
Create UAT Test Cases
Run the Tests
Record the Results
Confirm Business Objectives are met
Documents Used by the Business Analyst
One of the most important activities performed by the Business Analyst is to identify and develop UAT
test scenarios. These scenarios are derived by analyzing the documents that were previously developed
during the early phases of the project. These documents include:
Business Use Case
Business Process Flows
Project Charter
Context Diagram
Business Requirements Document (BRD)
System Requirements Specification (SRS)
Testing Guidelines and Techniques
Other Vendor’s Deliverables
Documents Created by the Business Analyst
Once UAT Test Scenarios are identified, the Business Process Unit will create three deliverables:
UAT Test Plan
UAT Test Cases
After running the tests, a Defect Log captures problems
What is a UAT Test Plan?
The UAT Test Plan documents the strategy that will be used to verify and ensure an application meets its
requirements to the business. The UAT Test Plan is a document which outlines the plan for user
acceptance testing of the project deliverables. This document is a high level guide, and will refer to test
cases that will be developed and used to record the results of user testing.
What are UAT Test Cases?
The User Acceptance Test Cases help the test execution team to test the application thoroughly. This also
helps ensure that the UA testing provides sufficient coverage of all the UAT scenarios. The Use Cases
created during the Requirements definition phase may be used as inputs for creating test cases.
The User Acceptance Test Case describes in a simple language the precise steps to be taken to test
something
What is a UAT Defect Log?
The UAT Defect Logs a document for capturing and reporting defects identified during UAT. Defects are
documented so that they can be evaluated and resolved.
Information included in the Defect Log is:
Severity (e.g., High, Med, Low)
Status (e.g., Open, Closed, Deferred)
Date Reported/Fixed
Problem Description
1.12. Techniques of managing user expectations
Some users may make unrealistic demands, but most of the time; they just want software that's easy to
use and that works the way it's supposed to. Justin James itemizes several basic user expectations and
ways to address them.
It's no surprise that users have expectations that, if not met, make those users angry and frustrated. User-
friendly applications are much more likely to generate revenue, from sales of the software, sales enabled
by the software, or some other revenue model. Yet for whatever reason, a significant portion of
applications don't meet user expectations in a number of areas. Here are 10 common user expectations
and what you can do to meet them so that you'll have a happy group of users.
I: Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. "Inaccurate" covers a
huge amount of ground, in the users' eyes. For example, if a package has been delivered but the courier's
Web site shows that it is still 200 miles away, that isn't "out of date" to the user, it is "inaccurate."
Another winner is when item information on an invoice or account history has no resemblance to the
product that was ordered; this is sure to generate a few frantic calls to the customer service department.
The potential for user pain is limitless within this category. Unfortunately, many of the root causes of
inaccurate data are out of the developer's hands: user error, insufficient information, failure to follow
processes, and so on. But enough of it is within our power to at least make a dent in the problem. Make
sure that your application validates all data, contains rules for performing "sanity checks" whenever
possible, requires the right data, and uses atomic transactions instead of batch processing whenever
possible.
II: Responsive UIs
If there's one surefire way to make users angry, it's to put the dreaded hourglass on their screen. For extra
credit, block the main UI thread entirely so it doesn't respond to user input and looks like the application
is hung. If they don't kill the application completely, they sure will be shocked when it suddenly starts to
respond like a ghoul rising from the grave (brain eating optional).
If you really want to annoy them, have it suddenly process all of their frantic clicks and other inputs.
Nothing can cause users to fly off the handle like finding out that their work was destroyed by keystrokes
sent while the application looked hung. Provide them with the experience they expect and deserve:
Perform long-running processes in a separate thread to allow the UI to update, give them a progress
indicator that makes it clear that the application is not hung, and offer them a useful and responsive cancel
button if possible.
III: Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really
remember a username -- and the username they have on that service is hard to remember. For example, I
use "jjames" for many Web sites, but sometimes that is not available, so I might end up with "jjames6" or
something else, and I use site only a few times a year. The frustration comes in when I keep trying
passwords with the username "jjames" and I forget that this is a site where I have the unusual name.
That's when I start asking myself if I really need the site at all. You should either have a prominent
"forgot your username?" system or just use the e-mail address, account number, or some other piece of
information that is unique to each user but is not an arbitrary username.
IV: Consistent input
Some Web developers seem to think that it makes sense for the phone number field on a page to have a
different input box for each part of the phone number and to make the cursor automatically move to the
next part of the phone number field when the current one is filled. This does make sense in a way, but it
doesn't make too much sense to users unless all of the fields they encounter behave the same way. Do
your users a favor and save yourself some work in the process: leave these fields alone or just have the
phone number be one large text input.
V: Compatibility
A long time ago, when people went to stores to purchase software in boxes, it was common to have to
spend 15 minutes studying the box to determine whether it would run on your system. Now, as long as the
application runs on your OS, it's hard to find a machine made in the last few years that lacks the physical
specs to run the non-game applications out there. Nonetheless, application incompatibility still exists.
Ironically, it is most common on the supposedly platform-independent Internet. With the exception of
some "must-have" enterprise class application, there is no way that a user or organization is going to jump
through hoops to make your application run or your Web site work.
So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn't mean
that a Windows application needs to be made to run on Linux; but it does mean that a Windows
application should work on XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your
Web applications should work on Internet Explorer, Firefox, Opera, Safari, and Chrome across OSes
without a loss of functionality or significant differences in appearance.
VI: Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or
that a simple text editor should require 1 GB of RAM to run. Yet it seems that more and more
applications are huge resource hogs. It seems like every minor application out there is nearly as large as
Microsoft Office was five years ago... and Microsoft Office itself is now the size that an operating system
was a few years ago! Users expect better, and so should you. Cut the bloat. Ask yourself if your
application really needs 100 MB of stock images of people using their laptops on the beach or 30 MB of
custom sound files. Chances are, it doesn't.
VII: Documentation
We all know how much developers dislike writing documentation. So we tell ourselves that the
application is so easy to use, "only an idiot would need a manual." There are two problems with this
thinking. The first is that the world has plenty of idiots in it. The second is that we are usually wrong
about how easy the application is to use. If your organization has a technical writer to create the
documentation, involve that person from the get-go; the top complaint I hear from technical writers is that
they are handed a nearly finished product and told to document it, with little insight into how it actually
should be used. If you do not have a technical writer available, you will really need to work hard to make
sure that the documentation does not merely state the obvious and is written in a way that will be helpful
to end users who are unfamiliar with your application.
VIII: No surprises
Some applications are filled with surprises. Of course, the definition of a "surprise" is that users don't
expect it. But at a higher level, users expect that nothing will come at them from left field, either. This
covers a lot of territory. Here are some examples of things your application should not do:
Require additional payments or service fees (including cell phone minutes for mobile
applications) that are not made obvious before the user purchases the software in the first place
Install any advertisement distribution mechanisms
Add any browser toolbars, Outlook plug-ins, or other "helpful applications or add-ons" to the
system
Delete or modify user data or system files, including libraries
Send or capture usage data or personal information, for marketing or technical purposes, without
the user's knowledge and consent
Replace the current default applications for tasks without explicit user confirmation
While many users probably won't notice at least a few of these, and many users won't raise a big stink
about it, it is still wrong. Users don't like it. After all, do you like it when applications behave like this?
IX: Easy data backup/restore
Some applications are notorious for being difficult to back up and restore. Some applications hide their
data in areas that might not get backed up (especially when the user prepares to move to a new PC or do
an OS wipe/reinstall). Microsoft Outlook Express immediately comes to mind, since it buries your mail in
the Windows folder instead of user data. (I once lost five years' worth of saved e-mails thanks to this.)
Other applications like to lock their data in a way that backup applications can't back them up properly.
Make sure that your application puts its data in the appropriate places to allow it to be easily backed up,
restored, transferred to a new PC, and so on, and test common backup applications for compatibility with
your application, even while it is running, if appropriate.
X: Does what it says it will
I know, this one is just plain silly, right? It makes perfect sense that if an application claims it will do
something, that it actually does it. (Doing it well is optional.) At the same time, far too many apps not
only fail to meet users' assumptions, but they do not deliver on their explicitly stated promises either.
While this may bring up the traditional issues of salespeople and marketing departments promising
beyond reality, the simple fact is this: If a user has paid for a particular feature set, you need to deliver
that feature set, one way or another. Don't let your users down by delivering an application that says it
does XYZ, but only does X and Z!
1.13. Baseline
The project’s Baseline is used to measure how performance deviates from the plan. Your performance
Measurements would only be meaningful if you had an accurate baseline
A project baseline is defined as the original scope; cost and schedule the project’s baseline must be
completely defined and documented before the project execution and control activities can begin
Once the project starts execution, the project’s baseline is put under change control to help you evaluate
any further change and its impact on the project. No meaningful measurements can be made if the scope,
cost and schedule are not under strict change control disciplines.
If any change is approved then your new baseline is redefined as the original plan plus the approved
change. It is a good idea to keep records that show how the plan has progressed and changed over time.
Frequent requests for changes to the project requirements may indicate that there was an incomplete
initial requirements analysis or the lack of meaningful communication with users and customers early in
the project initiation.
1.14. Defect Management
The process of recognizing, investigating, taking action and disposing of defects. It involves recording
defects, classifying them and identifying the impact.
The typical defect management process includes the following high level process steps. When
Implemented inside of a specific organization, each of these high level steps would have more detailed
Standard operating procedures along with policies to carry out the details of the process.
Identification - This step involves the discovery of a defect. Hopefully, the person discovering the
defect is someone on the testing team. In the real world, it can be anyone including the other individuals
on the project team, or on rare occasions even the end customer.
Categorization - When a defect is reported, it is typically assigned to a designated team member to
confirm that the defect is actually a defect as opposed to an enhancement, or other appropriate category as
defined by the organization. Once categorized, the defect moves on in the process to the next step which
is prioritization.
Prioritization – Prioritization is typically based on a combination of the severity of impact on the user,
relative effort to fix, along with a comparison against other open defects. Depending on the size and
structure of the organization, the prioritization is often handled by a formal change control board. The
priority should be determined with representation from management, the customer, and the project team.
Assignment - Once a defect has been prioritized, it is then assigned to a developer or other technician to
fix.
Resolution - The developer fixes (resolves) the defect and follows the organization's process to move the
fix to the environment where the defect was originally identified.
Verification - Depending on the environment where the defect was found and the fix was applied, the
software testing team or customer typically verifies that the fix actually resolved the defect.
Closure - Once a defect has been resolved and verified, the defect is marked as closed.
Management Reporting - Management reports are provided to appropriate individuals at regular
intervals as defined reporting requirements. In addition, on-demand reports are provided on an as-needed
basis.
1.15. Analysis techniques
Opposition is an inevitable part of change and one that can significantly impact your community
organizing. However, if you know how to take stock of the opposition inside and outside of your effort or
group, you are more likely to plan and act effectively.
That's where SWOT analysis comes in. SWOT can help you handle both ordinary and unusual situations
in your community health or development initiative, by giving you a tool to explore both internal and
external factors that may influence your work.
What is SWOT analysis and why we should use SWOT analysis
The name says it: Strength, Weakness, Opportunity, Threat. A SWOT analysis guides you to identify the
positives and negatives inside your organization (S-W) and outside of it, in the external environment
(O-T). Developing a full awareness of your situation can help with both strategic planning and decision-
making.
The SWOT method (which is sometimes called TOWS) was originally developed for business and
industry, but it is equally useful in the work of community health and development, education, and even
personal growth.
SWOT is not the only assessment technique you can use, but is one with a long track record of
effectiveness. The strengths of this method are its simplicity and application to a variety of levels of
operation.
When do you use SWOT?
A SWOT analysis can offer helpful perspectives at any stage of an effort. You might use it to:
Explore possibilities for new efforts or solutions to problems.
Make decisions about the best path for your initiative. Identifying your opportunities for success
in context of threats to success can clarify directions and choices.
Determine where change is possible. If you are at a juncture or turning point, an inventory of your
strengths and weaknesses can reveal priorities as well as possibilities.
Adjust and refine plans mid-course. A new opportunity might open wider avenues, while a new
threat could close a path that once existed.
SWOT also offers a simple way of communicating about your initiative or program and an excellent way
to organize information you've gathered from studies or surveys.
The elements of SWOT analysis:
A SWOT analysis focuses on the four elements of the acronym, but the graphic format you use varies
depending on the depth and complexity of your effort.
Remember that the purpose of performing a SWOT is to reveal positive forces that work together and
potential problems that need to be addressed or at least recognized. Before you conduct a SWOT session,
decide what format or layout you will use to communicate these issues most clearly for you.
We will discuss the process of creating the analysis below, but first here are a few sample layouts-ideas of
what your SWOT analysis can look like.
You can list internal and external opposites side by side. Ask participants to answer these simple
questions: what are the strengths and weaknesses of your group, community, or effort, and what are the
opportunities and threats facing it
Internal External
Strengths Weaknesses Opportunities Threats
Or if a looser structure helps you brainstorm, you can group positives and negatives to think broadly
about your organization and its external environment.
Positives Negatives
Strengths
Assets
Resources
Opportunities
Prospects
Weaknesses
Limitations
Restrictions
Threats
Challenges
And here's a third option for structuring your SWOT analysis that might be appropriate for a large
initiative that requires detailed planning or many alternatives. This more elaborate "TOWS Matrix" is
adapted from Fred David's Strategic Management text. Here a working table guides you to identify
strategies by matching items in each quadrant.
STRENGTHS
1.
2.
WEAKNESSES
1.
2.
3.
4. 3.
4.
OPPORTUNITIES
1.
2.
3.
4.
Opportunity-Strength (OS)
Strategies
Use strengths to take advantage of
opportunities
1.
2.
Opportunity-Weakness (OW) Strategies
Overcome weaknesses by taking advantage
of opportunities
1.
2.
THREATS
1.
2.
3.
4.
Threat-Strength (TS) Strategies
Use strengths to avoid threats
1.
2.
Threat-Weakness (TW) Strategies
Minimize weaknesses and avoid threats
1.
2.
David gives an example for Campbell Soup Company that stresses financial goals, but it also illustrates
how you can pair the items within a SWOT grid to develop strategies. (This version of the chart is
abbreviated.)
STRENGTHS
Current profit ratio
increased
Employee morale high
Market share has
increased
WEAKNESSES
Legal suits not resolved
Plant capacity has
fallen
Lack of strategic
management system
OPPORTUNITIES
Western European
unification
Rising health
consciousness in selecting
foods
Demand for soups
increasing annually
Opportunity-Strength (OS)
Strategies
Acquire food company in Europe
(S1, S3, O1)
Develop new healthy soups (S2,
O2)
Opportunity-Weakness (OW)
Strategies
Develop new Pepperidge Farn
products (W1, O2, O3)
THREATS
Low value of dollar
Threat-Strength (TS) Strategies
Develop new biodegradable soup
containers (S1, T2)
Threat-Weakness (TW)
Strategies
Close unprofitable European
Tin cans are not
biodegradable
operations (W3, T1)
This example also illustrates how threats can become opportunities (and vice versa). The limitation of tin
cans (which aren't biodegradable) creates an opportunity for leadership in developing biodegradable
containers. There are several formats you can use to do a SWOT analysis, but whatever format you use,
don't be surprised if your strengths and weaknesses don't precisely match up to your opportunities and
threats. You might need to refine, or you might need to simply look at the facts longer, or from a different
angle. Your chart, list or table will certainly reveal patterns.
Listing Internal Factors: Strength and Weaknesses (S, W)
Internal factors include your resources and experiences. General areas to consider are:
Human resources - staff, volunteers, board members, target population
Physical resources - your location, building, equipment (Does your building have a prime
location? Does it need renovations?)
Financial - grants, funding agencies, other sources of income
Activities and processes - programs you run, systems you employ
Past experiences - building blocks for learning and success, your reputation in the community
Don't be too modest when listing your strengths. If you're having difficulty naming them, start by
simply listing your characteristics (e.g., we're small, we're connected to the neighborhood). Some
of these will probably be strengths.
Although the strengths and weakness of your organization are your internal qualities, don't
overlook the perspective of people outside your group. Identify strengths and weaknesses from
both your own point of view and that of others-those you serve or deal with. Do others see
problems--or assets--that you don't?
How do you get information about how outsiders perceive your strengths and weaknesses? You
may know already if you've listened to those you serve. If not, this might be the time to gather
that type of information. See "Related Sections" for ideas on conducting focus groups, user
surveys, listening sessions, and meetings.
Listing External Factors: Opportunity, Threat (O, T)
Cast a wide net for the external part of the assessment. No organization, group, program, or
neighborhood is immune to outside events and forces. Consider your connectedness, for better
and worse, as you compile this part of your SWOT list.
Forces and facts that your group does not control include:
Future trends - in your field (Is research finding new treatments?) or the culture (Do current
movies highlight your cause?)
The economy - local, national, or international
Funding sources - foundations, donors, legislatures
Demographics - changes in the age, race, gender, culture of those you serve or in your area
The physical environment (Is your building in a growing part of town? Is the bus company
cutting routes?)
Legislation (Do new federal requirements make your job harder...or easier?)
Local, national or international events
As a tool designed for businesses, the major threat to success for most SWOT practitioners is "the
competition." Programs to improve the health and well-being of individuals and communities might not
have competitors in the market sense, but there could be overlap in services with other agencies that you
need to consider. Or perhaps preferences for funding aren't favoring you – you're interested in health
promotions, but treatment is getting all the resources.
So it can help to think of the "competition" in a broad sense as you consider threats to your effort. Perhaps
the competition for your target population's time and attention exists in a competing unhealthy habit, such
as smoking, or in a societal force like tobacco advertising, or even in the lure of couch and TV, which
occupy time that might be given to exercise.
Create SWOT Analysis:
Who Creates the SWOT?
The most common users of a SWOT analysis are team members and project managers who are
responsible for decision-making and strategic planning.
But don't overlook anyone in the creation stage!
An individual or small group can develop a SWOT analysis, but it will be more effective if you take
advantage of many stakeholders. Each person or group offers a different perspective on the strengths and
weaknesses of your program and has different experiences of both.
Likewise, one staff member, or volunteer or stakeholder may have information about an opportunity or
threat that is essential to understanding your position and determining your future.
When and where do you develop a SWOT Analysis?
A SWOT analysis is often created during a retreat or planning session that allows several hours for both
brainstorming and more structured analysis. The best results come when participants are encouraged to
have an open attitude about possibilities. While you might "SWOT" in conjunction with an informational
or business session, the tone when creating a SWOT analysis is usually collaborative and inclusive.
When creating the analysis, all people involved are asked to pool their individual and shared knowledge
and experiences. The more relaxed, friendly and constructive the setting and environment, the more
truthful, comprehensive, insightful and useful your analysis will be.
Here are steps for conducting a gathering to produce your analysis.
Designate a leader or group facilitator who has good listening and group process skills, and who
can keep things moving and on track.
Designate a recorder to back up the leader if your group is large. Use newsprint on a flip chart or
a large board to record the analysis and discussion points. You can record later in a more polished
fashion to share with stakeholders and to update.
Introduce the SWOT method and its purpose in your organization. This can be as simple as
asking, "Where are we, where can we go?" If you have time, you could run through a quick
example based on a shared experience or well-known public issue (even the new TV season).
Depending on the nature of your group and the time available, let all participants introduce
themselves. Then divide your stakeholders into smaller groups. If your retreat or meeting draws
several groups of stakeholders together, make sure you mix the small groups to get a range of
perspectives, and give them a chance to introduce themselves.
The size of these depends on the size of your entire group – breakout groups can range
from three to ten. If the size gets much larger, some members may not participate.
Have each group designate a recorder, and provide each with newsprint or dry -erase board.
Direct them to create a SWOT analysis in the format you choose-a chart, columns, a matrix, or
even a page for each quality.
Give the groups 20-30 minutes to brainstorm and fill out their own strengths, weakness,
opportunities and threats chart for your program, initiative or effort. Encourage them not
to rule out any ideas at this stage, or the next.
Remind groups that the way to have a good idea is to have lots of ideas. Refinement can
come later. In this way, the SWOT analysis also supports valuable discussion within your
group or organization as you honestly assess.
It helps to generate lots of comments about your organization and your program, and
even to put them in multiple categories if that provokes thought.
Once a list has been generated, it helps to refine it to the best 10 or fewer points so that
the analysis can be truly helpful.
Reconvene the group at the agreed-upon time to share results. Gather information from the
groups, recording on the flip-chart or board. Collect and organize the differing groups' ideas and
perceptions.
Proceed in S-W-O-T order, recording strengths first, and weaknesses second, etc.
Or you can begin by calling for the top priorities in each category -the strongest strength, most
dangerous weakness, biggest opportunity, worst threat--and continue to work across each
category.
Ask one group at a time to report ("Group A, what do you see as strengths?") You can vary which
group begins the report so a certain group isn't always left "bringing up the end" and repeating
points made by others. ("Group B, let's start with you for weaknesses.")
Or, you can open the floor to all groups ("What strengths have you noted?") for each category
until all have contributed what they think is needed.
Discuss and record the results. Depending on your time frame and purpose:
o Come to some consensus about the most important items in each category
o Relate the analysis to your vision, mission, and goals
o Translate the analysis to action plans and strategies
If appropriate, prepare a written summary of the SWOT analysis to give or e-mail to participants
for continued use in planning and implementing your effort.
How do you Use your SWOT analysis
In some ways a SWOT analysis pushes you to think "inside the box" by asking you to categorize your
effort in such simple opposing terms. But the purpose of this information gathering is definitely to help
you move outside the box of any constraints or limitations that may have hindered you before.
Knowledge is indeed power, and knowing what the positives and negatives of your program are puts you
in a more powerful position for action. While a SWOT analysis is not in itself action, it can be a "support
team" to help you:
Identify the issues or problems you intend to change
Set or reaffirm goals
Create an action plan
As you consider your analysis, be open to the possibilities that exist within a weakness or threat.
Likewise, recognize that an opportunity can become a threat if everyone else sees the opportunity and
plans to take advantage of it as well, thereby increasing your competition.
Finally, during your assessment and planning, you might keep an image in mind to help you make the
most of a SWOT analysis: Look for a "stretch," not just a "fit." SWOT usually reflects your current
position or situation. Therefore one drawback is that it might not encourage openness to new possibilities.
You can use SWOT to justify a course that has already been decided upon, but if your goal is to grow or
improve, you will want to use it differently.
In summery
A realistic recognition of the weaknesses and threats that exist for your effort is the first step to countering
them with a robust and creative set of strengths and opportunities. A SWOT analysis identifies your
strengths, weaknesses, opportunities and threats to assist you in making strategic plans and decisions.
SWOT is a simple yet comprehensive way of assessing the positive and negative forces within and
without your organization, so you can be better prepared to act effectively. The more stakeholders you
involve in preparing the SWOT, the more valuable your analysis will be.
Whatever courses of action you decide on, the four-cornered SWOT analysis prompts you to move in a
balanced way throughout your program.
It reminds you to:
build on your strengths
minimize your weaknesses
seize opportunities
counteract threats
A SWOT analysis will be most helpful if you use it to support the vision, mission, and objectives you
have already defined. The SWOT will at least provide perspective, and at best will reveal connections and
areas for action.
GAP Analysis
I. The process through which a company compares its actual performance to its expected
performance to determine whether it is meeting expectations and using its resources effectively.
Gap analysis seeks to answer the questions "where are we?" (Current state) and "where do we
want to be?" (Target state).
A method of asset-liability management that can be used to assess interest rate risk or liquidity
risk excluding credit risk. Gap analysis is a simple IRR measurement method that conveys the
difference between rate sensitive assets and rate sensitive liabilities over a given period of time.
This type of analysis works well if assets and liabilities are comprised of fixed cash flows.
Because of this a significant shortcoming of gap analysis is that it cannot handle options, as
options have uncertain cash flows.
II. Gap analysis compares the gap between an organization’s actual performances against its
potential performance. In gap analysis, you typically list out the organization’s current state, its
desired state, and a comprehensive plan to fill out the gap between these two states. This analysis
can yield a lot of insights into an organization’s performance and functioning. It is pertinent for
businesses as well as more organic organizations such as school classrooms and communities.
III. Gap analysis is more organic and flexible than SWOT (Strengths, Weaknesses, Opportunities and
Threats) analysis, which typically follows a four quadrant pattern. gap analysis may be highly
quantitative or conceptual, using either Excel worksheets or flowcharts. The analyst has much
more freedom in choosing what to focus on. At the same time, every gap analysis template must
have a few essential components, as shown below:
I. State Descriptions
The first step in gap analysis is identifying your current and future desired state. This can be done by
describing the following:
1. Your Current State
Every gap analysis starts with introspection. Your gap analysis template should start off with a column
labelled ‘Current State’ wherein you list out all the attributes you’d like to see improved. Your focus can
be as wide (ex: the whole business) or narrow (ex: HR policies within CRM division) as the objective
demands. The analysis can be quantitative (‘currently get 50 orders per day’), qualitative (‘lack of
diversity in workplace’) or both. The key thing is to be specific and factual with an emphasis on
identifying weaknesses.
2. The Future State
The future state represents the ideal condition you’d want your organization to be in. This state can be
highly specific (ex: ‘increase order count to 100 per day’, ‘decrease absenteeism by 25%’), or generic
(‘create more inclusive work culture’). Your gap analysis template should record all the idealized
attributes as they correspond to the current state.
Sometimes, you may not even have a clear conception of an idealized future state and might be
conducting a gap analysis as an exercise towards self-improvement. In this case, you can record ‘N/A’
under the future state column.
II. Bridging the Gap
This is where you identify and describe the gap before finding ways to remedy it.
1. Gap Identification
The next column in your gap analysis template should record whether a gap exists between the current
and future state. A simple ‘Yes’ or ‘No’ can suffice (a description of the gap will be made in the next
column).
2. Gap Description
The gap description should record all the elements that make up the gap between the current and future
state. The description should be consistent with the current/future state. It can be qualitative (‘lack of clear
HR policies for employee termination’) or quantitative (’50 orders/day difference between current and
ideal state’). This should only serve as a description, not a remedy.
III. Factors and Remedies
This is where the rubber hits the road and you identify the factors responsible for the difference between
your current and future performance. You can then use this data to come up with a remedies and action
plans to tackle the performance gap.
1. Factors Responsible for Gap
The next part of your gap analysis template should list all the factors responsible for the gap identified in
the previous column. This list should be specific, objective and relevant (ex: ‘poor employee pre-
screening’ can be one reason for high workplace absenteeism).
2. Remedies, Actions and Proposals
The last step in the gap analysis is listing out all the possible remedies for bridging the gap between the
current and ideal state. These remedies should directly address the factors listed in the column above (ex:
‘video pre-screening for all candidates before interview’ can be one remedy for employee pre-screening
issues). The remedies must be action oriented and specific (‘tie up with new payment processor to reduce
shopping cart abandonment’, not just ‘effect measures to reduce shopping cart abandonment’).
Gap analysis can be an effective tool for analyzing and understanding organizations. It is particularly
applicable in a new business setting, of course. New businesses will find it especially useful for gaining
insights into how to organize and allocate resources. if you are starting a new business,
As is-To be
Process As-Is and To-Be Analysis is the term given to producing flowcharts and process maps that depict
the current situation and then go on to develop the future presentation.
The As-Is is a detailed presentation of the process as it is performed today. It collects data and highlights
opportunities for improvement.
The To-Be can either be a new process addressing the problems from the AS-IS analysis or a completely
new process design that takes into account information from the AS-IS analysis
1.16. Scope identification
The project scope is developed by the project manager and basically defines the products and deliverables
to be produced during the project. The project scope takes the inputs from the user requirements and
business case, and it structures the project into exactly what needs to be performed. In other words, it
documents what the intended business goals are.
A common problem encountered with project scope is that the majority of initial client discussions and
negotiations take place with the client and marketing executive and are carried out in isolation from the
solution team. The project manager is rarely involved early on and it’s not until later that he gets to set
things right in his project schedule using a tool like Seavus project viewer Unfortunately, the early
schedule is often created by the marketing executive with the goal of ‘selling the project’ in mind.
The ultimate goal of marketing executives is to market and sell solutions to clients, and when a solution is
agreed upon, the client is left with the belief that it will get that specific solution. However, the technical
details are left up to the solution team to resolve, and in many cases, the scope of the project changes. The
project manager should work closely with the marketing manager and business analyst in order to
negotiate the complete scope of work. Remember that if the scope is left untouched and uncontrolled, it is
probable that your project will come in over budget and behind schedule.
It’s important that the project solution team meet with the client within a few days to initiate the kick-off
meeting and start defining the scope in more detail. This is where the business analysts and project
manager start playing a very valuable role by providing the appearance, the knowledge, and the
commitment to assist the client in solving its business problems. The project analysis team should include
the client as part of the team in order to verify that the scope is defined accurately. One way to present the
project scope is through the use of the project management plan. Another is by capturing the
requirements and creating a follow-up requirements definition document – both of which should be
signoff/approval points with the customer. The purpose of either of these documents is to allow
stakeholders to determine quickly if a given requirement should possibly be implemented by the project.
Whatever document is ultimately used, the following should be identified:
What the project scope is
What the project is not
How it will be managed
The risks of scope change
How scope changes will be integrated into the project
It is very likely that most projects will have some degree of scope change during their life cycle. Project
managers should clearly understand what is included or excluded from the project, and what this effect
will likely have on the entire project.
1.17. Scope identification
Requirements elicitation is the practice of collecting the requirements of a system from users, customers
and other stakeholders. [1] The practice is also sometimes referred to as requirements gathering.
The term elicitation is used in books and research to raise the fact that good requirements cannot just be
collected from the customer, as would be indicated by the name requirements gathering. Requirements
elicitation is non-trivial because you can never be sure you get all requirements from the user and
customer by just asking them what the system should do. Requirements elicitation practices include
interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing
and prototyping.
Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation
process. Requirements elicitation is a part of the requirements engineering process, usually followed by
analysis and specification of the requirements.
Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an
important first meeting could be between software engineers and customers where they discuss their
perspective of the requirements.
Problem
In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:
Problems of scope. The boundary of the system is ill-defined or the customers/users specify
unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
Problems of understanding. The customers/users are not completely sure of what is needed, have a poor
understanding of the capabilities and limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or untestable.
Problems of volatility. The requirements change over time. The rate of change is sometimes referred to
as the level of requirement volatility
Requirements quality can be improved through these approaches:[3]
Visualization. Using tools that promote better understanding of the desired end-product such as
visualization and simulation.
Consistent language. Using simple, consistent definitions for requirements described in natural language
and use the business terminology that is prevalent in the enterprise.
Guidelines . Following organizational guidelines that describe the collection techniques and the types of
requirements to be collected. These guidelines are then used consistently across projects.
Consistent use of templates. Producing a consistent set of models and templates to document the
requirements.
Documenting dependencies. Documenting dependencies and interrelationships among requirements.
Analysis of changes. Performing root cause analysis of changes to requirements and make corrective
actions.