Chapter 3: Gathering and Analyzing Business and User Requirements


The gathering of business requirements is the process of defining and summarizing user workflow, processes, and rules into a written non-technical format. A requirement describes a condition or capability to which a system must conform. This can be either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. We take the information that was provided from the vision statement and use it to create a more detailed solution. The vision statement gives a general guideline to what the problem is that needs to be solved. Next, we have to figure out the details of the problem and create documents that can be used to determine how to solve the problem. During the envisioning phase, business requirements or high-level requirements are identified and analyzed. The planning phase will take those requirements and refine them further. The result is a functional specifications document. This document is the culmination of the business requirements for the solution. Requirements fall into four main categories: business requirements, user requirements, operational requirements, and system requirements. All of these requirements are covered in this chapter.

Certification Objective 3.01: Gathering and Analyzing Business Requirements

The first step to analyzing business and user requirements is to assess the current business perspective. This includes examination of the business processes, organizational structure, and social/political environmental factors. By examining this first, we can form a basic understanding of the common business context, rules, and organizational information.

This information is critical to understand before proceeding to the next step, which is gathering the business requirements. Gathering requirements is the discovery and processing of information related to the vision of the project. Finally, this information is applied to models and use cases to identify features and dependencies.

Scenario 3.1: RecruitmentService.net Case Study

RecruitmentService.net is a fictional online employment agency dedicated to serving employers and job seekers. RecruitmentService.net maintains information on 50,000 jobs and over 75,000 resumes globally, and has a monthly subscription client base. It is headquartered in Chicago and has 150 employees. The year 2001 resulted in annual revenues of $5 million. RecruitmentService.net is undertaking a major renovation of their system, and it has hired you as a consultant as it considers the merits of using Windows 2003 and the .NET framework for the next version of their system. It is interested in using .NET technologies in implementing the new solution. RecruitmentService.net is interested in examining the benefits of web services. Their top competitor attracts some 41 million unique visits each month with more than 800,000 U.S. job listings and more than 17 million. It also operates sites in 20 other countries in Asia, Australia, Europe, and North America. In 2001, this competitor also recognized annual revenues of $536 million.

The purpose of the renovation is to create an application that is easier to maintain and that will support multiple types of devices for viewing. The current solution does not support multiple languages, but will adapt to the needed changes.

The Existing IT Environment

RecruitmentService.net has ten web servers, all of which run Windows 2000 Server. The web servers are built on Pentium III 500 MHz servers with 512 MB of memory, which use IIS 5.0. The data tier consists of a two-node cluster of dual-processor servers running Windows 2000 Advanced Server and SQL Server 7.0. The RecruitmentService.net application was developed using Visual Basic 6, ASP, and SQL. Some of the business functionality is encapsulated into COM objects.

Business Process

RecruitmentService.net is completely dependent on its web servers. To maintain a competitive advantage, continuous availability of the entire site is required. Download speed of the HTML and ASP pages is critical to the business. Employers input their job postings to the web site, and the web development content approval team verifies the posting information.

The web development team then generates a job seekers database. Job seekers have read-only access to the database data. Network administrators maintain the SQL server. RecruitmentService.net would like to both simplify and improve the method by which information is exchanged with employers and job seekers. For example, they would like to make it easier for employers with multiple job openings to submit those listings in a batch, instead of requiring that they fill out a job posting form for each opening. They would also like to allow job seekers to read job postings and check on the status of applications via web-enabled cell phones and other wireless devices.

Interviews with Key Personnel

The following notes are from key stakeholders and clients for the application.

CEO Interview Notes

As the web site grows, so must the increase in performance to meet the needs of today’s user. We must also maintain 100 percent uptime. Though we have clients and users all over the world, up to now we have primarily served the English- speaking world. We are ready to begin expanding into other cultures, and we would like to test a Spanish version of our site within the next six months. This will be followed by a German version, and then a French version shortly thereafter.

Chief Technology Officer Interview Notes

The system must support scalability. Anticipating significant growth, RecruitmentService .net must be able to add new machines into its racks with minimal cost and no system downtime. The system needs to handle a peak of 1,000 new records of incoming data per hour. We had some requests from large clients, especially those who use non-Windows systems such as Unix and IBM mainframes, to improve the way data can be exchanged between systems. We recently had a large international client who posted 125 job descriptions, and because of incompatibilities in our system, we had to enter each job listing manually. We suspect XML may be a good solution to this kind of problem. Whatever solution we choose, we would like a database to be able to create data directly in a format we could share with our clients.

The following products will be implemented: Windows 2000 Server for the web tier, and Windows 2000 Advanced Server for the infrastructure and data tier. The web servers will continue to run IIS 5.0. We are open to whatever software and hardware we may need to add, if the switch to .NET makes sense and supports all of our intended functionality.

Three times a week, the IT department at RecruitmentService.net runs a stored procedure that attempts to locate the redundant accounts, deletes accounts that have been inactive for more that a year, and creates a list of users to receive certain targeted e-mails. This procedure may affect several thousand records in a space of a few minutes.

Exam Watch

The exam will have scenarios like this one containing information that will have to be deciphered to answer multiple choice questions and create diagrams.

Analyzing the Current Business State

Examination of the current and future business perspectives is the beginning phase of gathering information. It is necessary to understand the current perspective in order to create a solution that fits and solves all the needs of that particular business.

Analyze Business Processes

The processes of a business are defined as a number of different use cases, each of which represents a specific workflow in the business. A use case defines what should happen in a business process when work is performed. It describes the performance of a sequence of steps that produces a valuable result to a particular business actor. A business process should generate value for the business. Keywords that are essential to understanding what a use case is include:

  • Actor A representation of a role played by an outside object. This actor can represent multiple physical objects.

  • Use case A representation of a set of events that occurs when an actor uses a system to complete a process. A use case is generally a large process, not an individual step or transaction.

  • System boundary Represents the extent of responsibilities of the system being used. The use case should only represent the interactions of a single system.

There are several standard relationships among use cases or between actors and use cases. These are:

  • Constraint A specification for conditions and propositions that must be maintained as true in order for the system to be valid.

  • Extends Indicates an instance of use case B, and can derive functionality from use case A. An example would be a Recruiter class that extends specific behavior from the Accounts object.

  • Package A grouping of model elements, represented by a symbol that looks like a manila file folder.

  • Communication Defines how an actor participates in a use case. An actor can only use the Communication object to link to other objects in the diagram.

  • Interface Specifies the externally visible operations of a class, component, package, or other elements without specifying internal structure.

  • Note Diagram comment that has no semantic influence on the model elements.

