requirements excellence framework™ overview stakeholder

Requirements Excellence Framework™ OverviewSTAKEHOLDER PERSPECTIVE

© Copyright 2012 Enfocus Solutions Inc. RequirementPro™, Enfocus Requirements Suite™, RequirementCoach™ and StakeholderPortal™are trademarks of Enfocus Solutions Inc. All Rights Reserved.

August 2012 www.EnfocusSolutions.com

© Copyright 2012 Enfocus Solutions Inc. All Rights Reserved

Requirements Excellence Framework™ OverviewStakeholder Perspective

Table of ContentsI. Introduction to Our Product p.1

II. Document Purpose p.1

III. An Introduction to Our Methodology p.2

IV. Document Structure p.2

Business Analysis Task Matrix

Task GroupsTask Group 1.0 Participate in Project Activities p.5

Task Group 2.0 Understand Business Problem and Proposed Solution p.6

Task Group 3.0 Support Organizational Change p.3

Task Group 4.0 Optimize Business Process and Workflow p.9

Task Group 5.0 Document Assumptions p.11

Task Group 6.0 Define Solution Needs p.13

Task Group 7.0 Define Transition Needs p.15

Task Group 8.0 Define Transition Needs p.17

Task Group 9.0 Participate in Solution Evaluation and Acquisition Activities p.20

Task Group 10.0 Participate in Project Lifecycle Events p.21

AppendicesA. 12 Key Principles for Successful Projects p.23

B. Stakeholder Rights and Responsibilities p.24

C. 6 Results of Bad Collaboration on Requirements p.25

D. 10 Keys for Business Process Improvement Projects p.27

E. Business Rules p.29

a. Business Rules Manifesto p.31

F. Suggestions for Documenting Your Needs p.34

a. Using Need Patterns p.38

b. Using User Stories p.43

c. Using Scenarios p.45

G. Balanced Scorecard p.47

H. Business Process Analysis Checklist for Stakeholders p.53

I. Industry Standards p.55

J. Glossary p.56

p.4

© Copyright 2012 Enfocus Solutions Inc. All Rights Reserved 1


Document Purpose

This document provides project stakeholders and RequirementPro™ users with an overview of the Requirements Excellence Framework™ from the perspective of the stakeholder. Requirements Excellence Framework™ provides a set of processes and practices for defining, managing, and measuring requirements that are focused on delivering value, reducing cost, satisfying the customer, and achieving project success. The Framework may be viewed from two

distinct perspectives: stakeholders and those performing business analysis. In this overview, topics will be covered at a high level in support of the stakeholder’s perspective. The Framework is not intended to replace or modify existing project management and systems development methodologies. Rather, Enfocus Requirements Suite™ augments and supports existing methodologies to provide a solid foundation for successful projects.

A Brief Introduction to Our Product

Requirements Excellence Framework™ is one of four complementary components of Enfocus Requirements Suite™. The other components are:

�� RequirementPro™, a hands-on tool that provides fully automated support for business analysis and requirements management.

�� RequirementCoach™, a large archive of sample documents, best practices, and training.

�� StakeholderPortal™, an application that allows stakeholders to actively participate in and have full transparency to a project by means of unique collaboration technology.

Enfocus Requirements

Suite™

RequirementPro™

RequirementCoach™

Requirements Excellence Framework™

StakeholderPortal™

Together, these four products represent the most robust business analysis and requirements management tool on the market.



The Business Analysis Perspective and the Stakeholder Perspective are organized around task matrices and task groups, each including a series of tasks. Depending on your organization, the project, and its approach, tasks and task groups may be performed in whatever sequence best supports your needs. The Stakeholder Task Matrix is presented on page 4.

The following pages provide brief overviews of task groups and tasks. The overviews include lists consisting of the business objectives and major outputs for each task group. In addition to these lists, a list of Industry Standards followed by Enfocus Solutions Inc. and a glossary are also provided at the end of the document.

Document Structure

An Introduction to Our Methodology

Requirements Excellence Framework™ provides a structured methodology that addresses business analysis and requirements management at every stage of development, whether implementing a new application or improving an existing one. The tools and techniques provided in the Framework can be used to address and mitigate common requirement risks, such as lack of user input, unrealistic expectations, developers adding unnecessary functionality, and changing, ambiguous, missing, or conflicting requirements.

The Framework is based on industry best practices and standards, such as BABOK, PMBOK, and CBOK, as well as input from leading industry advisors and consultants. These business analysis and requirements management best practices are central to our Framework. To facilitate and support business analysis and project management activities, it is the responsibility of stakeholders to provide adequate resources (e.g., time or money) to the project team, educate business analysts about their roles, and spend time providing and

clarifying stakeholder needs to later be translated by business analysts. Within the duration of a project, stakeholders should constantly be reviewing and providing feedback in regards to relevant requirements and other records. For stakeholders to successfully carry out these responsibilities, the system of communication and collaboration between stakeholders and the project team must be determined. Following our methodology and utilizing our products is by far the easiest way to make sure the necessary communication occurs within your projects.

Our methodology is designed with the utmost flexibility so that it can be molded to fit your needs. The Framework works well with many types of development. Our methodology is supported by our unique applications RequirementPro™ and StakeholderPortal™, which permit key data, such as business rules, business process definitions, product descriptions, and stakeholder profiles, to be maintained separately from project requirement data and to be reused from project to project.



Optimize Business

Process and Workflow

1.0

Participate in Project Activities

Requirements Excellence Framework

Stakeholder Perspective

6.0

Define Solution Needs

7.0

Define Transition Needs

8.0

Validate Requirements

9.0

10.0

Participate in Solution

Evaluation and Acquisition Activities

Participate in Project Lifecycle

Events

2.0

Understand Business

Problem and Proposed Solution

Support Organizational

Change

3.0

4.0

5.0

Document Assumptions



Stakeholder Task Matrix 1.0 Participate in Project Activities

1.1 Monitor and Complete Assigned Action Items

1.2 Read Project News1.3 Review and Comment on

Project Deliverables

2.0 Understand Business Problem and Proposed Solution2.1 Review Project Team Members2.2 Review Problem Statement 2.3 Review Project Vision 2.4 Review Capability Gaps 2.5 Review Business Objectives 2.6 Review Project Constraints 2.7 Review Business Case 2.8 Review Impacted Services

and Components 2.9 Review Solution Scope 2.10 Review Business Analysis

Approach and Milestones

3.0 Support Organizational Change3.1 Review Impacted Stakeholders3.2 Review Stakeholder Impact Analysis 3.3 Discuss Needs and Project with Peers

4.0 Optimize Business Process and Workflow4.1 Review Business Process As Is Model 4.2 Review Business Process To Be Model 4.3 Review Process Impact Assessment 4.4 Review Process Requirements 4.5 Update and Maintain

Business Rule Books

5.0 Document Assumptions5.1 Document User Assumptions 5.2 Document Location and

Facilities Assumptions 5.3 Document Transaction

Volume Assumptions 5.4 Document Scheduling Assumptions 5.5 Document Infrastructure Assumptions 5.6 Document Customer/Supplier

Assumptions 5.7 Document Dependency Assumptions 5.8 Document Other Assumptions

6.0 Define Solution Needs6.1 Define Usage Scenarios 6.2 Define Processing/Workflow Needs 6.3 Define Reporting/Query Needs 6.4 Define Master Data Needs 6.5 Define Security Needs 6.6 Define UI/UX Needs6.7 Define Compliance and

Governance Needs 6.8 Define Collaboration Needs6.9 Define Performance and

Availability Needs 6.10 Define System Interface Needs

7.0 Define Transition Needs7.1 Define Training Needs7.2 Define Organizational Change Needs 7.3 Define Business Process Change Needs7.4 Define Infrastructure Needs7.5 Define Data Conversion and

Migration Needs7.6 Define Production Cutover Needs7.7 Define Documentation Needs 7.8 Define User Support Needs

8.0 Validate Requirements 8.1 Review Use Cases 8.2 Review and Validate

Requirement Specifications 8.3 Prioritize Requirements 8.4 Validate Requirement Bundles

9.0 Participate in Solution Evaluation and Acquisition Activities9.1 Determine Short-list Solutions 9.2 Analyze Short-listed Solutions 9.3 Document Decision

10.0 Participate in Project Lifecycle Events10.1 Review Requirement Bundle Details 10.2 Review Lifecycle Events and

Supporting Attachments 10.3 Create Test Scenarios and Test Cases 10.4 Perform Tests and Verifications 10.5 Resolve Defects 10.6 Prepare Project Change Requests 10.7 Participate in Project Retrospectives



Task Group 1.0 - Participate in Project Activities

Brief Overview1.0 Participate in Project Activities is listed as the first task group because it is a foundation for every other task group. Correlated tasks such as 1.2 Read Project News and 1.3 Review and Comment on Project Deliverables are relevant to every stakeholder at any given time throughout the duration of the project. Using StakeholderPortal™, you can view a project’s recent activity, news feed, and all of your assigned action items. We encourage you as a stakeholder to comment on any project deliverable or task, whether you have a question about it, simply need more information, or wish to express some kind of recommendation or approval.

Participation Outcomes�� Staying informed throughout the project

�� Communicating your concerns and queries with the project team

�� Maintaining action items assigned to you

�� Checking your StakeholderPortal™ dashboard on a regular basis

TASK DESCRIPTION

1.1 Monitor Complete Assigned Action Items

Action Items are project tasks assigned by RequirementPro™ users (e.g., a business analyst or project manager) to be carried out and monitored by other project team members and stakeholders. When you are assigned an action item, you can indicate its status in StakeholderPortal™ upon completion. This action can also be performed on behalf of a stakeholder by a RequirementPro™ user and/or other stakeholder using StakeholderPortal™.

1.2 Read Project News

Reading the project news feeds is vital to staying informed. While StakeholderPortal™ features an automated activity feed (records tracked in RequirementPro™ and StakeholderPortal™), the project news feeds consists of important user updates, a feature similar to social networking’s status updates and micro-blogging.

1.3Review and Comment on Project Deliverables

Project deliverables, which are outputs from various activities, are recorded and attached in RequirementPro™. The records of these deliverables can be read by all impacted stakeholders using StakeholderPortal™ and commented on by any individual with access to the project. Reviewing these deliverables and offering your perspective will keep you engaged throughout the project.



Task Group 2.0 - Understand Business Problem and Proposed Solution

Brief OverviewThe core project team will inform you via StakeholderPortal™ when stakeholders need to review records such as the project’s vision statement, business case, and problem statement. Early in a project, the team should concentrate on laying out the facts before proposing a solution, so part of your job as a stakeholder is to ensure that these statistical, factual documents are accurate, aligned with your objectives, and present information in a concise manner. Delivering information through RequirementPro™ and StakeholderPortal™ will automatically ensure a business analyst or project manager that the organization of documents is sequential and prioritized. Review each task record for the relevance of information (e.g., a proposed solution should not be in a problem statement) and the clarity of writing (e.g., no ambiguity, logical errors, and/or fabricated statistics).

