Gap Analysis.

Gap analysis is a very useful tool for helping marketing managers to decide upon marketing
strategies and tactics. Again, the simple tools are the most effective. There's a straightforward structure to
follow. The first step is to decide upon how you are going to judge the gap over time. For example, by
market share, by profit, by sales and so on.
This will help you to write SMART objectives. Then you simply ask two questions - where are we now?
and where do we want to be? The difference between the two is the GAP - this is how you are going to get
there. Take a look at the diagram below. The lower line is where you'll be if you do nothing. The upper line
is where you want to be.
What is Gap Analysis?

This is how you close the gap by deciding upon strategies and tactics - and that's gap analysis.
Gap analysis consists of defining the present state, the desired or `target' state and hence the gap between
them. In the later stages of problem solving the aim is to look at ways to bridge the gap defined and this
may often be accomplished by backward-chaining logical sequences of actions or intermediate states from
the desired state to the present state. In other words, asking the question:
"What (b) must be in place, or must have happened in order that this desired state (a) can exist?"
- then -
"What (c) must be in place, or must have happened in order that this desired state (b) can exist?"
Etcetera.
Gap analysis alone however is not adequate for all problem situations as goals may evolve and emerge
during the course of problem solving, "what ought to be" can be a highly variable target. Also, some
problems have many alternative solutions, in which case backward-chaining search strategies will have
little practical use
Functional Requirements
Functional requirements capture the intended behavior of the system. This behavior may be expressed as
services, tasks or functions the system is required to perform.
In product development, it is useful to distinguish between the baseline functionality necessary for any
system to compete in that product domain, and features that differentiate the system from competitors’
products, and from variants in your company’s own product line/family. Features may be additional
functionality, or differ from the basic functionality along some quality attribute (such as performance or
memory utilization).
One strategy for quickly penetrating a market, is to produce the core, or stripped down, basic product,
adding features to variants of the product to be released shortly thereafter. This release strategy is obviously
also beneficial in information systems development, staging core functionality for early releases and adding
features over the course of several subsequent releases.
In many industries, companies produce product lines with different cost/feature variations per product in
the line, and product families that include a number of product lines targeted at somewhat different markets
or usage situations. What makes these product lines part of a family, are some common elements of
functionality and identity. A platform-based development approach leverages this commonality, utilizing a
set of reusable assets across the family.
These strategies have important implications for software architecture. In particular, it is not just the
functional requirements of the first product or release that must be supported by the architecture. The
functional requirements of early (nearly concurrent) releases need to be explicitly taken into account. Later
releases are accommodated through architectural qualities such as extensibility, flexibility, etc. The latter
are expressed as non-functional requirements.
Use cases have quickly become a widespread practice for capturing functional requirements. This is
especially true in the object-oriented community where they originated, but their applicability is not limited
to object-oriented systems.
Use Cases
A use case defines a goal-oriented set of interactions between external actors and the system under
consideration. Actors are parties outside the system that interact with the system (UML 1999, pp. 2.113-
2.123). An actor may be a class of users, roles users can play, or other systems. Cockburn (1997)
distinguishes between primary and secondary actors. A primary actor is one having a goal requiring the
assistance of the system. A secondary actor is one from which the system needs assistance.
A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is
satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the
service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences
that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because
of exceptional behavior, error handling, etc. The system is treated as a "black box", and the interactions
with system, including system responses, are as perceived from outside the system.
Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal),
without dealing with system internals. A complete set of use cases specifies all the different ways to use the
system, and therefore defines all behavior required of the system, bounding the scope of the system.
Generally, use case steps are written in an easy-to-understand structured narrative using the vocabulary of
the domain. This is engaging for users who can easily follow and validate the use cases, and the
accessibility encourages users to be actively involved in defining the requirements.
Use Case Diagrams
Previous | Home | Next
A use case is a set of scenarios that describing an interaction between a user and a system. A use case
diagram displays the relationship among actors and use cases. The two main components of a use case
diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are modeling. A use
case is an external view of the system that represents some action the user might perform in order to
complete a task.
When to Use: Use Cases Diagrams
Use cases are used in almost every project. The are helpful in exposing requirements and planning the
project. During the initial stage of a project most use cases should be defined, but as the project continues
more might become visible.
How to Draw: Use Cases Diagrams
Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example
is only meant as an introduction to the UML and use cases. If you would like to learn more see the
Resources page for more detailed resources on UML.
Start by listing a sequence of steps a user might take in order to complete an action. For example a user
placing an order with a sales company might follow these steps.
Browse catalog and select items.
Call sales representative.
Supply shipping information.
Supply payment information.
Receive conformation number from salesperson.
These steps would generate this simple use case diagram:
This example shows the customer as a actor because the customer is using the ordering system. The
diagram takes the simple steps listed above and shows them as actions the customer might perform. The
salesperson could also be included in this use case diagram because the salesperson is also interacting with
the ordering system.
From this simple diagram the requirements of the ordering system can easily be derived. The system will
need to be able to perform actions for all of the use cases listed. As the project progresses other use cases
might appear. The customer might have a need to add an item to an order that has already been placed.
This diagram can easily be expanded until a complete description of the ordering system is derived
capturing all of the requirements that the system will need to perform.
The GAP Analysis Program
"Keeping Common Species Common"

The goal of the GAP Analysis Program is to keep common species common by identifying those species
and plant communities that are not adequately represented in existing conservation lands. Common species
are those not currently threatened with extinction. By identifying their habitats, GAP Analysis gives land
managers and policy makers the information they need to make better-informed decisions when identifying
priority areas for conservation.
Project Management Software Gap Analysis
The easiest way to prepare a plan is by gap analysis. A plan can be seen as a set of instructions for moving
the organization from where it is, the current situation, to where the PMO wants it to be, the goal with
desired benefits. To make this plan correctly, it is necessary to know where the organization is now, and
what improvements provide the most benefit to the organization. Assessment is the process of finding out
things worth knowing. Assessments are used to determine the organization's current situation, the benefits
desired by the organization, the goal, and the feasibility of the goal. Once the information is gathered by
assessment, it is analyzed in the planning process. Then the plan – the guide for execution – is built.
Benefits of planning by gap analysis
Planning by gap analysis allows a PMO to adapt a general life cycle, such as the MPOM™ life cycle for
project management offices, to the specific PMO and company. This adaptation results in these benefits:
It maximizes the benefits the PMO offers to the organization.
It ensures that the benefits desired by executives and managers are the goals of the PMO.
It ensures that current problems or issues are defined and resolved.
It ensures that the PMOs goals and plans are feasible.
It improves the effectiveness and efficiency of the PMO and project management throughout the
organization.
The steps of planning and assessment
The steps of planning and assessment are:
1. Assessment of the current situation. This describes the current operating environment, methods, and
processes relevant to project management. It also defines and prioritizes issues and problems.
2. Assessment to define benefits and goals. The PMO will have its own ideas of what the organization
needs. However, it is also crucial to get input from executives and managers, and make sure that the
problems that they see with project management are resolved by PMO activities, and that the PMO's work
brings the benefits they want. This is crucial for obtaining commitment to the PMO's plan and support for
the PMO. That commitment and support translate into promotion and use of the PMOs methods and
services, which leads to success of the PMO.
3. Initial planning. Applying the two assessments above, it is possible to plan the PMO, completing the
planning phase, selecting services and implementing them to launch the PMO's execution phase.
4. Assessment to determine feasibility. During initial planning, questions may arise as to whether a
specific goal or service is feasible. For something to be feasible, it must be accepted by customers and
stakeholders, sufficient skills and talent must be available, and it must be affordable. An assessment can be
performed to determine the status of all of these feasibility issues.
5. Execution. The plan is executed; the services are put into operation.
6. Assessment to determine effectiveness and efficiency. Once the PMO, or a particular service, is up and
running, assessment can be used to ask the questions: Is the PMO (or the service) achieving its goals? Is it
doing so at as low a cost as is possible? The first question is one of effectiveness, the second, one of
efficiency. These assessments compare current results to desired results, and current expenditures to
possible alternatives that would lower cost.
7. Planning improvements. Based on the information from the assessments of effectiveness and
efficiency, minor or major improvements to PMO services may be planned and executed.
What are business req? There are many ways to do business requirements. The initial approaches to
business requirements "modeling" came from the IT world and have been modified to apply to any
organization providing services or products. Business Requirements are the elements or necessary
processes an organization must perform in order to do business. They can be expressed in textual
documents or graphical models. Understanding all facets of the enterprise is a crucial prerequisite to
undertaking a process improvement effort. The business requirements approach that the Inventory
and Monitoring Institute (IMI) presently uses directs the development of a set of hierarchical, top-down,
graphical models, which describe details of every business process and how they are interrelated. The most
common way of doing process improvement is to first examine the business "as-is" or as it is currently
operating. This effort often leads to an in-depth understanding of process interactions, or lack thereof,
which will uncover inefficiencies and disconnects that lead to a desire for improvement. The IMI uses a
business modeling language called eXtended Business Modeling LanguageSM (XBML) to capture the
business knowledge and produce a series of models, diagrammatic pictures or representations of all aspects
of the business captured to include the following dimensions:
WHAT (what do we do?)
WHO (who does what?)
WHERE (where do we do what we do?)
WHICH (which information do we need to do it?)
WHEN (when is it done, order of processes?)
HOW (how do all these elements interact?)
These models can be organized as either "as is" models or "to be" models. As-is models fully describe the
current business, whereas To-be models (also known as should-be models) can be developed describing
alternative business approaches or a desired future business condition.
In formulating these models, the IMI uses a facilitation approach called Business Co-FormulationSM.
Working with Subject Matter Experts (SMEs) from all areas of the organization, this structured approach
drives out the model content or graphic descriptions of information that show relationships and specific
data about what is needed to fulfill the business mission and objectives. The resulting set of models is
finalized after consensus from all involved on how the organization's business processes work.
Development of the models should not be the end of a business process improvement effort. To derive the
most benefit from investments made in model development, the models should be used to continually
examine the business processes, their interactions and efficiency.
Functional Specifications
DEFINITION: A functional specification (or sometimes functional specifications) 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 the programming code. (At least one major product development group used a "Write
the manual first" approach. Before the product existed, they wrote the user's guide for a word processing
system, then declared that the user's guide was the functional specification. The developers were challenged
to create a product that matched what the user's guide described.) Typically, the functional specification for
an application program with a series of interactive windows and dialogs with a user would show the visual
appearance of the user interface and describe each of the possible user input actions and the program
response actions. A functional specification may also …
Activities: Write the Functional Specification
At the beginning of this process, the project team analyzes and creates the requirements documents. There
are four categories of requirements:
Business requirements
User requirements
Operational requirements
System requirements (requirements of the solution).
As team members design the solution and create the functional specifications, they must maintain
traceability between requirements and features. Maintaining traceability serves as a way to check the
correctness of the design and to verify that the design meets the solution’s goals and requirements. The
usual method of maintaining traceability is to tag items in the functional specification with requirement
IDs.
The design process gives the team a systematic way to work from abstract concepts to specific technical
details. This begins with an analysis of user profiles, or personas. The team refines these personas into a
series of use scenarios. Finally, the team refines each use scenario into use cases. This process is called
story-boarding and results in the use scenarios document.
The team then uses the requirements documents, the use scenarios document, and the product and
technology evaluations from the previous process to develop a functional specification that it submits to its
customer and stakeholders for review. This is a detailed description, from the user’s and customer’s
perspectives, of what the solution will look like and how it will behave. The functional specification serves
multiple purposes, including:
Instructions to developers on what to build.
A basis for estimating work.
Agreement with the customer on exactly what will be built.
A point of synchronization for the whole team.
The functional specification is also the basis for building the master project plan and master project
schedule. After the customer and stakeholders accept the functional specification, the team baselines
(places under change control) it and begins to formally track changes to it. After the functional specification
is reviewed and a baseline made, the team can only change it with customer approval.
The project team also creates the design documents that record the results of the design process. These
documents are separate from the functional specification and are focused on describing the internal
workings of the solution. The project team can keep them internal and change them without burdening the
customer with technical issues. The design process has three levels—conceptual design (owned by Product
Management), logical design (owned by Program Management), and physical design (owned by
Development)—so the team produces the following three design documents:
Conceptual design document
Logical design document
Physical design document
The team completes and baselines each level in a staggered sequence.
The following table lists the activities involved in this process. These activities include:
Documenting the project requirements.
Writing the functional specification.
Table 5. Activities and Considerations for Writing the Functional Specification
Activities Considerations
Key questions:
Does the organization have specific business requirements for the solution?
Does the organization have return on investment (ROI) requirements for the solution?
Does the organization have scalability, availability, performance, or security
requirements for the solution? See the Policy SMF for more information.
Do users have specific ease-of-use, reliability, performance, accessibility, language, or
training requirements for the solution? See the Reliability SMF for more information.
Does the solution have specific system and service dependencies? See the service map
section of the Business/IT Alignment SMF for more information.
Does the solution have interoperability requirements?
Will the solution affect the network?
Does Operations have scalability, security, manageability, supportability, availability,
Document the project reliability, staffing, or training requirements for the solution?
requirements Does User Experience understand how users will interact with the solution? Can they
document these interactions as user scenarios and use cases?
Inputs:
Vision/scope document
Policies
Reliability requirements
Outputs:
Usage scenarios document
Requirements documents, including:
Business requirements
Operations requirements.
System requirements.
User requirements.