Business Analyst – Flashcards

refers to a capability that a solution must provide (such as the capability to conduct online transactions) or a condition that it must meet (such as compliance with a set of regulations).

denote externally visible behavior that a system must be able to perform and include features and use cases written from the customer, user, and system perspective.

anything other than functional requirements.

mean a Service that is delivered to Business Customers by Business Units, for example, delivery of financial services to Customers of a bank, or goods to the Customers of a retail store.

systems analyst refers to a role distinct from the business analyst; the business analyst analyzes the business, whereas the systems analyst designs the software solution.

is a standardized form used for textual documentation.

is something that tells you what something is like; it is the actual documentation and may be in the form of text and/or diagrams.

Initiation, Discovery, Construction, Final, and Closeout

Make the business case for the project. Work also begins on the user experience and on architectural proof of concepts. The objectives of the Initiation phase are to develop the business case for the project, establish project and product scope, and to explore solutions, including the preliminary architecture. (The prototyping effort during Initiation should be risk-driven and limited to gaining confidence that a solution is possible.) The BA assists the project manager by identifying stakeholders, business services and processes, and IT services impacted by the project. By the end of this phase, key functionality is identified—such as key user tasks and IT services.

Conduct investigation leading to an understanding of the solution's desired behavior. Requirements analysis peaks during this phase but never disappears entirely. During this phase, architectural proof of concepts are also constructed. The main objective of the Discovery phase is to understand the solution's desired behav-iour and baseline the architecture

Complete the analysis and design, code, integrate, and test the soft-ware. (On iterative projects, these activities are performed for each iteration within the phase.) Design and coding appear in all phases, but peak during this phase.

