SDLC:Software Development Life Cycle

 Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
 Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended
application. Analyzes end-user information needs.
 Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process
diagrams, pseudocode and other documentation.
 Implementation: The real code is written here.
 Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and
interoperability.
 Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and
runs actual business.
 Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different
computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

UML:

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of
an object-oriented software-intensive system under development.[1]UML offers a standard way to visualize a
system's architectural blueprints, including elements such as:

 activities, actors, business processes, database schemas,(logical) components, programming language statements,

reusable software components.[2]

UML diagrams represent two different views of a system model.

 Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and

relationships. The structural view includes class diagrams and composite structure diagrams.

 Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among

objects and changes to the internal states of objects. This view includes use case diagram, sequence diagrams, activity

diagrams and state machine diagrams

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the

structure they are used extensively in documenting the architecture of software systems.

 Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships

among the classes.

 Component diagram: describes how a software system is split up into components and shows the dependencies among these

components.

 Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes

possible.

 Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts

deployed on the hardware.

 Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time.

 Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these

groupings.

 Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and

profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates

what metamodel element a given stereotype is extending.

Behaviour diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a

system, they are used extensively to describe the functionality of software systems.

 Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity

diagram shows the overall flow of control.

 UML state machine diagram: describes the states and state transitions of the system.

 Use case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases,

and any dependencies among those use cases

Interaction diagrams
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being

modeled:

 Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a

combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and

dynamic behavior of a system.

 Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.

 Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the

lifespans of objects relative to those messages.

 Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

Gathering Requirements from All Parties

Techniques involving visualization of the requirements like storyboards, prototypes, scenarios are helpful when you have
a business user who may not be worried about the ins and outs of technical solution or have long attention duration for legalizing the
requirements with users to let the analyst drive his discovery efficiently than just reading a document with a prospective user.
The requirement gathering techniques may differ from one project to another. Some requirement gathering techniques may prove
highly beneficial for you in one project but may not be as productive in the other project or for some other company. Therefore the
usefulness of a technique is determined by its need and the kind of advantages it offers in a particular project. There are 10
essential requirement gathering techniques that you must be aware of in order to manage the projects in a better way and run your
business successfully are:

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

1. Brainstorming

It is utilized in requirements elicitation to gather good number of ideas from a group of people. Usually brainstorming is used in
identifying all possible solutions to problems and simplifies the detail of opportunities. It casts a broad net, determining various
discreet possibilities. Prioritization of such possibilities is vital to locate needles in haystack.

2. Document Analysis

Document Analysis is an important gathering technique. Evaluating the documentation of a present system can assist when making
AS-IS process documents and also when driving the gap analysis for scoping of the migration projects. In today‘s world, you will
also be determining the requirements that drove making of an existing system- a beginning point for documenting all current
requirements. Chunks of information are mostly buried in present documents that assist you in putting questions as a part of
validating the requirement completeness.

3. Focus Group

A focus group is actually gathering of people who are customers or users representatives for a product to gain its feedback. The
feedback can be collected about opportunities, needs, and problems to determine requirements or it can be collected to refine and
validate the already elicited requirements. This type of market research is different from brainstorming in which it is a managed
process with particular participants. There is a risk in following the crowd and some people think that focus groups are at best
unproductive. One danger that we usually end up with is with least common denominator features.

4. Interface Analysis

Interface for any software product will either be human or machine.Integration with external devices and systems is another
interface. The user centric design approaches are quite effective to ensure that you make usable software. Interface analysis-
analyzing the touch points with another external system- is vital to ensure that you do not overlook requirements that are not
instantly visible to the users.

5. Interview

Interviews of users and stakeholders are important in creating wonderful software. Without knowing the expectations and goal of the
stakeholders and users, you are highly unlikely to satiate them. You also have to understand the perspective of every interviewee, in
order to properly address and weigh their inputs. Like a good reporter, listening is a quality that assists an excellent analyst to gain
better value through an interview as compared to an average analyst.

6. Observation

The observation covers the study of users in its natural habitat. By watching users, a process flow, pain points, awkward steps and
opportunities can be determined by an analyst for improvement. Observation can either be passive or active. Passive observation is
provides better feedback to refine requirements on the same hand active observation works best for obtaining an understanding
over an existing business process. You can use any of these approaches to uncover the implicit requirements that are often
overlooked.
7. Prototyping

Prototyping can be very helpful at gathering feedback. Low fidelity prototypes make a good listening tool. Many a times, people are
not able to articulate a specific need in the abstract. They can swiftly review whether a design approach would satisfy the need.
Prototypes are very effectively done with fast sketches of storyboards and interfaces. Prototypes in some situations are also used as
official requirements.

8. Requirements Workshop

Popularly known as JAD or joint application design, these workshops can be efficient for gathering requirements. The
requirements workshops are more organized and structured than a brainstorming session where the involved parties get together to
document requirements. Creation of domain model artifacts like activity programs or static diagrams is one of the ways to capture
the collaboration. A workshop with two analysts is more effective than one in which on works as a facilitator and the other scribes
the work together.

1. Define Session: Define the purpose, scope, and objectives of the JAD session, selecting the JAD team, invite and obtain
commitment to attend sessions from the appropriate stakeholders, and schedule the session. It is important to obtain management
commitment to support the process and identify the appropriate stakeholders.

2. Research Product: Become more familiar with the product or service, gather preliminary information, obtaining any models.

3. Prepare: Prepare any visual aids, developing a realistic agenda, training the recorder, and preparing the meeting room.

4. Conduct Session: Follow agenda to gather and document the project needs and requirements. It is important to ensure all
participants are given equal treatment during the process.

5. Draft the Documents: Prepare the formal documents. The information captured in the JAD session is further refined through
analysis efforts, open questions or issues discovered through the sessions are resolved, and the final document is returned to
stakeholders for review and validation.

9. Reverse Engineering

Is this a last resort or starting point? When a migration project is not having enough documentation of the current system, reverse
engineering will determine what system does? It will not determine what the thing went wrong with the system and what a system
must do?

10. Survey

When gathering information from many people: to many to interview with time constraints and less budget: a questionnaire survey
can be used. The survey insists the users to choose from the given options agree / disagree or rate something. Do not think that you
can make a survey on your own but try to add meaningful insight in it. A well designed survey must give qualitative guidance for
characterizing the market. It should not be utilized for prioritizing of requirements or features.

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

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

The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives, SME’s, end-users,
business analysts, software architects and developers. It is essential that the roles, responsibilities, and rules for the JAD sessions
are well defined and communicated in advance to all participants.

Some typical roles found in a JAD session include:

 Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,
 Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,
 End users – 3 to 5, attend all sessions,
 Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,
 Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,
  Subject Matter Experts,
 Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.

 Requirements Traceability Matrix

The Requirements Traceability Matrix (RTM) is a tool to help ensure that the project’s scope,
requirements, and deliverables remain “as is” when compared to the baseline. Thus, it “traces” the
deliverables by establishing a thread for each requirement- from the project’s initiation to the final
implementation.

The diagram shows that the RTM can be used during all phases of a project to:

 Track all requirements and whether or not they are being met by the current process and design
 Assist in the creation of the RFP(Request for Proposal), Project Plan Tasks, Deliverable
Documents, and Test Scripts
 Help ensure that all system requirements have been met during the Verification process.

The Matrix should be created at the very beginning of a project because it forms the basis of the
project’s scope and incorporates the specific requirements and deliverables that will be produced.

The Matrix is considered to be bi-directional. 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. The RTM is also used to verify that all requirements are met and to
identify changes to the scope when they occur.

The use of the RTM enhances the scope management process. It also assists with the process control
and quality management. RTM can also be thought of as a process of documenting the connection and
relationships between the initial requirements of the project and the final product or service produced.

Requirements RFP (request for proposal) Design/Tasks deliverables

Verification

In each of the steps shown above, each requirement must be unique and clearly defined. The
requirement is then part of each critical component of the project. The references throughout the entire
process must be consistent and unique. In order to insure that this occurs, the Matrix traces each
requirement and creates a relationship between each of the processes.
  What is the difference between "requirements analysis" and
"gap analysis?"
In information technology, gap analysis is the study of the differences between two distinct information systems or applications. A gap is
often said to be "the space between where you are and where you want to be." Gap analysis may be defined simply as the difference
between what is needed and what is available. Gap analysis is a comparison process of two systems, and is undertaken as a means of
bridging the space between them. Gap analysis provides a foundation for measuring investment of time, money and human resources
required to achieve a particular outcome (for example, to turn the payroll process from paper based to paperless with the use of automation).

Gap analysis can be conducted on:

 a system – features that exist in the system now versus the features that need to exist in the
future
 a system interface – data that a system provides to an interface now versus data that will need to
be provided in the future
 a business process – activities and steps of a current business process versus the activities and
steps that will be supported by the business process in the future
 business goals and metrics – how well a business meets certain goals and metrics now versus
the targeted goals and metrics at some point in the future.

In business and economics, gap analysis is the assessment of business resources by comparing actual performance with its potential
performance. The goal of the gap analysis is to identify gaps in optimized performance. This provides a company with insight into potential
improvement. Such analysis can be performed at the strategic or operational level of an organization. Gap analysis is the study of what a
business is doing currently and where it wants to go in the future. Note that "GAP analysis" has also been used as a means for classification
of how well a product or solution meets a targeted need or set of requirements. In this case, "GAP" can be used as a ranking of "Good,"
"'Average" or "Poor."

 How Electronic Claims Submission Works:

The claim is electronically transmitted in data "packets" from the provider's computer
modem to the Medicare contractor's modem over a telephone line. Medicare contractors
perform a series of edits. The initial edits are to determine if the claims in a batch meet
the basic requirements of the HIPAA standard. If errors are detected at this level, the
entire batch of claims would be rejected for correction and resubmission. Claims that
pass these initial edits, commonly known as front-end edits or pre-edits, are then edited
against implementation guide requirements in those HIPAA claim standards. If errors are
detected at this level, only the individual claims that included those errors would be
rejected for correction and resubmission. Once the first two levels of edits are passed,
each claim is edited for compliance with Medicare coverage and payment policy
requirements. Edits at this level could result in rejection of individual claims for
correction, or denial of individual claims. In each case, the submitter of the batch or of
the individual claims is sent a response that indicates the error to be corrected or the
reason for the denial. After successful transmission, an acknowledgement report is
generated and is either transmitted back to the submitter of each claim, or placed in an
electronic mailbox for downloading by that submitter.

Electronic claims must meet the requirements in the following claim implementation
guides adopted as national standard under HIPAA:
• Providers billing an FI must comply with the ASC X12N 837 Institutional Guide
(004010X096A1).
• Providers billing a Carrier or DME MAC (for other than prescription drugs furnished by
retail pharmacies) must comply with the ASC X12N 837 Professional guide
(004010X098A1).
 • Providers billing a B DME MAC for prescription drugs furnished by a retail pharmacy
must comply with the National Council for Prescription Drug Programs (NCPDP)
Telecommunications Standard 5.1 and Batch Standard Version 1.1

 What is RUP?
The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning
tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality
software that meets the needs of its end-users, within a predictable schedule and budget.
[11, 13]

The Rational Unified Process is a process product, developed and maintained by Rational® Software. The
development team for the Rational Unified Process are working closely with customers, partners, Rational's product
groups as well as Rational's consultant organization, to ensure that the process is continuously updated and
improved upon to reflect recent experiences and evolving and proven best practices.

The Rational Unified Process enhances team productivity, by providing every team member with easy access to a
knowledge base with guidelines, templates and tool mentors for all critical development activities. By having all
team members accessing the same knowledge base, no matter if you work with requirements, design, test, project
management, or configuration management, we ensure that all team members share a common language, process
and view of how to develop software.

The Rational Unified Process activities create and maintain models. Rather than focusing on the production
of large amount of paper documents, the Unified Process emphasizes the development and maintenance of
models—semantically rich representations of the software system under development. [3, 7, 8]

The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language
(UML). The UML is an industry-standard language that allows us to clearly communicate requirements,
architectures and designs. The UML was originally created by Rational Software, and is now maintained by the
standards organization Object Management Group (OMG). [4]

The Rational Unified Process is supported by tools, which automate large parts of the process. They are used to
create and maintain the various artifacts—models in particular—of the software engineering process: visual
modeling, programming, testing, etc. They are invaluable in supporting all the bookkeeping associated with the
change management as well as the configuration management that accompanies each iteration.

The Rational Unified Process is a configurable process. No single process is suitable for all software development.
The Unified Process fits small development teams as well as large development organizations. The Unified Process
is founded on a simple and clear process architecture that provides commonality across a family of processes. Yet, it
can be varied to accommodate different situations. It contains a Development Kit, providing support for configuring
the process to suit the needs of a given organization.

The Rational Unified Process captures many of the best practices in modern software development in a form that is
suitable for a wide range of projects and organizations. Deploying these best practices using the Rational Unified
Process as your guide offers development teams a number of key advantages. In next section, we describe the six
fundamental best practices of the Rational Unified Process.
Rational Unified Process (RUP) methodology is fast becoming a popular software development to map business process
and practices. Development is phased into four stages. RUP methodology is highly flexible in its developmental path, as
any stage can be updated at any time. The first stage or inception centers on assessing needs, requirements, viability and
feasibility of the program or project. The second step or elaboration measures the architecture of the system's
appropriateness based on the project needs. The third stage is the construction phase, wherein the actual software
system is made, by developing components and features. This phase also includes the first release of the developed
software. The final stage is that of transition, and marks the end of the development cycle, if all objectives are met. This
phase deals with the training of the end users, beta testing and the final implementation of the system.

Understanding RUP: Six Best Industry Practices of RUP

RUP is designed to incorporate the six best software industry practices for software development, while stressing strongly
on object-oriented design. They are basically six ideas, when followed while designing any software project, will reduce
errors and faults and ensure optimal productivity. The practices are listed below:

Develop Iteratively
Loops are created to add extra information or to facilitate processes that are added later in the development stage.
Requirements
Gathering requirements is essential to the success of any project. The end users' needs have to be built into the system
completely.

