A Baseline document is defined as any official document that has gone through an initial

approval process and was approved for use as intended. Thus a BDC is an alteration to or
rewriting of any officially approved document. New documents are also announced with
a BDC.

Documents that are approved by the client and will not have
any more changes are baseline docs. Service Level Aggrement
(SLA), Business Requirment Docs(BRD)

Types of baseline document

Functional specification

In software development, a functional specification (also, functional spec or specs or

functional specifications document (FSD) or Program specification) is the set of
documentation that describes the requested behavior of an engineering system. The
documentation typically describes what is needed by the system user (design-goal),
which internal functions are necessary, as well as, requested properties of inputs and
outputs (e.g. of the software system). As a design document, a functional specification
does not typically define the inner workings of the proposed system, it means it does not
yet include the specification how the system function will be implemented. Instead, it
focuses on what various outside agents (people using the program, computer peripherals,
or other computers, for example) might "observe" when interacting with the system.

A typical functional specification might state the following:

When the user clicks the OK button, the dialog is closed and the focus is returned to the
main window in the state it was in before this dialog was displayed.

Such a requirement describes an interaction between an external agent (the user) and the
software system. When the user provides input to the system by clicking the OK button,
the program responds (or should respond) by closing the dialog window containing the
OK button.

It can be informal, in which case it can be considered as a blueprint or user manual from
a developer point of view, or formal, in which case it has a definite meaning defined in
mathematical or programmatic terms. In practice, most successful specifications are
written to understand and fine-tune applications that were already well-developed,
although safety-critical software systems are often carefully specified prior to application
development. Specifications are most important for external interfaces that must remain
stable.
User manual

A user guide, also commonly known as a manual, is a technical communication

document intended to give assistance to people using a particular system[citation needed]. It is
usually written by a technical writer, although user guides could be written by
programmers, product or project managers, or other technical staff, particularly in smaller
companies.

User guides are most commonly associated with electronic goods, computer hardware
and software.

Most user guides contain both a written guide and the associated images. In the case of
computer applications it is usual to include screenshots of how the program should look,
and hardware manuals often include clear, simplified diagrams. The language is written
to match up with the intended audience with jargon kept to a minimum or explained
thoroughly.

Risk analysis

risk analysis is a technique to identify and assess factors that may jeopardize the success
of a project or achieving a goal. This technique also helps to define preventive measures
to reduce the probability of these factors from occurring and identify countermeasures to
successfully deal with these constraints when they develop to avert possible negative
effects on the competitiveness of the company.

One of the more popular methods to perform a risk analysis in the computer field is
called Facilitated Risk Analysis Process (FRAP).

Risk analysis is the process of defining and analyzing the dangers to individuals,
businesses and government agencies posed by potential natural and human-caused
adverse events. In IT, a risk analysis report can be used to align technology-related
objectives with a company's business objectives. A risk analysis report can be either
quantitative or qualitative.

In quantitative risk analysis, an attempt is made to numerically determine the

probabilities of various adverse events and the likely extent of the losses if a particular
event takes place.

Qualitative risk analysis, which is used more often, does not involve numerical
probabilities or predictions of loss. Instead, the qualitative method involves defining the
various threats, determining the extent of vulnerabilities and devising countermeasures
should an attack occur.
Business requirement

A business requirements document (BRD) details the business solution for a project including the
documentation of customer needs and expectations. If an initiative intends to modify existing (or
introduce new) hardware/software, a new BRD should be created. The BRD process can be
incorporated within a Six Sigma DMAIC (define, measure, analyze, improve, control) culture.

The most common objectives of the BRD are:

• To gain agreement with stakeholders

• To provide a foundation to communicate to a technology service provider what the
solution needs to do to satisfy the customer's and business� needs
• To provide input into the next phase for this project
• To describe what not how the customer/business needs will be met by the solution

Prototype

In software development, a prototype is a rudimentary working model of a product or

information system, usually built for demonstration purposes or as part of the
development process. In the systems development life cycle (SDLC) Prototyping Model,
a basic version of the system is built, tested, and then reworked as necessary until an
acceptable prototype is finally achieved from which the complete system or product can
now be developed.

2) In prototype-based programming, a prototype is an original object; new objects are

created by copying the prototype.

3) In hardware design, a prototype is a "hand-built" model that represents a manufactured

(easily replicable) product sufficiently for designers to visualize and test the design.

The word prototype comes from the Latin words proto, meaning original, and typus,
meaning form or model. In a non-technical context, a prototype is an especially
representative example of a given category.

Use cases

A use case is a description of a system’s behaviour as it responds to a request that

originates from outside of that system.

The use case technique is used in software and systems engineering to capture the
functional requirements of a system. Use cases describe the interaction between a
primary actor (the initiator of the interaction) and the system itself, represented as a
sequence of simple steps. Actors are something or someone which exist outside the
system under study, and that take part in a sequence of activities in a dialogue with the
system to achieve some goal. They may be end users, other systems, or hardware devices.
Each use case is a complete series of events, described from the point of view of the
actor.[1]

According to Bittner and Spence, “Use cases, stated simply, allow description of
sequences of events that, taken together, lead to a system doing something useful.”[2]
Each use case describes how the actor will interact with the system to achieve a specific
goal. One or more scenarios may be generated from each use case, corresponding to the
detail of each possible way of achieving that goal. Use cases typically avoid technical
jargon, preferring instead the language of the end user or domain expert. Use cases are
often co-authored by systems analysts and end users. The UML use case diagram can be
used to graphically represent an overview of the use cases for a given system and a Use-
case analysis can be used to develop the 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.

A use case (or set of use cases) has these characteristics:

• Organizes functional requirements

• Models the goals of system/actor (user) interactions
• Records paths (called scenarios) from trigger events to goals
• Describes one main flow of events (also called a basic course of action), and
possibly other ones, called exceptional flows of events (also called alternate
courses of action)
• Is multi-level, so that one use case can use the functionality of another one.

Use cases can be employed during several stages of software development, such as
planning system requirements, validating design, testing software, and creating an outline
for online help and user manuals.
Gap analysis

In information technology, gap analysis is the study of the differences between two
different information systems or applications, often for the purpose of determining how
to get from one state to a new state. A gap is sometimes spoken of as "the space between
where we are and where we want to be." Gap analysis is undertaken as a means of
bridging that space. Among the various methodologies used to perform gap analysis is
IDEF, a group of methods used to create a model of a system, analyze the model, create a
model of a desired version of the system, and to aid in the transition from one to the
other.

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?"

"What (c) must be in place, or must have happened in order that this desired state (b) can
exist?"

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.