Steps for Elicited Requirements in Business Analysis

This article covers the steps that the business analyst will take to analyze the elicited requirements. We examine the characteristics of the project requirements and describe the tasks that are involved.

Once requirements have been elicited, the BA must fit the requirements into the project's architecture. That process starts with the two-tiered process of requirements analysis and documentation. The BA will structure the requirements and specify for the project team how they should be implemented into the solution or initiative. The primary objective is for the project team to achieve consensus on implementation expectations.

The BA documents the characteristics, including time, budget, and resource requirements, by creating a business domain model. The model will be based on feedback received from stakeholders during the analysis activities. This may require further elicitation. The BA refines the documentation to deliver a comprehensive model that is signed off by all parties.

As part of an iterative process, the BA will present documentation for review, make revisions based upon feedback and present revised documentation. This process continues until all requirements have been fully detailed and are completely implementable. Then stakeholders can sign off and the project can move to the development stage.

Requirements Analysis

By analyzing the requirements list, the BA determines the importance of each requirement in the project. Although every business, stakeholder, and end user requirement is usually considered important, the BA will need to prioritize, and even eliminate, some needs.

Requirements are broken down into three categories:

· Business Requirements. What must be delivered to provide value to the customer.

· Product Requirements. The system or product that facilitates the business requirement.

· Process Requirements. The work flow that must be accomplished to deliver the business requirement.

These categories can then be separated into two descriptions 1) functional, describing an action or capability that a system requires, 2) non-functional, a constraint that must be met, such as a regulation. The BA must both validate that stakeholder requirements meet the functional and quality standards to fulfill the business, product, or process requirements, and verify that the documentation is adequate to assist with solution development.

There are several techniques to prioritize the requirements within each category. The IIBA recommends that the BA be familiar with more than one method, as today's projects have wider dependencies with different ways of expressing requirements. Popular techniques include:

Mandatory/Optional. Which needs must be met and which simply optimize the solution or initiative?

Ranking. Due to constraints, which needs must be met first and which can wait?

Value Analysis. Which needs produce the greatest value?

Risk Rating. Which needs carry the best risk/reward ratio?

Kano Analysis. Which needs provide the greatest end user satisfaction?

Stakeholder Impact. Which needs strongly affect the most important stakeholders?

PERT Analysis. How should needs be sequenced to accommodate

scheduling?

The outcome of the analysis process is solution development. How does the enterprise achieve the goals of the project? The IIBA recognizes three methods of solution development that a BA can use (see figure 10-1). There are several models that can express the requirements as a component of the solution or initiative. Each method is dependent upon the requirements involved and the analysis techniques used.

Solution Development Methods

Figure 10-1. Solution Development Methods

Creating a Business Domain Model

The BA develops a business domain model to express the current and future state of the company. The goal is to ensure that all stakeholders understand and agree to the as is environment and the proposed environment. By constructing a domain mode, also called mapping, the BA can uncover inconsistencies, gaps, and conflicts between business units.

There are two fundamental principles that must be taken into account when developing the as is model. The first addresses variations in users and work functions. The BA must document the variances between multiple work units performing the same or similar functions, and between multiple end users performing the same tasks. The second principle addresses whether the future domain will accommodate inconsistencies or conflicts within the current domain or if those inconsistencies or conflicts require standardization prior to development.

The model provides a framework that will:

o Identify key areas that the solution or initiative will address.

o Identify areas that may be improved.

o Identify organizational weaknesses or elements that the as is enterprise does not address.

o Assist the project team in re-scoping or de-scoping the project.

Among the artifacts (deliverables) that the BA will incorporate into the domain model are:

1. Organizational Model.

2. Company Business Rules.

3. Business Processes.

4. Company Mission.

5. Company Vision.

6. External Stakeholder Documentation.

Analysis Tasks

To present requirements documentation that will form the basis for product development, The BA will perform five analysis functions. These can be done sequentially, concurrently, or iteratively. The functions include:

Want to learn more? Take an online course in Business Analysis.

· Analyze user requirements. Decompose the project requirements into sets that affect specific users to determine if different stakeholder group needs are addressed.