Components
Large projects, when split into components, are easier to test and can be more methodically integrated into a larger
system. Components allow the use of code reuse through the use of object-oriented programming.

Design Model Visual

Many projects use Unified Modeling Language (UML) to perform object-oriented analysis and designs, which consist of
diagrams to visually represent all major components.

Quality and Defects Management

Testing for quality and defects is an integral part of software development. There are also a number of testing patterns that
should be developed, to gauge the readiness of the project for its release.

Synchronized Changes
All components created by separate teams, either from different locations or on different platforms need to be
synchronized and verified constantly.

Rational Unified Process (RUP) methodology's developmental approach has proved to be very resourceful and successful
for a number of reasons. The entire development process takes into account the changing requirements and integrates
them. Risks and defects can, not only be discovered but addressed, and reduced or eliminated in the middle of integration
process. As defects are detected along the process, errors and performance bottlenecks can be rectified by making use of
the several iterations (loops). RUP provides a prototype at the completion of each iteration, which make it easier for the
developers to synchronize and implement changes.

Rational Unified Process (RUP) methodology is designed to work as an online help that provides content, guidelines,
processes templates, and examples for all stages of program development. To be a certified solution designer, authorized
to use this methodology, one needs to get a minimum of 62% in IBM RUP certification examination.
This is the dynamic organization of the process along time.

The software lifecycle is broken into cycles, each cycle working on a new generation of the product. The
Rational Unified Process divides one development cycle in four consecutive phases [10]

Inception phase
Elaboration phase
Construction phase
Transition phase

Each phase is concluded with a well-defined milestone—a point in time at which certain critical decisions must be
made, and therefore key goals must have been achieved [2].

The phases and major milestones in the process.

Rational Unified Process: Best Practices for Software development Teams

Each phase has a specific purpose.

Inception Phase
During the inception phase, you establish the business case for the system and delimit the project scope. To
accomplish this you must identify all external entities with which the system will interact (actors) and
define the nature of this interaction at a high-level. This involves identifying all use cases and describing a
few significant ones. The business case includes success criteria, risk assessment, and estimate of the
resources needed, and a phase plan showing dates of major milestones. [10, 14]
The outcome of the inception phase is

A vision document: a general vision of the core project's requirements, key features, and main constraints.
A initial use-case model (10% -20%) complete).
An initial project glossary (may optionally be partially expressed as a domain model).
An initial business case, which includes business context, success criteria (revenue projection, market
recognition, and so on), and financial forecast.
An initial risk assessment.
A project plan, showing phases and iterations.
A business model, if necessary.
One or several prototypes.
Milestone : Lifecycle Objectives

At the end of the inception phase is the first major project milestone: the Lifecycle Objectives Milestone.
The evaluation criteria for the inception phase are:

Stakeholder concurrence on scope definition and cost/schedule estimates.

Requirements understanding as evidenced by the fidelity of the primary use cases.
Credibility of the cost/schedule estimates, priorities, risks, and development process.
Depth and breadth of any architectural prototype that was developed.
Actual expenditures versus planned expenditures.

The project may be cancelled or considerably re-thought if it fails to pass this milestone.

Elaboration Phase
The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation,
develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you
must have the ―mile wide and inch deep‖ view of the system. Architectural decisions have to be made with an
understanding of the whole system: its scope, major functionality and nonfunctional requirements such as
performance requirements.

It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase, the hard
―engineering‖ is considered complete and the project undergoes its most important day of reckoning: the decision on
whether or not to commit to the construction and transition phases. For most projects, this also corresponds to the
transition from a mobile, light and nimble, low-risk operation to a high-cost, high-risk operation with substantial
inertia. While the process must always accommodate changes, the elaboration phase activities ensure that the
architecture, requirements and plans are stable enough, and the risks are sufficiently mitigated, so you can
predictably determine the cost and schedule for the completion of the development. Conceptually, this level of
fidelity would correspond to the level necessary for an organization to commit to a fixed-price construction phase.

Rational Unified Process: Best Practices for Software development Teams

In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending
on the scope, size, risk, and novelty of the project. This effort should at least address the critical use cases identified
in the inception phase, which typically expose the major technical risks of the project. While an evolutionary
prototype of a production-quality component is always the goal, this does not exclude the development of one or
more exploratory, throwaway prototypes to mitigate specific risks such as design/requirements trade-offs,
component feasibility study, or demonstrations to investors, customers, and end-users.

The outcome of the elaboration phase is:

A use-case model (at least 80% complete) — all use cases and actors have been identified, and most use-
case descriptions have been developed.
Supplementary requirements capturing the non functional requirements and any requirements that are not
associated with a specific use case.
A Software Architecture Description.
An executable architectural prototype.
A revised risk list and a revised business case.
A development plan for the overall project, including the coarse-grained project plan, showing iterations‖
and evaluation criteria for each iteration.
An updated development case specifying the process to be used.
A preliminary user manual (optional).

Milestone : Lifecycle Architecture

At the end of the elaboration phase is the second important project milestone, the Lifecycle Architecture
Milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the
resolution of the major risks.

The main evaluation criteria for the elaboration phase involves the answers to these questions:

Is the vision of the product stable?

Is the architecture stable?
Does the executable demonstration show that the major risk elements have been addressed and credibly
resolved?
Is the plan for the construction phase sufficiently detailed and accurate? Is it backed up with a credible
basis of estimates?
Do all stakeholders agree that the current vision can be achieved if the current plan is executed to develop
the complete system, in the context of the current architecture?
Is the actual resource expenditure versus planned expenditure acceptable?

The project may be aborted or considerably re-thought if it fails to pass this milestone.

Rational Unified Process: Best Practices for Software development Teams

Construction Phase
During the construction phase, all remaining components and application features are developed and integrated into
the product, and all features are thoroughly tested. The construction phase is, in one sense, a manufacturing process
where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and
quality. In this sense, the management mindset undergoes a transition from the development of intellectual property
during inception and elaboration, to the development of deployable products during construction and transition.

Many projects are large enough that parallel construction increments can be spawned. These parallel activities can
significantly accelerate the availability of deployable releases; they can also increase the complexity of resource
management and workflow synchronization. A robust architecture and an understandable plan are highly correlated.
In other words, one of the critical qualities of the architecture is its ease of construction. This is one reason why the
balanced development of the architecture and the plan is stressed during the elaboration phase. The outcome of the
construction phase is a product ready to put in hands of its end-users. At minimum, it consists of:

The software product integrated on the adequate platforms.

The user manuals.
A description of the current release.

Milestone : Initial Operational Capability

At the end of the construction phase is the third major project milestone (Initial Operational Capability Milestone).
At this point, you decide if the software, the sites, and the users are ready to go operational, without exposing the
project to high risks. This release is often called a ―beta‖ release.

The evaluation criteria for the construction phase involve answering these questions:

Is this product release stable and mature enough to be deployed in the user community?
Are all stakeholders ready for the transition into the user community?
Are the actual resource expenditures versus planned expenditures still acceptable?

Transition may have to be postponed by one release if the project fails to reach this milestone.

Transition Phase
The purpose of the transition phase is to transition the software product to the user community. Once the product has
been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or
finish the features that were postponed.

The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.
This typically requires that some usable subset of the system has been completed to an acceptable level of quality
and that user documentation is available so that the transition to the user will provide positive results for all parties.

This includes:
•―beta testing‖ to validate the new system against user expectations
•parallel operation with a legacy system that it is replacing
•conversion of operational databases
•training of users and maintainers
roll-out the product to the marketing, distribution, and sales teams

Rational Unified Process: Best Practices for Software development Teams

The transition phase focuses on the activities required to place the software into the hands of the users. Typically,
this phase includes several iterations, including beta releases, general availability releases, as well as bug-fix and
enhancement releases. Considerable effort is expended in developing user-oriented documentation, training users,
supporting users in their initial product use, and reacting to user feedback. At this point in the lifecycle, however,
user feedback should be confined primarily to product tuning, configuring, installation, and usability issues.

The primary objectives of the transition phase include:

 Achieving user self-supportability
Achieving stakeholder concurrence that deployment baselines are complete and consistent with
The evaluation criteria of the vision
Achieving final product baseline as rapidly and cost effectively as practical

This phase can range from being very simple to extremely complex, depending on the type of product. For example,
a new release of an existing desktop product may be very simple, whereas replacing a nation's air-traffic control
system would be very complex.

Milestone: Product Release

At the end of the transition phase is the fourth important project milestone, the Product Release Milestone.
At this point, you decide if the objectives were met, and if you should start another development cycle. In
some cases, this milestone may coincide with the end of the inception phase for the next cycle.

The primary evaluation criteria for the transition phase involve the answers to these questions:

Is the user satisfied?

Are the actual resources expenditures versus planned expenditures still acceptable?

Iterations
Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete
development loop resulting in a release (internal or external) of an executable product, a subset of the final product
under development, which grows incrementally from iteration to iteration to become the final system [10].

Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has the following advantages:

Risks are mitigated earlier

Change is more manageable
Higher level of reuse
The project team can learn along the way
Better overall quality

AGILE METHOD:

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

 Iterative analysis and development

 Time-boxed iterations of a predefined length
 Delivery of the most critical features and functions first
 Delivery of a complete build with an initial set of limited features within a few months
(often 1-2 months)
 Small cross-functional teams usually of 6-9 team members.
 Daily team communication meetings
 Reduced levels of documentation

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

Agile methods are intended to overcome or circumvent many of the recurring challenges that are
encountered during software development projects. The iterative nature of these methods, along
with the desire to deliver smaller sets of defined features per iteration, help mitigate risk due to
evolving requirements, unclear project stakeholder direction, and unforeseen project complexities
that typically arise during the latter stages of analysis and development. Some of the most
salient advantages of Agile methods include:
  Availability of working software much sooner which allows for more immediate feedback
from application users.
 More immediate, and therefore larger, Return on Investment from software features that
are developed in short iterations and release to production immediately.
 Less project overhead due to smaller team sizes.
 Avoidance of large schedule overruns.
 Avoidance of large budget overruns.

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

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

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

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

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

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

 Product Owner – identifies the features that will be included in the next 30-sprint and set the
priority of each. This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesn‘t exist.
 Scrum Master – acts much like the project manager. While the Scrum Master does not micro-
manage the teams deliverables, this person ensures that the 30-day sprint is on track and
enforces the key rules that guide Scrum such as; no new features can be added to the sprint
once it is kicked off, and team members cannot be pulled off to work on other side project in the
middle of a sprint.
 Team Member – unlike traditional software development methods, in Scrum there is little
separation of duties between team members. Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.
  NON FUNCTIONAL REQUIREMENT: Non-functional requirements are characteristics of a system or solution which
describe non-behavioral characteristics or qualities of a system.

Whereas functional requirements describe the behaviors or functions of a system, the non- functional requirements generally
describe those attributes which the system must have but which do not represent something an actor can do with the system.

Non Functional Requirements have also been called the 'ilities' because they can be expressed like this: usability,
reliability, interoperability, scalability, extensibility, etc. Non-functional requirements are also commonly referred to as quality of service (QoS)
requirements or service-level requirements.

In many instances non-functional requirements describe (are attributes of) functional

requirements. For example: if a functional requirement of a system is "the system shall allow
the customer to view current month's statement" a non-functional requirement which
describes this need might be "the system shall generate the current month's statement in 30
milliseconds" or "the system shall store monthly statements for up to 12 months".

In other instances, non-functional requirements describe constraints on a system such as legal and
regulatory constraints.

A simple test to determine if a requirement is functional or non-functional is to ask yourself if you can
describe the requirement using the action of an actor or user of a system (think use cases and user
stories). If the requirement can be easily described with a use case or user story then it is probably a
functional requirement, otherwise it is most likely a non-functional requirement

Software Requirements Specification (SRS) - a requirements specification for a software system - is a complete
description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the

software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary)

requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance

engineering requirements, qualitystandards, or design constraints).

[edit]General Outline of an SRS

Cover Page

Revisions Page

Table of Contents

1 INTRODUCTION

1.1 Product Overview

1.2 Purpose

1.3 Scope

1.4 Reference

1.5 Definitions and Abbreviations

2 OVERALL DESCRIPTION

2.1 Product Perspective

 2.2 Product Functions

2.3 User Characteristics

2.4 General Constraints

2.5 Assumptions and Dependencies

3 SPECIFIC REQUIREMENTS

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communications Protocols

3.1.5 Memory Constraints

3.1.6 Operation

3.1.7 Product function

3.1.8 Assumption and Dependency

3.2 Software Product Features

3.3 Software System Attributes

3.3.1 Reliability

3.3.2 Availability

3.3.3 Security

3.3.4 Maintainability

3.3.5 Portability

3.3.6 Performance

3.4 Database Requirements

3.5 Other Requirements

 DIFFERENCE BETWEEN USE CASE SPECIFICATION AND USE CASE REALIZATION:

usA Use Case Specification is a textual description of the functionality provided by the system. It
captures actor-system interaction. That is, it specifies how a user interacts with a system and how the
system responds to the user actions. It is often phrased in the form of a dialog between the actor and the
system. The use case specification is represented in the use case diagram by an oval, and is what most
people think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case
specification, is physically implemented within a design model in terms of collaborating objects. It
organizes the design model artifacts related to the use case. It often comprises multiple design artifacts
such as a class diagram, object diagram, sequence diagram, etc. that describe how the physical design
will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are
typically captured by the use case model and system requirements, from the concerns of the system
designers. In doing so, the designers can choose to implement the use case specification without
affecting the use case specification.

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

 Market Penetration (Existing Products/Existing Markets)

 Market Development (Existing Products/New Market)
 Product Development (New Products/Existing Market)
 Diversification (New Products/New Market)

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

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