Exercise 3-1: Create a Use Case Diagram

start example

This exercise illustrates a use case diagram that shows the actions of a job seeker.

  1. To open Microsoft Visio, click Start | All Programs | Microsoft Visio. Visio comes in three versions: Standard, Professional, and Enterprise. The Professional version comes with the Architect Version of Visual Studio.NET. The following image illustrates this process.

    click to expand

  2. Select BasisUseCaseStart.vsd. from the Chapter 3 CD-ROM code directory.

  3. When the file opens, you will see a boundary defined as the web site. There is one actor, which will be named in the exercise. There are four defined use case objects inside the boundary. The following illustration displays how the screen should look.

    • Accounts defines the master list of accounts to the system.

    • Account defines a type of view of the accounts to the specified actor.

    • Job Postings

    • Resumes

      click to expand

  4. To name the actor, double-click the Actor on the workspace. The following illustration shows the property window that displays. Change the Name property to Job Seeker.

    click to expand

  5. To add communication links between the actor and use case, drag and drop a Communication object to the workspace. The Communication object and others that will be used in the exercise are located on the left side of the screen under the Shapes window, just above the Model Explorer. The following illustration shown on the left displays the workspace where the objects we are going to use in this exercise are contained. Take the left end of the Communication object and drag it to the Actor. When the Actor turns red, drop the end. The following image shown on the right illustrates this process. Next take the right end of the Communication object and do the same for Account.

  6. While the line is still selected, double-click or right-click on the line and select Properties. A dialog box is displayed that allows the setting of options for the type of communication. The following illustration shows this window. In the Name property, type Create Account.

    click to expand

  7. Drag and drop two more Communication objects. Connect the Actor to the Resumes and Job Postings use cases. The communication link to Resumes should be named Create Resumes. The communication link to Job Postings should be named View Job Postings.

  8. Drag and drop an Extends object to the workspace. Connect the arrow end to the Account use case and the other end to the Accounts use case. The Account use case is actually an extension of the Accounts use case. The Accounts use case represents the master list of accounts for the system.

  9. To change what gets displayed on the diagram, the Connection objects might not be showing the names. To correct this, right-click on a Connection object and select Shape Display Options from the context menu. The following dialog box appears, which shows options to display or suppress specific values of a UML element view, such as showing or hiding attributes on a Class shape. Select the options that you want to display.

    click to expand

  10. If you chose the options shown in the previous illustration, the result should look like this:

    click to expand

end example

Building a Use Case Process

Some characteristics of a good business use case are to make sure that the description is clear and easy to understand for everyone. Each use case is complete from an outside (actor’s) point of view. Each use case is normally involved with at least one actor. Use cases are initiated by actors, interact with actors to perform the activities, and deliver results.

Let’s use a sample business use case to demonstrate these elements.

An example of a process is that of creating a new job seeker account. This process would entail the creation of a unique account name and password plus submission information for the online resume. The user could optionally create saved job searches for future examination.

Exam Watch

You will need to be able to identify business processes and accurately determine the order of the steps.

Business processes fall into several categories:

  • Common processes These would include tasks involved with accounting systems or human resource systems, for example. These are processes that exist in all businesses.

  • Industry-specific processes These are processes that only exist in a specific line of business. Reservation systems are a common industry-specific process in the airline and hotel industries.

  • Competitive processes These processes define how a business is unique compared to its competitors and customers. For example, RecruitmentService.net supports a single login process and competitor B does not support any quick login processes.

  • Support processes These processes assist with daily and maintenance operations. For example, RecruitmentService.net runs a process that cleans up account information three times a week.

Prioritizing Business Processes

After a list of business processes has been created and defined, they need to be prioritized. This will determine the order and construction of later requirements and development processes. Priorities will vary business by business, but there are some standard process review issues that should be considered and prioritized based on individual project needs. The following questions address the issues of revenue, costs, customer contact, business goals, and change:

  • Does implementing this process significantly increase or decrease our revenue?

  • Is there significant cost involved?

  • Does this process involve contact with customers?

  • Does it fit with our business model?

  • What is the impact of change on this process and does it have to change?

  • Does this process interact with or depend on other processes?

  • Does this process fall within the problem domain?

These questions will help define your core processes so you can determine if other processes are missing or need to be changed. A good business process description can be written by following these guidelines:

  • Describe the workflow, not just the purpose of the business use case.

  • Describe all possible processes in the business use case.

  • Describe only those processes that are inside the business.

  • Describe only relevant processes, not those that do not intersect.

You should be able to create a list of processes and activities that focus on high priority and high value. By prioritizing the processes, you can select the most critical processes in need of change. This also helps constrain the boundary and define the processes so there is no ambiguity.

Analyzing Personnel and Training Needs

Users are the individuals who will use the business solution in their daily work or who are affected by the business solution. There are three types of users: direct, indirect, and hidden. Direct users are individuals who will use the solution. Indirect users are people who do not directly use the application but are affected by it. Hidden users work with the solution, but they might not be easily identified. Because users fall into multiple categories, we want to create user profiles to help us determine the various impacts of the solutions being proposed. This includes end users who would use the solutions as well as people who are receiving information based on the solution, or who need to interact indirectly with the solution. For example, this could include managers who get reports from the solutions or third-party users.

Creating user profiles allows the requirements process to examine the needs of the various users, because it is very common that business goals are written in terms of customer expectations and needs. Users also have expectations and needs that need to be addressed. If these are ignored, the solution may fit the business goals and objectives, but fail because the users do not accept the solution. The organizational structure determines how user profiles are created. This allows the generation of an organization chart that can be used to determine user responsibilities and interactions. Examining the organizational structure helps determine which parts of the organization will be affected by the project. An example of information that would go into a user profile includes:

  • Definition of user (title or role)

  • User goals

  • Responsibilities

  • Likes and dislikes

  • Education level

  • Expectations and change requests

  • Computer experience

  • Knowledge of business applications and processes

From examining the case study, we can identify a few user profiles. There are the following actors: Administrators, Job Seekers, Hiring Companies, Sales, and Support Staff.

After creating profiles, we can then create a training assessment to determine which users need training and what type of training is needed. For example, the solution is to be developed with .NET technologies, so the developers will need skill assessments completed to determine the level of training needed to develop the new solution. This also helps the training group to determine staffing needs for performing training later.

Analyze the Organizational Structure, Both Current and Projected

