Tài liệu Module 6: Analyzing Information: Rationalizing Information doc

Module 1: Course Overview Module 4: Gathering Information Module 3: Characteristics of Information Organizing and Prioritizing the Current State Using Models Modeling Dynamic Behavior Re

Rationalizing Information

Module 1: Course Overview

Module 4: Gathering Information

Module 3: Characteristics

of Information

Organizing and Prioritizing the Current State

Using Models Modeling Dynamic

Behavior Review

Module 6: Analyzing Information:

Rationalizing Information Determining

Requirements, Wants, and Constraints

The use cases and usage scenarios that you first develop originate from a large amount of information that you collect about the business, its processes, and the business challenge Most likely, there will be redundant information that you will need to consolidate to describe the current state of the business in detail The next step in analysis is to consolidate and prioritize the use cases and usage scenarios to determine requirements, wants, and constraints

In this module, you will learn how to organize and prioritize use cases and usage scenarios to describe the current state from the business and user perspectives Then you will learn how to determine requirements, wants, and constraints from the business and user perspectives Finally, you will learn how you can use models to describe the dynamic behavior of business processes After completing this module, you will be able to:

" Analyze use cases and usage scenarios to describe the current state of a business

" Determine requirements, wants, and constraints from user and business perspectives

" Explain how models can be used to describe behavior in a system

" Use models to describe dynamic behavior in the business environment

Slide Objective

To provide an overview of

the module topics and

objectives

In this section, you will learn how to organize use cases and usage scenarios to eliminate any redundancies that may have resulted from the first pass at synthesizing information Then you will analyze the existing use cases and usage scenarios to describe the current state of a business

In Activity 6.1, you will organize and prioritize the use cases and usage scenarios that you developed in Module 5

Slide Objective

To provide an overview of

the topics and activities in

this section

Grouping by Actors and Actions

" Actors

$ Group use cases by identical actors

$ Group actor use cases by similar organizational roles

" Actions

$ Group use cases by identical actions

$ Group use cases by similar organizational processes

When you gather information, you use different information-gathering techniques with a large number of sources in the business Many of the sources you used had similar functions in the business For example, you may have looked at different artifacts that documented the company’s intranet Or using the Ferguson and Bardell, Inc case study, you may have interviewed several consultants or managers Each of these sets of sources can provide information that overlaps, resulting in duplication When you are first gathering

information, the duplication is normal, and it is part of ensuring that you collect all of the information that you need to describe the current state of the business The duplicate information also helps to validate the information received from various sources

After you begin analysis, you need to eliminate redundancies to determine the most important information to the business and the business challenge The analysis procedure performed in the previous module, in which you developed use cases and usage scenarios, represents the first step toward organizing information

The next step in organizing the information is to group the use cases and their usage scenarios by actors and by actions For example, in a training center example, you might group by similar actors, such as sales representative or instructor Individuals in a business may have different titles, but perform similar roles at different times Make sure that you identify the roles and group them together

When grouping by actions, look across use cases for similarities, such as multiple use cases that involve processing payments Different people will describe the same process differently You can determine similar actions by looking for multiple usage scenarios that are describing the same process

Do not eliminate the redundancies at this point; just group the use cases so that you can determine what overlap you have among the total set Again, you can also examine the redundancies to validate the information

Consolidating Redundancies

After you have grouped use cases and usage scenarios by actors and actions, you can begin to eliminate redundancies

Identify each distinct actor in the business and eliminate any redundant use cases or usage scenarios For example, for a sales representative in the training center, there may be use cases for processing a course payment by different credit cards, by debit cards, or by check Each use case would have its own set

of scenarios However, each use case describes a payment processing function

To eliminate redundancies, you would create a primary use case called “Process Course Payment” and group all of the existing usage scenarios under the one use case

Next, analyze any similar usage scenarios to determine the complete set of tasks necessary to describe the usage scenario Consolidate the tasks into one usage scenario to eliminate the redundant scenarios