Product Development describes the growth strategy of creating new products for existing markets. An organization may have the benefit of understanding the intricacies of
their market but this can create a false sense of security. Not all new products carry the same risk. However, for certain types of product, especially those in fast moving
technology markets, projecting the outcome of a new product launch can be very difficult. To overcome some of this risk organizations should be prepared to continuously
adapt their products after launch to ensure marketplace success.

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

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

COMMUNICATION DIAGRAM A UML 2.0 Communication Diagram models the objects or parts of a system, the interactions (or
messages) between them, and the sequence in which these interactions occur. There are a lot of similarities between communication diagrams and
sequence diagrams in terms of the information they show, but because of how each diagram presents the information, one diagram may be better at
conveying or emphasizing specific information over the other.

Communication diagrams use a free-form arrangement of objects or parts of a system. This can be compared to how classes and objects are laid out
in UML class and object diagrams. Then the interactions between the objects or parts of the system are show and labeled to indicate the chronological
sequence in which they occur. The free-form arrangement of objects lends itself wekk to showing the sequenced interactions in a more compact
space, allowing the analyst to place objects that have the highest number of interactions with each other near one another. This is the advantage of
the communication diagram over the sequence diagram. While showing nearly all of the same information as a sequence diagram, the communication
diagram can, at a glance, place a strong emphasize on which objects are interacting with one another

While communication diagrams are formally intended to show system objects and the interactions between them, many analysts choose to create them
at a higher level of abstraction. Instead of showing the interactions between objects of a system, larger parts of a system may be represented such as
the interaction between web methods, web services, or entire systems.

By using the communication diagram in this way, it shows some similarities to a system context diagram. The primary differences between the two are
that a system context diagram places a focus on a single system in context along with which actors and systems outside of the scope of the system
interact with it. Additionally, a system context diagram does not show the sequence of interactions.

The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system
has with other external entities (systems, organizational groups, external data stores, etc.).

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a
specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be helpful.
A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information system. DFDs are one of the three essential
components of the structured-systems analysis and design method (SSADM). A DFD is process centric and depicts 4 main components.

 Processes (circle)
 External Entities (rectangle)
 Data Stores (two horizontal, parallel lines or sometimes and ellipse)
 Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If there is a need to show more detail within a particular
process, the process is decomposed into a number of smaller processes in a lower level DFD. In this way, the Content Diagram or Context-Level DFD
is labeled a ―Level-0 DFD‖ while the next level of decomposition is labeled a ―Level-1 DFD‖, the next is labeled a ―Level-2 DFD‖, and so on.

Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many analysis tools they have been leveraged for
other purposes. For example, they can also be leveraged to capture and communicate the interactions and flow of data between business process es.
So, they don‘t have to be restricted to systems analysis.

A sample Context Diagram is shown here.

A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or synchronization of processes such as which
processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow which can show these things.

Some of the benefits of a Context Diagram are:

 Shows the scope and boundaries of a system at a glance including the other systems that interface with it
 No technical knowledge is assumed or required to understand the diagram
 Easy to draw and amend due to its limited notation
 Easy to expand by adding different levels of DFDs
 Can benefit a wide audience including stakeholders, business analyst, data analysts, developers

Class Diagrams and Object Diagrams use almost identical notations. Both represent a static view of a system, however Object
Diagrams represent a snapshot in time, whereas Class Diagrams are not time dependent and are an abstract view of the types of objects that may
exist within a system, the relationships between them, and how and when one type of object can exist in relationship to anoth er. Since Object
Diagrams represent specific object instances that exist at a single point in time, they are sometimes called Instance Diagrams.

A few notable differences in the notation and rules used to represent Class and Object Diagrams are:

1. Class Diagrams represent each class via a rectangle and display up to 3 types of information; the class name (not underlined) , its
attributes, and its operations. The Object Diagram also uses a rectangle to represent an object instance, however the object name is
underlined and lists the name of the object followed by a colon and then the class name which describes its type (e.g. Joe: Student, where
Joe is the name of the object instance and Student is class). Additionally the Object Diagram will list an object's attributes, but it will also
list the value of that attribute at that point in time (e.g. SSN = 555-55-5555).
 2. Class Diagrams enforce multiplicity rules between associated classes. For example, a Class Diagram may display an association between
a Car and Passengers. The Class Diagram would show a single rectangle to represent the class car and a single rectangle to represent
the class passenger, but display multiplicities stating that each car may have 1..4 passengers. An Object Diagram being a snapshot in time
would show a rectangle for the Car and up to 4 separate rectangles, one for each passenger that exists at that movement in time.
3. Many of the constraints or association types that exist in a class diagram have no relevance in an object diagram. Multiplicities in a class
diagram may constrain the number of passengers in a car to 4, but this rule would be enforced within the code itself such that a 5th
passenger object could never be created. Therefore, multiplicities are not shown within an object diagram. Only the actual numbers of
objects that exist at that moment in time are shown. Similarly, other constraints such as "at least one passenger be of type driver" could
also be captured and displayed in a class diagram but would not be shown in an object diagram since these rules are enforced within the
actual code.

FACT MODEL:A Fact Model is a static model which structures business knowledge about core business concepts and business operations. It
is sometimes called a business entity model.

The fact model focuses on the core business concepts (called terms), and the logical connections between them (called facts). The facts are typically
verbs which describe how one term relates to another. For example, the two terms Person and Car may have a fact connecting them called Owns (a
Person owns a Car). The same two terms may also have a different fact connecting them called Drives (a Person drives a Car). The facts, which
connect the terms, should do so in a way which reflects the real world since the primary purpose of a fact model is to create a standard vocabulary by
which all stakeholders can communicate unambiguously. The business knowledge represented in a fact model should be at the most atomic level of
business knowledge, meaning it should not be able to be further deconstructed and it cannot be derived from other knowledge. By using the standard
vocabulary defined by the fact model, these basic building blocks can be used to develop and communicate more advanced forms of business
knowledge, such as business rules, in a clear and unambiguous way. Fact models are incredibly useful regardless of whether it is a system solution
that is being considered or a process solution. However, if the solution is a system, the fact model can be used as an input into the development of the
data model in later stages of the SDLC.

Screen mockups in REQUIREMENT GATHERING can support the requirements gathering process when introduced at the
right time, but if introduced too early they can become problematic. Here are a few key points that an analyst should remember.

1) Mockups are nice because they help the business representatives or clients visualize the functionality of the system. This can be a big advantage
to help analysts and stakeholders identify problems early on. However, if introduced too soon in the process the natural tendency is for the business
reps/clients to try and be screen designers. Instead of stating that the system shall support "x", they beginning saying that they need a dropdown to
capture "y" and a button to do "z". The client is not a UI designer, in fact few business analysts truly are, so this can lead to a screen design which
does not have an appropriate emphasis on usability. Similarly, specifying the controls needed on a screen detracts from the true requirements of the
system and often results in an inadequate level of discussion around why a system must support certain functionality.

2) When requirements are captured in screen mockups with no supporting requirements list, it becomes impossible to know whether an early screen
design decision was made because it supports a necessary requirement or if it was made for some other reason. How can the analyst and developers
know whether they can eliminate or alter the screen feature without losing an important requirement. Questions like, "Do we really need to have the
control on this screen, or can we capture the data at a later point in the process?" becomes unanswerable without going back to the original
stakeholders. And, on complex projects no one stakeholder may be able to answer the question.

3) Screen mockups alone cannot capture the flow through the system. Often analysts will accompany screen mockups with a written description of
what happens when certain buttons are clicked or when certain values are entered within a field or dropdown. These descriptions are helpful, but they
fall short of describing the end to end processes that the system must support. Further document such as process flows or use cases are required, but
often overlooked when too much emphasis is place on screen mockups during the requirements gathering process. While analysts and stakeholders
who are involved in the screen mockup process may have a basic understanding of the processes supported, developers and testers will not.

Ultimately, the introduction of UI mockups can be very helpful, but this should only occur after an exhaustive list of featur es and usage scenarios (what
business process flows need to be supported by the system) have been documented. Only then can the UI mockups be generated without introducing
major pitfalls.

HOW DO YOU HANDLE STRESS AND PRESSURE

Stress and pressure in small quantities can be a motivator and allow us to operate at peak performance. However, in too large of quantities it causes
anxiety, frustration, fatigue, and a host of other bad things that ultimately are counterproductive to achieving our goals an d objectives. So it‘s important
to manage stress and to find the right balance that works for you.

When you do feel stress coming on and rising to levels which are counterproductive, you must first identify that the stress is there. This can be harder
to do than it sounds, since when we are in a stressed state are brains aren‘t usually in control of the situation. So how can you train yourself to do this?
Stress and pressure typically arise from a number of common root causes. Understanding these causes ahead of time can help us be able to quickly
identify the stress and take appropriate action to manage the stress and bring it back down to reasonable levels. Here are some of the more common
causes of stress and how you might deal with them.

1. Too much work/overburdened.

Feeling overburdened creates stress, but for most people this can be overcome by doing two specific things.

First, create a prioritized to-do list where you track every task along with progress notes detailing what has been completed for each task and
what remains. The key is to track the information so that you don‘t have to remember and so that you don‘t worry over forgetting something
important. If the list is too long, don‘t stress, that‘s what the second step is for.

Second, if time required to complete the tasks is too great, talk to your manager immediately. Review the tasks with him or her and talk about
realistic expectations.

2. Lacking direction.

If you feel as if you don‘t understand the direction you need to take on a task, raise it to your manager. Ask him or her to explain their vision for
the outcome of the task. It could be that your manager doesn‘t have a clear vision of what the results should look like, but they probably know
what requirements or problem the outcome should solve. Explain to your manager that you would like to make an attempt at a solid start and
then schedule periodic reviews together to review the progress that you‘ve made. This gives them the opportunity to provide guidance and
redirect your efforts if they feel you are going in the wrong direction. Remember that your manager probably wouldn‘t have given you a task
with such an undefined vision if he or she didn‘t have a great deal of confidence in your abilities.

3. Lacking knowledge or experience.

Lacking the experience needed to perform a task certainly isn‘t a confidence builder, but it‘s important to remember that lack of knowledge or
experience isn‘t a weakness. Everybody is always learning, and no one person has all of the answers. If it‘s information you lack, the key to
reducing stress in this situation is taking a structured and well thought out approach to acquiring the information you need. If it‘s experience
with a specific skill set then it‘s not out of line to discuss training options with your manager.

Ultimately, remembering that nobody is expected to know or have experience with everything is key to keeping stress levels in line.

You can‘t completely avoid stressful situations, but one overarching approach that has always worked for me is approaching every challenging
situation more like a strategic, thoughtful game of chess. Identify the challenges in front of you, evaluate multiple options for proceeding in the most
efficient manner possible, and then act.

XML stands for EXtensible Markup Language. It is a self descriptive markup language. This means that the tags used to describe the content of the
XML file are not predefined, but instead the author defines his own tags and document structure. XML was designed to transport and store data, while
HTML was designed to display data. Unlike HTML which has standard tags that browsers can be programmed to display (i.e., <p>, <table>, <h1>,
<em>), an XML file requires software to be written in order to send, receive, display or manipulate the data in the XML file.

XML was created to simplify data sharing. It provides a method for storing, sending, and receiving data between systems that may contain data in
incompatible formats. Since XML is stored in a plain text format, an XML document is both software and hardware independent. This makes it much
easier to create data that different applications can share.

While HTML can display data on a webpage directly, XML allows for easy separation of data from presentation information so th at if the data needs to
be changed the HTML page is left unaffected. This can be achieved by using Javascript within the HTML file that references the data in a separate
XML file. Whenever the data needs to be changed, only the XML file needs to be updated.

An XML Schema is a document that is itself described using XML and which defines how an XML document must be structured in order to
conform to structured required by the a system or service which references the XML Schema. Specifically it defines:

 The elements that may appear

 The attributes that may appear for each element
 Which elements are child elements
 The order in which child elements must appear
 The number of child elements that may appear
 The data types for each element or attribute
 Default values and constant value for elements and attributes
 Minimum and maximum occurrences of an element

The term DTD (Document Type Definition) is often used when discussing the acceptable form of XML documents. However, XML Schemas are
successors to XML DTDs and have a number of benefits over DTDs. Some of these benefits are:
  Schemas are written in XML
 Schemas may be extended to future additions
 Schemas contain a richer set of rules to which data must conform
 Schemas make it easier to validate correctness of data
 Schemas support data types

XML schemas are able to enforce specific rules and data conformity such as:

 Data Types – data conforms to a specific data type (string, date, numeric, boolean, etc)
 Value restrictions – data conforms to the acceptable values (enumeration, fractionDigits, length, maxExclusive, maxInclusive, maxLength,
minExclusive, minInclusive, minLength, pattern, totalDigits, whitespace, etc)
 Element Indicators – elements conform to specific indicators (Order Indicators, Occurance Indicators, and Group Indicators) which apply
rules to how many elements must appear, in what order, or adhering to a specific structure (maxOccurs, minOccurs, all, choice, sequence,
etc).

HTML stands for HyperText Markup Language. It is the predominant markup language used on web today for the creation of web pages. The term
markup language is used to describe annotations that are added to any document that are distinguishable from the original text of the document. In
the case of HTML, these annotations are distinguishable by the use of angle brackets ―<‖ ―>‖ to create HTML tags.

 HTML tags are used to annotate a document, such as a webpage, in order to define its structure. HTML tags define various types of
webpage content in terms of headings, paragraphs, lists, tables, data, quotes, and more.
 HTML and Cascading Style Sheets (CSS) are almost always used hand in hand. While HTML defines the structure of a document, CSSs
define the presentation of a document. Using the HTML <style> tag, a predefined style from a CSS can be referenced to format the content
of the HTML document as desired. Using HTML and CSS together allows for the decoupling of the structure and presentation of a
document. One of the benefits of this is that the presentation of a document can be changed at any time without modifying the HTML
document itself.

Stakeholder Analysis: is the process of identifying project stakeholders, how their needs may impact the project, and the contributions th at
the stakeholders will make to the requirements elicitation process. Projects typically have a large number of stakeholders from many different areas of
the organization. Based on each stakeholder‘s position and responsibilities, the level of their involvement and their importance to the project will vary.