Participation Outcomes�� Ensuring continuity throughout early project deliverables

�� Staying informed on the project foundation

�� Making sure that information relevant to you is accurate

�� Understanding the project’s objectives

�� Making necessary corrections to documents via comments in StakeholderPortal™

TASK DESCRIPTION

2.1 Review Project Team Members

StakeholderPortal™ provides a list of project team members, their respective roles, contact information, and company titles. As a stakeholder, you should review the contacts relevant to you while ensuring their information is complete and reliable. If you have any concerns throughout the project, you can simply leave a comment on the record in question or get in touch with the appropriate project team member.

2.2 Review Problem Statement

A good problem statement should be concise, specific, and measurable. When reviewing a problem statement, you should make sure the author has addressed the following questions: What is the problem? Who has the problem? And, in what form can the resolution be? This statement does not have to include too many details regarding the solution, but it may contain suggestions as to the nature of the project scope.

2.3 Review Project Vision

Project Vision should establish a common thread between all stakeholders. This document may not be long, but will ultimately serve as the foundation for project tasks, including optimization of business processes, defining solution needs, and validating requirements. The project vision document should not include any assumptions or requirements. That level of detail is too specific for this stage of the project.



2.4 Review Capability Gaps

Capability Gaps represent new capabilities required by enterprise needs. These gaps should make note of the existing process, its current outcome, as well as the desired outcome and the process needed to achieve such an outcome. This is documenting a gap and “filling” it. An ideal solution is one that takes capability gaps into consideration while not completely relying on them when creating the business case or business analysis approach.

2.5 Review Business Objectives

SMART objectives, (specific, measurable, attainable, relevant, and time based) can drastically improve a team’s performance and the outcomes of a project. To make sure that the business objectives are SMART, look for things like specific dates, statistics, and a “by-phrase” (what or who is providing the action). Here’s a good example: “Over 50% of all Medicare prescriptions will be prescribed and dispensed using eMM by December 31, 2013.”

2.6 Review Project Constraints

Project Constraints are parameters based on the limitations of a project. These often deal with project budgets and deadlines and must be taken into consideration throughout the project. Using RequirementPro™, a project team member can specify a constraint’s type, as well as provide attachments and assign action items that you can view on StakeholderPortal™.

2.7 Review Business Case

A Business Case is used to provide justification for the project and to request funding. A business case compares the costs of a project with the benefits it provides. The business case must show that benefits outweigh costs. In many instances, it includes a financial analysis that calculates the project’s return on investment or the net present value. While reviewing this document, make sure that it is more than just a financial justification for the project and includes all relevant information.

2.8 Review Impacted Services and Components

Implementing a new service can affect many existing components and related services. A business analyst or similar project team member will make a list of impacted components and services on RequirementPro™, which you can review and download on StakeholderPortal™. Impacted components are integral to a project because they represent indirect technology needed or affected by the solution, project, or project team.

2.9 Review Solution Scope

Scope Statements are used to conceptualize the recommended solution so that stakeholders can understand which new business capabilities the solution will deliver. Scope statements will eventually become the foundational record for which many requirements will be created. They need to be prioritized and reviewed to assess which needs must be elicited first.

2.10 Review Business Analysis Approach

A business analyst should help stakeholders actively participate in the project and deliver requirements iteratively. A good business analysis approach, set up with the proper milestones, is vital to a project’s success. Review the business analysis approach to ensure it generally fits your needs as a stakeholder as well as the needs of the enterprise.



Task Group 3.0 - Support Organizational Change

Brief OverviewOrganizational change is a process that consists of careful planning, preparation, and execution of the implementation of new or updated applications. Organizational change is most effective when all stakeholders are informed of reasons behind change, specific benefits of implementation, and details of change (who is affected, how much will it cost). While Task Group 2.0 explored fundamental deliverables like the problem statement and business case, this task group concerns itself with the adjustment to and exploration of project impact. Throughout the organizational change task group, you will be reviewing impacted stakeholders, as well as their prepared impact analysis. Before moving on to the next task group, you should discuss the project with relevant peers. This includes making sure that your group understands the project and discusses stakeholder needs.

Participation Outcomes�� Reviewing and analyzing impacted stakeholders

�� Understanding and revising stakeholder impact analysis

�� Discussing the project with peers

�� Formulating your needs and that of relevant peers

TASK DESCRIPTION

3.1 Review Impacted Stakeholders

Your project in StakeholderPortal™ should include a comprehensive list of impacted stakeholders as well as their respective roles within the organization. In this task, your responsibility is to make sure the list is as accurate as possible, leaving behind no pertinent stakeholder. Inform a project team member if you feel a stakeholder is missing from the list.

3.2Review Stakeholder Impact Analysis

At this point, a business analyst or project team member should ask you to review the impact analysis. You can view the analysis of each impacted stakeholder by selecting a name in the impacted stakeholder list. To complete this action item, simply examine the stakeholder’s information and impact detail for incongruities. Also, review the stakeholder’s additional information, such as his or her concerns and skills evaluation, to ensure that the appropriate details have been recorded.

3.3Discuss Needs and Project with Peers

Communication throughout a project is absolutely key to its success. More likely than not, you and your peers represent a group of stakeholders with similar interests and needs. This task is aimed at both the communication between you and your peers and between you and the project team. Your role as a stakeholder is to effectively discuss the project with employees relevant to its outcome and begin discussing your group’s needs.



Task Group 4.0 - Optimize Business Process and Workflow

Brief OverviewProcess improvement is at the heart of business analysis. Process modeling and analysis—somewhat early deliverables in a project’s lifecycle—should be reviewed by all relevant stakeholders. Processes can have requirements that should be kept separate from functional and non-functional requirements. These requirements detail demands of the process, from high-level enterprise needs to specific, key performance indicators. Along with optimizing the business process comes maintaining business rule books, which contain simply-written, enterprise-wide regulations. As a project stakeholder, your responsibility is to regularly update the rule books that pertain to you, ensuring that project objectives are aligned with enterprise goals.

Participation Outcomes�� Ensuring business process models are accurate

�� Making sure the process impact assessment is up-to-date

�� Reviewing process requirements for clarity and efficiency

�� Maintaining business rule books for the project

TASK DESCRIPTION

4.1Review Business Process “As Is” Model

Models can be developed according to the current state of the process—the “As Is” snapshot. The “As Is” model is particularly useful if re-engineering is needed to correct problems. Models can be created using a variety of methods. Use case diagrams, Business Process Modeling Notation (BPMN), and Unified Modeling Language (UML) are all excellent tools for representing a process. As a stakeholder, you should be familiar with how to read and analyze process models.

4.2Review Business Process “To Be” Model

Models can also be developed according to a concept of what the process should become—the “To Be” snapshot. Comparing and contrasting the “As Is” and “To Be” models provides a project team with the analysis an enterprise needs to reshape the way it performs business. When reviewing a “To Be” model, look for any incongruities between the model’s steps (usually represented with arrows) and its data representations (usually represented with boxes or circles).



TASK DESCRIPTION

4.3Review Process Impact Assessment

A process impact assessment should be provided to all project team members and stakeholders. In StakeholderPortal™, the list of impacted business processes are organized according to APQC’s Process Classification Structure (for more information, visit www.apqc.org), which supplies a four-tiered arrangement for general process classification. To review the process impact, click on a process and ensure its expected outcomes, systems impact, organizational impact, and risks are correct.

4.4Review Process Requirements

Process requirements describe activities performed by the organization. Conceptually, think of process requirements as high-level business requirements explicit to process-related activities. For example, process requirements could determine a specific framework that must be followed and/or constraints to which the organization must adhere. These requirements often specify the demands of implementing the “To Be” model, detailing what resources are needed for process improvement.

4.5Update and Maintain Business Rule Books

Maintaining rule books is as simple as regularly providing updates to enterprise-wide regulations based on your area of expertise and knowledge. Business rules often describe the operations and constraints that apply to an organization or enterprise. They can also apply to people, processes, corporate behavior, and/or automated systems in an organization. While maintaining rule books, use your specialized knowledge to provide necessary changes and additions to groups of rules, their organization, and relevance.



Task Group 5.0 - Document Assumptions

Brief OverviewAs a stakeholder, you bring a lot of background understanding, assumptions, and past experience to the project. Often, stakeholders may have assumptions of which business analysts do not. All assumptions should be recorded, no matter how obvious they appear to you as a stakeholder. The point of documenting your assumptions is to provide context for the project and project team. Whatever your assumptions are regarding a particular scenario, you need to document them and provide a business analyst with clearly written, accurate records via StakeholderPortal™.

Participation Outcomes�� Creating and maintaining assumptions

�� Documenting factors such as location, scheduling, infrastructure, and dependency

�� Writing your own assumptions based on categories relevant to your project

�� Keeping track of assumption records

TASK DESCRIPTION

5.1Document User Assumptions

It is important to communicate user expectations to members of the project team. Documenting even the simplest user assumption can save your project team from the endless rework that often ensues after User Acceptance Testing.

5.2Document Location and Facilities Assumptions

Document where the system will be used. Location and facilities assumptions are incredibly important, especially when making decisions like designing a cloud-based web application versus an installed system (people may need access on laptops, or at more than one location). These assumptions are easier to document because not much will change concerning the location and/or facility of your end-user’s operation.

5.3Document Transaction Volume Assumptions

Documenting transaction volume assumptions is the process of providing historical volume data. The user must answer the question, “How many transactions do you perform in a given period of time?” This information must come directly from the users.

5.4Document Scheduling Assumptions

Documenting the time by which a project must meet business needs is a fundamental piece of project planning that is often overlooked. While some scheduling assumptions may seem like random guesses, the authors may in fact be aware of inevitable scheduling priorities or conflicts within their area of expertise. These assumptions should be realistic for the people actually working with the deadlines, and you should consider breaking down the scheduling of deliverables into smaller units.



TASK DESCRIPTION

5.5Document Infrastructure Assumptions

The infrastructure is the physical hardware used to create a system. Make sure the requirement development team is aware of infrastructure assumptions. For example, can your project team assume that the system will be installed in a temperature-controlled lab of last year’s iMacs, or will the end-users be performing their tasks on computers running Windows 98 with 15 megabytes of random access memory? As a user and stakeholder, it is important to document assumptions about your digital environment and comfort.

5.6Document Customer/Supplier Assumptions

Consider the supply chain when documenting customer/supplier assumptions. How will the business deliver your product or service to the end-user? If your project team is undertaking a web application, can you assume that all of your end-users will have Internet access and a credit card ready for an automated transaction? The supply chain is vital to a project and any assumptions you can make about it need to be carefully reviewed to ensure a smooth transition between production and distribution.

5.7Document Dependency Assumptions

