Guidewire part 2

Have you ever tried to build something without looking at the instructions? Trying to develop system requirements without a point of reference is a little like trying to build something without instructions. However, when gathering requirements, this is a common approach:

The workshop begins... Ascreen is displayed... Someone demonstrates or illustrates a possible solution for the requirement... Everyone agrees to the approach... The team begins documenting the functional requirements from scratch

Who is responsible for driving the requirements elaboration workshop?

Business Analyst (BA)

Match the solution to the role

Business Resource / SME - They were biased due to a prior bad experience. They wanted a new product because of prior reporting issues on standard products. Developer - They thought a custom configuration could resolve the problem efficiently. They suggested creating custom reports to solve the problem. Business Analyst - They wanted the customer's needs met and for them to be happy with the solution. They suggested using the standard Business Owner Policy to meet insurers needs. Quality Analyst - They view the solution through a filter on whether it can be tested. They advised that the report accuracy is not measurable until production.

Requirement Gathering Process

The requirements gathering process is different depending on the phase of the project. - Inception phase - user stories are identified and high- level requirements elaborated - Sprint o - requirements for the first sprint are elaborated to get a head-start on Development - Development phase- user stories are refined to the functional detail level

What is one thing that determines what data is gathered on a claim intake screen?

The type of claim (personal auto, homeowners, worker's comp.)

Confirming value alignment is really all about ensuring that

everything we do, all the decisions we make, and the solutions we develop, are in support of the business objectives.

The project team arrived at the following solutions based on the business specifications provided. Select the solution or solutions that involve assumptions. Be prepared to describe the assumption made. (Select all that apply)

- Add a Vandalism and Theft coverage to the Simple Small Business Policy Line - Add a Data Breach Coverage Term to the Vandalism and Theft coverage with availability only for Nevada. - Make the Data Breach Coverage term required when Vandalism and Theft coverage is selected for policies written in Nevada. - Make a Police Report file attachment required before payments can be made on all vandalism or theft claims. Answer: If the project team arrived at these solutions without asking clarifying questions to confirm this information, these would all be assumptions: - That Simple Small Business is a Product or Policy Line. - That only Nevada can have Data Breach Coverage Term. - That Data Breach Coverage is required by Succeed Insurance versus the State. - That the Police Report file is required for ability to pay. Conclusions: Some final conclusions about assumptions: In all these scenarios, assumptions could be made about information that was missing. When there is not enough information in the business requirement, ask clarifying questions to avoid making decisions based on assumptions.

Lesson objectives - Claims Maintenance

- Describe the major parts of a claim - Use the full search capability of ClaimCenter - Describe the information available on theClaim Summary - Navigate to Claim details from the ClaimSummary - Describe what a supervisor does

Identify the common pitfalls to avoid when elaborating requirements to maximize the value of Insurance Suite:

- Determining the solution before the problem has been identified. - Accepting a solution offered as a requirement - Asking questions that do not solicit details - Allowing personal filters to influence requirements or solutions - Assuming the requirement is correct or needed

After the workshop, here are a few best practices to follow:

- Ensure the User Story Card is fully updated from the changes outlined during the Elaboration Meeting. - Follow-up on any Action Items. - Schedule future follow up meetings if needed. - Update related documents such as process flows, decision logs, or story progress status. - And, escalate any risks or concerns to the PMO or Steering Committee.

When requirements are not aligned? (Maximizing product Value)

- Every day, thousands of decisions are made on a project by people who bring their own requirements and focus through their area of expertise. - These decisions can divert requirements away from the business objectives. The result - requirements that are not strategically aligned. The impacts include: - Cost overruns for the project. Increased technical debt. - Time to market may delay or prevent benefits realization. - Team members may be frustrated when not working toward the same goal. The develop the legacy system they had. They end up with a system with no value. - To avoid this, project teams must confirm strategic value alignment. Every day, thousands of decisions are made on a project by people who bring their own requirements and focus through their area of expertise. These small decisions, over time, add up and, if unchecked, can divert a project away from the business obiectives. The result; the requirements are not aligned with the h business objectives or business strategy. The impacts of misaligned requirements can be very expensive with time and money spent developing unnecessary features. This effort can lead to cost overruns for the project. Additionally, increased development pulls resources away from innovation efforts and, at the same time, increases technical debt with time spent developing and testing the requirement for implementation and future releases. The additional development time can be further detrimental to financials when the time to market causes benefits realization to be delaved or prevented. Without clarity of project goals, project team members may each have different objectives in mind. This can lead to frustration when not all are working toward the same goal. When requirements are not aligned with business objectives, insurance companies can develop the legacy system they had. Even worse, they can end up with a svstem that provides no value. To avoid this, project teams must confirm whether business requirements contribute to meeting business objectives, or they should not be built at all. They should also continuallv find wavs to reference the business objectives in the work that they do. Therefore, confirming value alignment is really all about ensuring that

This lifecycle of a User Story diagram shows how a user story evolves:

- In the beginning, the user story is refined with additional details - Requirements are documented during the Elaboration Workshops - Requirements are further refined as needed during development and testing Finally, the requirements are approved with the acceptance of the user story by the Product Owner This can be a very iterative process. Whether your process looks like this or a different process, it is important to establish a requirements gathering process that works for your project to get the entire project on the same page. *This Lifecycle of a User Story diagrain shows the recommended, Agile best practices for completing all the tasks related to requirements gathering for one user story within a Delivery Sprint. Note: If a story is too large, it can be broken down into separate stories. For example, if broken into three stories, then there would be 3 separate user story lifecycles; one for each story for the sprint in which it is completed. You can see how a user story evolves: from the beginning when the user story is refined with additional details, to the documentation of the requirements during the Elaboration Workshop, to the refinement of requirements as needed during development and testing, and through to acceptance of the user story by the Product Owner. This can be a very iterative process. Whether your process looks like this or a different process, it is important to establish a requirements gathering process that works for your project to get the entire project team on the same page. Next, review the Guidewire suggested best practices for requirements elaboration workshops.

Question: Select the best functional requirement based on what you heard.

- Increase the field length of the Loss Description field on the Metropolitan Report Details screen. Change the default field length of 200 characters to 300 characters. Feedback: This solution is the only option that follows the guiding principle of leveraging the base configuration and fulfills the requirement with the information provided. The other options solve too soon by including information that was not provided by the insurer.

Identify the Business Objective or Business Strategy that this requirement is aligned with: Succeed Insurance wants users to be able to collect additional information about a business premises. It is important to know details about previous damage to buildings on the property, and any precautionary measures taken to protect the property, prior to issuing new insurance. This would include location, age of structure, evidence of subsidence, details of any structural damage that have occurred since constructed, and added monitoring systems such as smoke detectors and burglar alarms.

- Maintain Underwriting excellence with reduced loss experience This business requirement helps to meet the business objective of reducing loss experience through underwriting. Having the end user collect more information would not bring product to market faster, decrease reliance on IT, improve efficiency, or help to gain a competitive advantage.

Guidewire suggests the following best practices to prepare for a workshop:

- Review current state and future state processes. - Review inception notes and any backlog grooming details. - Review the Application Guide and functionality in the Sandbox. - Review any training materials and training notes. - Create demonstration data necessary for demonstrating functionality. - Identify key questions to be answered during the workshop. - Prepare for your audience (supporters, detractors, and those new to the project).For example: Are they afraid of change? If so, be prepared to reassure them. If they are excited, foster that excitement. - Prepare an agenda. - Establish and communicate participation expectations by including them in the meeting invite. - Schedule the meeting in advance. Be sure to invite SMEs who are closely related to the area being discussed, as well as SMEs for related upstream and downstream business process areas, like Finance, Audit, and so on.

The Claim Summary has three sections.

- The Basics section shows how long the claim has been open and the target days for a claim of this type to be closed or completed. It also includes a description of the claim. - The Financials section gives a high-level view of the current state of the financials for this claim. It shows the Gross incurred, which is a summary of the recorded exposures and reserve lines, as well as what has been paid on the claim to date. - The High-Risk Indicators section shows any high-risk indicators such as in litigation, coverage in question, or other flags. An adjuster can quickly see if there are any issues that must be addressed.

Weigh the options

- Thoroughly uncover and investigate all options by asking questions. Ask questions to determine: - What are the benefits or value of each option? - Are there an impacts to downstream systems or processes? - Does one option present more risks over the other? - What is the difference in cost for each option? Use the answers to these questions to come to an agreement. With time and budget limitations, often a decision comes down to priority and cost. When the decision is between two requirements, the requirement with the highest value should get preferential consideration.

Which of the Guiding Principles below would you reference when making a decision about whether to implement the following requirement: For simple, small businesses that may be very budget conscious, Succeed Insurance currently offers customers the option of splitting their down payment into two payments. Succeed would like for the new system to automatically split a customer's large down payment into two payments.

- We are not bound by the way we have always done things in the past - We will challenge current processes - We will leverage best practices built into the Guidewire software - We will drive adherence to product alignment to reduce total cost of ownership - We will strive for common workflows, processes, and systems across the organization - We will automate that which can and should be automated - We will limit scope as far as practical to accelerate time-to-Market * When making a decision to change an InsuranceSuite application, weighing the impacts against ALL of the Guiding Principles can help ensure the decision is correct.

Example: practice elaborating requirement solutions In this exercise vou will practice elaborating a requirement that includes a solution. Read the requirement with a solution, and select the best response to the question below. "Succeed Insurance would like a red flag to appear on the Loss Details screen when the policyholder is delinquent in paying their invoice. Which of the following would you ask when elaborating this requirement? (Select all that apply)

- What problem is this trying to solve? - How will this information be used? - Can the same result be accomplished with standard functionality? Feedback: The questions that challenge the solution given as a requirement are correct. The question that just clarifies the solution, does not challenge the solution, and indicates you are being an "Order-taker."

Make or Escalate the Decision

- When reaching an impasse, the next steps depend on the type of issue or decision. - There are two types of project issues: - Team Issues and Program Issues. - Team issues are matters that are isolated to specific teams which can typically be resolved on their own without escalation. - Program issues are of high severity and require escalation to the ProgramManagement Office (PMO) or Steering Committee. Issues or decisions that meet the following criteria are considered high severity: - Could delay the completion of a critical path deliverable - Could delay the end date of the project - May cause a significant financial impact - Will impact the intended scope of the release When escalating to the PMO or Steering Committee and provide this information about the issue or decision: - Description - Impact - Action Plan - Implementation Steps - All possible options *Team issues are matters that are isolated to specific teams which can typically be resolved on their own without escalation. The Project Manager and the team can put an action plan together themselves. These issues and decisions are not logged, but can be noted in the weekly status report. * Program issues are of high severity and are determined by the project manager or Scrum Master. These issues or decisions require escalation to the Program Management Office (PMO) or Steering Committee and should be documented on a Issue or Decision Log. For more details about this process, be sure to take the course: Surepath Overview or refer to the InsuranceSuite Implementation collateral: Guidewire Program Governance - Datasheet Guidewire Issue and Decision Management - Datasheet

Open a Risk

- When there are differing opinions on requirements, log a project Risk Item. - A risk - is defined as an event that could endanger the planned course or goals of the project. - If a risk is unavoidable, then it is no longer a risk: it is an issue. - A project issue is a problem that should be dealt with immediately, while a risk is something to look out for. - Risks can be identified by anyone on the project team. - Risks should be logged in a Risk Register. - Risks that have an exposure rating of Severe or Significant will be monitored and tracked during the project life cycle. - The risk rating is based on the level of exposure to risk: its potential impact and the likelihood it will occur. * A risk - is defined as an event that could endanger the planned course or goals of the project. A risk can happen, but it does not necessarily mean that it will happen. For more details about this process, refer to the InsuranceSuite Implementation collateral: Guidewire Risk Management - Datasheet

Exercise- Asking Good Questions

- You will be presented with a business requirement and several sets of questions that could be asked to clarify the requirement. - For each question set, identify the best elaboration question. - Information will be provided for every question you select in the question feedback. - Note: Only by selecting the BEST questions, will you be given the details you need to answer the last question. Requirement: Succeed Insurance wants PolicyCenter users to be able to add Additional Interests to Simple Small Business policies. good questions: - Can you describe the Additional Interests that can be added to a Simple Small Business policy? * Answer: An additional Interest is any party that has a financial interest in an item that is insured, but does not have ownership.They cannot be added as an additional insured because they are not offered coverage. For example, they can be the building mortgagee or lease-holder, a lease-holder on leased equipment, or a lien- holder like a contractor with money owed. There can be an unlimited number of Additional Interests added to a policy, but typically there is only 1 per insured object. - Can you describe how the data captured for Additional Interests will be used? * Answer: The data captured for additional interest will be used to trigger the Additional Interest endorsement form for each party added during new business, policy change, and renewal transactions. A cancellation or change transaction will trigger a notification to be sent to the appropriate additional interest. -What are the benefits of adding Additional Interests to policies? * Answer:Succeed benefits by being alerted to parties with subrogation interests on policies. This will make processing subrogation claims more efficient. Because of this, we plan to add this option to all policy lines. The Additional Interest party benefits by being notified when changes are made to the policy such as cancellations, lapses in coverages, or failure to renew. They also will be financially compensated if the item they have interest in incurs a loss. The benefit to the policy-holder is there is no additional premium charged when additional interests are added. Which functional requirement or requirements are correct ba

Original definition - Artificial

Artful and skillfully constructed * If you were asked to define the words "artificial" or "awful" 50 years ago, you would have given very different definitions. Artificial would have been defined as: "artful and skillfully constructed," and awful meant: "inspiring wonder."

Strategies for Handling Conflicts

1) Identifying the desired outcome 2) Weigh the options 3) Make or Escalate the Decision 4) Document the Decision 5) Open a Risk 6) Move on