Stakeholder Analysis is sometimes called a Stakeholder Involvement Plan or a Stakeholder Elicitation Plan. Regardless of the name used,
Stakeholder Analysis goes beyond identifying project stakeholders. After all project stakeholders have been identified, it should be determined how
involved each stakeholder should be in the requirements elicitation process. The business analyst should document a number of factors for each
stakeholder including:

 Importance – How important is the stakeholder in the requirements elicitation process? Are they required in order to document all of the
critical project requirements, or are they nice to have adding clarity to processes that may further refine req uirements? Answering these
questions will help ensure that the project will meet its goals and objectives, and that critical requirements aren‘t missed.
 Influence – How influential is the stakeholder to the project? Even if they aren‘t needed for the requirements elicitation, are they in a
position of authority? Does the stakeholder have the ability to dramatically alter the course of the project if they hear about and are
unhappy with the current direction of the project? Answers to these questions will ensure that the most influential stakeholders are updated
on a regular basis with the project status.
 Level of Involvement – What level of involvement and how much time will be expected of each stakeholder? Do they need to be fully
allocated to the project? Do they need to be in every requirements elicitation session? Can they be involved in only key requirements
elicitation sessions? Do they only need to attend a final requirements review session? These questions help ensure that the necessary
people are made available to the project for the right amount of time.
 Frequency of Involvement – How often will each stakeholder need to be involved; daily, every other day, once per week? This information
will help the business analyst plan and schedule the necessary meetings accordingly.
 Method of Involvement – What method will be used to involve each stakeholder? Will they receive email-based status reports? Will they be
involved in requirements gathering sessions? Will they be asked to sit in one-on-one requirements interviews? This information will aid in
development of a communication plan and the appropriate selection of communication techniques.

Active Listening is a method used to listen and respond to others in a structured and deliberate way. It requires a listener to understand and
actively evaluate what he or she heard. Actively listening can be used to achieve a number of goals.

 One of the more common goals of actively listening is to ensure that the listener accurately understands what the speaker has said by
replying back to the speaker and paraphrasing what they believe they have just heard (―So, if I understood you correctly…‖). The speaker
can either acknowledge that the listener‘s understanding was accurate or can quickly identify any misunderstanding that the listener may
have. Actively listening helps the listener avoid incorrect conclusions due to unintentional assumptions that the listener may have made.
It‘s important to note that a listener that employs active listening is not necessarily agreeing with the speaker.
 Another goal of actively listening is for the listener to extract additional information from the speaker. While listening to the speaker, the
listener may notice something in the speaker‘s tone or body language. By responding to the speaker with phrases such as ―you seem to
 feel …‖ the speaker has the opportunity to confirm or correct the listener‘s understanding. This is a non-confrontational approach to asking
follow-up questions which clarify the speaker‘s intent.
 Active Listening can be a powerful tool for business analysts during requirements elicitation. Requirements elicitation often occurs during a
period of a project where not everyone has the same background knowledge and understanding of the project. Because of this, there are
typically many assumptions that are being made by each person as they build a framework in their mind of the project and its problems and
challenges. Actively listening can verify correct assumptions and dismiss false ones resulting in a clearer and more accurate set of
requirements.

Six Sigma is a process improvement methodology. It is structured into 5 phases which can be iterated to continually improve key processes and
deliver greater efficiencies and success within an organization. These 5 phases are Define, Measure, Analyze, Improve, and Control expressed as the
acronym DMAIC (pronounced dee-may-ic). Six Sigma, being a process improvement methodology, views the entire world in terms of processes—
processes that achieve goals, processes that act on data, etc.

 Define – The define phase is used to define the problem that has been identified. The term ―voice of the customer‖ is often used withi n Six
Sigma. The voice of the customer is used to understand where the problem resides. This could be an external client or an internal client
such as business workers that are involved in a specific business process that is not performing as well as it could. While defining the
problem, clear goals of the project are outlined. The goals should define what will make the process better or what is ―critical to quality‖.
 Measure – The measure phase takes the defined problem and measures key aspects of the current state process. Collecting of this data is
necessary to ensure that the results of the control phase can be compared against those of the measure phase and objectively show that
the process has been improved to the degree expected. You may have heard the phrase ―you can‘t improve what you can‘t measure‖.
 Analyze – In the analyze phase the data captured in the measure phase is analyzed to understand cause-and-effect relationships and
perform root cause analysis. The equation y = f(x) is very popular in Six Sigma. It emphasizes that some problem domain ―y‖ is a function
of ―x‖ where ―x‖ are the inputs or factors that drive the outcome ―y‖. Analyzing the data from the measure stage is intended to uncover all of
the inputs that have a significant impact on the outcome of the process.
 Improve – The improve phase is where the current process is redesigned based upon the analysis that was completed in the analyze
phase. By ensuring that the inputs to a process are available at the right time and in the right condition, the outcome of the process should
improve. And really the process can be just about anything. Consider requirements as an input to the development of an IT system. If it‘s
found that the quality of the input (requirements) is subpar, the team can focus on a better process for gather requirements which will result
in an improved project outcome. Once the new process is designed it should be tested or prototyped before implementing. The results of
the tested process can be measured to ensure that the desired improvements are being realized.
 Control – The control phase is an important step in the DMAIC process. It emphasizes the need to continually monitor the improved
process to ensure that any deviations from the targeted outcome can be corrected. Without the control phase the benefits of many process
improvement initiatives would begin to decrease over time. The control phase can also be used to uncover new areas for improvement and
the DMAIC process begins all over again.

The four fundamental methods of REQUIREMENT verification: are Inspection, Demonstration, Test, and Analysis. The four
methods are somewhat hierarchical in nature, as each verifies requirements of a product or system with increasing rigor. I will provide a description of each with two brief
examples of how each could be used to verify the requirements for a car and a software application.

Inspection is the nondestructive examination of a product or system using one or more of the five senses (visual, auditory, olfactory, tactile, taste). It may include simple
physical manipulation and measurements.

 Car: visually examine the car to ensure that it has power windows, power adjustable seats, air conditioning, a navigation system, a tow package, etc.
 Software Application: visually examine the software for screens that were requested, check for the fields needed for data entry, verify that the necessary buttons
exist for initiating required functionality, etc.

Demonstration is the manipulation of the product or system as it is intended to be used to verify that the results are as planned or expected.

 Car: use the automatic switches to verify that the windows and seats work as intended, start the vehicle and ensure that the air conditioning produces cold air, take
the car for a test drive to sense the acceleration and cornering as it was described based on the requirements.
 Software Application: enter all required fields on a screen and select the button to return a specific report. Ensure that the report is returned with the type of data
needed.

Test is the verification of a product or system using a controlled and predefined series of inputs, data, or stimuli to ensure that the product or system will produce a very specific
and predefined output as specified by the requirements.

 Car: accelerate the car from a complete stop to 60 mph, and verify that it can be done in 5.2 seconds. Accelerate through a turn under controlled conditions,
producing .8G of force, without the car loosing traction.
 Software Application: enter the type and model of car, automatic windows, power steering, and all other options as stated in the predefined test plan, select the
price now button and receive back a price quote of precisely $43,690.

Analysis is the verification of a product or system using models, calculations and testing equipment. Analysis allows someone to make predictive statements about the typical
performance of a product or system based on the confirmed test results of a sample set or by combining the outcome of individual tests to conclude something new about the
product or system. It is often used to predict the breaking point or failure of a product or system by using nondestructive tests to extrapolate the failure point.

 Car: complete a series of tests which rev the engine at a specific rpm for a set length of time, while monitoring engine vibration and temperature, to verify that the
expected results are achieve. Use this information to model the failure point of the engine, i.e. max rpm sustained over a specific period of time.
 Software Application: complete a series of tests in which a specified number of users input the characteristics of the car they are attempting to price and initiate the
pricing functionality at the same time. Measure the response of the system to ensure that the pricing function returns its results within the time specified. Analyze
 the relationship between increasing number of system users and the time it takes for pricing to be returned. Record the results to capture system degradation.
Use this information to predict at what point the system no longer meets the maximum allowable time to return pricing as defined by the requirements.

Various types of testing, the business analyst: is usually most involved with Functional Testing, Regression Testing, and
Usability testing.

Since the business analysts are closely involved in documenting the business requirements in the BRD and may also be writing the functional
specifications, many organizations will involve the business analysts in the role of Functional Testing. This may be to create functional test cases, or
sometimes even to carry out the test cases themselves. Regression testing is used to refer to retesting a portion of the system after a modification
has been made to ensure that it still performs per spec, and typically refers to Functional Testing.

Similarly, given that many business analysts also end up designing screens and portions of the user interface, it often makes sense to engage them in
usability testing. Usability testing may be done up front on a lightweight prototype of the application to help the business analyst understand the best
way to design the features across screens and how to design the individual screen UIs. It can also be completed after the final application is delivered
to the client. This way, the results of the usability testing can be used to improve on UI design as future modifications are made.

Unit Testing (Component Testing) – refers to the testing of individual software components as they are completed. This type of testing is typically
completed by the development team.

Integration Testing – refers to the testing of components as they are combined or integrated together. This ensures that each component that has
been tested on its own operates correctly when it is used in conjunction with the other components that it is designed to interact with. This is
particularly important for client/server and service oriented architecture systems.

User Acceptance Testing – refers to testing that is performed by the user or end customer of the system as a condition of approval. User Acceptance
Testing is where the user/client ensures that the final application or product meets the agreed upon requirements set forth b y the Business
Requirements Document. This is also why traceability of requirements throughout the entire Analysis, Development, and Testing lifecycle is so
important.

Functional Testing (Black Box Testing) – refers to testing the features and behavior of an application to ensure that it coincides with the functional
software specifications provided. This type of testing is also referred to as black box testing because it completely ignores the internal workings of the
program and focuses only on the outputs as a result of the specified inputs and execution steps.

Usability Testing – refers to testing the ease in which users can learn the application, as well as the users‘ efficiency and productivity while using the
application.

Performance Testing (Load Testing, Stress Testing) – refers to testing performed to evaluate whether the system meets the documented
performance requirements. Performance Testing ensures that the system will support a specified number of users while still maintaining specific
service level agreements (SLAs) for page load times and service response times. This type of Performance Testing is also called Load Testing.
Additionally, during Performance Testing, often it will be required to test the systems limits and determine the maximum numb er of concurrent users
that can be supported before the system fails. This is referred to as Stress Testing.

Regression Testing – refers to testing a portion of the application that has previously been tested following a modification to ensure that the or iginal
functionality still works and behaves per the specification. While Regression Testing really just means to go back and retest, it typically refers to
Functional Testing

Difference between a use case alternative flow and an exception flow? A use case specification describes
the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system.
It represents the most common way that the use case plays out successfully and contains the most popular sequence of user -system interactions.
Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference?

First, it’s worth saying that there are a number of opinions in this area since the Unified Modeling Language has no standard for Use Case
Specifications. Some authors mention only alternative flows and use them for both optional flows and error flows. However, of those authors that do
differentiate between alternative flows and exception flows some agreement in definition has emerged.

An alternate flow describes a scenario other than the basic flow that results in a user completing his or her goal. It is often considered to be an
optional flow and implies that the user has chosen to take an alternative path through the system. An exception flow is an unintended path through
the system usually as a result of missing information or system availability problems. Exception flows represent an undesirable path to the user.
However, even though the exception flow has occurred the system will ideally react in a way that recovers the flow and provide some useful
information to the user.

The primary benefit of differentiating between alternative flows and exception flows is the focus that exception flows bring to error conditions. By
capturing all of the ways that the system can fail or produce an error, the business analyst can be sure to create a design which mitigates the impact
of the error.
Problems you are faced with when gathering requirements
While this is a broad question, it is often used by interviewers to find out whether the candidate has actually performed requirements elicitation in the past and has experienced its challenges.
Once challenges are mentioned many interviewers proceed to ask what the candidate has done or would do in order to overcome those problems.

So, here are some of the problems faced by business analysts during the requirements elicitation/gathering activities:

Contradicting/Conflicting Requirements - These are requirements received from different stakeholders or from same stakeholder at different times and which cannot all be met at the
same time because their are in conflict. What the BA can do: get all stakeholders in the same room (if possible), document and publish stakeholder requirements or meeting notes while they
are fresh.

Communication Problems - This is a broad category of requirements issues and includes: miscommunication, language barriers, wrong assumptions, unclearly defined vocabulary or domain
model, variance in vertical domain knowledge, using only one-way communication channels (over the wall requirements), notation differences (lack of standards), etc. What the BA can
do: continuously improve communication skills, document info gathered and publish for review/feedback, verify assumptions, create a glossary of terms, use multiple subject matter experts,
etc.

Undocumented Processes - This is the reality in most organizations. The business runs with "word of mouth" or poorly documented processes and procedures. In these situations, to the
high-level executive it may look like everybody is doing the work the same way when the actual details/steps of the process vary from end-user to end-user. The business analyst is often
forced to reverse engineer the business processes every time a new projects is started. What the BA can do: Document existing business processes and the differences among the various
users. Present the documented processes to the stakeholders/high-level executives. If possible and within the scope of duty, create and maintain an up-to-date library of existing business
processes/operating procedures.

Lack of access to end-users - On many projects the stakeholders and IT management "think" they understand the requirements and what happens in the business and do not enable or
allow the business analyst to have direct access to the end-users. What the BA can do: Present your case to the project sponsor as to why it is key to observe the users at work and find out
how each activity is actually performed and the types of problems faced by the user in their day-to-day work.

Instability of UI Preferences - Stakeholders and end-users who are new to the requirement elicitation process or who are faced with new or unprecedented concepts or processes tend to
have a hard time identifying (and feeling good about) their preferences and, therefore, they tend to keep changing their minds. What the BA can do: use prototypes and other visual tools
such as diagrams to gather, document, and verify requirements.