While examining the business processes, another important factor is assessing the impact of the solution on users. To determine the impact, there are several artifacts that can aid in the examination of the current view: mission statement, organization charts, and marketing materials. Artifacts can be defined as documents or files that could consist of reports, screen captures, and user or technical documentation. After gathering this information, we can examine the organizational structure. For example, it is very common to have individuals responsible for performing actions that span several organization positions. By examining an organization chart alone, key information could be missed about the roles and responsibilities of such individuals.

Exam Watch

Organizational information is generally used to resolve conflicting information that can be presented in the case studies.

Analyze Vertical Market Position and Industry Position

To assess the vertical market position, a market analysis must be performed. This documents the marketplace in which the business organization currently competes and plans to compete. An examination for each marketplace would include documenting the business organization’s competitors and their competing applications. This includes an examination of:

  • Market needs

  • The size of markets

  • Market saturation

  • Market segments for each market segment identifying:

    • Profile

    • Demographics

    • Market channels

    • Market expectations

    • Market trends

    • Major competitors

When examining the competing businesses, much of this information is probably public and can be gathered from information at your local library or Chamber of Commerce. You will want to include a brief analysis of the business and a description of target markets and services. The next step is to examine the competitor’s product and service and detail their strengths and weaknesses. This gives you a view of your market.

From the case study, we can gather further information. RecruitmentService.net had a good year last year, but it must continue to expand and meet its customers’ ever changing needs in order to remain competitive. You can also gather that RecruitmentService.net is relatively small compared to its main competitor. The main competitor is in more markets and has a larger volume of resumes and job postings. Expansion of services and the market share will be imperative if RecruitmentService.net wants to remain competitive. This can only be accomplished with careful planning.

Analyze the Organizational Political Climate

Assessing the business political environment is another important feature of examining the organizational structure. The assessment is done to determine the key stakeholders in both the business processes and for the project. From the case study, there isn’t much information about the political climate. The examination of the political climate can also be helpful in identifying individuals who can help provide a positive influence for those who are more hesitant to accept the change. Assessing the political climate also requires looking at the historical perspective of the company and industry. This also helps with understanding how decisions are made within the organization.

Stakeholders are individuals or groups who have an interest at stake in the outcome of the project. Their goals or priorities are not always identical to those of the customer. Each stakeholder will have requirements or features that are important to them. Many of the project documents and processes involved informing stakeholders with the progress of the project and identifying features. Stakeholders can include:

  • Department managers of users who will be using the system

  • Department managers affected by the new system

  • Support staff affected by the system

Analyze Business Reach or Scope

The examination of the current reach and scope is an internal analysis. This analysis is the examination of the lines of business, target market segments, and products. This also includes taking the core business services and determining the key feature sets, target user groups, strengths, and weaknesses. This view in combination with the competitive market analysis gives a comprehensive overview of the business and its environment.

Analyze Current and Future Regulatory Requirements

Another factor in evaluating the business market is examining current and future regulatory requirements. Legal and regulatory requirements are defined by governmental law or regulation and must not be violated by the business. The business may face regulations at many levels. For example, the solution may need to comply with the Americans with Disabilities Act, making sure that users with disabilities can access information. An example of industry standards would be guidelines published by the World Wide Web Consortium (W3C). It defines standards that detail how the Web should work in different browsers and guidelines for compliance with creating accessible applications.

Preparing the Vision/Scope Document

At this point, we have gathered enough information to complete the vision/scope document. This started with the examination of the business process to identify key flows of the business. User profiles were created to determine the types of users and the level of training that will probably be needed to educate them. Competitive analysis was done to determine the key features of the competition and the position of the business in the market. Stakeholders have been identified, as well as regulatory requirements.

The approval of the vision/scope document is the ending milestone of the envisioning phase and begins the planning phase. The requirements gathered during the envisioning phase are high-level requirements and will be further defined in the planning phase. The vision/scope document approval means that the customer and the project team have agreed upon the direction of the project and features that the solution will include. A general timeline is also established. This is a living document; it will get revised and updated as the process continues.

The deliverables for the envisioning phase are as follows:

  • Vision/scope document

  • Risk assessment document

  • Project structure document

Analyzing Business Requirements for the Solution

The next phase is the planning phase. During this phase the project team works through the design process, creates work plans, develops cost estimates, and schedules for various deliverables. The planning phase is comprised of three levels of design: conceptual, logical, and physical. Each of these levels will be described in later chapters in more detail; in this chapter we will focus on preparation for these stages. This phase culminates with the completion of the functional specifications.

The initial phase of requirements gathering is to generate high-level requirements. These are created from the examination of the business and by obtaining input from key stakeholders. This level of requirements presents a 10,000-foot view of the solution.

Requirements break down into three types: business, functional, and nonfunctional. Business requirements can be considered why requirements. These requirements capture the highest level of answers to the question “Why are we doing this?” and should capture the fundamental reason for the project’s existence.

Functional requirements can be considered what requirements. For example: What is necessary for this process to work properly? These requirements capture the functionality that must be built into the system to satisfy the business requirements.

Nonfunctional requirements can be considered how or how well requirements. For example: How does is the specific process work? These are the technology-specific requirements. This includes items like capability, usability, performance, reliability, and so on.

All of these requirements also have the following general characteristics:

  • A formal statement of purpose that defines the scope of the task to be performed.

  • Validation criteria to determine if the task has been performed correctly. For example, this could be a screen that appears when the task is completed, or an external action that can no longer be performed.

  • Requirements may have extra characteristics that are needed to give a more complete description. Examples of these attributes are:

    • Requirement identification This can be used to trace the requirement when creating further documents.

    • Categorization What type of requirement is this? Examples include data requirement, functional requirement, nonfunctional requirement, or constraint.

    • Criticality to customer Could be high, medium, or low.

    • Criticality to user Could be high, medium, or low.

    • Frequency of execution For example, daily, weekly, monthly, or yearly, if applicable.

    • Implementation status Is this requirement not implemented, implemented, or preexisting?

    • Source How was this requirement discovered?

    • Volatility How often does this requirement change?

Scenario 3.2: RecruitmentService.net Case Study Requirements

Using Scenario 3.1 as a basis of information, identify the key requirement features.

Requirement 1.1 states that job seekers are able to create up to five saved job searches, which can be viewed or e-mailed at specified intervals. The preferred method is to e-mail results or the results can be viewed from the web site. This requirement is defined as a functional requirement. To determine the validity, a status check is done to determine if the requirement has been performed at the appropriate time. Since this is the most common way that the users will be receiving job listings, it is determined to have a criticality of high. The only preexisting condition is that the saved search must be properly formed to return results.

Requirement Identification

Requirement 1.1

Purpose

Create job searches

Validation criteria

Status check to determine is the job has been performed at the appropriate time

