Enterprise Architecture, Segment Architecture & Solution Architecture

What is an Enterprise Architecture?

There are a variety of definitions for an enterprise architecture. However, a general description might define an enterprise architecture as a framework that results in the production of a set of documents that define the enterprise. The enterprise architecture information collected includes the core mission areas, goals, principles, business capabilities/functions and processes. In addition, business solutions and technology are planned and implemented to support business capabilities and processes--no business decisions are made on a whim.  A properly defined enterprise architecture should, at a minimum, provide information that allows an enterprise to do the following:

1. Purchase the right tools and maximize their use through stated needs, services provided by the business, strategic objectives, etc.

2. Understand shared services/processes to request and purchase tools that are implemented for the greater good.

3. Identify opportunities for process improvement to resolve bottlenecks (through automation or process re-engineering), retire redundant systems, identify and resolve threats and risks, and maximize opportunities. 

EA Resources

Enterprise architecture is a topic that many organizations (federal, commercial and non-profit) have touched on. A few of the resources available online are listed below:

• The Federal Segment Architecture Methodology (FSAM) -  FSAM includes a toolkit developed by the federal government. It provides steps along with the inputs/outputs to be collected and documented for each step. FSAM also provides templates to plan the project and document information collected from requirements gathering sessions. The templates also provide direction to define the target enterprise architecture. FSAM includes insight on recommended analytical activities and useful matrices that should be created. 
• Federal Enterprise Architecture (FEA) Practice Guide - The FEA Practice Guide can be used to learn about segment architecture including what a segment architecture is, how to define a segment architecture and who should be involved in the project. It provides the ability to understand (at a high level) the steps that should be used to understand the agencies business problems, needs, strengths & weaknesses, etc. The guide presents understandable, best practices that provide the direction needed to implement an architecture in a way that supports federal government-wide initiatives including data sharing.
•  Department of Defense Architecture Framework (DoDAF) - The DoDAF website provides a wealth of information for anyone seeking to gain expertise in defining a framework for a Department of Defense agency. It outlines the models that should be created; the roles needed to define and implement the DoDAF; specifications and matrices to be created; along with the level of detail that should be captured.

The above list is far from all inclusive; however, it does present enough information for even a novice IT professional to conclude that EA is a hot topic. Organizations that accurately define their enterprise architecture and use the information to make decisions will save money and operate efficiently.

Segment Architecture

As previously mentioned, the FEA Practice Guide provides an overview of EA concepts. But most importantly it provides best practices for implementing a segment architecture. It references the FEA Consolidated Reference models and how the BRM is used to define the core mission areas (vertical segments) and the supporting business services (horizontal segments) and enterprise services implemented across the agency to improve collaboration, knowledge, etc. The FEA Consolidated Reference Models are discussed in the following section.

FEA Consolidated Reference Models

The FEA framework includes 5 key models. These models include the Business Reference Model (BRM), the Performance Reference Model (PRM), the Service Component Reference Model (SRM), the Data Reference Model (DRM) and the Technical Reference Model (TRM).

Business Reference Model

The BRM provides four levels, enabling enterprise architects to break the agency into segments by navigating from the BRM Business Area (pertaining to Services for Citizens) to the LoB to the lowest-level sub-function (or segment). The Mode of Delivery component enables agencies to map the delivery mechanism. For example, the "General Retirement and Disability" would map its Mode of Delivery to (205) Federal Financial Assistance: 081: Direct Transfers to Individuals.

Not all agencies have segments under Services for Citizens. GSA, for example, will not map LoBs to the Services for Citizens Business Area since their customers are federal government agencies. However, most other agencies will find the sub-functions needed. 


The BRM also includes the Support Delivery of Services Business Area and the Management of Government Resources Business Area. These two business areas are for agency support LoBs. Both are used to identify business services supplied across the enterprise. The business services are listed horizontally while the Services for Citizens segments are listed vertically. This provides a tool architects use to identify LoBs that perform the same business functions. For example, an agency may have LoBs to manage policy for Health Care, a separate LoB manage policy for Business Industry Development and Conservation, and different LoB manage policy for Marine and Land Management. Collecting information about the business functions helps identify policy work the LoBs do that is the same. This enables stakeholders  to agree on one target process to do the same work the same way. And, the stakeholders can agree on a single system to support the work. This one act helps streamline business operations. Hence, all three groups are not separately managing processes with each making changes to the process when change is required. Instead, one LoB manages the process, makes the change and provides the updated process to all LoBs.

