Certification Objective 4.02: Transforming Requirements into Functional Specifications

After gathering detailed information about business and user requirements and business processes, the team can now proceed to the analysis of the information. This is the analysis of the created documents in the envisioning phase where the initial or candidate requirements are created. There are two purposes of the analysis. The first is to review user and business processes and activities. The second purpose is to document and model the context, workflow, task sequence, and environmental relationships of the business.

The transformation is performed in the following steps:

1. Synthesizing information

2. Refining use case diagrams

3. Selecting an appropriate application architecture for the solution

4. Creating a conceptual model of the application

Synthesizing Information

The synthesizing of information is the process of assimilating gathered data and interpreting the results. The team transforms the gathered data into meaningful information, by performing the following tasks:

• Identifying discrete pieces of information about what the user said and did.

• Recording the detailed flow of the tasks that the user performed.

• Identifying tools and pieces of information that were used.

• Identifying exceptions and alternatives that occur while the user performs the task.

• Modeling the relationship between business process, business systems, and users.

• Modeling the current environment in which the user works and any possible changes to that environment that might be required.

  Exam Watch

  The synthesis of information is an important skill for taking the architecture exam. You will have to take the information provided and sift through the information using these steps.

The deliverable for this step includes information models and current usage scenarios. The information models include the relationship between the business process, business system and users, workflow process, and task sequence. Also included are updated user profiles, candidate requirements, and detailed use case scenarios.

Restating Requirements

The candidate requirements at this point are groups put together that are now in need of further organization. This process is the restating of requirements. Restated requirements meet the following criteria: well-defined, concise, testable, and organized in a hierarchy of related requirements. A well-defined requirement is a complete sentence and typically, uses “will,” “may,” “must,” or “should” statements. Each requirement must address one item only. Each requirement should have specific inputs resulting in known outputs. Related items are grouped together to form feature sets. Requirements should be written in the language of the business. The following table is an example of restated requirements.

Requirement ID	Requirement
1.1	Must be able to analyze customer data
1.1.1	Must be able to analyze demographic data
1.2	Must be able to sort (descending, ascending) customers

Exam Watch

Requirement IDs are for tracking requirements from creation to implementation.

Categorize Requirements

After restating the requirements, the next step is to categorize them into user, system, operations, and business requirements. User requirements define the non-functional aspect of the user’s interaction with the solution. They help you determine the user interface and performance expectations of the solution in terms of its reliability, availability, and accessibility. A successful solution has completed all requirements and has passed user usability. Also identified in this step is the training required for users to use the solution. An example requirement would be that the user should be able to create an online resume in ten minutes. Another would be that the user should be able to complete a search with results returned within a minute.

Exam Watch

Categorizing requirements into groups allows you to focus on finding the requirements you need to focus on for the scenario questions.

System requirements specify the transactions that have been broken down to their simplest state and their sequence in the system. This helps the project team define how the new solution will interact with the existing systems. Critical dependencies are identified and managed by the team.

An example requirement would be for the solution to not require internal users to provide additional credentials other than the logged credentials from the corporate network.

Operations requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks. Key concepts addressed are security, availability, reliability, manageability, scalability, and supportability. An example requirement would be that the site design should include a system for managing the total system throughput and response time within the stated service levels.

Business requirements describe the organization’s needs and expectations for the solution. They define what the solution must deliver in order to capitalize on a business opportunity or to meet business challenges. Requirements are identified by considering the organization as a valid entity with its own set of needs from the solution. These requirements are generally high-level requirements and provide the context in which the solution will operate. An example requirement might be that the solution must be able to interact and communicate with other business processes, applications, and data sources.

Refining Use Case Diagrams

During the envisioning state, the use case diagrams specified high-level diagrams for the organization. The purpose was to present all of the use cases available. The purpose of refining the use case diagrams is to create use cases within the scope of the solution. This is performed by the following four tasks.

First, create subordinate use cases. Each use case is revisited within the scope of the solution. Each task associated with the use case is identified and modeled as subordinate use cases. All of the actors that perform the tasks are identified, and the relationship is identified between the various tasks and actors.

Second, create usage scenarios for each subordinate use case. This takes the original usage scenario and adds detailed information to it. Added to the usage scenario are the following items: a detailed scenario narrative, specifics of the basic course, specifics for an alternative course, and a description of the preconditions and postconditions.

Third, validate each use case and usage scenario against the original artifacts and users. This step helps determine whether any steps in the process have not been documented. The features list is then developed based on the requirements. Revisions to the feature list are identified by elaborating on the use cases, and any additions are validated by the customer.

Exam Watch

Remember to validate your use cases against the requirements and user responses.

Finally, refine the requirements with the validated use cases and usage scenario information. Because the validation is an iterative process, the requirements need to be checked to make sure that they are valid or need redefining.

Selecting the Appropriate Architecture

The selection of the architecture depends on the understanding of the services that the solution must provide. A service is defined as a unit of application logic that includes methods for implementing an operation, a function, or a transformation. Services can be either simple or complex. For example, services creating, reading, updating, and deleting information are simple. More information concerning services and application architecture will be covered in Chapters 6, 7, and 8.

Creating a Conceptual Model

The final step is the optimization and creation of the conceptual model. This process is the evolving of the solution into its final form. The optimization examines looking at the future state of the solution and examines the current state scenarios. More about this and the conceptual model will be covered in Chapter 5.