IMPLEMENT THEN ENHANCE

1) We are NOT building a system from scratch. 2) We are NOT bound by the way we have always done things. 3) We WILL challenge current processes. 4) We WILL leverage vendor best practices. 5) We WILL drive adherence to PolicyCenter alignment 6) We WILL strive for common workflows, processes, and systems across the organization. 7) We WILL only automate that which can and should be automated. 8) We WILL limit scope as far as practical to accelerate time-to-market. A best practice is to distribute and display the insurance company's Guiding Principles in project work areas.

Assumptions lead to wrong requirements

You assume it will not rain and leave your umbrella behind, then you get caught in the rain walking home. In life, assumptions can be a source of frustration. In a project, assumptions can have more dire consequences when they lead project teams down the wrong path of development.

Documents

A ClaimCenter document is either an electronic file or a physical piece of paper which contains information relevant to the claim. Documents can be a First Report of Injury, Notification of Pending Inspection, Affidavit of Vehicle Theft, images of damage, and so on. ClaimCenter keeps electronic documents internally and retains information about where the physical document is stored.

Good Questions

Another reason for inaccurate requirements is, when elaborating, good questions are not used. To get the right requirements, it is important to ask good questions. Good questions get the clarification and details needed to accurately define the functional requirements. They also: - Probe for more details - Obtain supporting evidence - Push for value alignment - Challenge preconceived ideas - Consider dependencies and other systems

