Comprehensive and Robust Requirements Specification Process

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 and 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 hurricanes and tornadoes in that a requirement is assigned an exclusive 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, if the requirements for a web shopping cart state that the application must be able to calculate the tax for the specific state and/or province of the online customer, the requirement would be written as:

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

However, the requirement is later reworded to state that the application must be able to calculate the tax for the specific state and/or province of the online customer, then the requirement would be rewritten as:

1.1 Requirement Removed. 1.2 The state or province from the customer's profile will be used to calculate 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, an ambiguity review, and ambiguity walkthroughs involving the design, development, and testing teams to establish clarity and completeness of the requirements. The reviews and walkthroughs utilize a clear set of criteria for the reviewers to ensure that the information is complete, consistent, 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, 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.

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 can indicate opportunities for training among the Business Analysis team, a need for more resources, or more executive support, but can also indicate if the problem is with the development or testing teams. It can also 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. The naming and numbering conventions are the same as for the requirements but are indicated as rules with a 'B' preceding the number.

For example, if the business rule B36 for the same shopping cart, states that taxes shall be calculated on the total purchase amount according to a 12% British Columbia tax rate, then the business rule would be written as:

B36.1 British Columbia tax rate 12%

If requirement 1.1 references this business rule, it would be written as:

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

Use Cases

Use Cases can be started at any point during the requirements process and polished as the requirements are completed. Their value is in adding a layer of validation for the requirements to support a review for completeness. These may be presented to the users in a walkthrough to help validate the step-by-step process through which the user and system will go in performing specific transactions. Both literary (descriptive) and diagram (such as UML, Activity or Swim Lane) use cases are appropriate for this due to the value each of these can provide to the end users.