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. 5 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 6 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:

us A 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 processes. 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 another. 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 features 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 and 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 that 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 that

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 requirements? 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 within 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 by 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 number 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 why 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 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 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 semantic 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

chapters)

1st digit is alpha (all letters except U)

2nd, 3rd, 4th and 5th digits are

numeric

2nd and 3rd digits are numeric; 4th, 5th, 6th and

7th digits can be alpha or numeric

Decimal after first 3 characters Decimal after first 3 characters

Some Examples

780.60 - Fever, unspecified

995.81 - Adult physical abuse

810.00 - Closed fracture of clavicle,

unspecified part

R50.9 - Fever, unspecified

O9A.311 - Physical abuse complicating pregnancy,

first trimester

S42.001A - Fracture of unspecified part of right

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

all digits are numeric

digits can be either alpha or numeric. Letters O and

I are not used to avoid confusion with the numbers 0

and 1.

2nd, 3rd, 4th and 5th digits

are numeric

2nd and 3rd digits are numeric; 4th, 5th, 6th and

7th digits can be alpha or numeric

Decimal after first 3

characters Decimal after first 3 characters

Some Examples

43.5 - Partial gastrectomy

with anastomosis to

esophagus

44.42 - Suture of duodenal

ulcer site.

0FB03ZX - Excision of Liver, Percutaneous Approach,

Diagnostic

0DQ10ZZ - Repair upper esophagus, open approach

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 policy. 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