Once the BRM sub-functions are identified; they can be used as segments to map the segment architecture data--starting with the business architecture components. The business functions performed by the segment; and, the business processes used all provide a picture of how the work is currently done. However, the business problems stated point out that improvement is needed. If an industry best practices analysis was performed--a look at the principles,  practices and tools adopted by "top performers" is insightful. Hence, the EA team already has ideas on what the "target" business architecture should look like.

Performance Reference Model 

The PRM includes performance measurement areas, measurements categories and measurement groupings that map to the BRM LoB segments.  Agencies must define the indicators that will be used to measure performance for the IT Investment/Program, etc.

Service Component Reference Model

The Service Component Reference Model (or SRM) provides a tool to define reusable software components without referencing a technology. This enables agencies across the entire federal government to define components that would ultimately enable them to share more than just data. When building a model from which to categorize the organization, the SRM presents the categories that can be listed as Enterprise Services. Architects can then easily identify services to be implemented across the entire enterprise.

The SRM is also used to define reusable software components. A list of software is used to break down the business applications into a list of reusable software components. The related capabilities are also added and associated with the supported business functions.  Once the list is completed, a matrix is developed. The matrix shows the software components that provide the same capabilities. Agencies can then eliminate costs by decommissioning redundant systems. In addition, the tool can be used for governance. As change requests are received, the capabilities requested can be queried against the software component capabilities data-source. If a match is found, the Governance Board can then request further justification as to why duplicate capabilities are being requested.

Data Reference Model

The Data Reference Model (or DRM) provides a tool that is used to classify data. The primary objective of the DRM is to provide a framework that allows data to be shared across an agency or with a Community of Interest. The DRM calls for data to be classified by Subject Area and Information Class. Once the data is standardized and organized, it can then be reused and shared.  To share the data, the Data Description (or Entity) is associated with a Data Exchange Package (DEP) that includes not only the data; but also relevant information such as header/trailer information specific to the data (or payload). In addition, provider/consumer information and interface that will access the data is also provided. Documenting the data includes associating it with the relevant information system(s) and segment(s).

Technical Reference Model

Until the Technical Reference Model (or TRM) is used; the SRM is not associated with any technology. However, to reflect the true enterprise; the service components must be related to technology. The TRM provides the ability to describe technology-specific components that may include code-behind classes (i.e., Visual Basic .Net (VB.Net),  Active Server Pages .Net (ASP.Net), etc.) the service; but also the technology used to deliver the service. Business logic services can be described as Enterprise Java Beans (EJB), Web Services for Remote Portals (WSRP), etc. Data access layer data providers, relationship to mechanism presentation delivery--whether it be a web browser or other mechanism. The technology is also associated with the segment to provide a complete picture of the technologies providing the support.

Federal Segment Architecture Methodology (FSAM)

FSAM provides the guidance needed to develop artifacts in support of a segment architecture project. There is a rapid approach that can be used to shorten the length of time it takes to document the Business, Information, Application and Technology architectures. The FSAM artifacts include fields that request elements from the FEA Consolidated Reference Model for example the Segment Code (taken from the BRM) is requested. The FSAM Business Function Model is based on the BRM structure. The FSAM Service Component model requests the service domain and service type; both elements are taken from the SRM. 

Lastly, FSAM includes a logical data model and data dictionary, which can be used to build an EA Repository. UML models can be stored on a shared drive with the Repository providing the path to the model. Alternatively, a tool (see the Federal Enterprise Architecture (FEA) Practice Guide for recommendations) can be used to generate the EA Repository. The FSAM EA Repository, once populated, enables agencies to generate the Exhibit 300 Investments Part 1 Section A, Integrated E-300 Milestones, Integrated Performance Information, AIT Investments (Exhibit 53) as well as Segment, PART and PAR Performance Reports.

