Comprehensive & Robust Requirements Specification Process

Last updated

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.

Contents

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 Methodologies

CRRSP's approach to software requirements allows for applications with most types of project methodologies and a flexible and adaptable 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. [1] 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 [2] and Logic Modeling. [3] 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 [4] 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. [5] 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.

Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but not necessarily limited to:

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

A business rule defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals. For example, a business rule might state that no credit check is to be performed on return customers. Other examples of business rules include requiring a rental agent to disallow a rental tenant if their credit rating is too low, or requiring company agents to use a list of preferred suppliers and supply schedules. While a business rule may be informal or even unwritten, documenting the rules clearly and making sure that they don't conflict is a valuable activity. When carefully managed, rules can be used to help the organization to better achieve goals, remove obstacles to market growth, reduce costly mistakes, improve communication, comply with legal requirements, and increase customer loyalty.

In business and engineering, new product development (NPD) covers the complete process of bringing a new product to market, renewing an existing product or introducing a product in a new market. A central aspect of NPD is product design, along with various business considerations. New product development is described broadly as the transformation of a market opportunity into a product available for sale. The products developed by an organisation provide the means for it to generate income. For many technology-intensive firms their approach is based on exploiting technological innovation in a rapidly changing market.

Benchmarking is the practice of comparing business processes and performance metrics to industry bests and best practices from other companies. Dimensions typically measured are quality, time and cost.

Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through to the final manifestation of the software, typically in a planned and structured process. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

Requirements analysis Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

Systems development life cycle Systems engineering term

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life-cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Business analyst Person who analyses and documents a business

A business analyst (BA) is a person who processes, interprets and documents business processes, products, services and software through analysis of data. The role of a business analyst is to ensure business efficiency increases through their knowledge of both IT and business function.

Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.

Business analysis is a professional discipline of identifying business needs and determining solutions to business problems. Solutions often include a software-systems development component, but may also consist of process improvements, organizational change or strategic planning and policy development. The person who carries out this task is called a business analyst or BA.

Software project management is an art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance will be met. It may be alternatively referred to as systems performance engineering within systems engineering, and software performance engineering or application performance engineering within software engineering.

Functional specification

A functional specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.

V-Model (software development) Software development methodology

In software development, the V-model represents a development process that may be considered an extension of the waterfall model, and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction, respectively.

A phase-gate process is a project management technique in which an initiative or project is divided into distinct stages or phases, separated by decision points.

Extreme programming Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.

In business analysis, the Decision Model and Notation (DMN) is a standard published by the Object Management Group. It is a standard approach for describing and modeling repeatable decisions within organizations to ensure that decision models are interchangeable across organizations.

References

  1. Barbara Davis, Requirements Networking Group, January 20, 2010, " "5 Critical Requirements Steps that get Missed: What Business Analysts Are Not Doing | Requirements Networking Group". Archived from the original on 2010-04-13. Retrieved 2010-11-23.", November 22, 2010
  2. Jaideep, IT Knowledge Exchange, Mar 2, 2009, "", November 22, 2010
  3. RUSH Project, Research Utilization, May 31, 2009, "", November 22, 2010
  4. Richard Bender, Bender RBT, Date Unknown, "", November 22, 2010
  5. Barbara Davis, Requirements Networking Group, January 18, 2010, " "Benchmarking Requirements for Improvement | Requirements Networking Group". Archived from the original on 2010-05-20. Retrieved 2010-11-23.", November 22, 2010