Perform final testing before the product or service is transitioned into production. (While final testing occurs in this phase, testing activities may occur throughout the SDLC, for example, before design or as a replacement for it.

- What are the major problems you are experiencing? - How often do they occur? - What opportunities are we missing? - What are the costs and benefits of a change? - What are the risks?- Who will be affected by the success or failure of the solution? - Who are the users? - Who is the customer? - Who will sign off on the solution? - What is each stakeholder's interest (an addressed need or opportunity) in the solution?- What new business services or processes will be introduced by this project? - For each identified service or process, what is the expected impact of the change on the business area and on other services and components? Which of the business process participants (business actors and workers) will be direct users of the system? - Which tasks involve the IT system? - What is the best way to group the automated steps into tasks that can be accomplished by one user in one session? - What business services or processes (business use cases) does this user task support? - What business goals does it support?

Requirements may be signed off iteratively, as they are developed On waterfall projects, the following items are baselined and finalized; on iterative projects, requirements are subject to change at any time as long as they are not being implemented. Are the requirements complete, correct, realistic, testable, and within scope?

The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

The purpose of this phase is to manage and coordinate the processes, systems, and functions required for the deployment of a release into production and end project activities.

During the Plan stage, annual planning occurs; criteria for defining, categorizing, and prioritizing a project are developed; and projects are approved. During the Initiate stage, a business project is begun. During Execute, the proposed changes are realized. During Transition, the solution is made operational. At some point during or after this time, Post-Implementation Review. As the project closes, Early Life Support occurs—a period of time during which a team is on standby should problems occur, after which the internal IT team signs off on the changes.

- Scope initiation: Brainstorm opportuities, risks, features. - Requirements definition. - Problem Log (PLOG) Resolution: Resolve a problem or issue. - Structured walkthrough: Review a project artifact, such as a section of the BRD. - Process modeling, workflow analysis: Analyze the workflow of a business process. - Design reviews: Review external design definitions, screen prototypes, etc. - Business process management: Manage, improve a business process. - Gate review: Review and sign off on deliverables at specified points in the project. - Confirmation of agreements. - Post-implementation review: Assess results of a change.

Customers - Provide insight into problems with current service offerings. Know what new services or changes are desirable from the perspective of the person paying for the service. Users - Ensure that requirements meet the needs of end users of the IT system. Ensure system supports all user tasks (goals) and workflow requirements and is easy to use. Understand day-to-day problems with current system. High-Level Management - Ensures that business objectives (such as increased capacity, reduced costs, and improved efficiencies) are met and that management control, tracking, and reporting requirements are included. Internal Users - Ensures that solution improves line operations for internal users; concerned with increasing efficiency, performance, throughput, turnaround, and so on of users under their control. Product Champion - Has broad vision for the change. An agent of change, motivator. Service Desk Agents - Have first-hand knowledge of customer complaints, interruptions of service, and other problems with current system. Have own requirements whenever a change occurs: new procedures, training, and so on. Executive Sponsor - Point of escalation for resolving conflicts that arise as service design progresses. Early and continuing involvement of sponsors and the steering group (approval boards) promotes buy-in. Business Process Owners - Understand problems and issues with current business process. Ensure that IT changes are consistent with the end-to-end business process. Ensure that the proposed process is fit for purpose. Ensure continual improvement of the process and its metrics. Service Owners - An executive position with hiring and firing authority. Ensures that business objectives (financial, etc.) for the service are addressed and realized. Service Manager - Ensures tactical, operational needs for the service are met. Responsible for continual service improvement and for evaluating emerging needs of customers. Service Level Manager - Ensures that Service Level Agreements (SLAs) are defined, agreed on, and met. Works with customers and suppliers of services.

Product Manager - Provides input regarding the impact on the business if the proposed changes are made or not made. Provides insight regarding the impact of the change on existing services. Defines the overall risk profile and costs across lines of service. Business Relationship Manager - Provides a consolidated view of costs and risks across customers and contracts. Provides insight into how proposed changes will impact other services currently supplied to customers. Change Manager - Responsible for a final step in the approval process— ensuring that the Change Management process is followed. Primarily concerned with protecting the production environment and ensuring that the change does no harm (i.e., that change-related incidents are minimized). Reviews a checklist of items to ensure that the sponsor has agreed to the changes, that funding is available, and that resources have been allocated. Project Manager - Ensures that requirements are within scope of project and well-managed and that the System Development Life Cycle (SDLC) is being properly followed. SME - Provide deep knowledge in their area of expertise (business, technical, or other). Business Architects - Ensure that business standards, guidelines, and so on are being followed and that the changes are consistent with the business model. Standards - Representatives of (or experts in) standards and guidelines that constrain the project. Internal Solution Providers Provide a reality check to ensure that the requirements and requested warranties are realistic and that the requirements are of sufficient quality to be used for design and coding purposes. Supplier Manager - Ensures that all contracts with suppliers support the needs of the business and that all suppliers meet their contractual commitments. Ensures that suppliers have acceptable plans for responding to failures of their components. Testers - Ensure that requirements are testable. Report on test plans and results. Maintenance Programmers - Have first-hand knowledge of bugs in current system. Ensure that the changes will be maintainable in the future (proper documentation, standards followed, and so on).

The purpose of risk analysis is to analyze exposure to risk in order to support better decision-making and proper management of those risks.

Describes how to determine which activities are necessary in order to complete a business analysis effort, including identification of stakeholders, selection of business analysis techniques,and approaches, including requirements management and monitoring techniques and soft- ware tools.

Describes how to translate a business need into a change that can feasibly be implemented by the business. Covers problem definition and analysis, business case development, feasibility studies, and the definition of a solution scope.

The UML is a standard notation for the specification, visualization, and modeling of the structure and behaviour of business and software systems.

Accessibility requirements describe the ease with which an application, product, or IT Service can be used by a person with special needs.

A diagram that depicts behavior using a control and data-flow model. The BA uses activity diagrams to model business processes and user-IT interactions. Activity diagrams (or other workflow diagrams) are recommended for describing the internal workflow of business processes (business use-case realizations) and, as an adjunct to text, in describing user-IT interactions (system use cases) when the flows connect in complex ways.

An actor is a type of user or an external system that interacts with the system under discussion. The BA uses actors to model user groups and external systems. They are depicted on Role Maps and use-case diagrams.

Manifesto for Agile Software Development: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan

The purpose of analysisis to create an abstract representation of the business area under discussion. The representation should be valid regardless of the technology used. In waterfall approaches to software development, analysis occurs in the early part of a project; with agile and other iterative approaches, it may occur throughout the life cycle.

The architecture is the repository for across-the-board knowledge about a system, including its structure, stan- dards, templates, and process models. The term architecture may be applied to any type of system or part thereof, such as a business, an IT system, or a service. The BA contributes business process models and static (structural) models to the architecture.

An audit is a formal inspection to verify compliance with required standards, guidelines, procedures, and/or outcomes.

is a record of something at a given moment in time.

is a test that can be designed without knowledge of the inner workings of the system.

Business analysisis the discipline concerned with analyzing a business area, its structure, its processes, and its problems, and with representing business needs to solution providers

A business analyst (BA) is a liaison between business stakeholders (those requiring a solution) and the solution provider. The solution may or may not involve IT. The BA is expected to discover, analyze, negotiate, represent, verify, and validate the requirements for a solution. Business analysis may be performed by people with job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others.

The business architecture is a repository for knowledge about a business, including its processes and supporting organizational structure. Business architecture also contains a set of business goals and a roadmap for the evolution of the business.

The Business Continuity Plan defines the circumstances and process for activating a contingency when a disruption occurs to business operations and the process for restoring the service. The BA is responsible for eliciting and documenting business continuity requirements that are input to the Business Continuity Plan. Business continuity requirements are a component of the Business Service Level Requirements.

A business model is an abstract representation of a business area. The business model describes both the structure of the business as well as the ways its processes are carried out.

A business object is something that the business area keeps track of, monitors, or controls. A business object is an occurrence (specific instance) of an entity class.

The Business Requirements Documentis the consolidated documentation of all of the requirements (capabilities that a solution must provide or conditions that it must meet) that stem from the business.

A business use case is a business process representing a specific workflow in the business—an interaction that a stakeholder has with the business that achieves a business goal. It may involve both manual and automated processes and may take place over an extended period of time.

A Gap Analysis is an analysis of the difference between customer needs and an existing system. The BA per-forms a Gap Analysis to determine how much of a customer's needs are not met by the current IT system or an off-the-shelf solution.

A legacy system is a system in the twilight of its life cycle that is developed and hosted on aging technology.

Net Present Value is the value of an item, expressed in today's currency.

A Pareto chart plots events against their frequency of occurrence.

A performance testis a system test that checks the speed of the system, such as how fast it responds (response time) or how many transactions it can process per unit time (through-put). The BA must ensure that performance tests are planned and executed to ensure that performance requirements documented with the non-functional requirements are satisfied by the solution.

Plan-Do-Check-Act is a guideline for managing a process. On an IT project, it involves planning for the change, executing it, verifying whether the change met its objectives, and plan-ning and implementing corrective action based on the results. On an iterative incremental project, a Plan-Do-Check-Act cycle is executed for each iteration.

A project is an activity with specified objectives, resources, and time frames.

A process is a repeatable series of steps used to achieve a result.

Regression testing is retesting to ensure that items that were not sup-posed to have changed remain unaffected by the solution.

A requirement is a capability that a solution must provide or a condition that it must meet. Examples of requirements include the capability to conduct online transactions and the condition that the solution com-ply with a set of regulations. Within a business analysis context, a requirement is differentiated from a specification, in that a requirement describes what is required, whereas a specification defines how it will be satisfied. There are many types of requirements for which the BA is responsible; these may be broadly categorized as high-level business objectives, as well as functional and non-functional requirements.

Risk is something that is unknown or uncertain that may impact the success or failure of a project

Total Cost of Ownership is the full cost of an item over its entire lifespan. TCO includes the initial investment, maintenance, and overhead costs.

Total Cost of Utilization is the total cost to the customer of using a service during the entire period it is used.

A user requirement is one that must be satisfied by an IT solution, written from the perspective of the end user. A recommended practice is to docu-ment user requirements as system use cases

BAs have responsibility for the following areas: - identifying the tactical options that will address a given situation and will - support the delivery of the business strategy; - defining the tactics that will enable the organisation to achieve its strategy; - supporting the implementation and operation of those tactics; - redefining the tactics after implementation to take account of business changes and to ensure continuing alignment with business objectives.

In business analysis, you do not actually perform the activities to build the solution, nor do you actually manage the process to build the solution or test the solution. Instead, you identify the activities that enable the company (with your expert help, of course) to define the business problem or opportunity, define what the solution looks like, and define how it should behave in the end. As the BA, you lay out the plans for the process ahead.

The most common objectives of the BRD are: - To gain agreement with stakeholders - To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer's and business' needs - To provide input into the next phase for this project - To describe what not how the customer/business needs will be met by the solution The BRD is important because it is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The BRD distinguishes between the business solution and the technical solution. When examining the business solution the BRD should answer the question, "What does the business want to do?" For example, the business wants to serve 100 bottles of red wine each night during a three-day conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution should support the business solution. For example, the company would need a wine grotto or refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees Fahrenheit.

The functional requirements section should describe "what" the system is to accomplish rather than the "how." Develop a prioritized list similar to the following: Business requirements should focus on what the client wants, not how they want it. Once the complete requirements are gathered, the solution should be discussed. There may be more than one type of solution that will meet the resource availability, etc. and will help in estimating the time required to deliver the solution to the client. Then the specifications should be written based on the solution to meet the requirements. This is where the business analyst arrange workshops with different teams involved in the project to discuss the UI design changes, DB changes, architectural changes, etc. These teams will comprise of developers, QA, DB, data security, etc.

Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected. Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories: People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)] Systems: Systems is processing information and making decisions. Systems/people: System is processing information and people are making the decisions. Distinguish between employee and customer. Distinguish leadership requirement for associate in case decision making authority has to be moved up. The BRD appendix can be used to list a number of project details - constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project.

Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for: - People - Process - Technology - Materials and supplies - Facilities - Product - Machinery and equipment - Others as necessary (depending on the organization) Definitions and acronyms: Define any terms not clearly understood by all.

