It is time for a change, a renovation in process consultancy. For the last 40 or 50 years, the same steps are being followed; the same thought process is being applied with little or no change.

In between, industry specific new standards/models got evolved and practiced. Other than that no major change happened in the process consultancy arena. From where to start the change..?

If the right process is followed in the right way by the project team itself, then there is no need of a second person to ensure process compliance. But occurrence of mistakes is a common phenomenon especially when there is human intervention (and even with machines too). Hence it is always recommended to have an external person for verifying the process compliance.

The following questions may seem questioning the validity of existing well known standards or models. With due respect to all of those standards, I am trying to see the process frame work through different angles- “the second generation of Process Consultancy”.

• If all the projects are being executed in the same way following the same written process and procedures, how can they be innovative?

• If lessons earned are documented, passed to the followers and practiced, won’t they be copycats?

• Is the written process really fitting your projects or aren’t you pretending it to be okay, just to avoid the tailoring procedures?

• Is there really an established process for at least half part of your project or aren’t you just executing it as it come up on your way?

The questions won’t end continues till there is a second generation. And then, only those consultants who have subject expertise as well as analytical nature may be the most suitable for next century organizations.

Horizontal traceability shows relationship among related items such as between requirements itself. It traces dependent items within a development phase. Vertical traceability is a characteristic identifying the source of requirements typically from requirements to design, to the source code and to test cases.

Horizontal traceability is an aspect identifying non hierarchical similarities, mutual properties, interactions, etc. among requirements and work products. For example assume we want to implement a login function in four different types of browsers. There are four sub teams to do this. Here the functional requirement remains the same. If any change in requirement happens, then it needs to be reflected across all the four browsers. These kind of dependent requirements are easily traceable if

Read More

Requirements are the basis for design. Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as requirements levied on the project by the organization.

In CMMI Requirements Management (REQM) Process Area provides traceability of requirements from customer requirements to product requirements to product component requirements. Requirements Development (RD) Process Area describes Customer requirements, Product and Product component requirements.

This post is a consolidation of different types of requirements as described in CMMI, starting from Customer requirements to Derived requirements.

Requirements 1

Customer requirements

Customer needs and constraints are analyzed and elaborated to obtain prioritized customer requirements. In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated.

 Contractual requirements

Customer requirements are further refined and made suitable to be included in the contractual documents or supplier agreements. Contractual requirements include both technical and nontechnical requirements necessary for the acquisition of a product or service.

 Product and product component requirements

The customer functional and quality attribute requirements are usually expressed in the customer’s terms and can be nontechnical descriptions. A translation of requirements from customer’s language to developer’s language gives rise to product requirements. Or rather the product requirements are the expression of the customer requirements in technical terms that can be used for design decisions. An example of this translation is found in the first House of Quality Function Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” may be mapped to size, weight, fit, dampening, and resonant frequencies.

The product architecture provides the basis for allocating product requirements to product components. The developer uses product requirements to guide the design and building of the product or service. Product component requirements are a complete specification of a product or service component, including fit, form, function, performance, and any other requirement.

In short, product and product component requirements are the refined Customer requirements. This refinement of customer requirements converts implicit requirements into explicit derived requirements such as interface requirements.

Derived Requirements

Derived Requirements are those requirements which are not explicitly stated in customer requirements but are inferred from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions) or from requirements needed to specify a product or service component. Derived requirements can also arise during analysis and design of components of the product or service. Derived requirements also address the needs of other lifecycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.

Interface requirements

As internal components are developed, additional interfaces are defined and interface requirements are established. Interfaces between functions (or between objects or other logical entities) are identified. Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product component integration and are an integral part of the architecture definition. Before integration, each product component should be confirmed to be compliant with its interface requirements. Interfaces can drive the development of alternative solutions described in the Technical Solution process area.

The blog won’t be complete if the below kinds of requirements are not touched

  • Allocated requirement

Requirements are said to be allocated when the higher level requirements are levied on a lower level architectural element or design components.

More generally, requirements can be allocated to other logical or physical components including people, consumables, delivery increments, or the architecture as a whole, depending on what best enables the product or service to achieve the requirements.

  • Service requirements

Service requirements are the complete set of requirements that affect service delivery and service system development. Service requirements include both technical and nontechnical requirements.

  • Technical requirements

Technical requirements are the properties (i.e., attributes) of products or services to be acquired or developed

  • Nontechnical requirements

Nontechnical requirements are the requirements affecting product and service acquisition or development that are not properties of the product or service.

Examples include numbers of products or services to be delivered, data rights for delivered COTS and non- developmental items, delivery dates, and milestones with exit criteria. Other nontechnical requirements may include additional conditions and commitments identified by agreements, needed capabilities, conditions derived from business objectives and work constraints associated with training, site provisions, and deployment schedules etc.