Analyzing Information

Analyzing requirements is one of the most critical activities of the requirement management process. The objective of this activity is to make sure you have very well formed written business requirements that everyone has agreed to. It helps to make developer ’s life easier. Once  Requirement gathering is done, next step is analyzing the requirements. Before analyzing the requirements, you should ensure and verify that you have enough information to indicate the current state of the business and product requirement. If any critical information is missing, you have to pay heavy price in the form getting rework in the later stage of the project. It will be real pain in the butt.

Sometimes, Requirement gathering and analyzing go hand in hand. As you review the requirements and analyze it, you will undoubtedly discover that you have more questions.

You then frame the queries or doubts regarding the requirements and take them back to the appropriate source for the clarification. This form of collaboration will continue throughout the life cycle of the project, although most of the information gathering and analysis will occur at the beginning of the life cycle.

When you think you have gathered enough information from the customer, you will have to determine what information is most relevant to the business challenge. You need to synthesize the information to create a detailed description of the current state of the business.

As you synthesize and analyze the information, you can identify any gaps that exist in the information you collected, and, if necessary, gather additional information.

 Use Cases and Usage Scenarios: 

After you have synthesized the information, you can develop use cases and usage scenarios to document the business processes and business requirement in more details.

 Use Cases: 

Use case shows the functionality of a system and how an individual interacts with the systems to obtain value.

The purpose of use cases are to:

n      Identify the business process and all activities from start to finish.

n      Document the context and environmental issues.

n      Establish the connections between business needs and requirements.

n      Focus users and development team

 

The Use cases provide the following benefits:

n      Provide context for the requirements

n      Facilitate common understanding

n      Provide the basis for usage scenario

n      Facilitate objectivity and consistency in evaluating user suggestions.

 Usage Scenarios: 

Use cases describe the high-level interactions between an individual and a system. Usage scenarios provide additional information about the activities and task sequences that constitute a process. Together, use cases and usage scenarios provide a description of a workflow process.

Example of an interview
Following is an example of an interview from the Adventure Works Cycles scenario that was introduced in Chapter 1, “Introduction to Designing Business Solutions.”
Summary of an interview with the territory sales manager We had a great year in sales this year. Our jobs have been a lot easier since the company equipped us with laptop computers and PDAs. We have been doing some forecasting for the next year, and we are starting to see a slow decline in sales, particularly if we continue to operate like we have in the past. The sales department has established a number of goals for the new fiscal year. The top three goals are (a) focus on our best customers, (b) use sales staff time more effectively, and (c) manage sales opportunities better.
We don’t have an easy way to analyze our customer base. Currently, customer data is stored in our systems, but there’s no easy way to retrieve the data and allow us to view the data in different ways. To better identify our best customers and why they are our best customers, we need a way to access our data and to be able to analyze it in a meaningful way.
Another problem we’ve experienced in recent months is in presenting our products and achieving sales in our foreign markets. Currently, all the information on our computers is written in English only. We need to store multilingual and multiregional information in the database rather than depending on the sales force to translate the information.
Our team needs to obtain the latest pricing information on a daily basis, and we should be doing this every day. Currently, the sales representative connects to the corporate network and downloads the new pricing list each day in the morning. However, the download process does not identify which prices have been modified for that individual sales representative. So the sales representative must download the entire list every morning. You can imagine how customers feel when they have negotiated a deal with us only to find out that the price was incorrect.
Another area that needs definite improvement is in our sales opportunities management. Employees are supposed to use our customer management system to plan, execute, and track sales and marketing strategy. In addition to that, sales representatives need to install a large application on their laptop computers and connect to the corporate network to use it. We want to be more mobile than that; we want to be able to access this information from a Web site. The information must be easy to access and meaningful for the sales representatives and the company; otherwise it doesn’t help anyone. We want to achieve the following goals with the new system: Minimize the amount of technical knowledge that sales and marketing needs to access the data, and allow the staff to obtain standard reports, generate custom queries, track promotions, and view customer segmentation information. In addition, we want this system to be flexible enough so that we can add third-party data sources and financial evaluation tools. No matter who views a particular customer’s information, that individual must get a clear, unified view of the customer and the customer’s relationship with us.

Example of a use case diagram: 

 Draft Requirements Document:

Draft Requirements Documents with additional informations:

Actor Catalogue:

Actor is a entity which interact with the system. eg Sales Manager, Accountant, Vice Preseident etc. Actor Catalogue contain information about all the actors used in Use Cases. Actor catalogue contains

information like Actor name, responsibilities, source of this information etc.

For example, in the given exampleActor Catalogue, a sales representative is an actor whose responsibilities include establishing contacts with customers within a geographic region, and acquiring knowledge about products and their specifications and information about all the customers. The source of this information is tracked in case you need to go back to the source for additional information or clarification.

 Business Catalogue:

The business rules catalog is a living document that lists the business rules for a solution. The business rules catalog is a predecessor for the requirements document. This document is created early in the design process, when the team gathers information. This document, like the actors catalog, is meant only for the team and is typically not provided to the customer.