Abundance of Choice - When stakeholders or end-users are presented with too many choices they generally have a harder time deciding the option to select. When they do make a decision
they are less satisfied than if those who have to pick from a much smaller list of options. What the BA can do: provide stakeholders and decision makers with more than option (when
possible), however do not give them more than 3 options to choose from.

Stakeholder Design - This is the case when the stakeholders or end-user have the urge to design the system (how the system should work) rather than providing the requirements (what the
system should do). The problem with this pattern is that the BA is no longer able to distinguish between requirements and design decisions. What the BA can do: ask the stakeholders/users
what the system should do and when you get the answer keep asking "Why?". Eventually you should be able to get to the actual problems faced by the user and you'll be able to understand
the "real" requirements.

Bad Requirements - Requirements are considered "bad" if they are: ambiguous, incomplete, not verifiable, etc. When stakeholders provide and analysts document bad requirements, they
result in systems which are not completed or not used. What the BA can do: develop a checklist of characteristics and tests which you can check for each requirement to ensure all the
requirements send for sign-off are all good to go.

These are just some of the problems faced by requirements analysts during the elicitation process. There certainly are many more.
OOAD

1. What do you mean by analysis and design?

Analysis:
Basically, it is the process of determining what needs to be done before how it should be
done. In order to accomplish this, the developer refers the existing systems and documents.
So, simply it is an art of discovery.
Design:
It is the process of adopting/choosing the one among the many, which best accomplishes
the users needs. So, simply, it is compromising mechanism.

2. What are the steps involved in designing?

Before getting into the design the designer should go through the SRS prepared by the
System Analyst.
The main tasks of design are Architectural Design and Detailed Design.
In Architectural Design we find what are the main modules in the problem domain.
In Detailed Design we find what should be done within each module.

3. What are the main underlying concepts of object orientation?

Objects, messages, class, inheritance and polymorphism are the main concepts of object
orientation.

4. What do u meant by "SBI" of an object?

SBI stands for State, Behavior and Identity. Since every object has the above three.
? State:
It is just a value to the attribute of an object at a particular time.
? Behaviour:
It describes the actions and their reactions of that object.
? Identity:
An object has an identity that characterizes its own existence. The identity makes it possible
to distinguish any object in an unambiguous way, and independently from its state.

5. Differentiate persistent & non-persistent objects?

Persistent refers to an object's ability to transcend time or space. A persistent object
stores/saves its state in a permanent storage system with out losing the information
represented by the object.
A non-persistent object is said to be transient or ephemeral. By default objects are
considered as non-persistent.

6. What do you meant by active and passive objects?

Active objects are one which instigate an interaction which owns a thread and they are
responsible for handling control to other objects. In simple words it can be referred as
client.
Passive objects are one, which passively waits for the message to be processed. It waits for
another object that requires its services. In simple words it can be referred as server.

Diagram:
client server
(Active) (Passive)

7. What is meant by software development method?

Software development method describes how to model and build software systems in a
reliable and reproducible way. To put it simple, methods that are used to represent ones'
thinking using graphical notations.

8. What are models and meta models?

Model:
It is a complete description of something (i.e. system).
Meta model:
It describes the model elements, syntax and semantics of the notation that allows their
manipulation.

9. What do you meant by static and dynamic modeling?

Static modeling is used to specify structure of the objects that exist in the problem domain.
These are expressed using class, object and USECASE diagrams.
But Dynamic modeling refers representing the object interactions during runtime. It is
represented by sequence, activity, collaboration and statechart diagrams.

10. How to represent the interaction between the modeling elements?

Model element is just a notation to represent (Graphically) the entities that exist in the
problem domain. e.g. for modeling element is class notation, object notation etc.
Relationships are used to represent the interaction between the modeling elements.
The following are the Relationships.

? Association: Its' just a semantic connection two classes.

? Aggregation: Its' the relationship between two classes which are related in the fashion
that master and slave. The master takes full rights than the slave. Since the slave works
under the master. It is represented as line with diamond in the master area.
ex:
car contains wheels, etc.

car

? Containment: This relationship is applied when the part contained with in the whole part,
dies when the whole part dies.
It is represented as darked diamond at the whole part.
example:
class A{
//some code
};

class B
{
A aa; // an object of class A;
// some code for class B;
};
In the above example we see that an object of class A is instantiated with in the class B. so
the object class A dies when the object class B dies.

? Generalization: This relationship used when we want represents a class, which captures
the common states of objects of different classes. It is represented as arrow line pointed at
the class, which has captured the common states.

? Dependency: It is the relationship between dependent and independent classes. Any

change in the independent class will affect the states of the dependent class.
DIAGRAM:
class A class B

11. Why generalization is very strong?

Even though Generalization satisfies Structural, Interface, Behaviour properties. It is
mathematically very strong, as it is Antisymmetric and Transitive.
Antisymmetric: employee is a person, but not all persons are employees. Mathematically all
As’ are B, but all Bs’ not A.
Transitive: A=>B, B=>c then A=>c.
A. Salesman.
B. Employee.
C. Person.
Note: All the other relationships satisfy all the properties like Structural properties, Interface
properties, Behaviour properties.

12. Differentiate Aggregation and containment?

Aggregation is the relationship between the whole and a part. We can add/subtract some
properties in the part (slave) side. It won't affect the whole part.
Best example is Car, which contains the wheels and some extra parts. Even though the
parts are not there we can call it as car.
But, in the case of containment the whole part is affected when the part within that got
affected. The human body is an apt example for this relationship. When the whole body dies
the parts (heart etc) are died.

13. Can link and Association applied interchangeably?

No, You cannot apply the link and Association interchangeably. Since link is used represent
the relationship between the two objects.
But Association is used represent the relationship between the two classes.
link :: student:Abhilash course:MCA
Association:: student course

14. what is meant by "method-wars"?

Before 1994 there were different methodologies like Rumbaugh, Booch, Jacobson, Meyer etc
who followed their own notations to model the systems. The developers were in a dilemma
to choose the method which best accomplishes their needs. This particular span was called
as "method-wars"

15. Whether unified method and unified modeling language are same or different?
Unified method is convergence of the Rumbaugh and Booch.
Unified modeling lang. is the fusion of Rumbaugh, Booch and Jacobson as well as Betrand
Meyer (whose contribution is "sequence diagram"). Its' the superset of all the
methodologies.

16. Who were the three famous amigos and what was their contribution to the object
community?
The Three amigos namely,
? James Rumbaugh (OMT): A veteran in analysis who came up with an idea about the
objects and their Relationships (in particular Associations).
? Grady Booch: A veteran in design who came up with an idea about partitioning of systems
into subsystems.

? Ivar Jacobson (Objectory): The father of USECASES, who described about the user and
system interaction.

17. Differentiate the class representation of Booch, Rumbaugh and UML?

If you look at the class representaiton of Rumbaugh and UML, It is some what similar and
both are very easy to draw.
Representation: OMT UML.

Booch: In this method classes are represented as "Clouds" which are not very easy to draw
as for as the developer's view is concern.

18. What is an USECASE? Why it is needed?

A Use Case is a description of a set of sequence of actions that a system performs that
yields an observable result of value to a particular action.
In SSAD process <=> In OOAD USECASE. It is represented elliptically.

19. Who is an Actor?

An Actor is someone or something that must interact with the system.In addition to that an
Actor initiates the process(that is USECASE).
It is represented as a stickman.

20. What is guard condition?

Guard condition is one, which acts as a firewall. The access from a particular object can be
made only when the particular condition is met.
For Example,
customer check customer number ATM.
Here the object on the customer accesses the ATM facility only when the guard condition is
met.

21. Differentiate the following notations?

I: :obj1 :obj2

II: :obj1 :obj2

In the above representation I, obj1 sends message to obj2. But in the case of II the data is
transferred from obj1 to obj2.

22. USECASE is an implementation independent notation. How will the designer give the
implementation details of a particular USECASE to the programmer?
This can be accomplished by specifying the relationship called "refinement” which talks
about the two different abstraction of the same thing.
Or example,

calculate pay calculate

class1 class2 class3

23. Suppose a class acts an Actor in the problem domain, how to represent it in the static
model?
In this scenario you can use “stereotype”. Since stereotype is just a string that gives extra
semantic to the particular entity/model element. It is given with in the << >>.

class A
<< Actor>>
attributes

methods.

24. Why does the function arguments are called as "signatures"?

The arguments distinguish functions with the same name (functional polymorphism). The
name alone does not necessarily identify a unique function. However, the name and its
arguments (signatures) will uniquely identify a function.
In real life we see suppose, in class there are two guys with same name, but they can be
easily identified by their signatures. The same concept is applied here.
ex:
class person
{
public:
char getsex();
void setsex(char);
void setsex(int);
};
In the above example we see that there is a function setsex() with same name but with
different signature.

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

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

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

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

How are ICD-10-CM and ICD-10-PCS different from ICD-9-CM?

When the original ICD code sets were adopted by the World Health Organization, they did
not include procedure codes for facility providers. The ICD-9 code sets included 13,000
diagnosis codes and no procedure codes. At that time, the US healthcare industry added
11,000 facility procedure codes and designated the combined codes set as ICD-9-CM.The
new code sets are now in two segments. ICD-10-CM increases diagnosis codes from 13,000
to 68,000 codes. The accompanying ICD-10-PCS code set includes facility procedure codes
and increases the total content from 11,000 to 87,000 codes. The mandated
implementation date for both code sets is October 1,2013. Together, these two expanded
code sets will enable far more effective data for the vital classification of morbidity and
mortality data while enabling accurate claims management and reimbursement by the
insurance industry. They will advance effective disease management programs and track
outcomes of care to ensure quality. To effectively undertake the massive projects, these
two interdependent conversions require, and to complete implementation within the time
frames mandated by the Federal Government, there are key strategic steps we recommend
be followed. To follow are 10 Critical Success Factors we have identified to ensure
understanding of the changes themselves, the areas within the payer that will be affected
and the steps to be completed to meet these very complex, resource dependent and
unfunded mandates.

What is EDI X12

Just to put it simply - EDI X12 (Electronic Data Interchange) is data format based on ASC X12 standards. It is used to exchange specific data between
two or more trading partners. Term ‗trading partner‘ may represent organization, group of organizations or some other entity. In most cases it is just
organization or company. You will see term ‗trading partner‘ used heavily in computer programs that perform actual data communication, and programs
that tie data communication with specific translation
EDI X12 standards and releases
EDI X12 is governed by standards released by ASC X12 (The Accredited Standards Committee). Each release contains set of message types like
invoice, purchase order, healthcare claim, etc. Each message type has specific number assigned to it instead of name. For example: an invoice is 810,
purchase order is 850 and healthcare claim is 837. Every new release contains new version number. Version number examples: 4010, 4020, 4030,
5010, 5030, etc. Major releases start with new first number. For example: 4010 is one of the major releases, so is 5010. However 4020 is minor
release. Minor releases
Contain minor changes or improvements over major releases. Understanding the difference between major and minor releases is important. Let say
you have working translation for some messages
for release 4010, and if you want to upgrade to 4020 you will notice only a few changes between the two, and if you want to upgrade to release 5010
you might need to make a lot of modifications to current translation. At the time of this writing 4010 is most widely used release. It is the first release
that is Y2K compliant. Most of HIPAA based systems know and use 4010.
Conclusion: to translate or validate EDI X12 data you need to know transaction number (message numeric name) and release version number. Both of
those numbers are inside the file.
Trading Partner Requirements
EDI X12 standard covers number of requirements for data structure, separators, control numbers, etc. However many big trading partners impose they
own even more strict rules and requirements. It can be everything: specific data format requirements for some elements, requirement to contain
specific segments (segments that are not mandatory in EDI X12 standard being made mandatory),
etc. In HIPAA those specific trading partner requirements are usually listed in separate document called Companion Guide. It is essential to follow
these documents to the letter when implementing EDI systems.
Those business requirements make EDI system development highly specific to each implementation. This is one of the reasons wh y EDI software is
expensive to build, run and maintain.
EDI X12 Dissected
Standard EDI X12 format data is text file separated by segment, element and sub-element delimiters (separators). You can open EDI X12 files using
any text editor even standard Windows notepad.exe utility. Carriage return and line feed are not required characters by EDI X12 standard. If they are
not present in the file after each segment separator you will see continues line of data in the typical text
editor. It is very hard to read data formatted that way. In our examples we will use files with carriage return and line feed following segment separator,
so each segment will be on a separate line.
There is typical EDI X12 837 Healthcare Claim (HIPAA) release version 4010.
Each segment is displayed on the separate line. In this example each segment ends with ~ (tilde). That is so called segment separator or segment
delimiter. Each segment starts with 2-3 letter code that identifies it. Example: ISA, GS, ST, BHT are all segment identifiers. Each segment contains
elements separated by element separator. In our example it is * (star).While in our case separators are printable characters like tilde and star, they do
not have to be. They can be other characters like <, >(greater than or less than signs) | pipe sign, also non-printable characters. Most translators detect
separators for incoming EDI X12 files. Some segments form EDI X12 envelope. They are common to all EDI X12 files and message types. Those
segments are ISA, GS, ST, SE, GE, IEA. This set contains important information about trading partners (like Sender Id, Receiver Id, etc.). It also
contains interchange, transaction group and transaction control numbers, counts, transmission dates and times, and more .

Compliance Testing Specifications