Matters

A matter tracks information about a single lawsuit or potential lawsuit related to a claim. Matters may have a very long life and are designed to track all aspects of a (potential) lawsuit. Matters track information such as case numbers, court dates, primary attorneys, and other details.

Notes

A note is a detailed record of the actions or thought process behind the processing of a claim Notes enable users to record information about a claim and associate it with the relevant part of the claim. Notes can be attached to the claim itself, a contact on the claim, or an exposure without having to tie the note to a specific date or user. For security, robust visibility rules contro who can view or edit the note. Notes may be manually created by users or generated automatically by ClaimCenter.

Reserve lines

A reserve line consists of the funds set aside for one specific aspect of exposure processing. A reserve line contains both credits - money set aside to pay the exposure and debits - money paid out for the exposure. At any point in time, the value or size of the reserve line is the credits minus the debits. An exposure may have a single reserve or several reserve lines if there are multiple "sets" of money for different purposes. For example, an exposure for a collision coverage could have separate reserve lines for auto body damage and glass damage because the insurer tracks these two types of payments separately.

What does an end user need to access a Guidewire application?

A supported web browser and a valid username and password.

Wrong requirements also happen when project teams allow these common pitfalls to occur when capturing functional requirements:

Accepting solutions as requirements, Making assumptions, Allowing the influence of personal filters or bias, Failing to identify conflicting requirements, Failing to clarify terminology, Failing to ask questions that get enough details, And solving too soon.

Using Active Listening

Active listening is a process of listening attentively while someone else speaks, paraphrasing what is said, and withholding solutions or advice. Use active listening when: - Identifying the problem as the insurer describes the business need. - Investigating all related processes and asking good questions. - Identifying the root cause of the problem in their answers to your questions. - Evaluating solutions, after the problem and root cause of the problem have been identified. Active listening until the problem and root cause are understood, will ensure the requirements are more accurate, and the solution is correct.

Financials approval

All transactions are tested against a set of rules to see if the transaction needs further approval. For example. an dajuster may not nave me aumnoniv o create a transaction for $50,000 without a supervisor's approval. If a transaction requires additional approval, it is put in a pending approval state. If a transaction does not require approval, it is acted upon Immediately

Role-based Bias

Also, understand how your experiences in vour role can create filters and biases that can influence requirements. For example, team members may allow their own requirements to influence business requirements. Flip each image to reveal examples of role- based bias.

Activities

An activity defines a task that may be required to process a claim. The activity identifies when the task is expected to be completed, the due date, and whether it has been completed. The general purpose of an activity is to provide a list of actions or tasks that must be completed. Activities may be created manually or by a robust set of rules that are tied to specific actions. For example, when an auto claim is created. the business rules create an activity which is assigned to the claim owner to contact the insured.

What is the purpose of an exposure?

An exposure is used to track potential payments on one coverage, for one claimant.

Document the Decision

As mentioned in the previous section, Program issues or decisions need to be logged in an Issue or Decision Log. Document key decisions related to: project priorities, project goals, designs, added features, resources, and deadlines. Include information like: - Date when decision was made - What the decision was - Who made the decision or was part of the decision - List any alternative solutions that offered but not taken - Why decision was made or why alternatives rejected (Reason) - Any supporting data. If questioned or an issue arises in the future, the decision documentation should answer any questions leadership may have. For more details about this process, refer to the Insurance Suite Implementation collateral: Guidewire Issue and Decision Management - Datasheet

Some final words on "terminology"

As you can see, project teams need to be careful with the words they choose when communicating or documenting business requirements. Also, it is important to clarify terminology definitions when unclear. A best practice is to establish a dictionary for commonly used terms at the beginning of a project, to ensure everyone is on the same page.

Authentication and authorization