Categorization

Functional requirement

Customer criticality

High, because this the main way customers will receive information

Frequency of execution

User defined

Preexisting conditions

Property formatted saved search that returns results

Dependencies

Exchange servers
Valid search criteria

In Scenario 3.2, you can see an example of how a requirement from Scenario 3.1 would be defined. It gives a general description and specific information that gives further clarity about the requirement. Since there are different types of requirements that will need to be defined, the attributes or extra characteristics can change.

Identifying Business Requirements

The process of identifying business requirements starts with collecting information about your requirements. Applying these techniques requires the examination of the circumstances and type of requirements that need to be gathered. There are six information-gathering techniques that can be used: shadowing, interviewing, focus groups, surveys, user instruction, and prototyping.

Shadowing is the act of observing users. While observing a user’s daily routine and tasks, you can interview the user during their normal processes to gain information that could be overlooked in a more formal interview. This gives the user an opportunity to explain how and why their processes function. This provides two main benefits: gaining information from the user’s perspective and uncovering hidden information. Questions to keep in mind during this process are: What are the required tasks? What can be done to improve the system? What are the characteristics of the users? What activities are not performed daily? Who performs the tasks? Why are the tasks being performed? When are the tasks started and completed?

Interviewing is the act of asking a series of questions. Interviewing is a great way to get started in the requirements-gathering process. This is an opportunity to have one-on-one contact and helps generate information. This process does depend upon the skill of the interviewer and interviewee, and there can be potential problems with this method. For example, the wrong people could be interviewed. Another problem might be poorly planned questions that therefore result in answers that fail to provide the necessary information.

Focus groups are sessions with a representative group of users with similar user profiles. This is a valuable way to gather information because each user has their own perspective on their processes. In a focus group, you bring together from six to nine users to discuss issues and concerns about the features of a user interface. The session typically lasts about two hours and is run by a moderator who maintains the group’s focus. The group can provide more information about their activities and give a unique perspective on business processes. Early releases of the solution can be viewed by this type of group to allow feedback from a controlled collection of users.

Surveys are a way to gather information about specific subjects from a large group of people. This process allows users to anonymously contribute information that may not come to light via other techniques, such as user frustrations with policies and practices. A downside to this technique is that it can be very labor intensive to develop and administer.

User instruction is the technique of allowing the user to teach you about their processes. Some users may be uncomfortable teaching others and therefore may not like this technique. Identifying the experts in business activities can help you develop models for new processes, however, and this is a good way to examine user interfaces, artifacts, and user profiling.

Prototyping is the creation of a simple version of a solution. This helps users have a visual reference for processes that don’t yet exist or are difficult to explain. Prototyping is a good way to shadow a user in a controlled environment to help with the gathering of requirements. This technique is useful for verifying workflow processes and testing the integration of technologies.

Identify Dependencies, Both Inside and Outside the Company

Assessing internal and external dependencies can be done while using the requirements-gathering techniques described previously. Dependencies are determined by crossover of data from different systems and processes. Internal dependencies would be required information or processes that exist within the business. External dependencies, which are dependencies that exist outside of the system, can require extensive planning and integration. This could be a critical unknown that affects many internal processes.

By examining the case study, we can see that RecruitmentService.net will have dependencies on the types of ways that job submissions are generated from different customer systems. For example, Customer A has a human resource system that is hosted on a Unix mainframe. The customer’s human resource system can generate XML files that RecruitmentService.net can use to import multiple job listings using their listing specifications. The project team creates and notes requirements to fulfill these dependencies. They also notice that they have an internal dependency to their internal human resource system to track user account status and payments.

Identifying Features of the Solution

After starting the information-gathering process, two types of requirements will appear: features and extensibility requirements. Features define the functionality that the solution must deliver to be complete. These requirements are based on the business process needed, and how that process will interact with the user. Features are created by taking the initial business requirements and evolving them into functional and nonfunctional requirements. These requirements are grouped together to create features for the solution. An example of a feature from the case study would be security login, which is more specific than the security process.

Define Design Goals

Design goals are a list of categories or attributes of the solution that the team hopes to accomplish with design. The goals need to be stated specifically so they can be agreed upon by all team members in the planning stages. This list of design goals helps determine what features and requirements are important and helps resolve conflict between requirements. An example of a design goal is extensibility requirements, which specify the degree to which an application or component will be able to be enhanced in the future to meet changing requirements or goals. Design goals are used in conjunction with features. Using our case study to illustrate, an example of a feature would be that the proposed system will generate job search results. An example of the design goal of an extensibility requirement would be that the job search results can be sent to media other than e-mail, such as personal digital assistants and cell phones. See Table 3-1 for additional examples of design goals.

Table 3-1: Examples of Design Goals

Security

Extensibility

Maintainability

Reusability

Scalability

Manageability

Performance

Reliability

Availability

Integration with existing systems

Ease of development and deployment

An example of scalability for RecruitmentService.net is that their web site will be displayed in different languages in the future. An integration requirement from the RecruitmentService.net Case Study would define a set of standards for interfacing with external systems for exchanging data.

Define Data Requirements, Types, and Flows

Up to this point, we have looked at requirements for business processes, features, and dependencies. Now we need to examine data requirements. Data requirements specify a mandatory data type for an application, application domain, or component. The application domain is defined as a group of applications that work together to accomplish a specific purpose. The objective of data requirements is to specify data in terms of objects, context in terms of attributes, and relationships in terms of other data types. From our requirements discovery process, the team should have gathered a list and samples of reports, screen prints of entry screens, file outputs, or other similar data. This information is known as the artifacts of the project and, when combined with the understanding of the business processes, gives the team enough information to chart the definition and flow of data. Sometimes there is no data to use for requirements, but enough information can be gathered from the requirements that are defined. The case study indicates several data requirements. For example, with a new application, there is no preexisting data to use to determine requirements. You may gather requirements from artifacts like screen prints, drawings, or marketing materials.

Data types specify mandatory data about a business object. This is the beginning stage of looking at a data model of information. Typically your data types are defined by attributes, constraints or default values, and relationship to other objects. An example of this would be the customer.

A customer has the following attributes (among others): first name, last name, contact information, and payment method.

A data flow diagram is primarily for data discovery. The data flow diagrams can be used to convey information to help users, team members, and developers understand the various states that the data goes into. These states typically follow the business processes closely.

Exam Watch

Data flow is sometimes the only diagram used to determine the business processes.

Create Data Flow Diagrams