Documenting dependency assumptions is the process of determining the relationships between deliverables. For example, if you are setting up an automated email system, the system would first need to gather email addresses before attempting to send a bulk message. Additionally, resource dependency deals with the constraints of what is and is not at the disposal of the project. Dependency assumptions may explore the natural sequence of project events, and they are sometimes represented with simple flowcharts or ordered lists.

5.8Document Other Assumptions

Documenting assumptions outside of these categories may be essential to your project. A good point of reference is the averaging technique, which works well for almost any assumption. Even if you do not have numbers to work with, you can think about a process at its most optimistic and its least optimistic, setting goals for both and conceptually joining them somewhere in the middle.



Task Group 6.0 - Define Solution Needs

Brief OverviewOne of the fundamental features of Enfocus Requirements Suite™ is the direct entry of needs by stakeholders using StakeholderPortal™. After you enter your needs, a business analyst will evaluate them via RequirementPro™. Then the analyst will tag them for importance, urgency, compliance, impact, etc. The final task is to review them for any exclusions, contradictions, ambiguities, or general organization discrepancies. Writing good needs is a backwards process. Think about how a business analyst will evaluate your need based on relevant criteria for quality. Think about the review process—a business analyst looks for missing pieces, such as a cause without an effect, and logical errors, such as double negatives and the misuse of logical operators (nor, and, or). Ambiguous needs can lead to ambiguous requirements, so it is important to make sure your needs are clearly written and express what you really mean.

Participation Outcomes�� Defining scenarios for the project team

�� Defining the following types of needs:

�p Workflow �p Reporting �p Master Data�p Security�p User Experience�p Compliance

�p System Interface

TASK DESCRIPTION

6.1Define Usage Scenarios

A scenario is a description of a business problem designed to be as total and complete as possible, allowing needs to be viewed in relation to one another. Think of the scenario method as a way to contextualize a group of needs, based on one possible sequence of events. A scenario provides a common language that connects customer problems and technical solutions. These scenarios are beneficial when used to convey an interaction from the point of view of an end-user.

6.2Define Processing/Workflow Needs

Processing/workflow needs are best described by answering a question that starts with how, what, or where. A few good examples: “How is data verified before presentation?” “What happens to the output from the process? Where does it go?” and “What support processes might be affected by the system?”

6.3Define Reporting/Query Needs

Reports and queries can ensure that the system is balanced and that correct information was entered by a specific user. There are two types of reporting: analytical and operational. Analytical reporting deals with the analysis of transactions that have already happened, as opposed to operational reporting, which captures data from individual transactions (the most immediate type of assessment available). As a stakeholder with vested interest in reporting and query, you should specify the nature of desired reporting and the expected outcome.



6.4Define Master Data Needs

Master data records consist of information concerning core enterprise concepts that play a key role in the operation of the organization. Master data needs may include information about customers, employees, inventory, suppliers, analytics, and other topics. Master data records include associated metadata, attributes, roles, and taxonomies, such as customers, suppliers, parts, products, locations, and contact mechanisms.

6.5Define Security Needs

Needs that concern security, integrity, or privacy issues affecting access to the application should be thoroughly addressed. These needs, like compliance needs, usually originate in business rules, so if there are any security or privacy policies by which the product or service must abide, you should identify and document them.

6.6Define User Interface/User Experience (UI/UX) Needs

UX needs are not just about design, as you might have guessed, but also about usability. When defining UI/UX needs consider the system’s ease of use, navigation, structure, page formatting, button placement, and general friendliness. For example, if your end-users are not comfortable with command line, scripting applications, then your developers should probably implement some kind of graphical user interface (GUI).

6.7Define Compliance and Governance Needs

A compliance need is simply one that meets a regulation or standard already set in place by either the business, industry, or government. Many of these needs will come from the business rules, which are maintained by stakeholders and key project team members. Defining compliance needs is extremely important due to their mandatory nature. Having a full collection of compliance needs is essential to the success of a project.

6.8Define Collaboration Needs

Collaboration needs concern the communication between users of a system. Collaboration needs should provide suggestions for the best methods of collaboration. For example, if stakeholders were located in multiple areas or have busy schedules, the best way to communicate project news and updates to project team members and other stakeholders is most likely through StakeholderPortal™ and RequirementPro™.

6.9Define Performance and Availability Needs

These types of needs are straightforward and deal with general functions that the system should perform, as well as attributes to its capabilities. Performance needs are typically necessary features—basic and fundamental to how the system operates. They outline the purposes and measurable factors of performance, which is an assessment of what is achieved or delivered by a system, person, team, process, or IT Service. An availability need provides the ability to a configuration item or IT Service to perform those agreed functions when required. An availability need is one that utilizes access control and/or time windows for a system’s operation.

6.10Define System Interface Needs

Systems must possess the ability to successfully interact with other systems. Defining those needs ensures the designed system can provide data for other systems when it is necessary. There are multiple possible levels of interface. For example, for the system to provide information to another, should it be manually uploaded? Or should the system be seamlessly interfaced with the others that it must interact with?



Task Group 7.0 - Define Transition Needs

Brief OverviewTransition requirements, which come from stakeholder transition needs, represent a distinct class of requirements because they exist within the project scope. In this sense, transition requirements can be considered the “project requirements” because they are only needed during the project and are not commonly reused. All “solution requirements” should have the ability to be reused in multiple projects. However, once a transition requirement has been fulfilled, it ceases to exist—the business need is gone. One-time data conversions are the simplest example. The project team needs to convert data from the old system to the new system. Once the conversion is done, the need for conversion is gone, so the requirement no longer exists.

Participation OutcomesDetermining the following types of needs:

�� Training

�� Organizational change

�� Business process change

�� Infrastructure

�� Data conversion

�� Production cutover

�� Documentation

�� User support

TASK DESCRIPTION

7.1Define Training Needs

Training needs include the technical comfort of the end-user, what platforms and graphical user interfaces (GUI) users are familiar with, and the skills necessary to perform standard operational activities with a new system. Additionally, consider how an employee is supposed to learn how to use a new service or feature. Some users prefer an online training course while others prefer face-to-face classes. You have to find out which of the options is best suited for your organization.

7.2Create Verifications

Organizational change needs should detail the shifting of individuals, teams, and organizations from the current state of operations to a desired future state. These needs should be aimed at helping stakeholders embrace changes in their business environment. Organizational change needs address training of and communication to stakeholders. These needs should help prepare users to enter and retrieve information effectively and manageably.



TASK DESCRIPTION

7.3Define Business Process Change Needs

Business process change is the simple process of improving a business process and implementing it within the business. According to industry experts, business process change usually starts with humble beginnings in methodologies and technologies like Lean, Six Sigma, enterprise resource planning (ERP), customer relationship management (CRM), or business process management (BPM), but it almost always ends up yielding questions about organizational design, governance, change planning, and execution. The purpose of defining process change needs is to turn these high-level ideas into successful initiatives.

7.4Define Infrastructure Needs

The term IT infrastructure refers to the combined set of hardware, software, networks, facilities, etc. needed to develop, test, deliver, monitor, control, and support IT services. An infrastructure need should detail end-user adjustments to IT resources.

7.5Define Data Conversion and Migration Needs

Implementing a new system often requires the migration of data from the existing platform. At this stage, the project team and related stakeholders must decide what data from the current system or process should be converted, migrated, or archived to implement the new system or process.

7.6Define Production Cutover Needs

Production cutover is the transfer of the solution from the project team to the business. Production cutover needs identify and assign resources to each process, including sequences of tasks to set dates for deliverables. Handing a solution to a business can be difficult, but preparing for it can make the transition a lot smoother.

7.7Define Documentation Needs

Documentation needs include online help, presentations, and other notations (even program source code), as well as traditional documents. A good example would be the output from a documentation generator, but make sure to include less traditional documentation like instructional videos, interactive tutorials, and other informative materials, as well.

7.8Define User Support Needs

User support is an important component of a successful system. Needs in this category should express the methods that both users, support team, and developers will utilize for communication. User support should be intuitive and helpful, so keep this in mind when defining and documenting support needs.



Task Group 8.0 - Stakeholder Engagement and Communication

Brief OverviewStakeholder participation in validation activities can help the project team discover and fix unnecessary and incorrect requirements. Requirement validation is based on requirement bundles, which is a method for flexibly organizing requirements. Our method for defining and baselining bundles is completely customizable depending on the needs of your organization. There are two main, high-level differences regarding how your project team can apply our bundling system to its style of development. The first consideration is based on iterative development, which concerns releases in iterations, as opposed to waterfall development, which uses an all-at-once release schedule. When reviewing requirement bundles, ensure that the quality of individual requirements matches that of the bundle itself, adhering to quality characteristics listed at the end of this section.

Participation Outcomes�� Reviewing use cases

�� Validating specifications

�� Prioritizing requirements

�� Validating requirement bundles based on quality attributes

TASK DESCRIPTION

8.1Review Use Cases

Use cases are particularly convenient when dealing with large-scale development initiatives with complex software. They efficiently communicate what a system is supposed to do, place needs in a specific concept (into that of the user’s goals), and provide a great starting point for the design of practical user experiences. While reviewing use cases, stakeholders should pay close attention to the level of detail presented and make sure it is enough to qualify as a practical asset to the project.

8.2Review and Validate Requirement Specifications

Requirement specifications provide a complete description of the behavior of the system to be developed. The process of validating specifications entails careful review of its individual components as well as its compositional semantics. Ensure your requirements meet the individual requirement quality characteristics as listed on the following page.



INDIVIDUAL QUALITY CHARACTERISTICS FOR TASK 8.2

Accurate It is important to make sure that every requirement correctly illustrates the functionality to be implemented. The source of the requirement is the reference you should use to check its accuracy. A software requirement that conflicts with a corresponding system requirement is not accurate.

Atomic Dependencies between requirements can make planning, prioritization, and estimation much more difficult. A requirement should consist of one complete idea that can stand alone. It must be indivisible and irreducible. Essentially, each requirements must be independent of all others.

Complete Every requirement should contain a complete description that covers all attributes and includes enough narrative and all necessary attachments. Every requirement must describe in full the functionality to be delivered. Simply put, if the requirement is implemented as written, the market need is completely addressed.

Practical Systems and their environments have practical and technical limitations and capabilities. Make sure that the implementation of each requirement is possible and cost-justified under the current constraints. A good way to identify and avoid infeasible requirements is having a developer collaborate with the requirements analyst during the elicitation process.

Prioritized How essential is a requirement to a particular service release? If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. For more information, please see Task 8.3 Prioritize Requirements.

Unambiguous One of the most common and detrimental mistakes projects is the misinterpretation of requirements. If there are multiple readers of a requirement (which there usually are), they should all arrive at the same understanding. Besides the use of unambiguous language, ensure there is no jargon in the requirement that could be confusing.