Authentication is the process of verifying a user's identity, determining which objects a user is allowed to view and edit, and what actions a user is allowed to take. The Authentication prosess begins when the user supplies their username and password to ClaimCenter on the login page. ClaimCenter then authenticates the user. This may be within ClaimCenter or through a separate system's integration point. After authentication, ClaimCenter queries the ClaimCenter database to determine which permissions are assigned to the user and the user's default startup view. Permissions determine which screens the user can access and which actions they can perform. The startup view is the first page rendered after log in.

What are two mechanisms used to determine if a transaction requires approval?

Authority limits and transaction approval rules are used to identify which transactions require approval.

ClaimCenter internal user types

ClaimCenter is a browser-based application that enables users to participate in claims processing. The most common internal user types of ClaimCenter at a carrier are Claim Service Representatives (CSRs) who create claims for the insured, Adjusters who manage the claims, and Supervisors who supervise and approve work.

The value proposition of ClaimCenter

ClaimCenter is a claim-centric solution. All the data pertaining to a claim is centralized in the claim file. This includes information on policies, financials, diaries, documents, parties involved, litigation, and so on. ClaimCenter users have an integrated and holistic view of the claim. ClaimCenter facilitates collaboration among claims workers. It provides one centralized location where all information needed to adjudicate the claim can be worked on and shared. ClaimCenter also provides a wide span of control for supervisors by providing them with real-time team statistics and the ability to not only manage the team, but to also control and direct team activities

Checks

ClaimCenter uses the term "check" to mean any type of payment, either a physical paper check or an electronic funds transfer (EFT) transaction. A check may contain multiple payment transactions from multiple reserve lines. A single reserve line might have a single check or multiple checks issued against it. For example, there could be multiple payments for ongoing medical care. There may also be multiple payees, such as the award from a lawsuit, where the claimant receives 80% of the award and the lawyer receives 20% of the award.

Conflict is okay:

Conflicts and disagreements WILL occur on projects, especially when elaborating requirements. Business resources and Subject Matter Experts will have their opinions about how best to proceed; and project team members will have different opinions. Expect it. Conflict is okay At first, you might feel apprehensive about questioning a Subject Matter Expert's idea. However, the worst thing a project team member can do is to accept another idea when they feel it is wrong or will lead to problems later. Look at conflict as an opportunity to uncover issues and dive deeper into a topic. When there is conflict, consider all options until you arrive at the best solution. However, even with leveraging strategy and guiding principles, project teams can reach an impasse. What do you do when this happens?

Contacts

Contact information is typically captured when the claim is first created. Some contact information may be gathered at a later time, but ideally an intake process captures all information about the 'who' on a claim. Each contact involved in a claim must have one or more roles on the claim, such as a reporter, claimant, witness, doctor, attorney, repair shop, and so on. Contacts may be thought of as being involved in the loss, such as an injured person or a company whose property has been lost or damaged, or involved in providing services related to the loss, such as auto service vendors, property restoration or repair vendors.

Loss Details

During the adjudication process an adjuster may add information to the claim. The changes could range from adding a witness, to adding additional claimants. The Loss Details screen is where an adjuster would add or change details on the claim. Some of the information they may be changed or added on this screen are: *Fault Rating - Used to determine who has the liability for the damage. This impacts who is responsible for paying losses *Loss location - Used to record where the loss occurred and may impact whether the loss is a covered event. *Notification and Contact - Who reported the claim, and who the carrier should contact about issues concerning the claim. *Officials records - Any government officials, such as police officers, who were Involved in the loss and/or may have information about what occurred *Witnesses - Any non-government officials who may nave information about what

Supervisor

Each group in ClaimCenter has a supervisor. It is the supervisor's lob to ensure that the groups WOrK IS completed successtullv and on time. Supervisors are notified and assigned activities when ems are flagged oi escalated. They are also notified when transactions require approval. Supervisors may reassign objects to other users within a group

Inception Workshops

During Inception sprints, project teams will meet regularly with key stakeholders to identify and elaborate on the business requirements. Initially led by Guidewire, but eventually led by the customer, the Business Analyst typically facilitates these elaboration sessions. Elaboration sessions help team members gain a clearer understanding of the product by: - Looking at the standard user story backlog for the project for the products purchased and the lines of business to be implemented - Reviewing the standard process flows and how these tie back to the product functionality - Discussing the high-level requirements along with any concerns and possible gaps Validating the estimate for the user story *During Inception sprints, project teams will meet regularly with key stakeholders to identifv and elaborate on the business requirements. These meetings are called elaboration sessions or workshops. Project teams typically include Subject Matter Experts, Business Analysts, Business System Analysts or Technical Business Analysts, Quality Analysts and a Scrum Master. At the start of the project, these sessions are led by Guidewire, but eventually they are expected to be led by the customer as the project progresses. The Business Analvst typically facilitates the elaboration sessions. The goal of these elaboration sessions is to identify value-driven changes to the standard User Story to support business processes. These workshops also help project teams better understand the product to be implemented and the requirements needed. Here is how: Guidewire begins by looking at the standard user story backlog for the project based on the products purchased and the lines of business to be implemented. Then the standard process flows are reviewed and how these tie back to the product functionality. Next, the high- level requirements along with any concerns and possible gaps are discussed. After these elaboration conversations, the user story is revisited to validate the estimate for the user story. The team may decide the user story is not required, that the estimate can be reduced or increased, or perhaps to create a new user story if there is a gap requirement to address during the implementation.

Example : of different meanings

Exercise - What does incident mean to you? The Industry Definition: The insurance industry commonly refers to an incident as an event, an accident, or a near miss that may or may not develop into a claim. Typically, the industry follows an Event-to-Claims model where an incident can lead to one or more claims. The Guidewire Definition: In ClaimCenter, an incident is an entity on a claim that captures information related to potential exposures that may result in payments against a claim such as vehicle, property and injuries. Therefore, one claim can cover 0, 1, or multiple incidents.

Exposures

Exposures are used in ClaimCenter to track potential payments for a claim. Exposures are linked to a specific coverage, where the money is coming from, to which claimant. where the money is going to. For example, a collision exposure on a claim may track the costs to repair a vehicle and also track medical payments to a claimant.

Move on

Finally, after making or documenting the decision or risk, move on. Allow the program governance process in place to bring resolution to these decisions, and let it go.

Identify the desired outcome.

First, find out the desired outcome for the requirement. Often, the disagreement is about how to get to the desired outcome and not the outcome itself. After it is determined, use the team's alignment on the outcome to help bring about a solution that everyone can agree on.

Exposures