To understand how to create a data flow diagram, we need to define a few data flow diagram notation objects:

  • Processes transform data flow into outgoing data flow.

  • Data stores are repositories of data in the system. They are sometimes referred to as files.

  • Data flows are pipelines through which packets of information flow.

  • External entities or interfaces are objects outside the system, with which the system communicates. External entities are sources and destinations of the system’s inputs and outputs.

Using Visio, the default data flow modeling objects use the Gane-Sarson model. The other popular type of data flow modeling is DeMarco & Yourdon. Before using the Gane-Sarson model, there are some rules to understand, as follows:

  • All shapes on each detail page must be interconnected with data flows.

  • A process can’t originate data. It must be receiving data from an interface or a data store.

  • Names of elements must be unique between each type of object—that is, Data Store, Data Flow, Process, and Interface.

  • If more than one data flow exists with the same source and target, these data flows must have different names. For example, if you have two data flows going between a data store and a process, the data flows must have different names. The following illustration shows this.

    click to expand

  • Data flows must be connected to a process at start or end.

  • Data flows must be connected at both ends.

  • Data flows can’t be connected to the same object at both ends to create a loop.

These rules ensure that the model is valid. The nice thing about Microsoft Visio is that it will do this validation for you. Data flow diagramming is an important piece of the project because the project team and user can all share a common understanding of how the business processes function. Based on the Gane-Sarson model, we have the following diagram objects.

Process

Interface

Data store

Data flow

Exercise 3-2: Create a Data Flow Diagram

start example

The data flow diagram that we are going to create displays the data flow for a job submission.

  1. Open Visio and select File | New | Software | Data Flow Model Diagram.

    click to expand

    You will notice that your Visio application is divided into two parts. The section to the left is your stencils. This is where your selection of objects that can be drawn to the screen is stored for easy access. You should see the four data flow objects: Process, Data Flow, Data Store, and Interface. The section on the right is the workspace. This is where all of the objects that you select are drawn and displayed on the screen.

  2. You will now create the Recruiter interface object. To add this object, select the Interface object in the stencil area and drag and drop it to the workspace. Double-click it to enter edit mode for the object, then type Recruiter to name this object. You can use the formatting options to style your text.

    Exam Watch

    To add an object, select the object from the list of stencils and then drag and drop it onto the workspace where you want it.

  3. We are going to use the Model Explorer to create the rest of the objects. The following illustration shows what the Model Explorer looks like. If for some reason the Model Explorer window is not visible, click DFD in the menu, then click View | Model Explorer. You are working with objects under the title “DFD System 1” in the Model Explorer. To add an item (either Top Process, Data Stores, or Interfaces in the Model Explorer), right-click on the selected section and it will create a new object. To rename the new item, right-click on the appropriate item and select Rename, then type in the new name. The following table details the list of objects to be created and the name for each.

    Type

    Name

    Process

    Customer

    Process

    File Import

    Process

    Search Process

    Data Store

    Saved Search

    Data Store

    Job Submission

  4. Drag and drop the items from the Model Explorer to the workspace. Arrange the items, first by row and then left to right:

    • Row 1: Saved Search in top middle of workspace

    • Row 2: Customer, Search Process, Saved Search

    • Row 3: Recruiter, File Import, Job Submission

  5. To attach the objects together, we need to use Data Flow objects. A Data Flow object is basically a line with an arrow to show the direction. To attach objects, the ends are dragged and dropped on the appropriate objects. The object to be dropped on will turn red to show that it is the receiving object. The following table shows how the rest of the diagram will be connected.

    Name

    Originating Point

    Destination Point

    Submission

    Recruiter

    File Import

    Save Submission

    File Import

    Job Submission

    Request Data

    Job Submission

    Search Process

    Request Search

    Customer

    Search Process

    Return Request

    Search Process

    Saved Search

    View Search

    Saved Search

    Customer

    You are now finished. The diagram should look something like this:

    click to expand

In this example, we demonstrate in a data flow diagram how job submissions reach a job seeker. The submission goes into a file import process to a job submission data store where it waits for a job seeker to request information. The job seeker or the customer in the diagram can then query against available jobs to determine which to view. This process is now complete. To view the submission would be another data flow diagram to show how that process works.

end example

Using the combination of high-level requirements and data flow diagrams, the project team is now able to start defining in more detail functional and nonfunctional requirements that affect the users directly.

Exam Watch

In creating flow diagrams, you will need to be able to accurately determine the type of users so they can be associated with the right tasks.

Assessing User Requirements

Start this assessment by breaking down the processes into fine details and creating use cases. Use cases describe the process steps that an actor performs and the system responses in order to complete a specific business goal. Actors are defined as users or other systems that interact in the process.

Identity Use Cases

A properly created use case tightly displays the user/system interactions required to perform business processes, ensuring the system will follow the business needs. They also help provide traceability from business processes to business requirements to the implemented system. The case study use case would show several actors. Job seekers, recruiters, administrators, and managers would be surrounding an object representing the web site. When creating use cases, it is helpful to examine each actor and identify all tasks in the system with which the actor would be involved. For each actor, what information is necessary to perform the task? What use cases will support and maintain the system? What information must be modified or created in the system? The use cases define the responsibilities that an organization or individual completes on a specific process from start to finish. Use cases have some general elements in common:

  • Identifier Each use case should have an identifier to make it unique from other use cases.

  • Name Name the use case to identify what process is being described.

  • Overview description To quickly summarize the information.

  • List of actors The users or systems that participate in the process steps of a use case. This also is helpful for providing a quick view of responsibilities of an actor.

  • Triggers Define what event happened to cause the use case to start.

  • Required conditions Define what information must be available and/or state what the system should be set to.

  • Event steps Define the flow of the process and include the actor’s actions. The event steps should identify if steps are optional or conditional.

  • Expected outcome Identifies what the final result of this process should produce or accomplish.

    As the team processes the information they have gathered, these elements can be gathered from the requirements.

    There are several types of use case diagrams and documents that can be created:

  • The workflow process model displays how people communicate and coordinate together.

  • The system use case demonstrates how a particular system can be used.

  • The user use case model displays what a user can do, from a user profile perspective.

Another tool that is available are usage scenarios. Every use case must have at least one usage scenario. Usage scenarios bring clarity and completeness to the process. They are used as the main documentation for deriving test harnesses. Test harnesses are a mechanism in testing to create unit tests to make sure that all requirements are met and to prevent bugs in the software. There are two types of usage scenarios that are documented. Current-state usage scenarios document how users currently interact with business processes to successfully accomplish business tasks. This document helps identify the business processes needed to accomplish this task. This is a repeatable series of steps that can be discussed with the user to give a clearer focus.

