Comprehensive & Robust Requirements Specification Process

Comprehensive & Robust Requirements Specification Process (CRRSP)

The Comprehensive & Robust Requirements Specification Process 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 will 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

The unique approach to software requirements allows for application with almost any type of project methodology and for a a flexible and adapatable starting point at which to apply the methodology. CRRSP differs from other methodologies such as Waterfall, RAD (Rapid Application Development), Agile and RUP in that it is specifically a methodology for defining and validating the requirements within the context of the larger project life cycle while these 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 & Elicitation, Analysis, Elaboration & Specification and Validation . It is characterized by the detailed validation steps, tools and techniques as well as the unique analysis deliverables and traceability products.

Research & Elicitation

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

Analysis

In analyzing the mid-level requirements, the analyst uses Gap Assessment (which is a more detailed form of Gap Analysis) and Cause & Effect or Decision Tables to outline scenarios and further evolves the high level requirements into mid-level requirements.

Elaboration & Specification

Elaboration & Specification is simply 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 & Numbering Convention

The CRRSP methodology dictates a strict naming & numbering convention for requirements within a project and for products in general. It follows similar rationale and logic behind naming hurrincaines & tornados in that a requirement is numbered once and that number is never used again in that product, even if that requirement is scrapped and new ones are added in that spot. This ensures accurate traceability across multiple versions of the documentation and scope changes.

The way it works, is that numbers are assigned to a final draft version before release to the design, development & 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 and sub-numbers are assigned to the mid and low level requirements since they are simply detailed requirements needed to meet 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 still 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 so that they can ensure 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 they are spending their time, how to improve as they go along and to be able to increase their 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 as they are working 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 tsting 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 aming & 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 diagrams or Swim Lane diagrams) 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 your job is to get sign-off. People are better able to process what they can read, see and hear. They can't sign-off if they can't process because they happen to be a visual, aural or tactile person and you have presented the material in a way that makes it more difficult for them to process.

External links

• [6] Access to the CRRSP Community on Requirements Networking Group