For many claims, a single loss occurrence involves more than one coverage and more than one claimant. Exposures are the mechanism used by ClaimCenter to track the progress of each possible indemnity. An indemnity is a payment in compensation for a loss. In property and casualty insurance, the goal is to restore a policyholder to the same financial position after the loss as he was in prior to the loss, without allowing the policyholder to profit from the loss. Exposures policy and coverages claim The term exposure is used differently in ClaimCenter than in Policy Administration Systems. The underwriter looks at the possible coverages as exposures, whereas in ClaimCenter it is the coverages that are deemed in effect leading to the creation of a particular exposure for a particular claimant.

Good Requirement vs Solution with Requirement

Good Requirement: - Make data breach coverage available to simple small businesses in Nevada - theft claims require a police report and a detail inventory of stolen items - capture whether simple small business have a burglar alarm on premises - Users need ability to include detailed loss description for theft claim Solution with Requirement: - Add logic to add data breach coverage to all simple small business in Nevada - add a list view to capture loss item details and a type list for lost type - the premises detail screen must have a field for capture burglar alarm - Add a question: "was a police report requested?" And give the option yes or no - Provide a list view for users to list each loss item and loss item description

When would you use Guiding Principles?

Guiding principles are especially useful when there are: Multiple options for handling an issue or requirement, Conflicting requirements, Differing opinions on what the business needs.

Establishing Guiding Principles

Guiding principles should be established by the insurance company's leadership team. Through Guiding Principles, leadership can convey how the insurer stands on common challenges faced during implementation and what is important to the company. Knowing this will be invaluable to project teams in providing the direction to take when faced with these challenges or a decision to make. If your project team does not have guiding principles, reach out to your project lead for the answers to these questions. They can provide some insight as to what the insurance carrier's Guiding Principles might be: Is it better to be more fully automated or to get to market more quickly? Can we change process or change technology? If both, which should change first? Will we all do the process the same way or each have our own process? What are the vendors' best practices? Do we want to challenge current processes? Do we want to build a system from scratch? Are we bound by the way we have always done it?

Next, read the scenario: A valuable chemical spill occurred at an insured's premises. Three visitors were burned. The floor was melted where the spill occurred. Now that we have clarified the terminology for ClaimCenter, see if you can answer these questions correctly:

How many claims can be filed as a result? At Guidewire, this would be one claim with multiple exposures. How many incidents occurred? In other systems, this might be one incident with multiple claims. In ClaimCenter, there would be 5 incidents: - 1 incident for Property Damage (to the building's floor) - 1 for lost property (chemical spilled) - 3 separate incidents for each injured visitor under Liability - Bodily Injury (Visitor 1, Visitor 2, and Visitor 3)

Lesson Summary - Elaborating Requirements that Maximize Value

In Conclusion: Gathering, documenting, and managing requirements are key to a successful software development project. Unfortunately, it can be difficult to get requirements right. Many aspects of human nature can hinder the requirements gathering process, such as unclear terminology, making assumptions, the influence of our personal biases and filters, not asking good questions, and solving too soon. Awareness of these common pitfalls when elaborating requirements can help you avoid these obstacles and write requirements that maximize product value.

Listen. Do not solve.

In addition to asking good questions, we need to carefully listen to the answers being provided. We need to LISTEN, and not solve. By being good listeners, we can better identifv problems. In many cases, we start as great listeners; but as soon as we believe we know the problem, we start thinking of ways to solve the problem. Are you guilty of this? As mentioned earlier, Business Analysts and Developers are naturally predisposed to solve problems. Unfortunately, this also leads to a tendency to solve too soon. Man subscribe to a view that software design is all about problem-solving. But, without a clear understanding of what a "problem" is, how can it be solved? Also, if we solve requirements before understanding the problem, we can miss the root cause of the problem, and end up creating a solution that does not solve.

Incidents

In insurance terms, an incident is the 'what' that was lost or damaged. Incidents are typically captured when the claim is first created. Some information about incidents may need to be gathered later, but the ideal scenario involves an intake process where all the information about the what is captured. If an incident is defined as "an item that suffered damage", then in a claim where a person is hurt, the incident would be called a "body incident". However, the term "injury incident" is commonly used in the industry and has been adopted by ClaimCenter.

Exercise - Whose filter is influencing requirements?

In the following exercise, you will be given a requirement and a series of possible solutions. The purpose of this activity is to gain an awareness of the influence personal filters have on the requirements and how they are implemented. Instructions: Read the business specification and what happened during the associated elaboration session on the next two tabs. While reading, look for examples of personal bias or filters. Then, based on what you know of the natural biases of each team member, match the solution to the persona that you believe suggested each solution below. The Business Specification: Succeed Insurance would like to offer insurance to support small business coverage. For large commercial interests, Succeed has already determined that the standard Commercial Package will meet the needs of their larger corporate customers. However, for simple small businesses, they want a separate policy line that caters to sole proprietorships and partnerships such as shopkeepers, patisseries, hairdressers, and independently-owned coffee shops. The Elaboration Session: The Business Analyst suggested they look at the Business Owners Policy to see if a version of this product could be used. However, the SME firmly rejected this solution. She explained that Marketing executives want specific sales data for this product and previously, when trying to extract sales data on a specific market segment using a standard product, they were unsuccessful. The Developer offered to configure a custom report for the data needed for marketing but the Quality Analyst pointed out that the accuracy of the report would be hard to measure until after product was live and data could be collected from policyholders. Finally, it was decided to use Advanced Product Designer to develop a new product called "Simple Small Business" from scratch, , so that data could be collected separately for this market segment leveraging an existing report by policy type.

Policy and coverages

In the insurance industry, a Policy is a contract between the insurer and the insured. In the contract, the insurer promises to cover the policyholder for specific types of losses. Coverages are types of losses that the insurer will cover and are typically listed on a policy. ClaimCenter is not the system of record for policies, instead it is integrated with an external policy administration system, such as Guidewire PolicyCenter. Whenever information about a policy is needed, the policy administration system is queried, and the relevant information is copied to ClaimCenter. Unlike other elements of the Claim file, there can be only one Policy.

The claim

Initially, a claim must be described as an event where a potentiaily covered loss occurs. One aspect of the claims process is to refer to the relevant policy to ensure that the loss was in fact covered. Even if there is a coverage on the policy, the loss may not be covered if it occurred when the policy was not in effect. It could also be a loss type specifically excluded from a policy, such as a homeowner's policy which excludes earthquake damage or mold damage.

Original definition - Awful

Inspiring Wonder * If you were asked to define the words "artificial" or "awful" 50 years ago, you would have given very different definitions. Artificial would have been defined as: "artful and skillfully constructed," and awful meant: "inspiring wonder."

Exercise - Practice Listening, Not Solving

Instructions: - Listen to the requirements Succeed Insurance has for vandalism and theft claims, by playing the video - Then, select the best functional requirement based on what you heard, and try not to solve too soon A common form of property damage is Vandalism and Theft. Succeed Insurance wants the ability to include a detailed description about these events with claim intake. During a demonstration of ClaimCenter, they saw a Loss Description field on the Metropolitan Report Details screen that could capture this information, as long as the field length is at least 300 characters. For theft or vandalism claims, Succeed also requires a police report and a detailed inventory of damaged, destroyed, or stolen items. For customers doing business in Nevada, this state would like additional data breach coverage due to the risk for identify theft when electronic equipment is stolen. Note that Succeed is asking the project team to use the guiding principle of leveraging the base configuration whenever possible.

To keep changes to InsuranceSuite at a minimum, project teams may need to approach gathering functional requirements in a different way.

Lesson 1 and 2 provided strategies and tools to guide insurers to maximize the value of Insurance Suite by minimizing changes to the standard configuration. This lesson provides strategies for elaborating requirements that maximize the value of InsuranceSuite by ensuring that, when changes are needed, they are the right changes.

Identifying Risk for Simple, Small Business Policies

Let us practice using business strategy as a guide. This activity demonstrates how understanding business objectives can impact project decisions and, ultimately, the alignment of the solution.

Which of the following describes the unique approach Guidewire recommends for elaborating requirements when leveraging standard features?

Leverage functional requirements already available in user story cards for standard Guidewire products as a starting point.

Maximizing Product Value - lesson Summary

Making good decisions is difficult. Your team will make 1000+ project decisions every day. Probablv none of these individual decisions will steer the project off course; but if unchecked, cumulatively they can significantly decrease the chance of success. Without knowing the details of the business case, decisions are made more difficult and requirements for a project can get misaligned. When we reference Business Strategies and Guiding Principles to assist in making decisions, we saw how they can improve decisions and resolve conflicts on the basis of priority. Having alignment of the Business Objectives with the Strategic Value, and a framework of Guiding Principles to support decision- making, we can increase our chances of successfully maximizing the value of the InsuranceSuite product being implemented.

How can good requirements be the wrong requirements?

Most project teams have no problem writing good requirements. However, well-written requirements can still be the wrong requirements. Even good requirements can miss the target when the requirement, itself, does not meet the business objectives. So, how does this happen? How do project teams deviate from the objectives? The following metaphor may provide one possible explanation.

Exercise - Identify assumptions about requirements

Now that we are aware of our tendency to assume, we will use this awareness to identify examples of assumptions when made about requirements. Instructions: 1) Read the business specifications below. 2) Then, review the solutions provided by the project team. 3) Identify solutions where assumptions were made to arrive at the solution. Requirements: A common form of property damage is vandalism and theft. Succeed Insurance wants the ability to include a very detailed description about these events on intake of the claims for their Simple, Small Business policies. When losses occur due to vandalism or theft, Succeed requires a police report and a detailed inventory of damaged, destroyed, or stolen items. For customers doing business in Nevada, the state needs small businesses to have additional data breach coverage for theft of computer equipment.