The Workgroup for Electronic Data Interchange (WEDI) and the Strategic National
Implementation Process (SNIP) have recommended seven types HIPAA compliance testing,
these are:
1. Integrity Testing – This is testing the basic syntax and integrity of the EDI transmission to
include: valid segments, segment order, element attributes, numeric values in numeric
data elements, X12 syntax and compliance with X12 rules.
2. Requirement Testing – This is testing for HIPAA Implementation Guide specific syntax
such as repeat counts, qualifiers, codes, elements and segments. Also testing for
required or intra-segment situational data elements and non-medical code sets whose
values are noted in the guide via a code list or table.
3. Balance Testing – This is testing the transaction for balanced totals, financial balancing of
claims or remittance advice and balancing of summary fields.
4. Situational Testing – This is testing of inter-segment situations and validation of
situational fields based on rules in the Implementation Guide.
5. External Code Set Testing – This is testing of external code sets and tables specified
within the Implementation Guide. This testing not only validates the code value but also
verifies that the usage is appropriate for the particular transaction.
6. Product Type or Line of Service Testing – This is testing that the segments and elements
required for certain health care services are present and formatted correctly. This type of
testing only applies to a trading partner candidate that conducts the specific line of
business or product type.
7. Implementation Guide-Specific Trading Partners Testing – This is testing of HIPAA
requirements that pertain to specific trading partners such as Medicare, Medicaid and
Indian Health. Compliance testing with these payer specific requirements is not required
from all trading partners. If the trading partner intends to exchange transactions with one
of these special payers, this type of testing is required
E

HIPAA Message Types

EDI Health Care Claim Transaction set (837) is used to submit health care claim billing information, encounter information, or both,
except for retail pharmacy claims (see EDI Retail Pharmacy Claim Transaction). It can be sent from providers of health care s ervices to payers, either
directly or via intermediary billers and claims clearinghouses. It can also be used to transmit health care claims and billing payment information
between payers with different payment responsibilities where coordination of benefits is required or between payers and regul atory agencies to monitor
the rendering, billing, and/or payment of health care services within a specific health care/insurance industry segment.

For example, a state mental health agency may mandate all healthcare claims, Providers and health plans who trade professional (medical) health
care claims electronically must use the 837 Health Care Claim: Professional standard to send in claims. As there are many different business
applications for the Health Care claim, there can be slight derivations to cover off claims involving unique claims such as for Institutions, Professionals,
Chiropractors, and Dentists etc.

EDI X12 837

Data contents of the Health Care Claim Transaction Set (837) for use within the context of an Electronic Data
Interchange (EDI) environment.

This transaction set can be used to submit health care claim billing information, encounter information, or both, from
providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses. It can also
be used to transmit health care claims and billing payment information between payers with different payment
responsibilities where coordination of benefits is required or between payers and regulatory agencies to monitor the
render-ing, billing, and/or payment of health care services within a specific health care/insurance industry segment. For
purposes of this standard, providers of health care products or services may include entities such as physicians, hospitals
and other medical facilities or suppliers, dentists, and pharmacies, and entities providing medical infor-mation to meet
regulatory requirements. The payer refers to a third party entity that pays claims or administers the insurance product or
benefit or both. For example, a payer may be an insurance company, health maintenance organization (HMO),
preferred provider organization (PPO), government agency (Medicare, Medicaid, Civilian Health and Medical Program
of the Uni-formed Services (CHAMPUS), etc.) or an entity such as a third party adminis-trator (TPA) or third party
organization (TPO) that may be contracted by one of those groups. A regulatory agency is an entity responsible, by law
or rule, for administering and monitoring a statutory benefits program or a specific health care/insurance industry
segment.

EDI Retail Pharmacy Claim Transaction (NCPDP Telecommunications Standard version 5.1) is used to submit retail
pharmacy claims to payers by health care professionals who dispense medications, either directly or via intermediary billers and claims
clearinghouses. It can also be used to transmit claims for retail pharmacy services and billing payment information between payers with different
payment responsibilities where coordination of benefits is required or between payers and regulatory agencies to monitor the rendering, billing, and/or
payment of retail pharmacy services within the pharmacy health care/insurance industry segment.
EDI Health Care Claim Payment/Advice Transaction Set (835) can be used to make a payment, send an
Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a
health care provider either directly or via a financial institution.

Explanation of Benefits (EOB)

Explanation of Benefits forms (EOBs) are sent by payors to both enrollees and providers. These EOBs provide necessary information about claim
payment information and patient responsibility amounts. Sample EOBs are provided initially when implementing the payor business.
Compliance is checked periodically thereafter. Patient responsibility amounts are needed for accurate patient balance billing. EOB remarks
must clearly identify the network name associated with the discount. This is an important aspect of the “Explanation of Benefits” review
process.

Both enrollee and provider Explanation of Benefits (EOBs) shall include the following elements:

 Name and address of payor *

 Toll-free number of payor *
 Subscriber's name/address *
 Subscriber's identification number *
 Patient's name *
 Provider name *
 Provider tax identification number (TIN) *
 Provider's participation status (PPO, HMO)
 Claim date of service *
 Type of service
 Total billed charges *, allowed amount * and discount amount
 Excluded charges
 Explanation of excluded charges (code and associated key)
 Amount applied to deductible
 Co-payment/co-insurance amount
 Total patient responsibility amount *
 Total payment made and to whom *
 Benefit level information (annual deductible/amount applied, annual out-of-pocket/amount applied, lifetime maximums/amount
applied)
 ERISA disclosure (if applicable)
 Discount Remark – “Discount For HealthLink Participation” *
 National Provider Identifier for the Rendering Provider (by 5/23/07

remittance advice
A document that describes payments that are being made. The person or company that is making the payment will
sometimes include a remittance advice, which is like a receipt of the payment. A remittance advice is usually used by
companies processing either a purchase or a filed claim

Read more:http://www.investorwords.com/6904/remittance_advice.html#ixzz19XYVRONY

EDI Benefit Enrollment and Maintenance Set (834) can be used by employers, unions, government agencies, associations or
insurance agencies to enroll members to a payer. The payer is a healthcare organization that pays claims, administers insurance or benefit or product.
Examples of payers include an insurance company, health care professional (HMO), preferred provider organization (PPO), government agency
(Medicaid, Medicare etc.) or any organization that may be contracted by one of these former groups.

EDI Payroll Deducted and other group Premium Payment for Insurance Products (820) is a transaction set which can
be used to make a premium payment for insurance products. It can be used to order a financial institution to make a payment to a payee.

EDI Health Care Eligibility/Benefit Inquiry (270) is used to inquire about the health care benefits and eligibility associated with a
subscriber or dependent.

EDI Health Care Eligibility/Benefit Response (271) is used to respond to a request inquire about the health care benefits and
eligibility associated with a subscriber or dependent.

EDI Health Care Claim Status Request (276) This transaction set can be used by a provider, recipient of health care products or
services or their authorized agent to request the status of a health care claim.

EDI Health Care Claim Status Notification (277) This transaction set can be used by a health care payer or authorized agent to notify a
provider, recipient or authorized agent regarding the status of a health care claim or encounter, or to request additional information from the provider
regarding a health care claim or encounter. This transaction set is not intended to replace the Health Care Claim Payment/Advice Transaction Set
(835) and therefore, is not used for account payment posting. The notification is at a summary or service line detail level. The notification may be
solicited or unsolicited.

EDI Health Care Service Review Information (278) This transaction set can be used to transmit health care service information, such
as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the
outcome of a health care services review.

EDI Functional Acknowledgement Transaction Set (997) this transaction set can be used to define the control structures for a set
of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. Although it is not specifically named in
the HIPAA Legislation or Final Rule, it is necessary for X12 transaction set processing . The encoded documents are the transaction sets, which are
grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the s emantic meaning of the
information encoded in the transaction sets.

FFF

 Analyzing the code changes for migration purpose. Also analyzed the effort and impact of merging the new code from
changes done in production environment to the migrated environment. Updated AO11 documents with changes for
migration of the interface from one environment to another. Stored Procedure Modification to add new logger procedure
and to change database references. Also to merge the new modification done in production environment. Creation of Run
Book as per the new standards for migration environment. Batch Creation for testing and updated test case documents.
Interacting with Client to accommodate any new change in requirements as well to discuss project status.
Skill Set Utilized: Facets 4.31, Sybase, XML, Run Book Creation, Manual Testing, Windows XP, PVCS

With enhancements to Facets 4.51, customer service representatives at health plans can
use a new keyword feature to more easily find specific benefit information when
fielding telephonic inquiries. The Facets application can now be supported in other
languages, and the new version includes a feature for customization of screen views.
New functionality in Facets 4.51 enables payers to make changes and corrections to
debit cards used for medical services by members enrolled in consumer-driven
health plans. Additionally, flexible spending account claims that cannot be auto-
adjudicated can now be handled using the Workflow feature to increase
administrative efficiency. As part of an ongoing effort to support TriZetto customers
who administer Medicare health plans, Facets Billing now supports expanded split-
billing processing so that multiple entities (i.e. member, employer groups and
CMS) can each be billed for specific percentages of an insurance premium.
Experience in Functional areas of Facets including:

 Benefits & Contracts

  Subscriber / Member
 Prior Authorization
 Provider
 Plan / Products
 Medical Management
 Accounting, Billing & Commissions
 Capitation
 Business Rules and Workflow
 Claims
 Customer Service
 ITS Subsystem / Claims

Transactions and Code Sets Regulations

Standards for Electronic Transactions-New Versions, New Standard and New Code Set - Final Rules

On January 16, 2009, HHS published two final rules to adopt updated HIPAA standards; these rules are available at the Federal Register.

In one rule, HHS is adopting X12 Version 5010 and NCPDP Version D.0 for HIPAA transactions. In this rule, HHS also adopts a new standard
for Medicaid subrogation for pharmacy claims, known as NCPDP Version 3.0. For Version 5010 and Version D.0, the compliance date for all
covered entities is January 1, 2012. This gives the industry enough time to test the standards internally, to ensure that systems have been
appropriately updated, and then to test between trading partners before the compliance date. The compliance date for the Medicaid subrogation
standard is also January 1, 2012, except for small health plans, which will have until January 1, 2013 to come into compliance.

In a separate final rule, HHS modifies the standard medical data code sets for coding diagnoses and inpatient hospital procedures by concurrently
adopting the International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM) for diagnosis coding and the
International Classification of Diseases, 10th Revision, Procedural Coding System (ICD-10-PCS) for inpatient hospital procedure coding. These
new codes replace the current International Classification , 9th Revision, Clinical Modification, Volumes 1 and 2 and the International
Classification , 9th Revision, Clinical Modification, Volume 3 for diagnosis and procedure codes respectively. The implementation date for ICD-
10-CM and ICD-10-PCS is October 1, 2013 for all covered entities.

Version 5010 accommodates the ICD-10 code sets, and has an earlier compliance date than ICD-10 in order to ensure adequate testing time for
the industry. These two rules apply to all HIPAA covered entities, including health plans, health care clearinghouses, and certain health care
providers.

What Is ICD-10?
ICD-10 stands for International Statistical Classification of Diseases and Related Health Problems - 10th Revision and is a coding of diseases and signs,
symptoms, abnormal findings, complaints, social circumstances and external causes of injury or diseases, as classified by the World Health Organization.
ICD-10 is used by many countries primarily for reporting epidemiological data.

WHO has a detailed history of ICD-10 for those interested (PDF document).

What Is The ICD-10 Clinical Modification/Procedure

Coding System (ICD-10-CM/PCS)?
ICD-10-CM/PCS is a diagnosis classification system developed by the Centers for Medicare and Medicaid Services (CMS) and the National Center for
Health Statistics (NCHS), for coding and reporting in the healthcare environment of the United States. It consists of two parts:

1. ICD-10-CM was developed by the Centers for Disease Control and Prevention for use in all United States of America health care treatment
settings.
2. ICD-10-PCS was developed by CMS for use in the U.S. for inpatient hospital settings ONLY.

While it was developed from ICD-10, ICD-10-CM/PCS is a modification that focuses on diagnoses and reason for visits in all American health care settings.
ICD-10-CM/PCS is a morbidity classification, while ICD-10 is more of a mortalityclassification system.
What Are Some Differences Between ICD-9-CM and ICD-
10-CM?
First of all, there is a difference in the number of codes available. As of February 2010, ICD-9-CM had a total of 14,315 distinct
diagnostic codes, while ICD-10-CM had 69,101 codes. This is obviously a huge expansion and it allows for a lot more specificity
and detail, reflecting the advances in clinical medicine over the last several decades.

Second, there are structural differences between the two coding systems. Please see the table below for more details.

ICD-9-CM ICD-10-CM

3-5 digits 3-7 digits

1st digit is numeric (chapters 1-17)

or alpha (E or V) (supplemental 1st digit is alpha (all letters except U)
chapters)

2nd, 3rd, 4th and 5th digits are 2nd and 3rd digits are numeric; 4th, 5th, 6th and
numeric 7th digits can be alpha or numeric

Decimal after first 3 characters Decimal after first 3 characters

Some Examples

R50.9 - Fever, unspecified

780.60 - Fever, unspecified
O9A.311 - Physical abuse complicating pregnancy,
995.81 - Adult physical abuse
first trimester
810.00 - Closed fracture of clavicle,
S42.001A - Fracture of unspecified part of right
unspecified part
clavicle, initial encounter for closed fracture

What Are Some Differences Between ICD-9-PCS and ICD-10-CM-PCS

As of February 2010, ICD-9-PCS had a total of 3,838 procedure codes, while ICD-10-PCS had 71,957 codes. In addition, just ICD-
10-PCS codes are structurally different from ICD-9-PCS codes in some significant ways. Please see the table below fro details.

ICD-9-PCS ICD-10-PCS

3-4 digits 7 digits

 digits can be either alpha or numeric. Letters O and
all digits are numeric I are not used to avoid confusion with the numbers 0
and 1.

2nd, 3rd, 4th and 5th digits 2nd and 3rd digits are numeric; 4th, 5th, 6th and
are numeric 7th digits can be alpha or numeric

Decimal after first 3

Decimal after first 3 characters
characters

Some Examples

43.5 - Partial gastrectomy

with anastomosis to 0FB03ZX - Excision of Liver, Percutaneous Approach,
esophagus Diagnostic
44.42 - Suture of duodenal 0DQ10ZZ - Repair upper esophagus, open approach
ulcer site.

Important Note: ICD-10-CM/PCS will not affect physicians, outpatient facilities, and hospital outpatient departments' usage of
Current Procedural Terminology (CPT) codes on Medicare FFS claims. CPT use will continue.

