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.
· 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.
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
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.
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:
· 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).
Figure 10-2. Expression of Functional Requirements
§ 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."
§ 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.
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.
· 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.
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.
§ ERD Components:
· Entities. Group of uniquely identifiable elements.
· 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).
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.
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.
§ 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.
· Walkthroughs.
· Performance testing.
· Simulation.
· Database analysis.
· Algorithm analysis.
· Functional testing.
· Stress testing.