Solution Architecture

The Solution Architecture is used to implement individual IT projects. Adopting the Solution Architecture Framework ensures the FSAM artifacts developed remain current and useful. As business applications are updated, the FSAM Service Components model, for example, is used to add the new service components. The Solution Architect works with the EA team to ensure EA-related artifacts (such as updated/new business process swim lanes, use case and activity diagrams, interface diagrams, logical data models, service component diagrams, etc.) are incorporated into the Repository it can serve as a knowledge center and does not become outdated.  The Solution Architect also uses the existing FSAM Repository to extract data for IT project documents. For example, the FSAM Risk Capture template provides a list of risks for the segment. Relevant unresolved risks are complied and added to the IT Project Risk List and Mitigation Plan. 

n

Facilitating Meetings: Stakeholders in Business & SMEs (Subject Matter Experts)

Some think there is no need to learn about the different types of questions used to gather information. Most think all are born with the ability to ask questions. To some extent this is true. However, when defining a business solution; the only way to successfully design a business system is to extract all of the necessary information from the stakeholders and subject matter experts (SMEs). Keep in mind that stakeholders are people who are impacted by a software project's success or failure. And, stakeholders can be anyone ranging from end users to the end users' managers or even the executives that the managers report to. The primary stakeholder is usually the person whose department owns the system. For example, an HR system may be owned by the HR Department and the HR Director may be the primary, internal stakeholder and system owner. SMEs, on the other hand, are people who are considered experts in a business area. The SMEs may or may not be a stakeholder. But analysts may go to an SME to learn more about a business area (i.e., asset management,  project management, staffing, etc).

This post discusses the importance of designing questions; it tells how questions assist the systems analyst in designing a system; and, it describes some of the questioning techniques that can be used when meeting with stakeholders and SMEs.

Designing Questions for Requirements Gathering

Designing and defining a business solution is a costly process. It is imperative that the customer receive the product that is both needed and expected. The job of a Business Systems Analyst can, to some degree, be compared to that of a person who investigates crimes. For example, the U.S. Department of Justice Office of Justice Programs, National Institute of Justice produced a document title, "Eyewitness Evidence, A Guide for Law Enforcement Research."  The Guide includes the questioning procedure followed by Department of Justice investigators who interview witnesses. The Guide directs investigators to encourage the witness to volunteer information without prompting; ask open-ended questions (types of questions is discussed later in this post); augment the open-ended questions with closed-ended, specific questions; avoid leading questions, avoid interrupting the witness, etc.

Notice the procedure specifically identifies the types of questions to ask first and then the types of questions that should follow the initial screening. This is done because it has been determined that questions can be phrased a certain way to obtain a certain type of results. For example, leading questions are not used because they often result in the respondent providing answers the interviewee wants the respondent to provide. Outside of question types, the procedure also mentions investigators should "avoid interrupting the witness" so the respondent does not loose his/her train of thought and leave out important details. So, as can be seen by the information gained from the Department of Justice guide; using a procedure to strategically design question types; and, determine when to ask specific questions is very useful.

Questions Help Gain Insight Into Stakeholders & SME Needs;

Much like an investigator, a systems analyst must ask questions to uncover the unknowns related to business problems, needs and wants associated with a system. The unknowns are discovered by asking stakeholders & SMEs questions and documenting Their responses.  In addition, the systems analyst does the following:

• Draws conclusions from stated facts;
• Identifies gaps in information provided; and
• Pursues answers to close identified gaps.

The facts mentioned are obtained by questioning stakeholders and SMEs. And, once all information is obtained then gaps are closed and conclusions are drawn. Using this approach ensures all system requirements are traced from statements made by the stakeholder. Note in this context assumptions are not converted into requirements. Instead, the system is designed from stated facts, which ensures an accurate system design.

Types of Questions

It may surprise some to learn that there are different types of questions used; based on the type of desired response. Following is a list of the type of questions (please note that the list is not all inclusive) used; and, descriptions and examples for each question type is also included:

• Hypothetical
• Open-Ended
• Closed-Ended
• Probing
• Leading
• Reflective

Hypothetical Questions