As you are analyzing use cases and usage scenarios, you may find scenarios that describe instances of different use cases, but share a similar set of tasks For example, when processing a student’s course payment, the sales

representative may need to complete a process of recording the payment in a separate accounting database The sales representative completes the process no matter what the payment method Rather than repeat the process in each usage scenario, you may need to create a new use case, such as “Update Account Record,” that indicates the interaction of the actor with a different system

Slide Objective

To explain how to eliminate

redundancies among use

cases and usage scenarios

that are grouped by actors

and actions

Activity 6.1: Organizing Use Cases and Usage Scenarios

Organizing use cases and usage scenarios represents a necessary process of eliminating redundancies in large amounts of information Analysis is an iterative process in which you gradually create structure in the information provided by different sources

In this activity, you will group the use cases that you created in Module 5 by actors and by actions Then you will eliminate redundancies in both sets of use cases Finally, you will review the usage scenarios to determine if there are task sequences that should be consolidated as usage scenarios under a new use case After completing this lab, you will be able to:

" Organize use cases and usage scenarios by actors and actions

" Eliminate redundancies among use cases and usage scenarios

Slide Objective

To explain the activity

Constraints are aspects of the business environment that cannot or will not be changed They indicate the parameters to which the final business solution must adhere

In this section, you will learn how to identify requirements, wants, and constraints In Activity 6.2, you will prioritize the requirements and wants, and list constraints for the Ferguson and Bardell, Inc case study

Slide Objective

To provide an overview of

the topics and activity in this

section

Identifying Requirements

user feedback to document:

$ Inefficiencies, bottlenecks, and unnecessary steps

$ Redundant and ineffective practices and processes

$ Unnecessary paperwork

$ Dysfunctional policies

$ Undocumented new or changed business

$ Transport and delay time

The use case and usage scenarios that you organize and consolidate represent the current state of the business You need to examine this set of information to determine the requirements and wants for any solution to the business

challenge Requirements are what the user or business need for the new solution

When analyzing usage scenarios, look for problems that contribute to the business challenge For example, look at task sequences that contain duplication

or unnecessary work Compare task sequences that you observed during shadowing to the suggested task sequences that you find in artifacts such as user manuals or company policies Discrepancies may indicate that users are following old policies that negatively impact performance Conversely, users may discover more efficient task sequences that should become requirements in the new system

In addition to the usage scenarios, you will also obtain requirements by interviewing individuals or conducting focus groups Participants will tell you what changes need to happen for business processes to be more effective and efficient

Slide Objective

To explain how to identify

requirements in use cases

and usage scenarios

Identifying Wants

built new to optimally support key processes

$ Optimize the entire process

$ Integrate processes where possible

business perspectives

$ Improved productivity

$ Balance impact and technical feasibility

" Build a preliminary list of wants

Employees in a business work with business processes on a regular basis They have a continual opportunity to think about how a process could be improved The knowledge and experience that they develop provide both requirements and wants The requirements indicate what characteristics of the process are

essential to meet the goals of the business The wants indicate characteristics or features that would be nice to have in the process Wants are important, but not essential to achieving the business goals or resolving the business challenge Wants are based on the actual day-to-day experiences of people, but they represent an ideal state of how people would like things to be in the business Wants can indicate:

" How a process can be done more efficiently

" How a process can integrate more efficiently with other processes

" How a process can be accomplished with less strain for the individuals involved in the process

While you are gathering information, you need to follow up with individuals to determine if a statement they make about improving the system is a requirement

or a want If the improvement is not essential for completing the process or does not address the business challenge and the core values and vision of the business, then list it as a want

Working with requirements and wants is an iterative process During analysis, some requirements will become wants and some wants may better suit the business challenge and become requirements The project team must often assume a leadership role in determining requirements and wants and present their results for validation by stakeholders and users