Have you ever encountered terminology that had different meanings amongst project team members?

One reason for inaccuracy in requirements (and confusion amongst a project team) is the improper use of terminology. This may happen for several reasons: - Multiple words exist that mean the same thing. For example, the word"terminology" has multiple words to choose from that mean the same thing (vocabulary, definitions, or jargon). - Words can have multiple meanings. (For example: the word: term can mean a word or a length of time). - Words can also signify different meanings to different audiences or cultures. - The meaning of a word can even change over time.

Refining Requirements during Development

Requirements gathering continues during Development or the Delivery sprint. - Delivery Sprint - refers to all the activities that occur AFTER Inception from Development and Stabilization, through to acceptance. - In the Development phase, time is divided into sprint prep (Sprint N-1) to document functional requirements and the actual development sprint (Sprint N). - Detailed functional requirements are usually documented in RequirementsRefinement Workshops at the beginning of the Development phase. - If using Behavior- Driven Development, the BA, QA, and Developer (Three Amigos) meet in Story Huddles to clarify requirements with example maps for each story. *Requirements gathering continues during Development or the Delivery sprint. Delivery Sprint - refers to all the activities that occur AFTER Inception from Development and Stabilization, through to acceptance. In the Development phase, time is divided into sprint prep (Sprint N-1) and the actual development sprint (Sprint N). Project teams typically work on the requirements ahead of the sprint during sprint prep to allow for development to start on the first day of the sprint. Detailed functional requirements are usually documented in elaboration sessions or in Requirement Refinement Workshops at the beginning of the Development phase. If using Behavior - Driven Development, the BA, QA, and Developer (Three Amigos) meet in Story Huddles to further clarify example maps for each story, add examples, and translate examples into concrete examples. Then the Developer or Quality Engineer translate the concrete examples into Gherkin Scenarios to create the Feature File for automated testing. For more information on the BDD methodology, see the course: "Behavior- Driven Development at Guidewire."

Why else do you think solutions are included in requirements?

Requirements with solutions happen because members of the project team (Subject Matter Experts, managers, executives, Business Analysts and Developers) although well intentioned, tend to be problem-solvers. It feels natural to include the solution with the requirement. Sometimes a solution is included to alleviate a concern that the requirement will be interpreted incorrectly.

Match the best practice for elaborating requirements with the timeframe when they should be completed.

Review inception notes and the standard system functionality > Before a Requirements Workshop Actively listen to the conversation about the requirement > During a Requirements Workshop Escalate any risks or concerns to the Scrum Master > After a Requirements Workshop

Best Practices for Requirements Workshops

The following reviews the best practices Guidewire recommends to use when elaborating requirements. Review the best practices for each stage: before, during, and after, a requirements workshop.

Service requests

Service requests are created when the claim is initiated and saved, or after initial claim creation. When services are created in ClaimCenter, they are automatically submitted to vendors through a vendor portal. The service request can be for a quote to compare prices. a service to be performed, or both a quote and service. The vendor can start work immediately, specify a time frame for completion, delay the request, or decline the request. Typically, a service is tied to an incident such as requesting locksmith services for a lourolanzed home or requesting a vehicle damage assessment for one or more damaged vehicles. Each incident may have any number of services

