Comprehensive & Robust Requirements Specification Process

The Comprehensive & Robust Requirements Specification Process (CRRSP), or CRRSP (pronounced crisp), is a methodology for gathering, defining, and validating software requirements. CRRSP is not a step-by-step restrictive process, but an adaptable framework, intended to be customized by the Business Analysis teams that select the elements of the process that are appropriate for their needs.

History

CRRSP was developed in 2008 by a senior Business Analyst named Barbara Davis after years of research and refinement through hands-on experiences as a senior Business Analyst and Business Analyst Center of Excellence Practice Director with organizations such as UST Global and Safeway.

Relationship to Other Methodolgies

CRRSP's approach to software requirements allows for applications with most types of project methodologies and a flexible and adapatable starting point at which one can apply the methodology. CRRSP differs from other methodologies such as Waterfall, RAD, Agile, and RUP because it is specifically a methodology for defining and validating the requirements within the context of the larger project life cycle, while others are project methodologies that define the overall project life cycle itself.

One of the primary factors in CRRSP is that it evolves requirements through high-, mid-, and low-level requirements via an increasingly deeper dive on the requirements collateral.

Stages

The key stages in the CRRSP requirements methodology are Research and Elicitation, Analysis, Elaboration and Specification, and Validation. It is characterized by detailed validation steps, tools and techniques as well as unique analysis deliverables and traceability products.

Research and Elicitation

The goal of the Research and Elicitation stage is to understand and research the business drivers, goals and objectives, project artifacts created to date, and create workflow to help illustrate the current state and desired future state. It ultimately defines the project's mid-level requirements.

Analysis

In analyzing the mid-level requirements, the analyst uses gap assessment, a more detailed form of gap analysis, and cause and effect or decision tables to outline scenarios, further evolving the high-level requirements into mid-level requirements.

Elaboration and Specification

Elaboration & Specification is the stage of coherently documenting and authoring the requirements document into a format that will ultimately be passed onto the design, development and testing teams to be utilized in the creation of their products and deliverables. It generates refined business rules, refined workflow schemas, and the low level requirements.

Naming and Numbering Convention

The CRRSP methodology dictates a strict naming and numbering convention for requirements within a project and products in general. It follows similar rationale and logic behind naming hurrincaines and tornados in that a requirement is assigned an exlusive number that remains its own even if the article becomes scrapped. This ensures accurate traceability across multiple versions of the documentation and scope changes.

The numbers are assigned to a final draft before release to the design, development, and test teams for the ambiguity review process. This ensures that there is no confusion amongst the BA team when documenting the requirements. Numbers are only assigned to the high level requirements; sub-numbers are assigned to the mid- and low-level requirements since they are extensions of the high level requirements.

For example:

Requirements for a web shopping cart: 1. Application must be able to calculate the tax for the specific state AND/OR province of the online customer.

  1.1 Customer must be able to select their state AND/OR province from a selector.

Once numbers have been assigned to a requirement, they NEVER CHANGE. They are fixed to that requirement across multiple versions of the document, multiple phases of the project and mutliple iterations of the product. This ensures 100% traceability and that there will never be confusion amongs the project team, stakeholders and end-users as to what requirement number 1 actually is as the project and product evolves. The issues that occur if this does not happen are that BA's may tend to reference requirements number and then use up valuable time trying to locate all referring instances or interpreting correct and clear requirements, and development & testing teams working from older versions of the documents while awaiting changes will not be on the same page.

For example:

Revised Requirements for a web shopping cart: 1. Application must be able to calculate the tax for the specific state AND/OR province of the online customer.

  1.1 Requirement Removed.
  1.2 The state or province from the customer's profile will be used to calcualte the taxes on the purchase.

Validation

Validation uses a combination of ambiguity techniques derived from Requirements Based Testing and Logic Modeling . These techniques include an Ambiguity Log, Ambiuity Review and an Ambiuity Walk-through(s) involving the design, development & testing teams to establish clarity and completeness of the requirements. The reviews and walk-through(s) utilize a clear set of criteria for the reviewers to ensure that the information is complete, consistent, and accurate, and written in language that clearly states and defines the intended functioning of the new software.

Benchmarking

Proponents of this methodology are able to apply a specialized formula to determine the effectiveness of requirements activities by benchmarking and measuring against the established benchmark . By benchmarking requirements activities across a project, the BA team is able to better understand where time is being spent, how to improve as during the task and to be able to increase task efficiency and effectiveness as a means of improving the project. This has proven to be the most effective technique for rapidly re-aligning a flagging project because of the insight it provides the team during the process instead of just part of the forensics.

By benchmarking requirements activities in general across multiple projects, organizations are able to get a more detailed picture of the requirements activities and where they can be improved. This may indicate opportunities for training among the Business Analysis team, need for more resources or more executive support, but can also indicate if the problem is with the development or testing teams and can provide enough evidence to support changing the overall life cycle processes.

Business Rules

Business Rules are typically separated out into a separate document with references made within the requirements themselves. Again the naming & numbering conventions are the same as for the requirements but are indicated as rules with a 'B' preceeding the number.

For example:

Business Rules for the same shopping cart: B36 Taxes shall be calculated on the total purchase amount in accordance with the following State and provincial tax rates:

   B36.1 British Columbia tax rate 12%

How this is referenced in the requirements:

Requirements for a web shopping cart: 1. Application must be able to calculate the tax for the specific state AND/OR province of the online customer.

  1.1 Customer must be able to select their state AND/OR province from a selector.
  Applicable Business Rules: B36

Use Cases

Use Cases may be started at any point during the requirements process and polished as the requirements are completed, but their real value is in adding a layer of validation for the requirements to support a review for completeness. These may be presented to the user's in a walk-through to help validate the step-by-step process that the user & system will go through in performing specific transactions. Both literary (descriptive) and diagram (such as UML, Activity or Swim Lane) use cases are appropriate for this due to value each of these will provide to the end users, and must be accompanied by a facilitated walk-through session. Remember that an analyst's job is to get sign-off. People are better able to process what they can read, see and hear. The stakeholder or user can't sign-off if the person happens to be a visual, aural or tactile person and the analyst has presented the material in a way that makes it more difficult for the stakeholder or user to process.

External links

• [6] Access to official CRRSP Information (including certification & downloads) on Requirements Networking Group