Do not discount wants Though they may not have the same priority as requirements, they provide important information to the development team Wants represent potential features that make tasks easier for employees

Slide Objective

To explain wants as a result

of the analysis process and

to provide examples of

these wants

Listing Requirements and Prioritizing Wants

challenge

$ Business processes

$ Use cases and usage scenarios

$ Requirements

$ Interviews, focus groups, shadowing, and surveys

When listing requirements and prioritizing wants, identify what is most important to the users and stakeholders Typically, you will not prioritize requirements because they represent necessary features that the final business solution must have to address the business challenge To help determine requirements and wants, answer the following questions:

" What do people complain about the most?

" How many sources did you find that mentioned the same problem or needed

a particular process changed or added?

" How do the answers to the two previous questions relate to the core values and purpose of the business?

Conduct a complete review of the information that you collected that is relevant

to the business challenge and vision statement Analyze information from the business and user perspectives Each perspective may have a different set of requirements and wants

Analyze the information that you gathered and determine how often users requested similar features or improvements in current business processes Determine if there are conflicting requirements and wants and where the conflicts arise

List all of the requirements and wants, and then determine the priorities for the wants Develop a rating scale that will help you to group wants into major categories Identify levels such as 1–4 or A–D If you have too many levels, it will be difficult to determine which set of wants should be addressed first Not all wants suggested by people will end up in the final business solution By prioritizing, you help the development team determine what will be included in the first release of the product The development team can address the

additional wants with new releases

Slide Objective

To explain how to prioritize

wants

Finally, validate the list of requirements and the prioritized list of wants with users When you organize information and present it to users to validate, you can make it easier for users to reflect on any information that they gave you, as well as offer them a second chance to correct or verify it

business goals and requirements

Constraints indicate the parameters to which the final business solution must adhere They are aspects of the business environment that cannot or will not be changed Often, these constraints become design goals for the application

If you do not properly identify constraints for the development team, they may design a product that can never be deployed within the business Many development products fail because the information technology (IT) department will not deploy the solution if it violates security or other facets of the

enterprise architecture

Information that you collect from different sources regarding the four categories

of information will provide many of the constraints that you need to document Examples of possible constraints that you should document include:

" Network system architecture

" Security requirements

" Operating systems

" Planned upgrades in technologies

" Network bandwidth limitations

" Maintenance and support agreements and structures

" Knowledge level of support staff

" Characteristics of legacy systems List those constraints that impact the business challenge and the potential solution The development team will use the constraints to design a solution that optimizes the requirements while conforming to the parameters established

by the constraints

Slide Objective

To explain how to identify

constraints in the business

environment

Activity 6.2: Determining Requirements, Wants, and Constraints

In this activity, you will identify and prioritize requirements and wants Next, you will identify the constraints

After completing this lab, you will be able to:

" Determine the requirements, wants, and constraints from user and business perspectives

Slide Objective

To describe the activity

" Benefits of Modeling

and Usage Scenarios

" Activity 6.3: Using Models

In this section

Modeling represents another method of describing business processes Models indicate relationships and behavior among business processes, as well as the tasks that make up the processes

In this section, you will learn about the benefits of models and the different types of models available You will also learn about static and dynamic models that describe a system at two levels

In Activity 6.3, you will discuss how models can be used to analyze business requirements

Slide Objective

To provide an overview of

the topics and activity in this

section

Benefits of Modeling

One of the great difficulties involved in developing a solution to a business challenge is finding a common terminology to express the current state and proposed solutions One way to describe the current state of a business and a solution is through models

Models help to describe complex problems in a simpler structure for ease of communication Models also help to build consensus by making it easier to understand the business challenge and to determine what the requirements are and what information you might need to gather

As the business processes are modeled and adapted to reflect the requirements, you can build a model of the final architecture that describes the application or final business solution

Slide Objective

To explain the benefits that

modeling offers in terms of

understanding systems and

requirements