Business Requirements Analysis

Business analysis is the task of organizational self-examination, generally conducted with the intent to improve efficiency and effectiveness and ultimately, profitability.  BJP Partners categorizes this activity under the heading business process improvement.

As a subset of business analysis, business requirements analysis is a critical element in business process improvement.  Process improvement ranges across industries from manufacturing redesign, to service enhancement, to any kind of software enhancement or conversion.  Just as process improvement is conducted within the context of a formal project management regime, so is the task of requirements analysis.

Within the context of a project, the business analyst is charged with several tasks:

• Discovery of process: objectives, inputs, outputs and quality controls

• Analysis of process area to be modified (target of opportunity), usually at the direction of the business unit

• Assessment of target functionality, as-is

• Elicitation of functionality requirements for target of opportunity, as-desired

• Documentation of desired functionality

• Interaction with system, process and/or engineering analysts to assure that documentation completely communicates scope of requirements, i.e., functionality

There are several pitfalls to which business analysts are prone:

• In the discovery phase, there may be a temptation toward excessive study of the “as-is” process: As-is knowledge lends credibility to the analyst, but is time-consuming, therefore costly.  The analyst must be willing to work with framework knowledge, not intimate knowledge.  After all, “as-is” will soon become “as-was.”

• In the elicitation phase, there often exists the willingness to indulge business-unit meandering on policy, production or marketing alternatives.  Requirements analysis is not brainstorming.  The business analyst must be willing to terminate this wandering discussion and defer the meeting until the business unit articulates a unified direction.  Requirements analysis is not intended to provide a range of options, but a list of specifications.  If the business unit cannot achieve agreement on policy, procedures, etc, then the project is not ready for requirements analysis.  The requirements analyst should remand the task to a business analyst. 

• In the documentation phase, given the analyst’s intimate knowledge of the business process, there is often an inclination to include too much operational detail in the requirements.  Outcomes (units, time, quality) should be specified.  The systems analysts/production engineers may change the process altogether, making documentation of the “as-is” irrelevant.

• Failure of imagination.  This may appear a harsh condemnation of intellect, but it is not.  It reflects the circumstance that the requirements analyst’s domain of expertise is requirements analysis per se, not the subject matter being analyzed.  This suggests that the analyst must cajole the imagination of the subject matter expert at every opportunity.  This may be the most important issue, so consider the following example:

Say the question is value of an object and the intent is to use that value in a computation.  The requirements analyst might ask of the subject matter expert, “What is the relevant range of value”?  The subject matter expert might respond about 3,000 to 75,000.”  The analyst should follow-up with questions such as:

• Do you mean in US dollars only?  What if it is in another currency?

• Should there be error messages if the values seem egregiously high or low?

• What if the value is zero?  Should there be a value restriction on the field, disallowing that value for data entry, or should we accept the value and continue processing.  What if the value is negative?

• What would the error messages be if a zero or negative value is used?

It is the role of the business requirements analyst to press the subject matter expert to contemplate circumstances that are unusual, but not improbable.

Return to Professional Services