Who is the intended user? How many users are there? Are they the same type of user or different? What level of computer experience will the users have (or is needed)? What is the required security? Are there hardware constraints - networked or stand-alone? What are the approximate numbers of records required initially plus the anticipated growth? What technical support is necessary and available in-house? What other systems need to integrate/communicate?

You create a requirements document to explain what you need to someone capable of meeting the need. The challenge when trying to write a story about what you want software to do is to make it understandable to two groups that communicate in very different ways: the needers of the software and engineers who make it. If both groups do not understand and approve of your story, it will fail.

A software requirements document explains a business problem and the requirements of a software solution from a user anda business perspective. It is precise and detailed so that engineers can figure out what to build and how to evaluate what they produce. It uses common language that the business users and managers on the project can understand.

- A requirements document states - what is needed from a system in precise, measurable, and testable terms. - A requirements document details the way a system interacts with the elements around it. - A requirements document uses plain language understandable to soft? ware users and engineers alike.

- A requirements document does not explain how a system is built. - A requirements document does not describe the technology used to make a system. - A requirements document does not detail the schedule, plans, costs, or resources required to make the system.

- It sells a project to senior management and other stakeholders. - It demonstrates that a thorough and well?considered process has taken place. - It preserves a team's reasoning so that future team members can understand how choices were made. - It provides the basis for functional specifications and acceptance tests. - It can be a starting point for user documentation.