The future-state use cases and scenarios need to be created to show how the finished solution will appear. When finished, you have two sets of diagrams to show the current state today and how it will look in the future. The creation of these types of diagrams helps define the requirements further and iterate through the processes to make sure that dependencies were not missed. It also gives the project team a clear way to validate the requirements and processes of the solution.

Examining user requirements involves more than looking at how the user will perform actions in the system. Another aspect is the examination of where the application will be used. Other requirements are necessary if the solution will be used in other countries and/or by users of other nationalities. This process is called internationalization. Internationalization is the process of writing applications in a way that makes localizing the application to a particular region as easy as possible. Internationalization aims to remove the burden of re-engineering an application when writing for multiple countries or regions. Locale is the definition of a language and a culture, geographical, and political region. In computer terms, the locale determines the culture settings that your system operates in.

Identifying Localization Requirements

Localization is the process of translating local specific application elements to a particular locale. These elements include textual elements, visual elements, and content. This also affects how money is handled unless the currency is universal, like the Euro for Europe. For applications it affects, localization resources need to be created during the development process. An example from our case study would be that it must be able to be viewed in English and Spanish. This locale setting is determined by the user’s browser.

Identifying Globalization Requirements

Globalization encompasses both internationalization and localization. This refers to the entire solution process from design through implementation and localization. Globalization requirements define how specific process should handle locale information. These requirements help identify which processes and other requirements need this further customization to allow for globalization. Depending on the level of globalization, the requirements process takes the base set of requirements and extends them.

There are some key assumptions that must be examined. For example, language and the various dialects are the most obvious and the easiest to overlook. It is very possible to have words with different meanings in the same dialect of a language. Cultural differences are the most subtle, but there is generally high awareness of the potential issue. For example, images or colors that may be perfectly acceptable in one country may be considered inappropriate in that same usage in another culture. Another example is how address and date fields in other countries use non-U.S. formats for information.

Business practices and processes differences could be obvious or subtle. As an example, Japan does not round taxes, where other countries use the standard “bank rounding.” Differences in computing environment are challenging because of specialized technical skills required to recognize and address them. In Japan and other Asian countries, for example, it is possible to have different types of encoding methods for different systems and data. Recognizing these factors helps with the gathering process when looking for differences and issues. An example of a globalization requirement could be to provide a library of locale-aware formatting and parsing functions for numbers, dates, and currencies.

From the case study, examples of localization, internationalization, and globalization would be the ability for the web site to support English, Spanish, German, and French. Each language would require specific types of routines to display appropriate types of currency and date information. Another requirement would be the fact that the application would have to use .NET’s features of localization resource files to hold language-specific information.

Identify Accessibility Requirements

Accessibility requirements specifies the degree to which the user interface of an application or component shall be usable by users with common disabilities, whether they are auditory, visual, physical, or cognitive. There are published standards for the minimum requirements for accessibility requirements for web applications at http://www.w3.org/WAI/. The primary goal of these guidelines is to promote accessibility.

Scenario 3.3: Accessibility for Web Sites

Mr. Lee is in the market for some new clothes, appliances, and music. As he frequently does, he is spending a weeknight evening shopping online. He has one of the most common visual disabilities for men, color blindness, which in his case means an inability to distinguish between green and red.

He has difficulty reading the text on many web sites. When he first started using the Web, he had thought that a lot of sites used poor color contrast, since to him many sites seemed to use similar shades of brown. He eventually realized that many sites were using color combinations that were indistinguishable to him because of his red/green color blindness.

After additional experimentation, Mr. Lee discovered that on some sites, the colors were controlled by style sheets and that he could override these with his own style sheets in his browser. But other sites did not use style sheets and sometimes he could not override those. As he continued to experiment with turning style sheets on or off, he realized that on some sites the sale prices were indicated in red text, which only became visible for him when he turned off the sites’ style sheets—when possible—and used his own.

After a half hour of browsing, Mr. Lee makes a number of online purchases. Because of increased readability, he buys mainly from web sites where he can use his own style sheets.

Example requirements:

RecruitmentService.net will use cascading style sheets (CSS) to control the color scheme for the system.

Here is a quick reference on how to make accessible web sites:

Element

Description

Images and animations

Use the alt attribute to describe the function of each visual.

Image maps

Use the client-side map and text for hot spots.

Multimedia

Provide captioning and transcripts of audio, and descriptions of video.

Hypertext links

Use text that makes sense when read out of context. For example, avoid “click here.”

Page organization

Use headings, lists, and consistent structure. Use CSS for layout and style where possible.

Graphs and charts

Summarize or use the longdesc attribute.

Scripts, applets, and plug-ins

Provide alternative content in case active features are inaccessible or unsupported.

Frames

Use the noframes element and meaningful titles.

Tables

Make line-by-line reading sensible. Summarize.

To check your work

Validate. Find tools, checklist, and guidelines at http://www.w3.org/TR/WCAG.

start sidebar
From the Classroom—Web Accessibility Design

Increasing discovery, access, and usability of your web site for all visitors is a major benefit from applying many of the WCAG 1.0 checkpoints. The proportion of people with disabilities can range up to 20 percent in some populations. A significant portion of those people with disabilities—in some countries as many as 8 to 10 percent of the overall population—can benefit from web sites conforming with WCAG 1.0.

David Waddleton, MCSD, MCT, MCP

end sidebar

Following these guidelines will also make web content more available to all users, whatever user agent they are using (desktop browser, voice browser, mobile phone, automobile-based personal computer, and so on) or whatever constraints they may be operating under (noisy surroundings, under- or over-illuminated rooms, a hands- free environment, and so on). An example of this for RecruitmentService.net would be to allow customers to access information from personal digital assistants (PDA) and receive notifications from other types of handheld devices.

Gathering and Analyzing Operational Requirements

Identify Maintainability Requirements

Maintainability requirements are a measure of the ease with which a software system can be maintained. It is defined as the ease with which a software system or component can be modified to correct faults, improve performance, or adapt to a changed environment. Maintainability requirements help minimize maintenance costs and organizational staffing needs. This is made possible by ensuring that minor defects in an application or component are easy to correct or enhance. An example of a maintainability requirement would be how long it takes to fix a severe, average, or minor bug or error. Maintainability should include updating the associated documentation and types of testing necessary for validation. It is also helpful to specify a specific maximum time to complete the task.

Identify Scalability Requirements

A scalability requirement is a developer-oriented functional requirement that specifies the degree to which the specified system shall be able to modify its existing capacities. Scalability requirements may specify the future ability to handle more simultaneous users or interactions, or to store more information in its databases. They can be specified as individual textual requirements or tables of related requirements. Scalability requirements are not the same as scalability mechanisms such as increasing the amount of hardware components, scaling of components, and performance tuning.