Valuable Every requirement has to describe something that the customers truly need or express something required for compliance to an external requirement, interface, or standard. Does the source of the requirement have the authority to specify requirements? Check the source by tracing each requirement back to the origin (e.g., a use case, regulation, stakeholder, or system requirement). If you can’t identify the origin, is it really necessary?

Verifiable If a requirement is testable and verifiable, it is ready for inspection, demonstration, and testing to determine if it is properly implemented by the service. Use quantifiable measures and indicators of strength to provide evidence for verifications.



TASK DESCRIPTION

8.3Prioritize Requirements

It is good practice to categorize requirements based on priority because it ensures a sequential implementation of features based on their importance. The truth is that some features are more significant than others. Stakeholders need to prioritize requirements with the help and guidance of business analysts. This will help the project team make those tricky “trade-off” decisions that always come up at the last minute.

8.4Validate Requirement Bundles

At this point, you should check if the requirements in each bundle are consistent, structured, non-redundant, and traceable. These quality attributes, each explained on the next page along with individual requirement quality characteristics, ensure the safety of each bundle. You can also review the bundles as a whole, primarily checking for completeness and consistency. Refer to the attributes below to assess whether a product actually satisfies your needs as a stakeholder.

INDIVIDUAL QUALITY CHARACTERISTICS FOR TASK 8.4

Complete In Task 8.2 Review and Validate Requirement Specifications, you validated that each requirement had a sufficient amount of information. In Task 8.4 Validate Requirement Bundles, check to make sure there are no missing requirements. Missing requirements may account for missing features, resulting in missing stakeholder needs.

Consistent Ensure that every requirement in a bundle has the same level of detail. According to your preferences, you may or may not have a very detailed set of requirements. Make sure the project has a set standard for the level of detail in requirements. Also, ensure the language and level of concision is consistent, as well.

Structured Requirements in a bundle should also be structurally consistent. Set a standard for the sentence structure of requirement statements. For example, should the requirements begin with the words “The system shall...” or should they begin another way?

Non-redundant Once requirements have been placed into bundles, business analysts will be able to delete duplicate requirements. Help the team to determine which requirements are redundant and need to be removed.



Task Group 9.0 - Participate in Solution Evaluation and Acquisition Activities

Brief OverviewThere are several methods that can help make the process for evaluating and selecting a solution much easier. Many new project teams are making the decision to purchase a solution, versus building one. However, there are many things to consider before a team can make that type of decision. A business analyst should take the time to identify potential threats associated with highly specific instances in implementing a purchased solution. The most important concept to remember during this task group is that the team’s process for implementing a purchased solution has to match the value it could potentially add to your organization. As a stakeholder, when you are participating in solution evaluation and acquisition activities, you play an important role. Your contributions and suggestions may become business analysis deliverables depending on their relevance to the project and accuracy of solution ideas.

Participation Outcomes�� Defining and documenting short-list solutions

�� Analyzing your and other project team members’ short-listed solutions

�� Documenting your decision with your peers

TASK DESCRIPTION

9.1Determine Short-list Solutions

To determine short-list solutions, think about what features would be critical, desirable, or simply nice to have. You can rank these features and match them to specific, available solutions. In doing so, prioritizing the list of solutions is already complete, hypothetically. Additionally, you should conduct research for the features and benefits available within the tools that qualify as best choices to further examine the necessity of each solution’s major components and how they relate to business objectives. The viable alternatives will compose a short-list of possible solutions.

9.2Analyze Short-listed Solutions

Once the project team has compiled a list of possible solutions and components that are must-haves, business analysts can begin ruling out the alternatives missing the minimum criteria. Through this process of elimination, the team will most likely have to make some hard decisions. If they get really stuck with a handful of options, they will seek your advice as a stakeholder because you are an expert in that particular area of software. Analyze short-listed solutions as if each one represented the automated, future state of a process. Remember to look for flaws and problematic areas for each solution’s implementation.

9.3Document Decision

The software selection should be a group decision. If a group owns the results, versus one person, its implementation will go more smoothly. Unanimity is rarely achieved in this type of selection, but a solution with the most support from a vast number of stakeholder groups and project team members will undeniably represent the best option for the enterprise.



Task Group 10.0 - Participate in Project Lifecycle Events

Brief OverviewParticipating in project lifecycle events helps the project team confirm that the designed product or service fully addresses documented requirements. Requirements go through lifecycle events, like elicitation, inspection, development, validation, internal audit review, organizational change review, system and pilot tests, deployment, and measures of customer satisfaction. These events and their participants are defined by project needs. The goal of project lifecycle events is to track defects and help plan correction activities while verifying that requirements and project deliverables match business objectives. The key to participation is staying involved in project activities, and expressing concerns and suggestions whenever you find incongruities between planning activities and end results.

Participation Outcomes�� Reviewing details for requirement bundles

�� Viewing attachments in all lifecycle events

�� Creating your own test scenarios and test cases

�� Resolving defects through communication and collaboration

�� Preparing and administering change requests

�� Participating in project retrospectives

TASK DESCRIPTION

10.1Review Requirement Bundle Details

Bundles are groups of requirements that are packaged together and given to the development team to build a solution. Bundles usually equate to development iterations but can be organized according to a method that works for the project at hand. While reviewing bundle details, make sure the purpose and name of the bundle encompass the functionality represented by its list of requirements.

10.2Review Lifecycle Events and Supporting Attachments

Each bundle goes through events to ensure quality. Before a team or stakeholder can begin implementing an event (e.g., user acceptance testing), the event should be reviewed for relevance to the project. An event’s results are only as good as the design of the event. Attachments may provide detailed instructions and explanations for an event and should be read before committing to the event.

10.3Create Test Scenarios and Test Cases

Test scenarios are used in user acceptance testing as a means of requesting and classifying results. Test scenarios are collections of test cases, which are specific situations that must be tested by users to confirm successful implementation of the solution. Business analysts, subject matter experts, knowledgeable stakeholders, or QA staff may write test cases.



TASK DESCRIPTION

10.4Perform Tests and Verifications

Verification is the process of confirming that the designed and built product fully addresses documented requirements. Verifications consist of inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully address the requirements. When you are assigned the task of a verification via an action item in StakeholderPortal™, pay close attention to its associated requirements to make sure the feature’s functionality matches that of the requirement(s).

10.5Resolve Defects

An unverifiable requirement is a bad or unnecessary requirement. If you cannot verify it, then you cannot design it or build it. For example, take the requirement “The product must be reliable.” What is reliable? If you can’t define what reliable is, designers will not know either. If you can’t verify a requirement, you may not be able to convince your customer that your product is reliable. Resolving defects entails collaboration between stakeholders and the project team to remove any ambiguity, unnecessary features, and infeasible requirements from bundles and specifications.

10.6Prepare Project Change Requests

When requirement bundles have been approved or baselined by the project team, you can request and document any changes that need to be made to them. Three kinds of changes can be requested in a change request—requirements removal, modification, and addition. You should also specify what needs to change and, more importantly, why it needs to change. All change requests will be reviewed by the project team and only those approved will be later implemented.

10.7Participate in Project Retrospectives

A project retrospective should not be held as an afterthought without a defined, objective process. If retrospectives are held after a project is over, then the lessons learned should be applied to the next program or project. The sharing of perspectives leads to the understanding of what worked well, which is why stakeholder participation is so important. The discussion will provide the organization with opportunities for improvement and lessons learned. With increased buy-in from the people performing the work, a higher probability of achieving sustainable and permanent change will occur.



Appendix A: 12 Key Principles for Successful ProjectsThe same few complaints are commonly heard concerning IT departments within large companies:

�� IT projects are slow and expensive and do not deliver needed functionality.

�� IT does not understand the business.

�� IT is a black hole.

�� IT does not focus on the right things.

�� IT costs too much.

Enfocus Solutions has developed the list below of 12 key principles that should be followed to successfully implement a solution. Following these business analysis best practices will align IT with the business through delivering more successful projects that result in increased stakeholder satisfaction and that deliver more value to the business.

1. Build business analysis as an organizational capability.

2. Document the business problem before starting the project.

3. Reach agreement on solution scope before eliciting requirements.

4. Encourage collaboration between stakeholders and developers.

5. Address strategy, people, process, and technology.

6. Use iterative practices for both requirements and development.

7. Optimize the business process as part of every project.

8. Don’t forget the user experience.

9. Prioritize requirements for delivering business value.

10. Implement requirements-based project management practices.

11. Use requirements to validate and assess the solution.

12. Manage the enterprise portfolio to achieve business results.



Appendix B: Stakeholder Rights and ResponsibilitiesBefore a project is implemented, all relevant parties must agree on how they will work together. The following lists include the rights and responsibilities to which your project team should agree. If necessary, modify the list to fit your organization’s needs, but make sure all stakeholders and project team members are aware and in agreement.

Stakeholder Rights

1. To expect business analysts to learn and speak your language.

2. To have business analysts learn about your business objectives.

3. To expect business analysts to identify and understand their requirements.

4. To receive explanations of records that business analysts and project team members use as part of working with stakeholders.

5. To expect business analysts and project team members to treat you with respect.

6. To hear ideas and possible alternatives for stakeholder needs.

7. To describe attributes that make the product easy-to-use.

8. To be given opportunities to manage requirements for reuse.

9. To receive good-faith estimates from project team members.

10. To receive a system that meets your functional and non-functional requirements.

Stakeholder Responsibilities

1. To provide educational resources to the business analyst and project team.

2. To spend the necessary amount of time providing and clarifying requirements.

3. To be specific and precise about requirements.

4. To make prompt and timely decisions.

5. To respect the project team’s estimates and assessment of cost and feasibility.

6. To set priority of requirements.

7. To review and provide feedback regarding relevant records.

8. To communicate changes to requirements.

9. To follow the change management process already in place.

10. To manage your organization’s business processes and rules.



Appendix C: 6 Results of Bad Collaboration on RequirementsA recent survey of requirements management tools found that 91% of participants used word processing programs to define requirements. But large word processing documents are not easily reviewed, shared, or amended across the cross-functional teams of business and technology users involved in a project roll-out. Reviews of large text-based documents often result in missing requirements or undetected defects. In addition, feedback from stakeholders rarely occurs until the individuals are affected, which can be as late as during testing or development.

Instead, requirements development should be incremental, iterative, and collaborative. Stakeholders should be able to review requirements as they are developed and make comments when they feel that the requirements do not address their needs. Organizations should use collaborative tools like RequirementPro™ and StakeholderPortal™ to define requirements and not word processing tools that were never designed to develop or manage requirements.

The focus for effective requirements management needs to shift from document-centric to data-centric. Requirements should be managed in bundles that can be accessed, reviewed, and enhanced online. These bundled requirements should be more than just text. They should reference a wealth of data, including graphics, stakeholder comments, and clarifications, as well as information on regulations, competitive offerings, company policies, and business rules.

Failure to use the right collaboration tool for defining requirements will result in the following:

1. Missing or Incomplete Requirements

It is always best to elicit, analyze, and specify requirements in a structured fashion. It is very difficult to accomplish this using a general-purpose tool such as Word or Excel. Failure to gather requirements in a structured fashion often leads to incomplete requirements, which is one of the major reasons for project failure according to a study by The Standish Group.

2. Misunderstood Requirements

Good requirements are generally documented with more than text. Supplemental requirement documentation may include graphic illustrations, discussions, business process models, videos, and links or references to other documents. It is difficult if not impossible to capture this type of information in Word or Excel. Requirements are often misunderstood when they are not elaborated with additional types of information.



Appendix C: 6 Results of Bad Collaboration on Requirements Cont’d

3. Lack of Support for Requirements

Buy-in and active stakeholder support is essential for good requirements. People are reluctant to buy into a gigantic text based document when they did not author it. These large text documents are intimidating and overwhelming for most people; people provide a cursory review and reluctantly accept them, but do not buy into them. A collaborative tool works significantly better than a large text based document to get stakeholder participation and buy-in.

4. Incorrect Requirements

Requirements documents that are created using a general purpose tool such as Excel or Word are usually stored on the author’s computer, and are not accessible by others in real-time. This makes it difficult to share, discuss, validate, and track changes which frequently leads to incorrect requirements. When word documents are distributed, then the author loses control and almost always has a version control problem. Redistributing different versions of the same word document is error prone, awkward, and simply not practical for large teams. Requirement teams should be able to view, edit, and comment on requirements in real-time.

5. Lost Requirements

It is very easy for requirements to drop through the cracks when using general purpose tools like word processors. Critical requirements can be lost when the author forgets, is reassigned, or leaves the organization.

6. Inability to Support Iterative Development

Agile and other forms of iterative development require prioritization of requirements and organization of the requirements into a bundle that fits a development iteration. It is simply impractical to try to accomplish this with a word processor. The iterations are very short and the team must know what the requirements are before the iteration begins. This requires a data driven approach to requirements versus a document driven approach as the requirements are maintained in backlog, sized, and prioritized so they can be identified and planned for development iterations.



Appendix D: 10 Keys for Business Process Improvement Projects

There are some fundamental actions that project managers can take to ensure a successful result in undertaking business process improvement initiatives, as listed below. As a stakeholder, you should consider these key actions when determining your needs for improving business processes.

1. Choose the right business area to improve.

It is especially important that the first area chosen for action has the potential to return big benefits. Many successful BPI projects have been considered failures, simply because the return on investment wasn’t as large as initially anticipated.

2. Start with a problem statement, vision, objectives, and scope.

Organizations that treat BPI as something that their already over-stretched staff should simply fit in around their normal daily activities are not successful and typically nothing worthwhile actually results. Starting with a well-written clearly defined problem statement, vision, and project scope ensures that the project team and stakeholders have a common understanding of what is expected.

3. Use a Process Classification Framework.

For business process improvement initiatives, frameworks and reference models help support process analysis, design, and modeling activities. Starting with a process framework or reference model like the APQC Process Classification Framework can significantly accelerate these activities, providing analysis professionals with a strong foundation on which to build.

4. Use Agile methods.

The best way to manage a business process improvement project is to apply agile development methods. Break the project into small iterations that are fixed durations (2-4 weeks) of time. The work performed in each iteration should be prioritized and the project team should focus their efforts on high priority items first.

5. Gather ideas and input from both workers and managers.

It is simply a bad idea for BPI projects to elicit input and ideas only from managers. Managers play a role in a business process improvement project, but the really key people are the people that do the work. Listening to them keeps them involved and makes implementation and buy-in to change much easier.



Appendix D: 10 Keys for Business Process Improvement Projects Cont’d

6. Create a process map for the current and ideal state.

Process mapping is a method for thoroughly understanding a business process. Activities discovered through process mapping reveal linkages among organizational resources and the products and services produced and delivered to customers.

7. Benchmark the current process.

To reduce costs, increase revenues, speed delivery, or increase customer satisfaction, companies must apply benchmark data to their processes. Benchmarking should be closely linked to organizational value propositions, core values, strategies, goals, objectives, tactics, and actions. Benchmarking can help an organization achieve operational excellence.

8. Build knowledge management into the process.

A recent study by APQC, a best practice research organization, showed that to maximize the benefits of knowledge management, organizations must not only implement tools and approaches for knowledge sharing, but also embed those tools and approaches in the flow of employees’ daily routines.

9. Many problems can be solved without IT support.

It should be noted that often a well-designed business process supported with simple and inexpensive automation is much more effective than an inefficient business processes supported by large expensive enterprise systems.

10. Obtain organizational buy-in.

Without organizational buy-in, business process improvement projects are nearly always doomed to failure. Proper organizational involvement is one of the big keys to successful business process improvement.



Appendix E: Business RulesIn plain language, business rules describe policies for making decisions, formulas for calculations, definitions used in the business, and key facts and assumptions of how the business operates. Business rules exist whether or not you have an automated system. Business rules are owned by the business and not IT, and not every business rule is implemented in software. Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms. Below are some examples of some business rules.

�� A past due account is an account that has not been paid in full after 5 business days of the payment due date.

�� Past due accounts are subject to late fees, interest rate increases, and suspension of the customer’s credit limit.

�� Net sale is defined as the total sales price of an order before discounts, allowances, shipping, and other charges.

�� When an order is initiated via the Internet, sales taxes will be calculated by multiplying the net sale amount by the sales tax rate in effect in the state from which the order was placed.

Business rules are not software requirements. They exist outside the boundaries of software and therefore should be regarded as an enterprise-level asset. However, business rules often require that specific functionality be implemented to ensure that the system enforces or complies with those rules. Business rules may be implemented in a variety of ways. The easiest way to enforce a business rules is manually through a written policy or procedure. Business rules may also be implemented in software, database stored procedures, or a business rule engine.

A word of caution: Some people have made business rules so complex that it would take 20 PhDs to understand them. Business rules are not supposed to be complex; adding this amount of complexity simply destroys a much needed capability.

There has been much discussion of how business rules should be defined. At Enfocus Solutions, we prefer to group rules into five groups. View a chart describing these five types on the following page:



Appendix E: Business Rules Cont’d

TYPE PURPOSE EXAMPLE

Terms Terms are definitions documented in a glossary and used as the building block to define other business rules.

“A job is a set of services provided to a Customer at a specific location on a given day.”

Facts Facts are simply statements that are true about the business.

“Each estimate must include an amount.”

Constraints Constraints place restrictions on the actions the system or its users may perform.

“Each Job must be scheduled within 7 calendar days from when the Request is received.”

Action Enablers

Action Enablers are rules that trigger some activity under a set of specific conditions.

“If Job Completion Date is > 7 calendar days after the Job Request Date, apply 5% discount to the total.”

Calculations Calculations define the computational formulas or algorithms that generate new information.

“Job Discount = Job Total x Customer Discount.”

Business rules operationalize broader business policies. For example, a policy such as “provide discounts to repeat customers” is further clarified by stating a more discrete, atomic business rule: “If a customer orders products totaling $1,000 or more in any calendar year, then offer a 10% discount on each non-sale product item.” This business rule in turn is dependent on another, more fundamental business rule: “Each customer orders one or more products.”

As stated earlier, business rules are not functional requirements; however, business rules may strongly influence functional requirements. If business rules are not clearly documented, it is easy to miss them and can result in a significant amount of costly project rework. This is where you come in as a stakeholder. You have the knowledge necessary to analyze and capture business rules. Without your help, developers may guess wrong, and only during the latter phases of implementation will it be discovered that essential business rules have not been implemented. A lack of explicit focus on capturing the business rules creates rework and other inefficiencies.

Every organization has lots of business rules. Some organizations have tens of thousands. One of the first principles of the Business Rules Manifesto is to treat business rules as a first-class citizen of the requirements world. This means externalizing your business rules from all your documents and managing them on their own right. Business rules are embedded in business documents, such as agreements, regulations, and marketing materials, or in requirement documents, such as use cases and business requirements documents. For a business rules project, these business rules should be specified independently from the other deliverables. To learn more about the principles of the Business Rules Manifesto, published by the Business Rules Group, see the next page.



Business Rules Manifesto

The Principles of Rules Independence by Business Rules GroupArticle 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them.

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself—that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.



Business Rules Manifesto Cont’d

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly—for example in a rules engine—is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a rule’s truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. ‘More rules’ is not better. Usually fewer ‘good rules’ is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.



Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

Article 9. Of, By and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

Copyright, 2003. Business Rules Group. Version 2.0, November 1, 2003. Edited by Ronald G. Ross. www.BusinessRulesGroup.org

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged or extended in any manner.



Appendix F: Suggestions for Documenting Your Needs For many organizations, there is a recurring theme that is often heard when IT describes working with stakeholders. These are often reflected in statements such as:

�� Stakeholders cannot articulate what they want.

�� Stakeholders do not know what they want.

�� Stakeholders think they know what they want until the project team delivers to them what they said they wanted.

To alleviate these problems, Enfocus Solutions has created this document as a guide for stakeholders to define and document their needs. The RequirementPro™ and StakeholderPortal™ components of Enfocus Requirement Suite™ provide automated support for elicitation with features that facilitate needs documentation with the use of patterns, user stories, and scenarios. Any of these possible tools can be used for whatever methodology is followed by your organization. Depending on the type of need, choose the best method for entering your needs into StakeholderPortal™.

What are Stakeholder Needs?Stakeholder needs are the input to requirements elicitation, a task vital to the lifecycle of a successful project. Think of stakeholder needs as the rough drafts of requirements. As a stakeholder, it is your responsibility to communicate to the business analyst everything you need to achieve the proposed solution.

On a high level, there are two main types of needs: solution and transition. Solution needs address the necessary functions and qualities required to carry out a solution or project. These needs are analyzed by business analysts to eventually become the functional and non-functional requirements that will guide production to the end goal. It is vital that solution needs trace back to business objectives. Solution needs are commonly recycled and reused in different projects. On the other hand, transition needs are only required for a fixed amount of time. They facilitate the transition to the desired future state of business that will successfully deliver solution needs. Transition needs cannot be defined until a solution has been clearly determined.

Elicitation MethodsThere are several common methods for eliciting needs from stakeholders. Often, a combination of more than one method is used. No matter the type of method selected, all of the project’s stakeholder needs should be listed for the business analysts. Once the elicitation activities have been performed, you should enter all stakeholder needs into StakeholderPortal™ or have a RequirementPro™ user enter the needs on your behalf. Below is a list of various types of elicitation methods that might be used on a project.

Direct Entry of Needs by Stakeholders using StakeholderPortal™ One of the fundamental concepts behind RequirementPro™ and StakeholderPortal™ is the direct entry of needs by stakeholders. Using this intuitive approach to elicitation, a business analyst can save a lot of time and energy by having stakeholders input needs through the system.