When asking a Hypothetical question, the question should be phrased to paint a picture of a scenario. The respondent then provides feedback based on the scenario painted by the individual asking the question.

Example:  "If we automate the invoicing component of the CAI system, could you then processes 1 application each day?" Or, "let's say we add 2 more people to your team, how many applications could you process in 1 day?". Notice in each example the stakeholder or SME is expected to respond to the specific scenario provided. This approach does not leave room for them to provide additional information. Instead, the question is asked in such a way that the answer will either be yes or no.

Hypothetical questions should only be using in systems analysis when a stakeholder conveys a business problem; and, research results provide insight on possible solutions. Possible solutions can be posed as hypothetical questions directed to the stakeholder. These hypothetical questions would be used to solicit the individual's opinion on whether or not the solution would yield the desired results in the stakeholder's business environment.

Open-Ended Questions

Responses to open-ended questions solicits a broad statement from the stakeholder. This approach results in obtaining a vast amount of relevant information. With open-ended questions; no information is provided to lead the stakeholder or SME down a path. For example, "tell me about the process you use to approve applications."  Notice the question is general and only limits the stakeholder or SME to discuss information relevant to approving applications. However, the respondent can discuss any area that pertains to approving applications including business problems, business process steps, employees, etc. Investigators typically use this line of questioning when asking a witness about something he or she saw. The witness then provides the details in his/her own words without coaching from the investigator.

Closed-Ended Questions

Closed-ended questions should be used to confirm facts stated by the stakeholder or SME when open-ended questions were asked. Typically, close-ended questions are phrased in a way such that only a yes or no answer is required. An example of a close-ended question might be, "you stated one business problem is that applications are never completed in time for customers to take advantage of the Red-tag sale. Is this correct?" The respondent would then answer yes or no.


Probing Questions

Probing questions provide SMEs an opportunity to provide greater details about one or more topics previously discussed. For example, a systems analyst may have a list of use cases along with the related actors and descriptions. However, a series of probing questions may be needed to gain steps for the normal and alternate flows and functional requirements. For example, "earlier you mentioned all students must enroll for the Fall semester to receive a discount. What process should a student use to enroll for classes?" Probing questions are used to gain additional insight in areas where the responses already received resulted in information gaps.

Leading Questions

Leading questions are used to obtain the desired answer to a question. For example, "since you stated Red-tag employees rarely perform well; you think it's best to automate that component don't you?" This line of questioning forces the respondent into providing the desired answer, which is yes. Leading questions should never be used by a Systems Analyst because they lead to documenting requirements that will change when the stakeholder changes his/her mind and wants to reword a statement to provide a different answer. It's best to let stakeholders provide the answers they want to provide based on their business needs or problems.

Summary

Before you host a requirements gathering session; take time to formulate a list of questions. Be sure to reference the various question types that should be used. And, make sure you phrase each question type appropriately. Lastly, it's a good idea to stay away from leading questions that will result in poorly defined or inaccurate requirements. Inaccurate requirements result in increase project costs since stakeholders usually will not accept an incorrectly implemented business system.

The Business Process Analyst & the Business Process

A business process analyst, business analyst or systems analyst is used to review the business process if a new system is about to be built; or, massive changes are about to be made to an existing system. This post focuses on documenting the business process associated with implementing a new or updated system. The topics that will be discussed are gathering business requirements, documenting business requirements, tracing business requirements and generating the data dictionary.

Gathering Business Requirements

When defining a new system or system updates; the business process analyst will typically review the business process steps as they are performed by the worker. Some organizations use MOST work measurement to not only capture business process steps, but determine the amount of time it takes to perform each step. This information is then used to define the exact number of people needed to complete a job within a specific time-frame. However, for Information Technology projects MOST work measurement is typically not used because companies are looking at the process steps and related information; usually, they aren't looking  to assign time values to the process.

To review the business process the business process analyst may be tempted to want to "talk" to individuals to capture this information. But there are one of two approaches that will guarantee the information documented is accurate:

1. Review & Validate a business process already documented: If the business process has already been documented; the business process analyst may ask for a copy of the document. Next, ask a worker if you can shadow him/her as the worker performs the process one time. This provides an opportunity to validate the accuracy of the business process document. In other words, determine whether or not some of the process steps have changed since the document was written. If so, update the document to reflect the changes and circulate the updated document for review.