explains systems as a series of processes that are represented in "Data Flow Diagrams." Structured Analysis was the primary way to do this work for most of the twentieth century, and in many ways it still is, especially in large organizations like corporations, government, and the military. The teacher never said anything about stories, but one night he said, "Every system is basically the same. It takes data from somewhere, it does something to it, and then it puts it somewhere else." We also learned a simple form of diagram. (See the example of a Yourdon DeMarco data flow diagram earlier in this chapter.) These diagrams showed data moving between what he called "processes." Each process was an action that changed data (not a thing). The lights went on.

- Clear, precise words - Clear, short sentences - Clear, short paragraphs - A strong overall structure that breaks up all the content into short sections with meaningful titles, organized by subject - Lots of diagrams (data flow diagrams, to be specific) showing every process in the system - Structured descriptions of each process - Descriptions of all the important data in the system - Summary material that ties it all together

- Software requirements explain a business problem and the requirements of a software solution in nontechnical language. - Software requirements do not include project management details such as schedule, resources, and cost.

The system shall be able to import market data for commodity options supplied by MarcitData to the Transaction Management System for pricing of all commodity options transactions with less than 10 seconds latency to the market (see Appendix L for a MarcitData Commodity Options feed specification).

A good data flow diagram can show what a system does, what goes in, what comes out, and where it all goes in much less space and with more precision than is possible with text alone. A data flow diagram neatly condenses the work of a system into a series of processes and shows the output, products, or data that result from each process. Because of this focus on processes, inputs, and outputs, data flow diagrams are especially well suited to capturing and communicating requirements. In a data flow diagram, circles represent stages of work or processes, arrows show data moving into or out of processes, parallel lines enclose data stores that show data at rest, and rectangles stand for externals, or sources and receivers of data that are not part of the system being documented. The major occurrences are processes; the results of the process are data flows that trigger the next action. At each stage there are required actions and results that propel the story forward to its conclusion.

Data store: A data store is data at rest. Examples include a table in a database, a report, the volatile memory of a computer, or even a person's memory. A data store must have a name and requires either an input or an output.

Externals: An external is a source of or destination for data that is not in the scope of the current work. It is also sometimes called a terminator. An external must have a name and requires either an input or an output.

a visual element used in process flow diagrams, or flowcharts, that visually distinguishes responsibilities for sub-processes of a business process.

The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage. UAT tests are created to verify the system's behavior is consistent with the requirements. These tests will reveal defects within the system. The work associated with UAT begins after requirements arewritten and continues through the final stage of testing before the client/user accepts the new system.

- Loss of money - this can include losing customers right through to financial penalties for non-compliance to legal requirements - Loss of time - this can be caused by transactions taking a long time to process but can include staff not being able to work due to a fault or failure - Damage to business reputation - if an organization is unable to provide service to their customers due to software problems then the customers will lose confidence or faith in this organization (and probably take their business elsewhere) It is important to test the system to ensure it is 9error free and that it supports the business that depends on it. The later problems are discovered the more costly they are to fix.

a data motel is capable of telling and showing details about specific data that is physically stored in a database

this is broad view of any business process

By dividing a high level use case into several sub use cases then we get what is referred to as a low level use case.

it is a middle step dividing business users and developers.

MS Visio and Rational Rose

There are a number of diagrams used by business analysts including entity relationship diagram, data flow diagram, class diagram, activity diagram, state chart diagram, collaboration diagram, component diagrams, use case diagram, and deployment diagrams. Another business analyst interview question may ask you to define the three different types of diagrams used most often by all business analysts. The three are use case, activity, and sequence diagrams.

Sequence diagram is used to tell an object's interactions with one another being arranged in a timed sequence. A sequence diagram is often used by developers and tests as it allows them to understand the system better.

used for regression testing

used for testing the performance of your business

BRD described what is needed for the product and the FRD described the BRD in full details.

- Background/History - Scope and Objectives - Regulatory Requirements - Business Level Requirements - Strategic - Tactical (Interoperability) - Operational (Process related mostly) - Stakeholder and User Analysis - User Requirements (the abilities that the users need) - Functional Requirements - Non-functional Level User Requirements - Assumptions/Constraints - Risks and Dependencies - Solution Options - Business Glossary (the nouns and noun-verb phrases of the business) - Reference to Business Rules - Reference to Business Case/Vision - Use Case Models

Financial information would not be imbedded in BRD -> it would though include success criteria

When the BRD is complete, you will have a sign off list of people who will read and validate the document. Usually this list includes the project sponsor, the steering committee, the IT Lead, the project manager and the business lead.