· Analyze functional requirements. Identify the system capabilities that will deliver the solution in terms of its behaviors or operations (see figure 10-2).

Expression of Functional Requirements

Figure 10-2. Expression of Functional Requirements

· Analyze the quality of service requirements. Determine the business environmental conditions that do not relate to the functionality or behavior of the system but contribute to its implementation (see figure 10-3).

Figure 10-3. Business Conditions

· Determine assumptions and constraints. Identify aspects that are assumptions (believed to be true but not confirmed) and constraints (limiting or restrictive attributes) which can affect the solution's outcome. There are two kinds of restraints:

§ Business Constraints. Limitations or restrictions on the project's flexibility to adopt the solution or initiative. Includes budget, resources, skill sets, regulatory, and other constraints.

§ Technical Constraints. Architecture limitations or standards which must be met. Includes development languages, hardware and software platforms, file and usage restriction, and other data related functions.

· Determine requirements attributes. Identify information, such as source, importance and timing of the requirement that will help in managing the delivery of the solution. The BA will use imperatives to explain the priority of requirements, such as "shall", "must", "may", and "will."

Common attributes include:

§ Absolute reference. Unique numeric or textual identifier; remains stable if requirement is changed, moved, altered, or removed.

§ Acceptance criteria. Test that indicates that the requirement has been met.

§ Author or Source. Stakeholder submitting the requirement.

§ Complexity. Difficulty to implement the requirement.

§ Ownership. Stakeholder or group that needs the requirement.

§ Priority. Order of adoption or implementation of the requirement.

§ Stability. The maturity stage of the requirement; how long it's been in existence.

§ Status. Indicates whether the requirement is proposed, accepted, verified, or implemented.

§ Urgency. How quickly the requirement is needed within deadlines.

-----------------

Requirements Documentation

Following a thorough examination all the requirements, the BA will express their findings through requirements documentation. The purpose is to facilitate a common understanding among the stakeholders. It formalizes the project's scope and presents the information in a unified way to decision makers. Although the elicitation and analysis functions have been performed, there may be iterations in the documentation process due to reviewers' input that the BA receives.

Documentation will typically follow the company's standard formats. Among commonly used formats are:

· Vision Document. Describes a high level, broad view of the project. Provides a "road map" for project development.

· Business Process Description, Another high level summary explaining the problem or issue along with the solution or initiative in general terms.

· Business Requirement Document. Details the business needs of the project, including customer expectations. Describes what is needed (not how needs will be met).

· Request for Proposal (RFP). A formal inquiry to external parties for the purpose of contracting activities that will fulfill part or all of the solution or initiative.

· Systems Requirements Specification. Typically used to determine IT needs describing the behavior and implementation needs of the systems development team.

Creating a Business ModelDuring the analysis and documentation phase, the BA may construct a model to express the requirements scope. A business model is a framework that denotes, processes, structure, and behavior, or usage requirements. It can include textual content and visualizations (for instance, graphs, diagrams, and more). The model forms a cohesive representation of all the impact areas of the solution or initiative.

There are several industry accepted model templates that the BA can develop.

· Data and Behavior Models. Shows elements, rules, and attributes that exist within the project's scope, information that the system will require, record, and distribute, processes included in the work flow, and rules that govern behaviors within the system. Typically uses a static framework (does not change as development proceeds).

o BUSINESS RULES MODEL. Structures, methodologies, behaviors, activities, and other enterprise functions that must meet or are constrained by internal and/or external realities. Can be a policy, standard, regulation, or guideline, and must apply at all times or at specific times.

o CLASS MODEL. Organizational structure that expresses all entities relevant to project development. Includes both internal and external environments, and shows relationships and dependencies between entities. According to the IIBA, a class "represents a distinct concept within the solution domain, which may represent a physical item, a logical collection of information, a piece of functionality within the system, or an action that may be taken. Each particular instance of a class (the actual physical thing, the execution of an action, etc.) is an object." The class model uses the Unified Modeling Language (UML).

o CRUD MATRIX. Used during software or IT systems development, defines synchronous tasks, access rights, and other criteria used within database functions. The CRUD (create, read/retrieve, update, delete) matrix defines which user groups can input data into which software elements.