Interviews Sometimes the best way to elicit detailed information from stakeholders is to perform one-on-one interviews with a prepared list of questions.



Appendix F: Suggestions for Documenting Your Needs Cont’d Focus Groups It is a good practice to assemble a group of typical users, users of a previous service, or even users of a similar service. We suggest that you gather their ideas on functional and non-functional characteristics for the planned service.

Joint Requirement Planning Sessions/Workshops (JRP) Facilitated requirements elicitation workshops that permit collaboration between analysts and customers are a powerful way to explore user needs and to draft requirements documents.

Surveys What if you need to collect a lot of information from many potential users in a small window of time? Well-designed surveys, or even questionnaires, are a viable means of familiarizing yourself with user needs.

Observation Karl Wiegers, an industry guru, calls this type of elicitation “a day in the life study,” in which an analyst observes users (or prospective users) perform their work with an existing service.

Documentation Review Many requirements can be extracted from review and analysis of documents such as business process models, existing user documentation, or rules and regulations.

Identifying Your NeedsNo matter which method you use to perform elicitation, there are some factors to consider before you can enter a need into StakeholderPortal™. The four main areas on which you should reflect are business problems, people, processes, and technology. The following list includes possible considerations to spark ideas for needs. Think about

�� Problems

�� What problems do you experience in your role?

�� What is the priority of the problems? Rank your problems in order of importance to you. You cannot say all are equally important—that will not help your project team. Focus on one problem.

�� What is the cause of the problem?

�� How do you currently solve the problem?

�� How should the problem be solved?

�� People

�� Are roles/responsibilities clearly defined?

�� Do people have the right skills to perform these functions?

�� Is the organization structure aligned to support the process?



Appendix F: Suggestions for Documenting Your Needs Cont’d �� Process

�� Is the business process well defined?

�� Are the business rules that govern the business process documented?

�� Are there standards that govern the process?

�� Do all performed tasks add value?

�� Does the current system support the process?

�� How is process performance currently measured?

�� How should the performance be measured?

�� Do process changes needs to be made?

�� Technology

�� How quickly do you need the system to respond?

�� How many users will use the system at one time?

�� What type of training is needed?

�� What level of security is needed?

�� What data is needed to make decisions?

�� What online response time is required?

�� How much data should be maintained online?

�� What reports do you need to perform your job?

Reviewing Your NeedsAs stakeholders needs are entered, business analysts will review and analyze them to create the requirements specifications. You can help your business analyst by making sure your needs:

�� Are free of implementation. They should state WHAT is needed, not HOW to provide it.

�� Describe all necessary functions and are sufficient to meet project goals and objectives.

�� Include all performance needs (think about timing, throughput, accuracy, precision).

�� Are realistic.

�� Can be tested and verified.

�� Fit within project scope.

�� Meet business needs—make sure you did not write a wish list.



Appendix F: Suggestions for Documenting Your Needs Cont’d

Documenting Your Needs Using StakeholderPortal™Every need should be documented using StakeholderPortal™. There are three primary tools for documenting your needs in StakeholderPortal™.

1. Need Patterns

2. User Stories

3. Scenarios

Each of these tools are explained in more detail in the sections that follow.

Before exploring the tools, it is important to note that each tool requires unique and specific information. However, each need also contains general types of information in addition to its unique details. The same fields are required for every need, whether you are entering a pattern, scenario, or user story.

�� Stakeholder Persona Enter the name of the stakeholder persona that is assigning the need. Every need must come from a persona. However, needs may be entered by RequirementPro™ users on behalf of stakeholders if they do not have access to StakeholderPortal™.

�� Source Specify the source of the need. In this field, enter from where you collected the need’s information. For example, is there a new regulation? Was this need decided in a meeting?

�� Name Each need should have its own unique, concise, and specific title.

�� Scope Statement Every need must directly relate to a scope statement already defined by the project team. If your need does not address a scope statement, it does not belong in the current project.

�� Status Needs should be labeled with their statuses. In StakeholderPortal™, you have the option to select draft, reviewed, mapped, omitted, or withdrawn. The default setting is draft.

�� Priority The priority level is one of the most important pieces of information that you will provide to business analysts when you create a need. It provides business analysts with an idea of the features that need to be implemented first.

�� Description Since the need’s name should be concise, in this field, provide all the detail necessary to make the need complete. Give time estimates if they are applicable.




Documenting Your Needs Using Need PatternsWhen entering a need in StakeholderPortal™ or RequirementPro™, in addition to scenarios and user stories, you have the option to use one of the thirteen patterns defined by Enfocus Solutions. A need pattern is a guide to writing a particular type of need. Patterns are created to explain how to approach each type of need, what to enter into each field, and what to worry about. Need patterns should consist of detailed and precise low-level information so that they help you write better needs by pointing out all the issues on which you should focus.

A General Need is a typically necessary project aspect that does not fall under any other need category and is essential for system operation. The other twelve more specific patterns are listed and described below. Refer to this list if you are unsure about what information to enter into each field.

Access Control Need A need specifying who is able to use and view information within the system.

�� User Registration Specify the necessary process for adding a new user to the system. For example, do new users have to go to a webpage to sign up or are they invited?

�� User Authentication Specify how the users are to be recognized by the system. For example, do they enter a user ID and password? How long should the password be?

�� User Authorization Describe the process for authorizing new users. For example, do they get set up automatically when they sign up, or does a department head have to approve them?

�� Access Approval Specify the individual(s) who determine the roles people have and the data that each role has access to. For example, who can CRUD (create, read, update, and/or delete) records in the system?

�� Audit Controls Describe the need for keeping track of when users last signed on and how that information needs to be tracked.

�� Standard List any business rules or industry standards that must be followed in the report.

Assumption or Fact Need A need specifying an assumption or fact of how an IT service or component operates.

�� Source Every need requires source information, as listed previously. An Assumption or Fact Need could be collected in a meeting or from a conversation, but the assumption or fact probably comes from somewhere else. Cite from where the need originates.



Appendix F: Suggestions for Documenting Your Needs Cont’d Compliance Need A need helping to ensure that any regulations from the business, government, or industry are documented and accounted for. A need that acts as a directive to address new internal procedures or Federal laws and regulations.

�� Version If the need is a result of an updated regulation or standard, state the name of the most recent version so that there is no confusion among project team members.

�� Standard List any corporate policies or industry standards that must be followed. Enter the name of the policy.

�� Purpose State the reason why your organization must comply. For example, if it is not a law, are you contractually obligated?

�� Citation Provide the page number or reference number associated within the standard. Be very specific in your citation. Provide the paragraph number to guide people directly to the standard to which you refer.

�� Attachments It would be also be a good idea to attach a copy of the standard to the need record so that all team members can easily refer to it.

Documentation Need A need outlining the purposes for creating a new document.

�� Purpose State the reason for the new documentation. For example, a support team for a new business might need a manual written to make their tasks easier to learn.

�� Content Determine and describe the content needed in the new documentation.

�� Format Describe exactly how the document needs to be formatted. Documents require different formats depending on the location of distribution.

�� Standard List any corporate policies or industry standards that must be followed in the document.

�� Availability State where the document is to be available. Will it be available on a web page or does a user have to download it?

�� Language Specify the language of the document. In large companies that span continents, this might be an important field.



Appendix F: Suggestions for Documenting Your Needs Cont’d�� Distribution

Describe the method of distribution, which will have an effect on the format of the document. For example, is the document intended to be published on a website or printed in handouts? Also, state to whom it is being distributed. For example, is it going to be delivered to managers only or every employee?

�� Confidentiality State whether the document should be distributed to all external customers or internal users only.

Operating Environment Need A need describing the environment in which the solution will operate.

�� Variants List any possible exceptions. For example, if you are creating a product that must operate in high heat, would there be any situations where it also has to be able to operate in a colder environment?

Performance Need A need documenting different aspects of performance, which is a measure of what is achieved or delivered by a system, person, team, process, or IT Service.

�� Performance Type Describe the characteristics that define the performance. For example, should the system be able to perform a function in a certain amount of time, or should it be able to handle a high number of transactions?

Report and Queries Need A need describing the outputs necessary for a successful solution.

�� Purpose State the reason the report is needed.

�� Report Content Provide an extensive description of the data elements that must be in the report. For example, if a report of all employee information is necessary, the report will require names, addresses, phone numbers, identification numbers, etc.

�� Format Describe exactly how the report needs to be formatted. Reports require different formats depending on the location of distribution. For example, will it be displayed online or printed? After answering that question, should it be portrait, or landscape?


�� Language Specify the language of the document. (For example, English, Spanish, Portuguese, etc.) In large companies that span continents, this might be an important field.

�� Sort Sequence Specify how the need will be sorted. For example, should it be alphabetically or by invoice number?



Appendix F: Suggestions for Documenting Your Needs Cont’d�� Selection Criteria

Specify whether there are any criteria needed for limiting data. For example, should the report just pertain to your region or just your stakeholder persona perspective?

�� Security and Privacy Specify whether there are any security or privacy concerns with the report.

�� Distribution Describe the method of distribution, which will have an effect on the format of the document. For example, will the document be published on a website? Printed in handouts?

�� Frequency State how often the report is needed. For example, will it be only on demand? Will it be scheduled monthly?

�� Target Audience Describe the audience that will be reading the report. For example, is it intended for managers? Transaction users?

Safety Need A need to ensure that the system carries out the functions that make it acceptably safe.

�� Level of Impact State the frequency of various failure modes of components of a system.

Security and Access Need A need allowing the user to document privacy issues that can affect the delivery of a service.

�� Threat If the need is a response to a possible threat, describe the indicators or warnings of that probable trouble.

�� Data Security State whether there is confidential data in the system and how to protect it. For example, how do you secure information about employee salaries and social security numbers?

�� Network Security Describe any necessary network security such as encryption.

�� Transaction Security State who is authorized to perform a transaction.

�� Standard List any business rules or industry standards that must be followed in the area of security and compliance that relate to this need.



Appendix F: Suggestions for Documenting Your Needs Cont’d Training Need A need allowing the user to document aspects and constraints for future training.

�� Number of Users Provide the number of users that are going to need training.

�� Delivery Mode Name and describe the best method for delivering training. Will it be in the form of online videos? Or will there be a workshop held?

�� Constraints It is important to note any budget, time, or technical constraints influencing the ability to train users.

�� Training Needs List and describe the areas in which users will need training to be successful with the new solution.

�� User Availability Determine whether the team can assume people will be available for training during work hours or if the training will have to be scheduled at another time. For example, will it have to occur during the weekend?

User Interface Need A need allowing the user to document what improvements or modifications need to be made to the user interface.

�� General Characteristics State the defining aspects of the required general characteristics of the new user interface.


�� Navigational Flow Describe the flow of the required user interface. You should list the best and most logical sequence of actions.