Identify Availability Requirements

An availability requirement specifies the proportion of the time that the solution should function properly. These requirements are defined in terms of the minimum average percent of time that the solution must operate without scheduled or unscheduled downtime. Because some aspects of a solution are more critical than others, the availability requirements are normally restricted to critical capabilities. Availability is directly related to other quality factors such as reliability, maintainability, and security. This requirement is not the same as an availability mechanism like redundancy, which eliminates single points of failure, software failure monitoring, software upgrades, and regular hardware maintenance.

Identify Reliability Requirements

A reliability requirement specifies the maximum permitted frequency of the failure. This provides assurance to the user that the solution will function properly for long periods of time and minimize user disruptions. Reliability requirements should specify the conditions to which they apply. Reliability is related to availability—if the reliability is high, the availability is also high, and there is a very short time-to-fix period.

Identify Deployment Requirements

Deployment requirements specify the ease with which a solution shall be able to be successfully installed in its production environment. A typical objective is to ensure that time and money are not wasted during the installation process. This ensures that the solutions have a clearly defined path for deployment. An example of a deployment requirement would be how long it takes for the support staff to install the required components on production equipment and time for users to perform the client installation. Deployment requirements can be validated during later stages by observing the performance of the solution and defining a reasonable limit on the average installation time. Deployment requirements are especially important when dealing with untrained users and customers. These requirements also affect your support staff when users and/or customers have to perform any of the installations.

Exam Watch

You will need to be able to identify all possible ways to deploy applications.

Identify Security Requirements

A security requirement specifies the degree to which a business shall protect itself and its sensitive data and communications from accidental, malicious, or unauthorized access, or destruction. The following list identifies objectives of the security requirements:

  • Identify users and clients

  • Properly verify identities

  • Ensure that users and client applications can only access data and services for which they have been authorized

  • Detect intrusion attempts by unauthorized users

  • Ensure that communications and data are not intentionally corrupted

  • Ensure that confidential communications are kept secure and private

  • Enable auditing of status and usage of security mechanisms

  • Enable solution to handle attacks

  • Ensure that system maintenance does not disrupt security mechanisms

Security requirements depend on the correctness of the solution, because implementing defects are often bugs that produce security vulnerabilities. The team must keep in mind that it is impossible to create a 100 percent secure solution. Security requirements create other type of use cases, defined as abuse cases. Abuse cases show user interactions that attempt to violate the security of the solution. This also helps create a set of validations that require testing to determine the level of success. These validations can be additional work flows and testing scenarios.

Some sub-requirements that can also be defined under the security requirements are: identification, authentication, authorization, immunity, integrity, intrusion detection, nonrepudiation, privacy, security auditing, survivability, physical protection, and system maintenance security.

Exam Watch

You will define security requirements as a general category, but you will need to be able to identify them to perform the proper actions.

Identification requirements specify the extent to which a solution shall identify its users and external applications before interacting with them. Identification is the process that the solution uses to recognize users. Basically, all access to the system must be identified in some way. This requirement can specify that the user have a valid system-generated ID or use some other type of identification method.

Identification requirements generally are used as prerequisites for authentication requirements. Identification requirements should not be specific in terms of security architecture, such as a name or public key. A very common requirement mistake is to specify the use of user identifiers and associated passwords with design-level login use cases. This requirement will not have enough detail to implement at this time; the specifics will evolve later on in the process. Identification requirements must be consistent with privacy requirements, which may require the anonymity of users. A very common cause of public key infrastructure (PKI) failures is the lack of agreement on organization-wide identification requirements.

Authentication is the process that a business enterprise or application uses to confirm an external identity with a specified level of confidence. An authentication requirement specifies the extent to which the solution shall verify the identity of users and external interactions. A sample authentication requirement could be to authenticate all of its users before accepting a credit card payment by having a valid login to the system.

If identity requirements are important enough to be defined, there must be authentication requirements. Authentication requirements are typically prerequisites for authorization requirements. Authentication and identification requirements are very closely related and can be grouped together.

An access and usage privilege of authenticated users and client applications is defined as an authorization requirement. This is the process of authorizing specific authenticated users and client applications to access specific solutions. An example of this requirement could state that each customer should be able to obtain access to all his or her own personal account information. These types of requirements depend upon the identification and authentication requirements. Authorization is generally granted to individuals or groups of individuals. There should be a limited number of administrators with permissions to grant or change authorizations.

Immunity requirements define how the solution shall protect itself from infection by unauthorized applications like computer viruses and worms. The main objective is to protect the data and application from being destroyed. An example would be to filter out data that is inputted from an unverified source. Immunity requirements should not be specified in terms of types of software, hardware, and architecture mechanisms. These types of requirements can be optional and defined by the operations center where the application is being maintained. An example would be that network security precautions will allow access only on certain communication protocols. Another example would be to keep critical operation systems current to disallow a lapse for external access.

Integrity requirements specify the extent to which the solution shall ensure that its data and communications are not intentionally corrupted via unauthorized creation, modification, or deletion. The main objective is to prevent unauthorized individuals and programs from corrupting communications between the solutions and its external users and interfacing applications. An example could be for the solution to prevent the corruption by unauthorized individuals and applications of all e-mails that it sends to customers and other external users.

Intrusion detection requirements specify how to detect and record attempted access or modification by unauthorized individuals or programs. These requirements depend on identification, authentication, and authorization requirements. An example would be to detect and record all attempted access that fails required identification, authentication, and authorization.

Nonrepudiation requirements determine to what degree a business application shall prevent a user or system interaction from denying participation in the interaction. The purpose is to prevent future legal and liability problems that might result from someone disputing their interactions. Some examples of nonrepudiation requirements would be to save the contents of an order or invoice, data and time stamps, or the identity of the customer.

Confidentiality requirements define how to keep sensitive data and communications private from unauthorized individuals and programs. Sensitive data falls into two categories. The first is personal information, such as user address or payment information; the other is private information about the business, such as trade secrets. The main objective is to provide access to information on a “need to know” basis. Insecure data can lead to embarrassing public relations, financial losses, and legal liabilities. This requirement normally leads to the creation of privacy statements that generally appear on applications. A privacy statement is a legally binding document that describes the personal information gathering, usage, and dissemination practices of a solution.

Survivability requirements define how the solution handles certain components being intentionally damaged or destroyed. An example would be that the application will not have a single point of failure. These requirements are critical for military applications. These requirements are different from robustness requirements, which deal with unintentional failures and errors.