§ Usage Rights:

· CREATE. User group can initiate a new data element.

· READ/RETRIEVE. User group may view data within the data element.

· UPDATE. User group may alter data stored within the data element.

· DELETE. User group may remove a data element.

· LIST (optional). User group may express a data element, but cannot access internal data.

o ENTITY RELATIONSHIP DIAGRAM (ERD). Similar to Class Model, it visually expresses entities (such as products- customers, invoices, employees) and their relationships to each other and the systems used.

§ ERD Components:

· Entities. Group of uniquely identifiable elements.

· Attributes. Characteristics that define the entity.

· Unique Identifiers. One or a group of attributes which define a singular occurrence of an entity.

· Relationships. Association between two or more entities.

o DATA DICTIONARY. Defines the data and data structures that will exist within the system. The BA must resolve contradictory names, values, descriptions, and so forth, between business units. Assembles primitive data (single unit) into composite data (complex structures).

· Process/Flow Models. Shows how the system behaves over time, through the execution of a process or as a result of an event within the solution's scope. These models express entities only as a component of a series of events within the system process or data flow. Expresses a dynamic, moving environment.

Elements:

1. Flow Objects are Events, Activities and Gateways between functions.

2. Connecting Objects are Sequence Flow, Message Flow, and Associations.

3. Swim Lanes are Pool (group of objects) and Lane (subpart of pool) depicting who or what is performing the function.

4. Artifacts are Data Objects, Activity Groupings, or Annotations about elements

o ACTIVITY DIAGRAM. Displays the sequence of events and the logic that controls the flow. Includes manual, automatic, and integrated activities.

o DATA FLOW MODEL. Expresses input, process, storage, and output of data within the system. Explains what the system can do and how it performs functions. Includes a process hierarchy to establish data priority.

o FLOW CHART. Displays the processes and logic underlying a set of activities. Defines boundaries and interdependencies of activities.

o STATE MACHINE DIAGRAM. Specifies the changing state of an object as it progresses through a system or process, and the systemic changes that take place during this progression. Expresses the transitions along with the underlying logic that triggers the transition.

· Usage Models. Expresses the interaction between users and the product or solution. Only displays functions that are visible to external entities impacted by the system.

o PROTOTYPE MODEL. Physical or visual representation of the proposed application. Allows end users to view and interact with the product and determine functional feasibility.

o SCREEN SHOTS or STORYBOARD. Initial mock up or simulation of the product or application. Can be a drawing or computer screen shots, but expresses details within the interface with the user.

o USER CRITERIA MODEL. Expresses user profiles, interface designs, and use cases that impact the system or product development. Displays interactions, functions, boundaries, and opportunities between the user and the system.

Requirements Validation

One of the BA's primary responsibilities is to ensure that the project develops smoothly and that the solution or initiative attains the objectives that are sought. Being successful requires a thorough examination of the requirements prior to product development. Before the project can be developed, the BA must review the requirements to make sure that they are feasible and valid. This process is called requirements validation. It is especially important to validate the system requirements prior to initiating software implementation because of its sequential development; invalid requirements that are discovered later can lead to either a costly overhaul of the project or scrapping it altogether.

The BA will check the documents for the following:

§ Requirements conflicts.

§ Conformance to standards.

§ Completeness and consistency.

§ Technical problems or errors.

§ Vague, unverifiable statements.

Once completed, the stakeholders must agree that the requirements documentation is an acceptable representation to be implemented. Requirements validation activities should typically be completed before moving to the next step, which is requirements verification.

Requirements VerificationNow that the requirements have been validated, the BA must make certain that they are expressed clearly enough to be implemented, and that enough information is represented to allow product or solution development. The BA must also determine that the requirements meet company, regulatory, specifications, and conditional standards before beginning development. Requirements verification ensures that all requirements can be met throughout development.

Methods of verification include:

· Walkthroughs.

· Performance testing.

· Simulation.

· Database analysis.

· Algorithm analysis.

· Functional testing.

· Stress testing.

· Interface testing.