How requirements questions How will you use this feature? Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain the steps? How might we meet this business need? How might we think about this feature a bit differently? How will we know this is complete? Where requirements questions Where does the process start? Where would the user access this feature? Where would the user be located physically when using this feature? Where would the results be visible? When requirements questions When will this feature be used? When do you need to know about...? When will the feature fail? When will we be ready to start? Who requirements questions Who will use this feature? Who will deliver the inputs for the feature? Who will receive the outputs of the feature? Who will learn about the results of someone using this feature? Who can I ask to learn more about this? What requirements questions What do I know about this feature? Or, what assumptions am I making about this feature that I need to confirm? What does this feature need to do? What is the end result of doing this? What are the pieces of this feature? What needs to happen next? What must happen before? What if....? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true. What needs to be tracked?

Is there any other way to accomplish this? Does this feature meet the business need and solve the problem we're trying to solve?

If you are dealing with a consumer-facing application, such as a website, you'll want to start as any consumer would. Think of a goal the website should help you fulfill and start navigating to achieve it. If you are dealing with an internal tool, check around for training materials or business process documentation to gauge how a business user might use the tool. If no documentation can be found and you are exploring a new business domain, you might want to engage one stakeholder in a brief demo or invite yourself to some training of new hires. Taking an hour of someone's time in this situation will get you leaps and bounds ahead and make your exploration of the system much more fruitful.