Physical protection requirements specify the extent to which a solution protects itself from physical assault. The main purpose is to define how an application or business is protected against physical damage, destruction, theft, or replacement of hardware, software, or personnel components due to vandalism, sabotage, or terrorism. An example would be the data center shall protect its hardware components from physical damage, destruction, theft, or surreptitious replacement. Physical protection requirements are often prerequisites for survivability requirements.

A system maintenance security requirement prevents authorized modifications during maintenance to prevent the security mechanisms from being defeated. An example is the application shall not violate its security requirements during the replacement of a hardware component. These requirements may conflict with other requirements that may not allow taking the application or component offline during maintenance and the repetition of security testing.

Gathering and Analyzing Requirements for Hardware, Software, and Network Infrastructure

An interim milestone during the planning stage is technology validation. The team evaluates the products or technologies that will be used to build or deploy the solution to ensure that they work according to specifications. This is the beginning of a prototype of the system that can be used to show the success of the project. Another activity that must be completed at this milestone is baselining the environment. This is an “as is” discovery or audit of the current production environment that the solution will be in. This includes server configurations, networks, desktop software, and all relevant hardware.

Identify Integration Requirements

The integration requirements involve examination of the current environment and external systems and data that the solution will cross processes with. An example of this would be integration of a warehouse inventory solution and a SAP accounting system. Each is developed by a different vendor, and they must communicate together so that the cost of inventory and the processing of orders can be maintained. In this examination, the following questions must be asked:

  • What versions of the software are being used?

  • Is there an update available that gives functionality that will improve the integration?

  • What platforms do the solutions run on?

  • How is the integration going to be performed?

  • What technology is available for the integration?

  • What is the format of the data (XML, binary, or proprietary)?

  • What is the mapping between the interfaces?

  • Are there APIs available?

  • Is the interface a manual or automatic process?

Business events pass data between the different solutions. Business events are exchanges of messages or tasks that occur between different systems. Part of this integration examination is examining the data flow. There are different types of data flow requirements that need to be defined:

  • Conditional data Information that is required to make processing decisions. This data is extracted from business events.

  • Business rules The processing rules that are applied to the conditional data to determine the runtime execution path or the process.

  • Mappings The data transformation between the business events used to input and those used as output.

  • Business transactions The actual exchange of data.

  • Error handling Defines what exceptions can occur and how they should be handled. For example, suppose an order management application sends a new order event to a shipping application for processing. Suppose also that a shipping application runs in three separate offices as three separate instances. The order management application needs to notify the appropriate application instance based on the ship-to address in the order. In addition, the order management application needs to notify the billing application of the new order.

In this scenario, the data flow requirements would be:

Section

Result

Business Events

New order event from the order management application
Ship goods event to the shipping application
Send invoice event to the billing application

Conditional data

The state to which the order will be shipped. This information is extracted from the billing address in the new order event.

Business rules

The rule used to identify the shipping application instance to receive the ship goods event, which is based on the ship-to state/province in that order and the list of state/provinces associated with each application instance.

Mappings

The data transformation mapping from
New order event to the ship goods event
New order event to the send invoice event

Business transaction

Both the shipping and billing applications are updated successfully, or neither is updated. Compensating action for rolling back each application in case the other fails must be defined.

Error handling

If a data error occurs, such as an order is received with an invalid state/province, the order is flagged as incomplete and the appropriate parties are notified.

Exam Watch

You need to be able to identify how different systems will need to integrate and how the integration will happen.

This examination of the data flow helps determine the requirement objectives defined above and gives a complete description and guidelines for what needs to be accomplished with the solution integration.

Analyze the IT Environment

This is the creation of a high-level inventory of application, information, and technology resources, recording their location and analyzing and prioritizing their usefulness to business processes. The inventory of an organization can be divided into three categories:

  • Applications The systems that make up a executable software

  • Information The computerized data stores containing information, often accessed though a database management system

  • Technology The hardware, software, and electronic networks that support applications and data stores

This inventory also includes items that are planned or under development. The steps involved in this process are analyzing, identifying, and relating to business processes.

The analyzing of information starts by identifying major applications. The following information needs to be captured: name, locations, inputs/outputs, and implementation details. Other helpful information would be to capture key functionality, dependencies, and any perceived problems with these applications.

Identifying information stores should capture information such as entity name, attributes, and relationships. Some questions to ask and things to look for include:

  • What does the business need to know?

  • What are the industry requirements and standards?

  • What are your critical information needs?

  • What are your biggest data issues?

  • What are your functional data requirements?

  • What are your business process data and workflow requirements?

  • Are there statutory or legal constraints that affect your data and information needs?

    Exam Watch

    You need to be able to identify existing and future hardware requirements.

In analyzing this information you should identify the types of data and the types of information stores. There are different types of information stores, such as relational databases, indexed files, XML files, spreadsheet files, or other types of text files. The definition of information types based on applications used in the environment allows the IT organization to leverage its investment in existing technologies and products.

The identification of major technology involves collecting information such as whether it is hardware or software, name, vendor, version, location, connection type, and dependencies. This analysis takes the technology and classifies it according to use—for example, operating system, networks, servers, or workstations. It then determines the degree to which the technology is fulfilling metrics—for example, performance results compared to published metrics.

Some questions to ask and things to look for include:

  • What level of technology risk can you accept?

  • Do you deploy approved, standard technologies or buy ad hoc?

  • Do you understand how, what, and where technology is deployed in your organization?

  • Does your technology infrastructure map to your business needs?

  • What are the key technology trends affecting your IT operations?

  • Do you know what technical skills you need today and tomorrow?

After gathering this information, you can integrate it using the following steps. First, identify major applications used in the organization. Next, identify the major information stores. Determine which applications use which information stores. Identify the major technology components, and finally, determine which technologies support which applications and information stores.

Analyze the Impact of the Solution on the IT Environment

After analyzing the IT inventory in its current state, assessing the impact of the solution means comparing the difference between the future and current IT state. Does the solution reuse technology currently within the business? Is the solution too costly to implement or does new technology need to be purchased? Is another project going to change the current IT state? If the current state and the proposed solution are very different, it could evolve into another project just to get the current IT state to the level needed for the proposed solution.




MCSD Analyzing Requirements and Defining. NET Solutions Architectures Study Guide (Exam 70-300)
MCSD Analyzing Requirements and Defining .NET Solutions Architectures Study Guide (Exam 70-300 (Certification Press)
ISBN: 0072125861
EAN: 2147483647
Year: 2003
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net