How To Translate ICD-9 Codes Into ICD-10 Codes?

Given the significant expansion and details in ICD-10 codes, it is not always possible to find a unique ICD-10 code to match exactly an ICD-9 code. In
about 20% of cases, there are multiple ICD-10 codes for one ICD-9 code, or multiple ICD-9 codes for one ICD-10 code, or there is simply no exact match
between the two systems.

HCPCS (Healthcare Common Procedure Coding System) is comprised of Current Procedural

Terminology (CPT-4), a numeric coding system maintained by the American Medical Association (AMA). The CPT-4 is a uniform
coding system consisting of descriptive terms and identifying codes that are used primarily to identify medical services and
procedures furnished by physicians and other health care professionals. These health care professionals use the CPT-4 to identify
services and procedures for which they bill public or private health insurance programs. Level I of the HCPCS, the CPT-4 codes,
does not include codes needed to separately report medical items or services that are regularly billed by suppliers other than
physicians

Level II of the HCPCS is a standardized coding system that is used primarily to identify products, supplies, and services not included
in the CPT-4 codes, such as ambulance services and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS)
when used outside a physician's office. Because Medicare and other insurers cover a variety of services, supplies, and equipment
that are not identified by CPT-4 codes, the level II HCPCS codes were established for submitting claims for these items

HIPAA Gateway® helps your organization comply with HIPAA standards for EDI transactions. The solution is highly scalable,
and receives, routes, stores and sends transactions consistent with ANSI X12 standards. It supports HIPAA-regulated EDI transactions for
TriZetto solutions such as Facets
 The HIPAA Electronic Transactions and Code Sets Rules require the capture and processing of designated EDI transaction data as well as the
return of data (from a request, or input transaction) with the response or payment transaction. TriZetto HIPAA Gateway handles data
elements that exceed the scope of what your current system uses or requires and stores them in a repository.

Benefits

 Accepts inbound transactions from multiple sources.

 Supports integrated EDI batch processing and real-time EDI.

 Compliance-checks all inbound/outbound HIPAA-regulated EDI transactions.

 Captures all HIPAA-related EDI data in the repository.

 Supports customer-specific processing with user exit/extensions.

 Offers multiple repository data-base options (Sybase, MS SQL Server 2000 and Oracle).

HMO vs PPO
Most Americans who have health insurance through their employer (and many who are self-insured) are enrolled in some type of a managed care plan - either an HMO or PPO. The most
common types of managed care plans are health maintenance organizations (HMOs) and preferred provider organizations (PPOs). Less common are point-of-service (POS) plans that combine
the features of an HMO and a PPO.

Managed Care Networks

All managed care plans contract with doctors, hospitals, clinics, and other health care providers such as pharmacies, labs, x-ray centers, and medical equipment vendors. This group of contracted
health care providers is known as the health plan's "network."

In some types of managed care plans, you may be required to receive all your health care services from a network provider. In other managed care plans, you may be able to receive care from
providers who are not part of the network, but you will pay a larger share of the cost to receive those services.

Health Maintenance Organizations (HMOs)

If you are enrolled in a health maintenance organization (HMO) you will need to receive most or all of your health care from a network provider. HMOs require that you select a primary care
physician (PCP) who is responsible for managing and coordinating all of your health care.

Your PCP will serve as your personal doctor to provide all of your basic healthcare services. PCPs include internal medicine physicians, family physicians, and in some HMOs, gynecologists
who provide basic healthcare for women. For your children, you can select a pediatrician or a family physician to be their PCP.

If you need care from a physician specialist in the network or a diagnostic service such as a lab test or x-ray, your primary care physician (PCP) will have to provide you with a referral. If you do
not have a referral or you choose to go to a doctor outside of your HMO's network, you will most likely have to pay all or most of the cost for that care.

Preferred Provider Organizations (PPOs)

A preferred provider organization (PPO) is a health plan that has contracts with a network of "preferred" providers from which you can choose. You do not need to select a PCP and you do not
need referrals to see other providers in the network.

If you receive your care from a doctor in the preferred network you will only be responsible for your annual deductable (a feature of some PPOs) and a copayment for your visit. If you get health
services from a doctor or hospital that is not in the preferred network (known as going "out-of-network") you will pay a higher amount. And, you will need to pay the doctor directly and file a
claim with the PPO to get reimbursed.

How HMOs and PPOs Differ

The following outline compares some of the features of HMOs and PPOs. These are general rules and you should speak with your human resources office at work or directly with your health
plan. If you are in the process of deciding between enrolling in a HMO or PPO, you often can compare the plans by going online to the plans' websites to learn about the available benefits and
costs.

Which health care providers must I choose?

 HMO: You must choose doctors, hospitals, and other providers in the HMO network.
 PPO: You can choose doctors, hospitals, and other providers from the PPO network or from out-of-network. If you choose an out-of-network provider, you most likely will pay more.

Do I need to have a primary care physician (PCP)?

 HMO: Yes, your HMO will not provide coverage if you do not have a PCP.
 PPO: No, you can receive care from any doctor you choose. But remember, you will pay more if the doctors you choose are not "preferred" providers.

How do I see a specialist?

 HMO: You will need a referral from your PCP to see a specialist (such as a cardiologist or surgeon) except in emergency situations. Your PCP also must refer you to a specialist who is in the
HMO network.
 PPO: You do not need a referral to see a specialist. However, some specialists will only see patients who are referred to them by a primary care doctor. And, some PPOs require that you get a
prior approval for certain expensive services, such as MRIs.

Do I have to file any insurance claims?

 HMO: All of the providers in the HMO network are required to file a claim to get paid. You do not have to file a claim, and your provider may not charge you directly or send you a bill.
 PPO: If you get your healthcare from a network provider you usually do not need to file a claim. However, if you go out of network for services you may have to pay the provider in full and
then file a claim with the PPO to get reimbursed. The money you receive from the PPO will most likely be only part of the bill. You are responsible for any part of the doctor's fee that the
PPO does not pay.

How do I pay for services in the network?

 HMO: The only charges you should incur for in-network services are copayments for doctor's visits and other services such as procedures and prescriptions.
 PPO: In most PPO networks you will only be responsible for the copayment. Some PPOs do have an annual deductable for any services, in network or out of network.

How do I pay for services out of the network?

 HMO: Except for certain types of care that may not be available from a network provider, you are not covered for any out-of-network services.
 PPO: If you choose to go outside the PPO network for your care, you will need to pay the provider and then get reimbursed by the PPO. Most likely, you will have to pay an annual
deductable and coinsurance. For example, if the out-of-network doctor charged you $200 for a visit, you are responsible for the full amount if you have not met your deductable. If you have
met the deductable, the PPO may pay 60%, or $120 and you will pay 40%, or $80.

CO PAY
A type of insurance policy where the insured pays a specified amount of out-of-pocket expenses for health-care services such as doctor visits and prescriptions
drugs at the time the service is rendered, with the insurer paying the remaining costs. However, unlike coinsurance, where the insured is required to pay
a certain percentage of the covered costs, co-pay plans require the insured to pay a specified dollar amount.

Co Insurance
A co-sharing agreement between the insured and the insurer under a health insurance policywhich provides that the insured will cover a set percentage of the
covered costs after the deductible has been paid. Similar to co-pay insurance plans except co-pays require the insured to pay a set dollar amount at the time the
service is rendered.

Health Plans
HMO: An HMO (Health Maintenance Organization) is an organization that provides or arranges for coverage of certain health
care services required by members of the organization. Typical HMO coverages include access to a primary care physician,
emergency care, and specialists/hospitalization when needed.

Many HMOs operate with preventative medicine in mind by addressing your health care needs while you are healthy so as to
 prevent disease or illness.

Critics of HMOs address concerns as to a lack of selection of primary care physicians, "assembly line" medicine, and denial of
adequate referrals in the event of disease or illness. Critics often claim that a HMO may deny certain claims and may make
health care decisions based upon a pure profitability standpoint as opposed to decisions driven by providing the best level of
care for its patients.

HMOs are valuable in providing good care for many members – many HMOs organizations take very good care of their
members‘ health care needs while managing costs.

IPO: IPO (Independent Provider Organization) operates by having an HMO contract directly with independent physicians to
provides services to HMO members.

PPO: PPO (Preferred Provider Organization) is a form of managed care under which health care providers contract to provide
medical services at pre-negotiated rates. Members who subscribe to a PPO are required to use the health care providers who
participate in the PPO network - utilization of a health care provider outside the PPO network may result in the member paying
more out-of-pocket for services which could have been provided within the network.

HMOs often use a PRO (Peer Review Organization) to assure that members receive appropriate services that meet
professional standards of care. Complaints regarding levels of service are often referred to the PRO for resolution.

POS: POS (Point of Service) plans allow the individual policy holder or certificate holder to visit out-of-network, non-participating
doctors for a fee. If the services of a non-participating health care provider are utilized, the individual often obtains restrictions of
benefits or incurs more out-of-pocket costs.

Why Do You Need Health Insurance?

Today, health care costs are high, and getting higher. Who will pay your bills if you have a serious accident or a major illness? You
buy health insurance for the same reason you buy other kinds of insurance, to protect yourself financially. With health insurance, you
protect yourself and your family in case you need medical care that could be very expensive. You can't predict what your medical
bills will be. In a good year, your costs may be low. But if you become ill, your bills could be very high. If you have insurance, many of
your costs are covered by a third-party payer, not by you. A third-party payer can be an insurance company or, in some cases, it can
be your employer.
Evolution
Health care in America is changing rapidly. Twenty-five years ago, most people in the United States had indemnity insurance
coverage. A person with indemnity insurance could go to any doctor, hospital, or other provider (which would bill for each service
given), and the insurance and the patient would each pay part of the bill.
But today, more than half of all Americans who have health insurance are enrolled in some kind of managed care plan, an organized
way of both providing services and paying for them. Different types of managed care plans work differently and include preferred
provider organizations (PPOs), health maintenance organizations (HMOs), and point-of-service (POS) plans.
You've probably heard these terms before. But what do they mean, and what are the differences between them? And what do these
differences mean to you?
Types of Insurance
Fee-for-Service (Indemnity Plan)
This is the traditional kind of health care policy. Insurance companies pay fees for the services provided to the insured people
covered by the policy. This type of health insurance offers the most choices of doctors and hospitals. You can choose any doctor you
wish and change doctors any time. You can go to any hospital in any part of the country.
With fee-for-service, the insurer only pays for part of your doctor and hospital bills. This is what you pay:
 A monthly fee, called a premium.
 A certain amount of money each year, known as the deductible, before the insurance payments begin. In a typical plan,
the deductible might be $250 for each person in your family, with a family deductible of $500 when at least two people in
the family have reached the individual deductible. The deductible requirement applies each year of the policy. Also, not
all health expenses you have count toward your deductible. Only those covered by the policy do. You need to check the
insurance policy to find out which ones are covered.
 After you have paid your deductible amount for the year, you share the bill with the insurance company. For example,
you might pay 20 percent while the insurer pays 80 percent. Your portion is called coinsurance.
To receive payment for fee-for-service claims, you may have to fill out forms and send them to your insurer. Sometimes your doctor's
office will do this for you. You also need to keep receipts for drugs and other medical costs. You are responsible for keeping track of
your medical expenses.
There are limits as to how much an insurance company will pay for your claim if both you and your spouse file for it under two
different group insurance plans. A coordination of benefit clause usually limits benefits under two plans to no more than 100 percent
of the claim.
Most fee-for-service plans have a "cap," the most you will have to pay for medical bills in any one year. You reach the cap when your
out-of-pocket expenses (for your deductible and your coinsurance) total a certain amount. It may be as low as $1,000 or as high as
$5,000. Then the insurance company pays the full amount in excess of the cap for the items your policy says it will cover. The cap
does not include what you pay for your monthly premium.
Some services are limited or not covered at all. You need to check on preventive health care coverage such as immunizations and
well-child care.
There are two kinds of fee-for-service coverage: basic and major medical. Basic protection pays toward the costs of a hospital room
and care while you are in the hospital. It covers some hospital services and supplies, such as x-rays and prescribed medicine. Basic
coverage also pays toward the cost of surgery, whether it is performed in or out of the hospital, and for some doctor visits. Major
medical insurance takes over where your basic coverage leaves off. It covers the cost of long, high-cost illnesses or injuries.
Some policies combine basic and major medical coverage into one plan. This is sometimes called a "comprehensive plan." Check
your policy to make sure you have both kinds of protection.
What Is a "Customary" Fee?
Most insurance plans will pay only what they call a reasonable and customary fee for a particular service. If your doctor charges
$1,000 for a hernia repair while most doctors in your area charge only $600, you will be billed for the $400 difference. This is in
addition to the deductible and coinsurance you would be expected to pay. To avoid this additional cost, ask your doctor to accept
your insurance company's payment as full payment. Or shop around to find a doctor who will. Otherwise you will have to pay the rest
yourself.
Questions to Ask About Fee-for-Service (Indemnity) Insurance
 How much is the monthly premium? What will your total cost be each year? There are individual rates and family rates.
  What does the policy cover? Does it cover prescription drugs, out-of-hospital care, or home care? Are there limits on the
amount or the number of days the company will pay for these services? The best plans cover a broad range of services.
 Are you currently being treated for a medical condition that may not be covered under your new plan? Are there
limitations or a waiting period involved in the coverage?
 What is the deductible? Often, you can lower your monthly health insurance premium by buying a policy with a higher
yearly deductible amount.
 What is the coinsurance rate? What percent of your bills for allowable services will you have to pay?
 What is the maximum you would pay out of pocket per year? How much would it cost you directly before the insurance
company would pay everything else?
 Is there a lifetime maximum cap the insurer will pay? The cap is an amount after which the insurance company won't pay