�� Presentation Describe how the user interface should be presented to the user.

�� Dashboard and Graphics Describe the need for dashboards or graphics. If there is a dashboard, describe what information and widgets need to be displayed.



Appendix F: Suggestions for Documenting Your Needs Cont’d Workflow Need A need that helps document workflow process and the changes that need to be made to it.

�� Process Owner Each workflow should have a process owner. Make sure to name the owner of the related process.

�� Impacted Name the stakeholder personas that will be affected by this need. Be descriptive and list the impact for each stakeholder persona, as well.

�� Interaction Describe the type of interaction anticipated between the process and the parties that are involved with it.

�� Access Approval specify that a particular action must be approved before it takes place.

�� Audit Controls Describe the internal controls that are needed to address audit concerns.

�� Standard List any business rules or industry standards that must be followed.

Documenting Your Needs Using User StoriesAnother method you can use when entering your needs into StakeholderPortal™ is to write user stories that depict your needs. User Stories are high-level narratives that define stakeholder needs from the perspective of a specific role. Unlike scenarios, user stories are short and do not describe a flow or sequence of steps. A well written user story should adequately describe the desired functionality, who it is for, and why it will be useful. As a stakeholder, it is important you enter your own user stories since you are the domain expert. A user story should contain enough information so that the business analysts and project team can produce a reasonable estimate of the effort to implement the associated need. However, the most important pieces of information should fit into one sentence. User stories should be short and must follow this model:

As a <specific persona>, I want <desired feature/issue resolution>, so that <benefit>.

Following this user story model will ensure you cover the three most important points that need to be conveyed to the project team developing the solution requirements. By naming a persona affected by the feature or issue, you are identifying the exact group of people impacted by the new feature or solution. The benefit is another key element, because it gives business analysts a clear picture of the value that will be provided by creating the new proposed feature or resolving the existing issue. The simple user story model also you think about who a certain feature is built for and why it should be built.



Appendix F: Suggestions for Documenting Your Needs Cont’d Although the user story itself should only be a sentence long, the record of the user story needs to contain enough information to provide the project team with context for developing requirements based on those needs. One piece of required information in regards to a user story is the record’s priority level. This information is vital to business analysts when they are developing and managing the requirements based on your needs. Remember that in StakeholderPortal™, one of the required fields for all needs is their priority. The priority level that you assign to a need will eventually affect the implementation of requirements. As a stakeholder, your opinion in this situation is very valuable. Again, remember that you cannot provide the same priority for all needs and user stories—the business analysts need this information to make an appropriate assessment.

In addition to a priority level, all user story records should identify the acceptance criteria for the need. If you cannot identify the acceptance criteria, the need is not testable; therefore, the need cannot be implemented. Acceptance criteria play a large role in the confirmation of understanding requirements, as well as in decisions about acceptance of iteration deliverables. Acceptance criteria are used to define the boundaries of a user story and should confirm when a story is completed and working as intended. The acceptance criteria should be written in the same simple language as the user story itself.

According to Agile expert Bill Wake, adequate user stories must always adhere to the acronym INVEST. When using this method for entering needs, always remember to ensure your user stories possess the following qualities:

Independent In a list of user stories, no concept should overlap. They should be able to be scheduled and implemented in any order.

Negotiable The feature that is addressed by the user story needs to be negotiable. The user story should provide the grounds for a conversation between stakeholders and the project team.

Valuable Simply, a user story should clearly provide value to customers.

Estimable You do not have to be able to create an exact estimate, but you should be able to provide enough of an estimate to rank the user story’s priority and schedule the story’s implementation.

Small Smaller stories tend to provide more accurate benefits.

Testable If a need or user story is not testable, that may indicate that the story is not clear or valuable.




Documenting Your Needs Using ScenariosThe last option for entering your needs into StakeholderPortal™, scenarios, are a real-world narrative of the process that accomplishes a specific user goal. Scenarios consist of the same type of information as user stories but at a more in-depth level. Scenarios point to a clearer definition of the path a user will go on, as well as the tools they will need to reach the end of that path. Scenarios are used to identify various kinds of flows and objects that are needed to accomplish a task by trying to understand how the user goes about solving problems. The purpose of a scenario is to get a clear picture of the user interaction with your system without including details of system actions or actual design. A good scenario will articulate the goal, process, and outcome contextually relevant to a type of user. Every scenario should include the same few elements:

�� User The name of the stakeholder persona that would perform the scenario

�� Setting The context of the scenario

�� Goal The desired outcome for the user

�� Tasks The activities the user performs to achieve the goal

�� Decisions A list of the choices that users make when presented with alternative options

�� Conditions The most common necessary condition to be listed is a bounded time frame

A major necessity of a scenario is its ability to be used and grasped by people without a specialized background. Therefore, you are able to utilize scenarios while completing design activities that involve user participation. As such, these scenarios are beneficial when used to convey an interaction from the point of view of an end user. This provides a common language that connects customer problems and technical solutions. Using scenarios also allows the more technical aspects of an issue to remain, appropriately, with the designers.



Appendix F: Suggestions for Documenting Your Needs Cont’d The focus of a scenario is on the user and the specific actions they need to perform to accomplish a goal. As a stakeholder, when creating scenarios, write them from the point-of-view of your persona. It is important to identify the personas that are the primary users of the system and understand their motivations and expected usage of the product. Once you have identified the role you are writing for, the next step in creating a scenario is to identify the setting or situation in which the scenario will occur. Refer to the problem statement, business objectives, and scope statements to get an understanding of the solution for which you are writing the scenario. Make sure the setting or situation you are writing about relates to the solution. Then, identify the possible tasks performed by a user to accomplish a goal, including all decisions with which they will be faced. When entering your scenario steps into StakeholderPortal™, you do not have to worry about sequencing them correctly on the first try. Our application provides you with the ability to re-sequence the steps in a scenario at any time so that the scenario always reflects the current or desired process. List each decision as its own step.

When creating a scenario for entering your stakeholder needs, remember the following do’s and don’ts of scenarios:

Do�� Provide information about the related problem, setting of the scenario, and goal. This provides context

for the situation in which users could really find themselves.

�� Fully describe the set of tasks and decisions the user might encounter within a single session.

�� Try to be so specific that the reader feels he/she can visualize the user’s interactions.

�� Focus on user actions and use simple language.

Don’t�� Specify what the system is doing.

�� Specify user interface components.

�� Provide multiple scenarios for a similar task.

�� Create small scenarios with a couple activities and a few decisions.



Appendix G: Balanced Scorecard: Business BenefitsBalanced scorecards can be used to analyze business processes, projects, and even the business itself. The following four diagrams depict business benefits organized according to the four dimensions of the balanced scorecard, which are the perspectives of the Customer, Finance, Internal Processes, and Learning and Innovation. In each diagram, possible measures of each benefit are outlined. As a stakeholder, consider these benefits and the possible ways in which you can measure them while you perform your responsibilities of providing stakeholder needs and reviewing records.

Customer Dimension

BENEFITS POSSIBLE MEASURES

Increase Sales �� Increase lead conversion rate

�� Increase average spend per customer

�� Increase repeat sales

�� Reduce percentage of dormant customers

�� Increase customer engagement ration

�� Increase average sale per transaction

�� Reduce percentage of sales lost

�� Increase opportunity success win/rate

�� Increase number of new customers

�� Increase number of items per purchase

�� Reduce percentage of neglected opportunities

�� Increase percentage of cross sell/up sales




Enhance Customer Relationship

�� Increase retention rate

�� Increase customer satisfaction index

�� Increase percentage of satisfied customers

�� Reduce customer complaints

�� Increase compliments

Improve Customer Service

�� Reduce customer wait time

�� Increase first call resolution rate

�� Reduce average response time to resolve complaint

Sharpen Customer Perception

�� Improve brand awareness

�� Increase perception of reliability

�� Increase perception of value

�� Increase perception of service/warranty

�� Increase customer loyalty rate

�� Increase perception of easy to work with

Increase Market Share

�� Increase market share percentage

�� Increase market awareness

Improve Marketing Effectiveness

�� Increase click through rates

�� Improve product visibility on shelf

�� Reduce amount of negative media coverage

Appendix G: Balanced Scorecard: Business Benefits Cont’d

Customer Dimension Cont’d




Increase Revenue �� Increase average sales revenue per agent

�� Increase gross margin as percentage of selling price

�� Increase percentage of online revenue

�� Increase average deal size

�� Increase gross sales

�� Increase revenue per employee

�� Increase organic revenue growth

�� Decrease deferred revenue as percentage of tool revenue

Reduce Costs �� Reduce customer acquisition cost

�� Reduce cost of office space per employee

�� Reduce average travel cost per employee

�� Reduce payroll to net sales ratio

�� Reduce SG&A as percentage of revenue

�� Reduce discretionary spend per FTE

�� Reduce average production cost per item

�� Reduce freight costs per unit received

�� Reduce freight costs per unit shipped

�� Reduce average unit cost

�� Reduce inventory holding cost (IHC) as percentage of gross sales

Profit �� Increase profit per project

�� Increase return on equity

�� Improve Return on Assets (ROA)

�� Increase EBTDA per FTE

ROI

Value

Asset Management

Cash Flow


Finance Dimension




Decrease Cycle Time

�� Reduce sales cycle time

�� Decrease cash conversion cycle days

�� Reduce average time to procure

�� Improve percentage of one-time deliveries

�� Reduce average time to market for new products

�� Reduce customer order cycle time

�� Reduce transit time

�� Improve one-time ship rate

�� Reduce supply chain cycle time

�� Decrease manufacturing cycle time

�� Decrease order fulfillment lead time

�� Reduce inventory lead time

Reduce Waste �� Reduce average number of modifications per order

�� Reduce ration of paper to electronic documents

�� Increase floor space utilization rate

�� Reduce percentage of orders requiring rework

Increase Throughput

�� Increase outbound calls per hour

�� Increase procurement productivity

�� Increase volume

�� Increase yield percentage


Internal Processes Dimension




Improve Quality �� Reduce rework

�� Decrease percentage of invoices disputed

�� Increase percentage of key stakeholders satisfied with suppliers

�� Reduce number of formal disputes with suppliers

�� Reduce number of defects

�� Reduce percentage of backorders

�� Increase manufacturing schedule adherence

�� Increase percentage of correctly picked items

�� Reduce order errors

�� Reduce delivery errors

�� Increase percentage of orders delivered by committed date

Enhance Controls �� Resolve audit issues

�� Resolve compliance issues

�� Improve internal controls

�� Reduce risks

Increase Efficiency �� Increase total logistic efficiency


Internal Processes Dimension Cont’d




Employee Satisfaction

�� Increase job satisfaction

�� Increase employee loyalty

�� Enhance communications

�� Reduce average span of control

Communications �� Enhance communications

�� Reduce average span of control

Recruitment �� Increase percentage of vacancies filled internally