2. Document a business process that has never been documented: If the business process has not been document the business process analyst should shadow a worker and watch as the worker does his/her job. The business process analyst will watch closely and ask questions as the worker performs the process steps necessary to complete the task. The business process analyst will ask about the business rules applied, software used to capture data (inputs) or generate documents (outputs). The business process analyst will also capture the process flow. The benefit here is, if a new business software is to be built it can be built to support the existing process so the business process changes very little. This means instead of the process changing, the tools used to perform the business process changes. Or, if the business process will change, the process changes can be documented so workers can do their job once the new/updated system is implemented.

The following sections provide one way to document the business process, business rules, inputs, and outputs.

Documenting Business Requirements

Business requirements are typically documented in the form of business rules. But, capturing the business process provides more than just business rules. You will also document business process steps, inputs and outputs. The inputs and outputs typically provide requirements used to define reports or user interface fields.  These elements are ultimately used to define database table fields and the table field relationships needed to generate the outputs.


The document reflecting the current business process is the As-Is business process. After stakeholders/users discuss how they would like to do business with the new/updated system in place; you will need to write the To-Be business process document.

In the following As-Is example, Company "A" users upload enhancement requests to a shared drive to request changes to the company's software product. This section provides a high-level overview of the current business process, the actors, and process owners. The To-Be Business Process Operations Report outlines how the business process is performed with the new/updated system in place.

Input Documents

Document Name	Description	Step ID	Notes
Enhancement Request	The Enhancement Request is currently created using an Exchange Form. The re-engineered process will need to store each request in a database. Users will be able to submit these requests online using the updated system.	Step 1	(For the TO-BE environment, the customer wants a document library using content types so that all related documents for an Enhancement Request are centralized and easily accessible. )
Impact Analysis Report	The analyst emails a copy of the Impact Analysis report to the CCB reviewers.	Step 2	A COTS will be used for the TO-BE environment.
Test Documents		Step 4
Release Notes	The Technical Writing Department is responsible for updating the Release Notes and uploading the document to the shared drive. The path is sent to Product Support and the Deployment team.	Step 4

Output Documents

Document Name	Description	Step	Notes
N/A	Currently there are no outputs. The TO-BE Business process should include information on the reports to be generated for the new process.	Step 5

Sub-Process Operations

In this example, the BSA uses a separate process to create the Impact Analysis report. Therefore, a Sub-Process Operations report would be created to capture the steps. The ID of the Sub-Process Operations Report would include the Parent ID and the step number (i.e., Business Process ID:  2237.2). The business rules, inputs and outputs would also be captured.

Generating the Data Dictionary 

Once you have documented the inputs and outputs, it's a good practice to create a data dictionary. At a minimum the data dictionary should include the element name (such as Enhancement ID or user ID), description, whether or not the element is required, the data length based on any forms and/or business rules, data format (for example dates must be mm/dd/yyyy), data type (i.e., date, string, etc.). Following is one example of a data dictionary. Microsoft Press published a book titled "Software Requirements. It also includes an example of a data dictionary. 

Business Process To-Be Report
 

To capture the To-Be business process requirements stakeholders should review how business is currently done. In addition, a list of current business problems is also captured. The Analyst should look for opportunities in which automation can help the business process become more efficient. And, users and stakeholders should be prepared to discuss problematic areas. All of this information can help the organization look for opportunities to improve the way business gets done.

Business Process Flow Diagram
 
Another way to capture the business process is to create a business process flow chart, which uses symbols to define the business process. The following picture shows the As-Is business process used to Bill Customers.

In the previous process flow diagram the process begins with the IT Department. The rows shown on the process flow diagram includes horizontal swimlanes. A swimlane is the rectangle that depicts an actor. A swimlane can be horizontal or vertical depending on the number of actors and number of process steps. The shapes inside the horizontal swimlane depict the process start, process documents (i.e., complete timesheet), sub-processes (i.e., Process Customer Bill), process decisions (i.e., approved?) and process end.