anymore. This is important to know if you or someone in your family has an illness that requires expensive treatments.
Health Maintenance Organizations (HMOs)
Health maintenance organizations are prepaid health plans. As an HMO member, you pay a monthly premium. In exchange, the
HMO provides comprehensive care for you and your family, including doctors' visits, hospital stays, emergency care, surgery, lab
tests, x-rays, and therapy.
The HMO arranges for this care either directly in its own group practice and/or through doctors and other health care professionals
under contract. Usually, your choices of doctors and hospitals are limited to those that have agreements with the HMO to provide
care. However, exceptions are made in emergencies or when medically necessary.
There may be a small co-payment for each office visit, such as $5 for a doctor's visit or $25 for hospital emergency room treatment.
Your total medical costs will likely be lower and more predictable in an HMO than with fee-for-service insurance.
Because HMOs receive a fixed fee for your covered medical care, it is in their interest to make sure you get basic health care for
problems before they become serious. HMOs typically provide preventive care, such as office visits, immunizations, well-baby
checkups, mammograms, and physicals. The range of services covered vary in HMOs, so it is important to compare available plans.
Some services, such as outpatient mental health care, often are provided only on a limited basis.
Many people like HMOs because they do not require claim forms for office visits or hospital stays. Instead, members present a card,
like a credit card, at the doctor's office or hospital. However, in an HMO you may have to wait longer for an appointment than you
would with a fee-for-service plan.
In some HMOs, doctors are salaried and they all have offices in an HMO building at one or more locations in your community as part
of a prepaid group practice. In others, independent groups of doctors contract with the HMO to take care of patients. These are
called individual practice associations (IPAs) and they are made up of private physicians in private offices who agree to care for HMO
members. You select a doctor from a list of participating physicians that make up the IPA network. If you are thinking of switching into
an IPA-type of HMO, ask your doctor if he or she participates in the plan.
In almost all HMOs, you either are assigned or you choose one doctor to serve as your primary care doctor. This doctor monitors
your health and provides most of your medical care, referring you to specialists and other health care professionals as needed. You
usually cannot see a specialist without a referral from your primary care doctor who is expected to manage the care you receive. This
is one way that HMOs can limit your choice.
Before choosing an HMO, it is a good idea to talk to people you know who are enrolled in it. Ask them how they like the services and
care given.
Questions to Ask About an HMO
 Are there many doctors to choose from? Do you select from a list of contract physicians or from the available staff of a
group practice? Which doctors are accepting new patients? How hard is it to change doctors if you decide you want
someone else? How are referrals to specialists handled?
 Is it easy to get appointments? How far in advance must routine visits be scheduled? What arrangements does the HMO
have for handling emergency care?
 Does the HMO offer the services I want? What preventive services are provided? Are there limits on medical tests,
surgery, mental health care, home care, or other support offered? What if you need a special service not provided by the
HMO?
 What is the service area of the HMO? Where are the facilities located in your community that serve HMO members?
How convenient to your home and workplace are the doctors, hospitals, and emergency care centers that make up the
HMO network? What happens if you or a family member are out of town and need medical treatment?
 What will the HMO plan cost? What is the yearly total for monthly fees? In addition, are there copayments for office
visits, emergency care, prescribed drugs, or other services? How much?
Preferred Provider Organizations (PPOs)
The preferred provider organization is a combination of traditional fee-for-service and an HMO. Like an HMO, there are a limited
number of doctors and hospitals to choose from. When you use those providers (sometimes called "preferred" providers, other times
called "network" providers), most of your medical bills are covered.
When you go to doctors in the PPO, you present a card and do not have to fill out forms. Usually there is a small copayment for each
visit. For some services, you may have to pay a deductible and coinsurance.
As with an HMO, a PPO requires that you choose a primary care doctor to monitor your health care. Most PPOs cover preventive
care. This usually includes visits to the doctor, well-baby care, immunizations, and mammograms.
In a PPO, you can use doctors who are not part of the plan and still receive some coverage. At these times, you will pay a larger
portion of the bill yourself (and also fill out the claims forms). Some people like this option because even if their doctor is not a part of
the network, it means they don't have to change doctors to join a PPO.
Questions to Ask About a PPO
 Are there many doctors to choose from? Who are the doctors in the PPO network? Where are they located? Which ones
are accepting new patients? How are referrals to specialists handled?
 What hospitals are available through the PPO? Where is the nearest hospital in the PPO network? What arrangements
does the PPO have for handling emergency care?
 What services are covered? What preventive services are offered? Are there limits on medical tests, out-of-hospital
care, mental health care, prescription drugs, or other services that are important to you?
 What will the PPO plan cost? How much is the premium? Is there a per-visit cost for seeing PPO doctors or other types
of co-payments for services? What is the difference in cost between using doctors in the PPO network and those outside
it? What is the deductible and coinsurance rate for care outside of the PPO? Is there a limit to the maximum you would
pay out of pocket?
Point-of-Service (POS) Plan
Many HMOs offer plan members the option to self direct care, as one would under an indemnity or PPO plan, rather than get
referrals from primary care physicians. An HMO with this opt-out provision is known as a point-of-service (POS) plan. How the plan
functions (i.e., like an HMO or like an indemnity plan) depends on whether individual plan members use their primary care physician
or self direct their care at the "point of service."
To illustrate this point, this is how these plans typically work. When medical care is needed, the individual plan member essentially
has up to two or three choices, depending on the particular health plan. The plan member can choose to go through his or her
primary care physician, in which case services will be covered under HMO guidelines (i.e., usually a co-payment will be required).
Alternatively, the plan member can access care through a PPO provider and the services will be covered under in-network PPO rules
(i.e., usually a co-payment and coinsurance will be required). Lastly, if the plan member chooses to obtain services from a provider
outside of the HMO and PPO networks, the services will be reimbursed according to out-of-network rules (i.e., usually a co-payment
and higher coinsurance charge will be required). Because people who belong to POS plans are responsible for deciding how to
access care within the various options, it is important that they understand the financial implications of these choices.
Where Do People Get Health Insurance Coverage?
Group Insurance
Most Americans get health insurance through their jobs or are covered because a family member has insurance at work. This is
called group insurance. Group insurance is generally the least expensive kind. In many cases, the employer pays part or all of the
cost.
Some employers offer only one health insurance plan. Some offer a choice of plans: a fee-for-service plan, a health maintenance
organization (HMO), or a preferred provider organization (PPO), for example. Employers with 25 or more workers are required by
Federal law to offer employees the chance to enroll in an HMO.
What happens if you or your family member leaves the job? You will lose your employer- supported group coverage. It may be
possible to keep the same policy, but you will have to pay for it yourself. This will certainly cost you more than group coverage for the
same, or less, protection.
A Federal law makes it possible for most people to continue their group health coverage for a period of time. Called COBRA (for the
Consolidated Omnibus Budget Reconciliation Act of 1985), the law requires that if you work for a business of 20 or more employees
and leave your job or are laid off, you can continue to get health coverage for at least 18 months. You will be charged a higher
premium than when you were working.
You also will be able to get insurance under COBRA if your spouse was covered but now you are widowed or divorced. If you were
covered under your parents' group plan while you were in school, you also can continue in the plan for up to 18 months under
COBRA until you find a job that offers you your own health insurance.
Not all employers offer health insurance. You might find this to be the case with your job, especially if you work for a small business
or work part-time. If your employer does not offer health insurance, you might be able to get group insurance through membership in
a labor union, professional association, club, or other organization. Many organizations offer health insurance plans to members.
Individual Insurance
If your employer does not offer group insurance, or if the insurance offered is very limited, you can buy an individual polic y. You can
get fee-for-service, HMO, or PPO protection. But you should compare your options and shop carefully because coverage and costs
vary from company to company. Individual plans may not offer benefits as broad as those in group plans.
If you get a non-cancelable policy (also called a guaranteed renewable policy), then you will receive individual insurance under that
policy as long as you keep paying the monthly premium. The insurance company can raise the cost, but cannot cancel your
coverage. Many companies now offer a conditionally renewable policy. This means that the insurance company can cancel all
policies like yours, not just yours. This protects you from being singled out. But it doesn't protect you from losing coverage.
Before you buy any health insurance policy, make sure you know what it will pay for...and what it won't. To find out about individual
health insurance plans, you can call insurance companies, HMOs, and PPOs in your community, or speak to your insurance agent.
Tips when shopping for individual insurance:
 Shop carefully. Policies differ widely in coverage and cost. Contact different insurance companies, or ask your agent to
show you policies from several insurers so you can compare them.
 Make sure the policy protects you from large medical costs.
 Read and understand the policy. Make sure it provides the kind of coverage that's right for you. You don't want
unpleasant surprises when you're sick or in the hospital.
 Check to see that the policy states: the date that the policy will begin paying (some have a waiting period before
coverage begins), and what is covered or excluded from coverage.
 Make sure there is a "free look" clause. Most companies give you at least 10 days to look over your policy after you
receive it. If you decide it is not for you, you can return it and have your premium refunded.
 Beware of single disease insurance policies. There are some polices that offer protection for only one disease, such as
cancer. If you already have health insurance, your regular plan probably already provides all the coverage you need.
Check to see what protection you have before buying any more insurance.
Medicare
Medicare is the Federal health insurance program for Americans age 65 and older and for certain disabled Americans. If you are
eligible for Social Security or Railroad Retirement benefits and are age 65, you and your spouse automatically qualify for Medicare.
Medicare has three parts: hospital insurance, known as Part A, supplementary medical insurance, known as Part B, which provides
payments for doctors and related services and supplies ordered by the doctor, and prescription drug coverage, known as Part D
which covers both brand-name and generic prescription drugs at participating pharmacies in your area. If you are eligible for
Medicare, Part A is free, but you must pay a premium for Part B and Part D.
Medicare will pay for many of your health care expenses, but not all of them. In particular, Medicare does not cover most nursing
home care, long-term care services in the home, or prescription drugs. There are also special rules on when Medicare pays your bills
that apply if you have employer group health insurance coverage through your own job or the employment of a spouse.
Medicare usually operates on a fee-for-service basis. HMOs and similar forms of prepaid health care plans are now available to
Medicare enrollees in some locations.
The best source of information on the Medicare program is the Medicare Handbook . This booklet explains how the Medicare
program works and what your benefits are. To order a free copy, go to: www.medicare.gov . You also can contact your local Social
Security office for information.
Some people who are covered by Medicare buy private insurance, called "Medigap" policies, to pay the medical bills that Medicare
doesn't cover. Some Medigap policies cover Medicare's deductibles; most pay the coinsurance amount. Some also pay for health
services not covered by Medicare. There are 10 standard plans from which you can choose. (Some States may have fewer than 10.)
If you buy a Medigap policy, make sure you do not purchase more than one.
You need to shop carefully before deciding on the best policy to fit your needs. You may get another booklet, Guide to Health
Insurance for People with Medicare , to help you in making the right choice. To order a free copy, go to: www.medicare.gov .
Another good source of information on the same topic is The Consumer's Guide to Medicare Supplement Insurance . To order a free
copy, go to: www.medicare.gov .

Medicaid
Medicaid provides health care coverage for some low-income people who cannot afford it. This includes people who are eligible
 because they are aged, blind, or disabled or certain people in families with dependent children. Medicaid is a Federal program that is
operated by the States, and each State decides who is eligible and the scope of health services offered.
General information on the Medicaid program is given in the Medicaid Fact Sheet . For a free copy, go to: www.medicare.gov . For
specifics on Medicaid eligibility and the health services offered, contact your State Medicaid Program Office.

BACKGROUND The ANSI ASC X12 837 standard provides the following text describing the purpose of
this transaction set.

“This X12 Transaction Set contains the format and establishes the data contents of the Health Care Claim Transaction Set (837) for use within the context of an
Electronic Data Interchange (EDI) environment. This transaction set can be used to submit health care claim billing information, encounter information, or both,
from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit health care
claims and billing payment information between payers with different payment responsibilities where coordination of benefits is required or between payers and
regulatory agencies to monitor the rendering, billing, and/or payment of health care services within a specific health care/insurance industry segment.For purposes
of this standard, providers of health care products or services may include entities such as physicians, hospitals and other medical facilities or suppliers, dentists,
and pharmacies, and entities providing medical information to meet regulatory requirements.The payer refers to a third party entity that pays claims or administers
the insurance product or benefit or both. For example, a payer may be an insurance company, health maintenance organization (HMO), preferred provider
organization (PPO), government agency (Medicare, Medicaid, Civilian Health and Medical Program of the Uniformed Services (CHAMPUS), etc.) or an entity such as
a third party administrator (TPA) or third party organization (TPO) that may be contracted by one of those groups. A regulatory agency is an entity responsible, by
law or rule, for administering and monitoring a statutory benefits program or a specific health care/insurance industry segment.”3

The Health Care Service Data Reporting Guide (HCSDRG) derives its name from the language above that permits use of the 837 standard for use in reporting health
care services. This is the same standard that is used to report institutional claim adjudication information for payment to private and public payers. Separate 837
implementation guides have been developed by the ANSI ASC X12N Task Group 2 Work Group 2 for payment of institutional, professional, and dental health care
claims. A fourth implementation guide has been written for the reporting of health care services. It has been given the following name by the ANSI ASC X12N
organization:

004050X156.4

What is the Transaction Implementation Guide and where can I get one?
Each transaction has an Implementation Guide that specifies the official government set of general rules surrounding the transaction
What is a companion guide and how can I get one?
A companion guide is used in conjunction with the HIPAA Implementation Guide. It details how a specific payer interprets the data elements, and the information
they require for processing claims

What do the different electronic transaction numbers mean?

The transaction numbers are:

 270/271: Eligibility and response - eligibility in a health plan

 277/276: Claims status inquiry and response - health care claim status

 278: Prior authorization - referral certification and authorization

 820: Premium payment - health plan premium payments

 834: Enrollment – Inbound enrollment and disenrollment in a health plan

 834: Enrollment – Outbound enrollment and disenrollment in a health plan

 835: Remittance advice - healthcare payment and remittance advice

 837: Claims - health care claims and equivalent encounter information

 NCPDP 5.1: Retail pharmacy claims - retail pharmacy claims and equivalent encounter information