These are recommended best practices for during a requirements workshop:

Start by reviewing the workshop agenda and participation expectations.Examples of good expectations: - Limit speaking to one conversation at a time so that all ideas are heard, and - Try to limit laptop and phone use to taking notes - Review strategic objectives. For example: stay with the base configuration, do not rebuild the legacy system, and other details from their business case like - expand the business or cost savings in targeted areas. - Identify meeting participant roles. Participant roles can include: Note Taker, User Story Card Editor, Time- keeper, Meeting Serum Master to identify when the team heads off-topic, and an Action Item Tracker. - Actively listen to the conversation. If necessary, ask someone to take notes so that the rest of the team can focus on the conversation. - Use the standard workflows and screens for the base configuration of the InsuranceSuite application as the starting point. - Focus on the "happy path" of the requirement first, and then work on the edge cases. - Use the parking lot for off-topic items. This is an excellent technique for keeping the conversation focused on the topic at hand. - Reassure the team that items placed on the parking lot will be dealt with after the meeting, possibly in later meetings as needed. - Wrap up meeting with a review of accomplishments, outstanding items, action items, and any additional meetings needed. On the other hand, - Do not permit more than one conversation at a time. Side conversations make it difficult to keep the meeting focused on the topic at hand. - Do not reinvent the legacy system. Instead, keep the conversation focused on what the business needs are, and avoid getting into how the old system worked. - Do not be afraid to suggest "Let us put that on the backlog" when requirement appears to be out of scope. - Do not revisit decisions that have already been made. Only refer to the decision tracker as necessary.

The scenario - Implement a Modern Website (Modernizing the User Experience without Guiding Principles)

Succeed Insurance was implementing a brand -new Policy Administration System. One of the business objectives was to enable agents in the field to sell new policies. A decision was made to implement a custom website on top of the core system for agent access. The business case indicated that it would enable new insurance offerings and processes to support selling insurance through agents. Due to the focus on the modern interface, they overlooked the complexity of the business process for selling policies and how costly the maintenance would be. Because the core system and the digital user interface were two different applications, it required dual maintenance for changes like adding a new line of business. In the end, the project exceeded timelines and was over budget. The digital user interface may have been very modern, but it was difficult to use. After building it, they finally considered whether it was aligned with Succeed's guiding principles and ended up scrapping their extremely expensive, custom website. Your Thoughts? - Was the sleek, flashy portal aligned with the Business Objectives? Yes. So, even though they were aligned with a business objective, they still had problems. - How would having Guiding Principles as a guide have impacted this project? They would have guided the team to decide not to develop the custom user interface because they knew that time-to-market was important to Succeed Insurance. - Do you believe this project was considered a failure? Explain why or why not. While the project did meet a business objective, it hindered time-to-market.A project must contribute to achieving both the strategic objectives AND be aligned with the guiding principles to be a success. - If provided at the beginning of the project, which of the following guiding principles would have prevented the outcome? (Select the best option) We will limit scope as far as practical to accelerate time-to-market. This guiding principle would have driven discussions that may have prevented the expensive user interface from being built. Some of the other guiding principles may have supported building the user interface instead.

Scenario 1 - Identifying Risk for Simple, Small Business Policies

Succeed Insurance would like certain risks reviewed by an underwriter before a Simple Small Business policy is issued. To eliminate the need for agents to identify and manually send an issue to Underwriting, Succeed would like to automate the process by creating Underwriting Rules for each risk. With this in mind, they have identified several risks they would like their underwriters to review. However, they want to avoid underwriting rules that would create too many manual approvals. your thoughts? - What requirement for an underwriting rule did you select to implement? Explain your choice. - What information was key to making your decision? - Did you find yourself wanting to know more information? If yes, what did you want to know? - Why would additional information have helped? - If working as a group, were all team members aligned with the decision on what to implement? Why or why not? Use Strategy to Guide You: Now, repeat the same process, but this time start by reviewing the Business Objectives and strategies for Succeed Insurance. Succeed Insurance Business Objectives and Strategies 1. Achieve improved speed to market by: Increasing straight-through processing Increasing business efficiency through improved automation 2. Maintain Underwriting excellence by reducing loss experience Note: These business objectives and strategies are listed in order of priority. Knowing that Succeed wants to avoid underwriting rules that create too many manual approvals and, at the same time, achieve these business objectives, which requirement would you choose? Conclusions: Now that you have completed this exercise, you should conclude: without strategy; we will struggle with alignment and decision-making. The strategic objectives of the business need to be in the forefront of every team member's mind throughout the implementation project. If we all know the strategic objectives of the business, we can better align our decisions and have a higher probability of project success.

Insurance Terminology

Terminology used in the Insurance Industry can also be inconsistent between insurers and regions. For example, a word that can have multiple meanings is "Activity." Activities can be a task to complete. Often, insurers request an Activity be added when just a "reminder" is needed. Reminders can be accomplished through other methods such as using a warning message or making a field required. In fact, insurers often add so many Activities to a claim work plan that the efficiency of claim handling is impacted.

The New Claim Wizard (NCW)

The New Claim Wizard is the starting point for creating claims in ClaimCenter. It guides the user through the creation of a claim. Since it is Line of Business aware, the wizard adapts to the rosuits tinat he winaidacaptules only the data specific to the Line of Business claim type. For example, the data gathered for a property claim is different from the data required for an auto claim.

Could a project leverage InsuranceSuite to the fullest, align changes with strategic objectives, and still fail?

The answer is, Yes. Operating without Guiding Principles, is like operating a boat without a rudder - there is no clear direction. Without direction, project teams can make decisions that are not aligned with what is important to the business. Guiding Principles create a culture where evervone understands what is important. Unlike business objectives and strategies that can change, Guiding Principles are constant. They provide direction for project teams through all circumstances, irrespective of changes in business goals, business strategies, or type of work. Project teams should always have a set of Guiding Principles to follow specific to the project. Guiding Principles present a set of rules that help project team members make the right decisions when faced with a choice like: How to answer a question about a requirement, How to best solve a problem, and How to manage scope. When used in this way, Guiding Principles help project teams navigate difficult project decisions and increase their chances of arriving at a successful conclusion to their implementation.

How can we be good listeners?

The answer: actively listening.

Scenarios 1 - good requirements can be the wrong requirements