�� Increase percentage of new hire retention

�� Reduce percentage of temporary contracted FTEs

�� Increase percentage of vacancies that followed internal procedures

Skills �� Improve skills

�� Reduce percentage of low performing employees

�� Reduce average time to competence

�� Improve percentage understanding of company strategy

Workforce �� Increase percentage of higher degree employees

�� Decrease employee turnover

�� Reduce absence rate

�� Increase average tenure per employee

�� Reduce percentage of sick days

Training �� Increase percentage of employees who have gone through training

�� Increase average training days per employee

�� Increase satisfaction effectiveness for training

Knowledge Management

�� Improve knowledge sharing

�� Improve knowledge capture

�� Increase usage of knowledge assets

�� Increase number of active communities of practice


Learning and Innovation Dimension



Appendix H: Business Process Analysis Checklist for StakeholdersAs a stakeholder, it is important that you review certain outputs during each stage of the lifecycle of a project. Refer to this checklist to ensure you have played your part in every necessary step of the process.

1. General

1.1 Has the business process analysis been completed?

1.2 Has the project sponsor approved the “To Be” business process?

1.3 Is the business process aligned with the organization goals, objectives, personnel, and culture?

1.4 Does the process comply with all applicable statutes, regulations, and internal policies?

1.5 Will the “To Be” process resolve the problems in the current process?

1.6 Has a business process diagram been prepared and included?

2. Business Rules

2.1 Have user roles, procedures, and business rules been established to capture the necessary information?

2.2 Have the business rules been documented in the RequirementPro™ business rules knowledge base?

3. Organizational Change

3.1 Do we have general agreement concerning the “To Be” process?

4. Performance Metrics

4.1 Have performance metrics for the process have been defined?

4.2 Have baselines for the performance metrics been defined and documented?

5. Performance Improvement - Process

5.1 Will the new business process improve our time to market?

5.2 Will the new business process reduce our cycle time?

5.3 Will the new business process reduce our cycle time?

5.4 Will the new business process improve organization efficiency?

5.5 Will the new business process improve organization effectiveness?

5.6 Will this improve our ability to manage objectively?

5.7 Will the new business process increase our predictability?



Appendix H: Business Process Analysis Checklist for Stakeholders Cont’d

6. Performance Improvement - Learning and Growth

6.1 Will the new business process improve our workforce capability?

6.2 Will the new business process help us attract or keep talent?

6.3 Will the new business process help our resource utilization?

6.4 Will the new business process help our company morale?

6.5 Will the new business process increase our management capability?

6.6 Will the new business process improve our employee/manager ratio?

6.7 Will the new business process help employee satisfaction?

7. Performance Improvement - Customer Satisfaction

7.1 Will the new business process increase customer satisfaction?

7.2 Will the new business process reduce the level of required customer support?

7.3 Will the new business process help us address specific customer concerns?

7.4 Will the new business process improve our ability to meet customer goals or needs?

8. Performance Improvement - Financial

8.1 Will the new business result in lower costs?

8.2 Will the new business process result in increased revenue?

8.3 Will the new business process help us increase market share?

8.4 Will the new business process improve our financial ratios?

�� Inventory turnover

�� Days in receivables

�� Return on net assets

�� Total Cost of Ownership (TCO)

9. Performance Improvement - Crosby’s Cost of Quality

9.1 Will the new business process reduce the Cost of Performance? (Cost to develop and provide a product or service, focused on those activities that plan and handle the work.)

9.2 Will the new business process reduce the Cost of Prevention? (Cost to establish and maintain processes for doing the work, training for those who perform the work, and other enablers.)

9.3 Will the new business process reduce the Cost of Appraisal? (Cost to review products and services under development, to be sure they meet requirements and conform to the processes.)

9.4 Will the new business process reduce the Cost of Nonconformance (Rework)? (Cost incurred to deal with defects in the product or service, including the rework of the product/retesting/review, etc., as well as the cost for customer support or help desks, payment of penalties and fines, and other costs associated with the effect of defects.)



INDUSTRY STANDARDS

APQC Process Classification Framework

The APQC Process Classification Framework, created by The American Productivity and Quality Center (APQC), is a taxonomy of standard business processes that can be customized for use in any business so that everyone in the organization has the same interpretation of enterprise operations. (www.apqc.org)

BABOK A Guide to the Business Analysis Body of Knowledge (BABOK) is the written guide to the collection of business analysis knowledge reflecting current best practices, providing a framework that describes the areas of knowledge. (www.iiba.org)

BPMCBOK

The Guide to the Business Process Management Common Body of Knowledge (BPM CBOK) is the intellectual basis for the Certified Business Process Professional (CBPP) certification. The current version of the CBOK represents a medium level of knowledge development. (www.abpmp.org/)

Cobit 5 COBIT 5 is the latest edition of ISACA’s globally accepted framework, providing an end-to-end business view of the governance of enterprise IT that reflects the central role of information and technology in creating value for enterprises. (www.isaca.org/)

ITIL The Information Technology Infrastructure Library (ITIL) is a set of best practices for IT service management that focuses on aligning IT services with the needs of business. (www.itil-officialsite.com/)

Lean Six Sigma

Lean Six Sigma is a synergized managerial concept of Lean and Six Sigma that results in elimination of the seven kinds of waste (classified as Defects, Overproduction, Transportation, Waiting, Inventory, Motion, and Over-processing). (www.isssp.com/)

PMBOK The Project Management Body of Knowledge (PMBOK) is a book that presents a set of standard terminology and guidelines for project management. It is process-based, meaning it describes work being accomplished by processes. (www.pmi.org/)

TOGAF TOGAF, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency. (www.opengroup.org/)

Appendix I: Industry StandardsRequirements Excellence Framework™ is designed to support and be compatible with the concepts and principles of industry standards. To keep project teams and their stakeholders up-to-date on the latest industry trends, Enfocus Solutions Inc. monitors all of the current standards. For more information, please visit their respective organizations’ websites. To become acquainted with these standards, refer to the following list.



Appendix J: GlossaryAction Item Project tasks assigned to project team members and other stakeholders through RequirementPro™.

Baseline/Baselining The action of creating a reference point. A baselined bundle of requirements must adhere to a stringent change management process.

Business Analysis Planning Alignment of a business analyst’s objectives with those of other project team members/relevant stakeholders.

Business Case A document providing justification for a project and its funding. A business case must provide enough information to make the decision whether to invest.

Business Objective A statement that an organization uses to define its goals and direction.

Business Process A collection of related, structured tasks that produce a specific service or product for a particular group of customers.

Business Process Analysis The activity of reviewing and altering existing business practices so they fit a new and improved process.

Business Rule Descriptions of the regulations that apply to an organization or enterprise.

Capability Gaps The difference between existing and desired operational abilities.

Change Request A document containing a call for an adjustment of a system.

Constraint Parameters based on the limitations of a project (e.g. deadlines, budget, etc.).

Component An identifiable part of an IT service usually providing a particular function or group of functions. See Impacted IT Service/Component.

Elicitation Various methods of collecting the requirements for a system from users, customers, and other stakeholders.

Enterprise Portfolio Management Information, relevant to the enterprise, that is collected outside of a project for reusability and referencing.

Functional Requirement A requirement that describes a function of the system or a component of the system.



Appendix J: Glossary Cont’dImpacted IT Service/Component Components and related existing services that represent indirect technology needed or affected by the solution.

Iterative Development A way of breaking down the events of software development into smaller parts. Design, development, and testing occur in repeated cycles.

IT Infrastructure Consists of the equipment, systems, software, and services used commonly across an enterprise.

IT Service A service provided to one or more customers, made up of a combination of people, processes, and technology. See Impacted IT Service/Component.

Graphical User Interface (GUI) A human-computer interface in which the user visually interacts with a computer using items such as windows, icons, and menus.

Lifecycle Event Defined project events that help plan correction activities while verifying that project deliverables match business objectives.

Need A description of an activity that the users must be able to perform.

Need Pattern A way to group and categorize needs for easier requirements definition.

Needs Analysis The process of analyzing the data gathered during elicitation to establish initial priorities.

Non-Functional Requirement A requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.

Production Cutover The transfer of the enterprise solution from the project team to the business.

RequirementCoach™ A high-value component to Enfocus Requirements Suite™ that provides hands-on guidance and examples for project success.

Requirement Excellence Framework™ The Framework on which Enfocus Requirements Suite™ was built, containing critical documentation and guides.

Requirement Pattern A method to specify and improve the quality of common types of requirements.



Appendix J: Glossary Cont’dRequirementPro™ A cloud-based business analysis tool that promotes collaboration, industry standards, and best practices.

Requirement Bundle A flexible way of organizing requirements based on iterations, features, or any other shared characteristic.

Requirements Development Methods to deduce, capture, and agree upon a set of functional characteristics that will achieve the stated business objectives.

Requirements Management Methods that support communication between the project team members and adjustment to changes throughout the course of the project.

Resource Dependency A relationship between two resources in which one resource cannot be used without another specific resource.

Retrospective A meeting held to examine and assess past events. In Agile development, retrospectives should be held at the end of every iteration.

Scope Statement A high-level description of a particular category of requirements. Solution: an improvement or process/service implementation that addresses a project’s problem statement.

Solution Analysis Methods to define, determine, and identify areas of strengths and weaknesses within the project’s solution.

Solution Assessment Methods to choose an existing solution that matches project objectives.

Stakeholder Anyone who has an interest in the project; project stakeholders are individuals and organizations that are actively involved in the project.

Stakeholder Analysis Methods to produce a shared understanding of project stakeholders between all project team members.

StakeholderPortal™ A component of Enfocus Requirement Suite™ designed to capture stakeholder needs through Web 2.0 collaboration technology.

Tag Management A categorization feature in RequirementPro™ that allows users to organize requirements and bundles with unique characteristics.

Test Case A specific set of conditions under which a tester may evaluate a test scenario. See Test Scenario.



Appendix J: Glossary Cont’d Test Scenario A set of test cases used to test the various possible outcomes of a specific hypothetical situation or scenario. Test scenarios are usually employed to test a lifecycle event. See Test Case, Lifecycle Event.

Traceability The ability to trace the life of a requirement, in both a forward and backward direction. It is important to have the ability to trace a requirement back to its source.

Transition Requirement A distinct class of requirements that exist within the project scope. Use Case: a list of steps, typically defining interactions between a role and a system, to achieve a goal.

User Acceptance Testing Tests conducted to determine if the requirements of a specification or contract are met.

User Experience The way in which a user perceives a product or service

User Interface The means by which the user and a computer system interact

Validation The process of confirming the completeness and correctness of requirements.

Verification The process of confirming that the designed and built product fully addresses documented requirements.

Waterfall Development A system of development which proceeds sequentially from the requirements stage to the implementation stage. Once the previous stage is complete, the next stage may begin. When one stage is completed, it cannot be easily reversed, much like falling water.