If we did XYZ, what would happen? What benefit does XYZ have? What would change once XYZ is in place? How does XYZ change things? Why should I care about XYZ? What's your goal? (or, the goal) How would XYZ impact you? (good technique to shift the conversation to a non-participant) What else do we need to think about if we do XYZ? Let's talk about what problem we might be trying to solve here. (yea, it's often necessary to re-iterate, just re-phrase if you can!) How would your day-to-day work change if we did this?

A UI specification defines the rules of engagement for a user interacting with a specific page on a website or screen within an application.

Project managers are responsible for delivering the solution to a problem. Business analysts are responsible for discovering the problem and determining the solution.

the product scope is what the product should or should not be, or do, once completed.

The Project scope are the activities and deliverables that need to be performed/delivered during the project life cycle. The product scope is to be measured against the product requirements, while the project scope should be measured against the project plan. The Project Scope includes all the work needed to be done to create a product, or deliver a service, or result. The Project Scope includes all the work needed to be done to create a product, or deliver a service, or result. The Project Scope is all about the project, it defines the requirements of products, the work required to create the product, and defines what is in the scope and what not. The Product Scope is the characteristics, features, or function of the product, service, or result. It is the outcome of the project. The Product Scope is all about the product: how will it look like, how will it function, etc.

1. Requirements specification resulting in the product requirements document 2. Design resulting in the Software architecture 3. Construction (implementation or coding) resulting in the actual software 4. Integration 5. Testing and debugging 6. Installation 7. Maintenance

The Product Owner represents the stakeholders and is the voice of the customer. He is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog.

an ordered list of "requirements" that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a working software system. The items are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

detailed, written instructions to achieve uniformity of the performance of a specific function

• Reducing the cost of developing the application. Minimal savings that might occur in the early stages of the development cycle by delaying testing efforts are almost certainly bound to increase development costs later. • Ensuring that the application behaves exactly as expected. For the vast majority of programs, unpredictability is the least desirable consequence of using an application. • Reducing the total cost of ownership. By providing software that looks and behaves as shown in your documentation, your customers require fewer hours of training and less support from product experts. • Developing loyalty and word-of-mouth market share. Finding success with a program that offers the kind of quality that only thorough testing can provide is much easier than trying to build a customer base on buggy and defect-riddled code.

User Acceptance Testing (UAT) - also called beta testing, application testing, and/or end user testing - is a phase of software development in which the software is tested in the "real world" by the intended audience or a business representative. Whilst the technical testing of IT systems is a highly professional and exhaustive process, testing of business functionality is an entirely different proposition.

The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage.

The "V" model is a methodology where development and testing takes place at the same time with the same kind of information available to both teams. It is good practice to write the UAT test plan immediately after the requirements have been finalized.

Most of us have had an experience with software that did not work as expected. Software that doesn't work can have a large impact on an organization, and it can lead to many problems including: • Loss of money - this can include losing customers right through to financial penalties for non-compliance to legal requirements • Loss of time - this can be caused by transactions taking a long time to process but can include staff not being able to work due to a fault or failure • Damage to business reputation - if an organization is unable to provide service to their customers due to software problems then the customers will lose confidence or faith in this organization (and probably take their business elsewhere) It is important to test the system to ensure it is error free and that it supports the business that depends on it. The later problems are discovered the more costly they are to fix.

When performing UAT, there are seven (7) basic steps to ensure the system is tested thoroughly and meets the business needs. 1 - Analyze Business Requirements 2 - Identify UAT Scenarios 3 - Define the UAT Test Plan 4 - Create UAT Test Cases 5 - Run the Tests 6 - Record the Results 7 - Confirm Business Objectives are met

One of the most important activities performed by the Business Analyst is to identify and develop UAT test scenarios. These scenarios are derived by analyzing the documents that were previously developed during the early phases of the project. These documents include: - Business Use Case - Business Process Flows - Project Charter - Context Diagram - Business Requirements Document (BRD) - System Requirements Specification (SRS) - Testing Guidelines and Techniques - Other Vendor's Deliverables

Once UAT Test Scenarios are identified, the Business Process Unit will create three deliverables: - UAT Test Plan - UAT Test Cases - After running the tests, a Defect Log captures problems

The UAT Test Plan documents the strategy that will be used to verify and ensure an application meets its requirements to the business. The UAT Test Plan is a document which outlines the plan for user acceptance testing of the project deliverables. This document is a high level guide, and will refer to test cases that will be developed and used to record the results of user testing.

must describe all the capabilities a product must have in order to fulfill the business, stakeholder and user needs. It defines the inputs, outputs, functions, and attributes of the system, as well as the attributes of the system environment.

- Identify and approve the change, which could involve many decision-makers with varying levels of influence and authority. - Create the software code to implement the change. - Test the change and validate the new code works as expected. - Fix any defects or deployment issues. - Release the change to a test and/or production environment. - - Again, this can often involve many decision-makers and gate-keepers and include sub-processes for each system component involved in the release package.

User experience is the totality of the effect or effects felt by a user as a result of interaction with, and the usage context of, a system, device, or product, including the influence of usability, usefulness, and emotional impact during interaction, and savoring the memory after interaction. "Interaction with" is broad and embraces seeing, touching, and thinking about the system or product, including admiring it and its presentation before any physical interaction.

Usability is the pragmatic component of user experience, including effectiveness, efficiency, productivity, ease-of-use, learnability, retainability, and the pragmatic aspects of user satisfaction.

Usefulness is the component of user experience to which system functionality gives the ability to use the system or product to accomplish the goals of work (or play).

Functionality is power to do work (or play) seated in the non-user-interface computational features and capabilities.

Contextual inquiry is an early system or product UX lifecycle activity to gather detailed descriptions of customer or user work practice for the purpose of understanding work activities and underlying rationale. The goal of contextual inquiry is to improve work practice and construct and/or improve system designs to support it. Contextual inquiry includes both interviews of customers and users and observations of work practice occurring in its real-world context.

Persuasiveness refers to the extent to which the experience visitors have on a Website encourages and promotes specific behaviors, which are referred to as "conversions." What constitutes a conversion varies from site to site, and even non-eCommerce sites may be promoting some type of conversion (e.g., newsletter signup, switching to online tax filing, looking up and using medical information).

Presence of a product is a kind of relationship with users in which the product becomes a personally meaningful part of their lives.

- Your users are accessing only a small portion of the overall functionality your system offers - There are a significant number of technical support calls about how to use a particular feature in the product. - There are requests for features that already exist in the product. - Your competitor's products are selling better even though your product has more features.

Work is the set of activities that people undertake to accomplish goals. Some of these activities involve system or product usage. This concept includes play, if play, rather than work per se, is the goal of the user.

The entire context of work and work practice in the target enterprise or other target usage environment.

Work practice is the pattern of established actions, approaches, routines, conventions, and procedures followed and observed in the customary performance of a particular job to carry out the operations of an enterprise. Work practice often involves learned skills, decision making, and physical actions and can be based on tradition, ritualized and habituated. Work practice includes all activities, procedures, traditions, customs, and protocols associated with doing the work, usually as a result of the organizational goals, user skills, knowledge, and social interaction on the job. The context of this kind of work often includes some manual activities in association with some interactive activities.

A work activity is comprised of sensory, cognitive, and physical actions made by users in the course of carrying out the work practice.

Task analysis is the investigation and deconstruction of units of work. It is the process of representing the structure of these units plus describing how they are performed, including goals, steps, and actions.

- prepare and conduct field visits to the customer/user work environment, where the system being designed will be used - observe and interview users while they work - inquire into the structure of the users' ow- work practice - lear- about how people do the work your system is to be designed to support - take copious, detailed notes, raw user work activity data, o- the observations and interviews

Domain-complex systems are systems with high degree of intricacy and technical content in the corresponding field of work. Often, characterized by convoluted and elaborate mechanisms for how parts of the system work and communicate, they usually have complicated workflow containing multiple dependencies and communication channels. Examples include an air traffic control system and a system for analyzing seismic data for oil exploration.

User proxies can be business experts or consultants who are familiar with the user's work.

sometimes more helpful to ask them to walk us though what their work specifically entailed the day before and if that was typical. This kind of a specific probing gives them an easy point of reference to make their descriptions concrete.

Video recording is an effective way of comprehensively capturing raw contextual data where conditions and resources permit. Video recording can help you capture important nonverbal communication cues in contextual data.

- Copious digital pictures of the physical environment, devices, people at work, and anything else to convey work activities and context visually. Respect the privacy of the people and ask for permission when appropriate. n On-the-fly diagrams of workflow, roles, and relationships; have people there check them for agreement. - On-the-fly sketches of the physical layout, floor plans (not necessary to be to scale), locations of people, furniture, equipment, communications connections, etc. - Quantitative data—for example, how many people do this job, how long do they typically work before getting a break, or how many widgets per hour do they assemble on the average?

A work role is defined and distinguished by a corresponding job title or work assignment representing a set of work responsibilities. A work role usually involves system usage, but some work roles can be external to the organization being studied.

A flow model is a diagram giving the big picture or overview of work, emphasizing communication and information flow among work roles and between work roles and system components within the work practice of an organization.

An affinity diagramming is a hierarchical technique for organizing and grouping the issues and insights across large quantities of qualitative data and showing it in a visual display, usually posted on one or more walls of a room.

A user class is a description of the relevant characteristics of the user population who can take on a particular work role. User class descriptions can include such characteristics as demographics, skills, knowledge, experience, and special needs—for example, because of physical limitations.

A data bin is a temporary repository—for example, a labeled pile of notes on a table—to hold data—raw contextual data at first and, later, synthesized work activity notes. Each bin corresponds to a different data category or contextual data topic.

Domain-complex systems are systems with high degree of intricacy and technical content in the corresponding field of work. Often, characterized by convoluted and elaborate mechanisms for how parts of the system work and communicate, they usually have complicated workflow containing multiple dependencies and communication channels. Examples include an air traffic control system and a system for analyzing seismic data for oil exploration.

For organizations to effectively operate a release management function they need to ensure they have processes and supporting tools. Release management software allows release teams to plan, manage and control the release schedule and track the status of each release to ensure production worthiness. Release Management software also provides the added benefit of applying central governance and auditing over releases before decision-makers approve releases to production.

is the coordinated promotion of new functionality into existing production environments on a specified date. Enterprise Releases can vary significantly in their size and composition and could include: - New systems or major function blocks delivered through major programs or projects. - Routine minor enhancements in the form of Business as Usual (BAU) change requests. - Minor defect fixes in the form of Business as Usual (BAU) service requests.

1. Review the Existing Enterprise Release Management Process Any improvement to the Enterprise Release Management function needs to start with a review of the current people, processes and tools within Release Management. A successful Release Management function is characterized as having capable people, a clearly defined regularly process and a toolset that supports all participants in the process.2. Establish an Enterprise Release Strategy that clearly articulates Regular Release Cycles As Enterprise Release Management is concerned with ensuring all child releases and work packages arrive at the same time within a defined window, it is essential to establish a Release Strategy with regular windows that enable new features to be deployed to customers at regular intervals. The frequency of these windows is typically monthly or quarterly and is driven by responsiveness required by customers as well as the complexity of the IT environment. The most successful Enterprise Release Management functions are those that are exercised regularly and tweak their processes slightly each release based on the lessons they learn.3. Invest in the right people to be custodians of the Enterprise Release Function. The team with the best players wins and it is no different in corporate teams and Release Management. Programme Managers and Project Manager will manage a broad set of work stream and activities to deliver to key milestones. Development managers will manage developers and product work packages for deployment. The key roles that participate in a successful release function, which is concerned with managing the smooth path of new features or changes through the various pre-production transitions include the Release Manager, Environment Manager, Test Manager and Implementation Manager 4. Provide as much transparency as possible Publish the target release plan for the next 12 months. Whilst the composition of releases may not be known with certainty the intent is to lock in the release windows so that all teams work towards not only the final release date but also the intermediate targets such as the completion of requirements, completion of system testing, completion of user acceptance testing and so on. In an environment where targets are continually shifting being able to set and communicate release windows 12 months into the future essentially shifts the discussion to release composition rather than release date. 5. Engage Stakeholders through prioritisation and release composition Once the release dates are defined and approved, Stakeholders are engaged to prioritize outstanding feature requests and allocate them to future releases. Stakeholders fill releases as far into the future as practical. There should be certainty around the immediate next release and less definition about the composition of releases scheduled further into the future. Regular structured releases give customers confidence that they can order something and it will be delivered. 6. Optimize Test Environment Usage All phases within the release process require IT environments to be in place for test execution and validation well prior the completion of any code. The release infrastructure covers the hardware, storage, network connections, bandwidth, software licenses, user profiles and access permissions. 7. Control the activity through release stages Releases encompass many moving parts. Transparency and control of each phase within the Release is critical to the alignment to a set delivery window. As Releases move through their key phases and milestones, at a physical level work packages are being promoted through various environments for various forms of testing and validation. 8. Continuous Communication Regular communication with stakeholders, delivery teams and suppliers is essential to ensure all parties have a consistent view of the expected outcomes and the manner in which they are achieved.

- Establishing a planning policy for the implementation of new versions. - Developing new versions or buying them from third parties. - Testing new versions in an environment that simulates the live environment as closely as possible. - Validating the new versions. - Implementing new versions in the live environment. - Carrying out back-out plans to remove the new version if necessary. - Informing and training customers and users about the functionality of the newly released version.

A disaster recovery (DR) test is the examination of each step in a disaster recovery program, as outlined in the business continuity/disaster recovery (BCDR) planning process. Disaster recovery testing helps ensure that an organization can recover data, restore business critical applications and continue operations after an interruption of services. The primary function of a DR test is to fully evaluate an organization's business continuity and disaster recovery plans. The testing process allows an organization to conduct plan maintenance and train staff about disaster recovery procedures. Disaster recovery tests should be conducted on a regular basis. Communications, data recovery and application recovery are typically a focus of all disaster recovery testing. Other areas for testing vary, depending on the organization's recovery point (RPO) and recovery time (RTO) objectives.

Structured Walk-Through Testing During a structured walk-through test, disaster recovery team members meet to verbally walk through the specific steps of each component of the disaster recovery process as documented in the disaster recovery plan. The purpose of the structured walk-through test is to confirm the effectiveness of the plan and to identify gaps, bottlenecks or other weaknesses in the plan.Checklist Testing A checklist test determines if sufficient supplies are stored at the backup site, telephone number listings are current, quantities of forms are adequate, and a copy of the recovery plan and necessary operational manuals are available. Under this testing technique, the recovery team reviews the plan and identifies key components that should be current and available. The checklist test ensures that the organization complies with the requirements of the disaster recovery plan. A combination of the checklist test and the structured walk-through test is suggested for initial testing to determine modifications to the plan before attempting more extensive testing.Simulation Testing During this test, the organization simulates a disaster so normal operations will not be interrupted. A disaster scenario should take into consideration the purpose of the test, objectives, type of test, timing, scheduling, duration, test participants, assignments, constraints, assumptions, and test steps. Testing can include the notification procedures, temporary operating procedures, and backup and recovery operations. During a simulation, the following elements should be thoroughly tested: hardware, software, personnel, data and voice communications, procedures, supplies and forms, documentation, transportation, utilities (power, air conditioning, heating, ventilation), and alternative site processing. It may not be practical or economically feasible to perform certain tasks during a simulated test (e.g., extensive travel, moving equipment, eliminating voice or data communication). Parallel Testing A parallel test can be performed in conjunction with the checklist test or simulation test. Under this scenario, historical transactions, such as yesterday's transactions, are processed against the preceding day's backup files at the contingency processing site or hot-site. All reports produced at the alternate site for the current business date should agree with those reports produced at the existing processing site. Full-interruption Testing A full-interruption test activates the total disaster recovery plan. This test is costly and could disrupt normal operations. Therefore, it should be approached with caution. Adequate time must be scheduled for the testing. Initially, the test should not be scheduled at critical points in the normal processing cycle, such as the end of the month. The duration of the test should be predetermined to measure adequate response time. Various test scenarios could be planned to identify the type of disaster, the extent of damage, recovery capability, staffing and equipment availability, backup resource availability, and time/duration of the test. The test plan should identify the persons responsible and the time they need to perform each activity. However, only part of the plan should be tested initially. This approach identifies the workability of each part before attempting a full test. Also, it may be best at first to test the plan after normal business hours or on weekends to minimize disruptions. Eventually, unannounced tests can be performed to emphasize preparedness.

For organizations with a relatively new plan, a quarterly or semiannual test may be prudent for the first year. After this initial period, semiannual or annual tests should be required as a matter of policy.

- Recovery of systems at the standby site, and establishment of an environment to enable full accommodation of the nominated applications - A fully documented set of procedures to obtain and utilize offsite tapes to restore the system and critical applications to the agreed recovery point, as set out in the recovery plan - Recovery of system/application/network/database data from the offsite/backup tapes - Detailed documentation on how to restore the production data as stipulated in the recovery plan, to the agreed recovery point (e.g., start of day) - Fully documented procedures for establishing communication lines/equipment to enable full availability and usage by appropriate areas (e.g., business units, data entry, users, etc.) - Established communication lines/equipment as set out in the plan - Examination of the designated alternative site and confirmation of all components are as noted in the plan

1. Put yourself in the user's shoes and understand how they will use the product 2. Address the 5 Ws - Who, What, Where, When, and Why. This highlights the benefits to the user. 3. Break down the requirements into simple parts - do not complicate it.

A use case model is a tool that is used to describe the business environment. The goal of the tool is to show the actions and events that take place during a given process that is performed by an actor.

Risk refers to something that can be forecasted and handled by creating mitigation plans. Risk that happened is called Issue. There will be issue management or contingency management to solve issue. As a business analyst you will not be solving the issue, but rather trying to make Damage control and use the knowledge gained as a learning experience for projects in the future.

Risk refers to something that can be forecasted and handled by creating mitigation plans. Risk that happened is called Issue. There will be issue management or contingency management to solve issue. As a business analyst you will not be solving the issue, but rather trying to make Damage control and use the knowledge gained as a learning experience for projects in the future.

Risk refers to something that can be forecasted and handled by creating mitigation plans. Risk that happened is called Issue. There will be issue management or contingency management to solve issue. As a business analyst you will not be solving the issue, but rather trying to make Damage control and use the knowledge gained as a learning experience for projects in the future.