The errors shown here indicate that each task was completed with a preconceived idea of what the solution should be. Using the requirements from a legacy system as a starting point is like starting with a preconceived idea for the solution. The requirements for the old system may not be the "right" requirements for the new system. This is especially true when attempting to stay as close as possible to the base configuration of the new system.

Common mistakes when asking questions

These are some typical mistakes made during elaboration sessions when seeking clarification of requirements: - Asking Yes/No Questions because they will return yes/no answers. It is better to ask open-ended questions like "Tell me a story" questions. These are a great way to get unexpected, unasked details that are probably very important. - Another common pitfall in requirement elaboration is asking questions that lead to a pre-disposed solution. When you do this, you may miss key details. - Also, try not to ask multiple questions without waiting for an answer. For example: Do you want a sundae? Do you like chocolate? Do you want a cherry? Are you allergic to nuts? If the answer is "Yes," what question is the answer associated with? - Finally, sometimes a bad question is one that is not asked. Do not forget to ask about the impacts of a requirement to downstream systems.

Exercise - Assumptions Activity

This exercise illustrates how easy it is to make assumptions. Instructions: Read the description for each scenario below. (Groups may read only an assigned scenario). Think of an explanation of what happened. (Groups may discuss together). When done, check to see if your answer is correct by flipping the question card A" Scenario 1: A man rode into town on Friday. He stayed for 5 days and then rode home on Friday. How is this possible? The answer: Friday is the name of his horse. The reason this is difficult to answer is because of our assumption that Friday is a day of the week and not something that can be ridden. Scenario 2: There is an ancient invention, still used in some parts of the world today, that enables people to see through walls. What is it? The answer: The invention is a Window. Some assumptions that make this difficult to answer are: Walls are opaque, walls are not part of the house, windows were not invented, windows are not ancient, and the phrase: "Some parts of the world," means only a few places. Scenario 3: Two train tracks run parallel to each other, except for a short distance where they meet and become one track on a bridge. One morning, a train speeds onto the bridge. Another train, coming from the opposite direction, speeds onto the bridge. Neither train can stop on the short bridge and vet there is no collision. How is this possible? The answer: The Trains crossed the same bridge at different times of the morning. Assumptions you probably made were: There are two different tracks or two trains arriving on the bridge at the same time. Your Thoughts? As you can see, all of us are prone to making assumptions. After arriving at the correct answer to each scenario, reflect on the following questions: (Answers will vary) What did you assume incorrectly? What information do you think was left out that led to that false assumption? How did you think differently to change your assumption? If vou were correct, what helped you make correct assumptions? How can this be applied to working with requirements?

Our Own Personal Filters

We all have our own filters, bias, and experiences that impact how we perceive the world around us. Biases are filters we have accumulated in our subconscious based on our past experiences. We use these filters to simplify the complex world around us. This is due to a tendency of the brain to search for information that supports something we already know. These biases may help us make quicker decisions, but those decisions may not be accurate. Everyone on a project brings their own filters. It is important to be aware of how we let these filters and bias impact our decisions as we try to agree on how requirements should be implemented. These biases impact our understanding and may even prevent reaching a common understanding.

Reassigning objects

When a claim is reassigned, all exposures and activities belonging to the original owner are also reassigned to the new owner. Any exposure or activity belonging to a user other than the clains owner remains with that user. In this example, the claim and the first exposure are reassigned to Isabel Harkin. The second exposure is not reassigned because Betty Baker was not the owner of the exposure.

A better starting point when gathering requirements. Imagine if you were given a set of standard requirements for the new system.

When implementing InsuranceSuite, insurers do not need to start fromscratch Instead, insurers can leverage functional requirements that are already available. Existing requirements can expedite user story reviews and any needed modifications. At Guidewire, we suggest a different way to gather requirements beginning with a better starting point. Imagine if you were given a set of standard requirements for the new system, instead. How would this change the requirements gathering process? When implementing Insurance Suite, insurers do not need to start from scratch. Instead, insurers can leverage functional requirements that are alreadv available in user story cards for standard Guidewire products. Project teams can use existing requirements to expedite user story reviews and any needed modifications. This is yet another benefit when implementing the base configuration of Insurance Suite

When a user attempts to log into ClaimCenter, what three pieces of information does the application attempt to determine?

Whether or not the user can be authenticated, what are the user's roles (permissions), and what is the user's startup page.

Use Guiding Principles to assist decision - making

You will most commonly use Guiding Principles to assist with decision- making. Referencing Guiding Principles is a great strategy to use when making decisions that involve a choice. For example, deciding whether to: Change the base configuration or stick to the standard features? Develop a requirement or place it out of scope? Resolve a problem using Option 1 or Option 2? By pointing to what is important to the organization, Guiding Principles "guide you" to the best option to choose. When using Guiding Principles to make a decision, evaluate each option for alignment with the guiding principles for the project. If the requirement is not aligned, your decision should be clear. The requirement should not be implemented.

Whose filter is influencing requirements?

Your Thoughts? How can awareness of personal filters be used to ensure the best solutions are selected and accurate requirements are written? (Answers will vary.) Awareness can help you identify when your personal filters are influencing requirements or solutions. If they are, the solution should be examined for whether it is truly the best option for the insured.

Assumptions

are factors believed to be true; but have not been confirmed. When an insurer provides business requirements for changes, never assume they are needed or right. For example, if given a requirement for a new workflow, based on their current process, do not assume it is the right or best process to use. This can lead to recreating systems and processes that the insurance company alread has. Also, do not assume that everyone knows how a requirement supports the business objectives. We know that requirements should support the goals of business, but the connection is not always clear. Do not be afraid to ask what business objective the requirement fulfills if you do not see the connection. It is better to confirm rather than to assume.

Subiect Matter Experts (SMEs)

mav onlv provide details on what they know, which may not include Guidewire product capabilities. In fact, some SMEs push to rebuild what they had in the prior system which may lead to development of process that is not based on industry best practice.

Developers

naturally tr to solve the problem at hand with technology... and any solution is possible with enough time and money. Requirements elicited by Developers mav lead to unnecessarilv high development costs.

Business Analysts (BAs)

will push for the solution that requires the least amount of configuration and sticking to standard features. However, as the intermediary between the customer and Guidewire, BAs have a desire to keep the customer happy.

Quality Analysts (QAs)

will want to determine if requirements can be measured and tested and may encourage changes that will make requirements testable.