Requirements & Traceability

Traceability is a key aspect of requirements management. When non-requirements management tools (such as Excel) are used to manage requirements; true traceability is lost. The objective of this post is to discuss the tools needed to trace requirements, the requirements needed to perform tracing and the benefits of tracing.

Tools Needed

To trace requirements, a requirements management tool that allows traceability is required. Most of my experience has been with Rational RequisitePro by IBM (http://www-01.ibm.com/software/awdtools/reqpro/). However, I have used other tools that perform the job equally as well. Rational tools have been around for a very long time and most large organizations and agencies prefer this tool. But, research can be conducted to find a comparable tool for your project, if necessary.

Requirements Needed

To perform a complete trace all levels of requirements must be captured as follows:  Features (FE), Business Rules (BR), Use Cases (UC), and Functional Requirements (FR). In this post I will briefly cover each requirement type and provide a basic example.

The Features of a system provide the highest level of grouping for requirements. For example, FE1: Manage Customer Sales is an example of a Feature. The next level consists of use cases. For example, UC1: Add a Customer Record, UC2: Add an Employee Record and UC3: Place a Customer Order. 

Business Rules can also be captured. For example, BR1: All customers must be associated with a primary salesperson. It should be noted that some BRs will be implemented by a system and some will not. Either way, it's best to capture all BRs and add annotations to clearly mark the stakeholders' decision regarding implementation. If a complete list of BRs is managed, as stakeholders look at the list, they are able to more easily determine whether or not a BR is missing. 

Functional Requirements are the lowest level of requirements. For example, FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status. Now our list of requirements is as follows:

FE1: Manage Customer Sales
    UC1: Add Customer Record
    UC2: Add an Employee Record
    UC3: Place a Customer Order (Includes UC1 and UC2. In other words, you must perform UC1 and UC2 to perform this use case.)
        BR1: All customers must be associated with a primary salesperson. (System Implementation)
        FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.

If the Project Manager wants an accurate reporting of the impact a change has on time-lines and project costs, the requirements management tool can be configured to also support managing Test Cases (TCs) and Test Procedures (TPs). For example, TC1: Place an Order will include the following UCs:  UC1: Add a Customer Record, UC2: Add an Employee Record, and UC3: Place a Customer Order. We also need test procedures to test the business rule and the functional requirement. Therefore, our test items are as follows:

TC1: Place an Order  
     TP1: Test procedure for UC1 not included in this example.
     TP2: Test procedure for UC1 not included in this example.
     TP3: Test procedure for UC1 not included in this example.
     TP4: Test procedure for UC2 not included in this example.
     TP5: Test procedure for UC2 not included in this example.
     TP6: Add a customer record (No salesperson).   Expected Result:  An error message displays "Salesperson is required" and save is not executed. (Test procedure for UC3.)
     TP7: Add a customer record (with salesperson)  Expected Result:  The record is saved. (Test procedure for UC3.)
     TP8: Customer order total < $1000. Expected Result: A notification is NOT sent. (Test procedure for UC3.)
     TP9: Customer order total = $1000. Expected Result: A notification is sent.  (Test procedure for UC3.)
     TP10: Customer order > $1000.   Expected Result: A notification is sent. (Test procedure for UC3.)

In our requirements management system FE1 is traced to UC1, UC2 and UC3. UC3 is traced to BR1, FR1 and TC1. TC1 is traced to TP1 through TP10. 

Benefits of Tracing

In supporting IT projects sometimes business decisions impact the requirements gathered. If this occurs there are only two ways to assess the damage:  guess or analyze facts. In today's market, inaccurate guesses can result in loosing a customer. For example, guessing a shorter time frame than what is required means the team rushes to meet the deadline; but, the work is not completed accurately. Or, over guessing may result in providing inflated costs and time-lines,  which may cause mistrust. Generating an Impact Analysis report provides the facts needed to make sound decisions for an IT project.

For example, initially a customer agrees to wait three weeks for the Place a Customer Order component. However, the customer's company has been invited to a trade show in 1 week. Now the customer wants the component completed by then. Below is a copy of our Impact Analysis report: 


Impact Analysis Report for UC3:  Place a Customer Order

UC3: Place a Customer Order
     BR1: All customers must be associated with a primary salesperson. (System Implementation)
     FR1: Once a customer  purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
     TC1: Place an Order
          TP1: Test procedure for UC1 not included in this example.
          TP2: Test procedure for UC1 not included in this example.
          TP3: Test procedure for UC1 not included in this example.
          TP4: Test procedure for UC2 not included in this example.
          TP5: Test procedure for UC2 not included in this example.
          TP6: Add a customer record (No salesperson)   Expected Result:  An error message displays "Salesperson is required" and save is not executed.
          TP7: Add a customer record (with salesperson)  Expected Result:  The record is saved.
          TP8: Customer order total < $1000   Expected Result: No notification is sent,
          TP9: Customer order total = $1000. Expected Result: A notification is sent and
          TP10: Customer order > $1000. Expected Result: A notification is sent.
          UC1: Add a Customer Record 
                 FR2: Functional requirement for UC1 not included in this example.
          UC2: Add an Employee Record
                 FR3: Functional requirement for UC2 not included in this example.
------------------------END SAMPLE IMPACT ANALYSIS REPORT--------------------------

The Project Manager meets with the customer and provides a copy of the Impact Analysis report. The Project Manager negotiates holding off on implementing BR1 and FR1 to meet the new deadline; and, the customer agrees. Therefore, the following items do not have to be completed for the upcoming release: BR1, FR1, UC2, FR3, TP4, TP5, TP6, TP7, TP8, TP9, TP10.

In addition to being able to generate an Impact Analysis report, traceability provides other benefits. For example, when a requirement changes the requirements management system will typically mark the associated requirement(s) as invalid. For example, if UC3 changes the requirements management system marks its relationships with BR1, FR1 and TC1 as invalid. The analyst rechecks those items to make sure the relationships is still accurate and makes any necessary changes.  Also, a trace matrix can be used to ensure 100% testing coverage of all requirements. This provides a tangible way to guarantee all requirements and business rules have been accurately implemented to ensure a successful implementation.

Requirements: Exactly What Does the Customer Need?

One of the most important aspects of designing a system is requirements gathering. A company can have the most seasoned user experience professionals, top-notch developers and exceptional testers that catch every defect. But, will the customer be happy with a beautifully built, flawless product that isn't what was needed? Probably not!

For over 8 years I've worked as a business systems analyst; typically hired as a consultant after a project has failed. And, in most cases, the projects that failed did so because incorrect assumptions were made. And, requirements were then written from a mixture of inaccurate assumptions and customer statements.

The only way to accurately identify customer requirements is to ask questions. Ask questions and let the customer state his/her vision for the implementation. Be sure to ask about business problems and needs that may have initiated the need for the project. And, trace the applicable requirements from the stated problems/needs to make sure the project addresses these areas.

In short, to accurately design a business solution from requirements; the analyst must take on the role of a detective. He or she must search for unknowns; and, turn mysteries into concrete statements for feedback. At times the analyst will have to draw conclusions from provided information; and, clearly state those conclusions for feedback. Thorough investigative work is what it takes to accurately define a business solution.  But it also takes an understanding of the technology associated with the project.

It's also good practice to gain an understanding of any initial groundwork already laid for the project. For example, ask for a copy of the Statement of Work (SOW). Also, ask for existing system documents, system diagrams, and access to the current system, if applicable. And, in some cases, personal time may need to be used to read through the materials--if the deadlines are tight. But, it is worth it to put forth the effort to gain this insight prior to meeting with the customer. This allows requirements gathering sessions to be used to gather requirements.

Below is a list of tips you may find useful while meeting with customers to understand system requirements:

1. Ask for existing system or project documentation.

2. Be willing to use your personal time to learn concepts if deadlines are tight.

3. When meeting with the customer ask questions. And, make sure the stated business problems/needs are addressed.

4. Enter all requirements into a requirements management system.

5. Perform a gap analysis.

6. Write questions that will help close the identified gaps. Then be sure to obtain complete answers to those questions.

7. Update the requirements as you receive answers to your questions.

8. Generate a trace matrix or report for customer review.