Requirement Engineering Tip from SBDi Consulting

This tip focuses on the scenario of identifying that a change in the requirements has occurred. Requirements suppliers, such as users, executive management, and business community knowledge experts are busy people. Unless they are involved in the product development effort on at least a weekly basis, they may forget to tell the Requirements Engineer that something has changed. This is just human nature.

The Requirements Set is NEVER stagnant. It may be stable for a specific iteration but requirements within the requirements WILL change. Some of the changes will be minor and thus can be postponed to the next iteration of the product. While others will halt the development process in order to account for the change.

The person in charge of the requirements set for the product must be the investigator, or should I say instigator, of obtaining the change information from all different perspectives. It is the responsibility of the requirements supplier to notify, at very least, the Product Manager of any changes. It is ALSO the responsibility of the Requirements Engineer to be proactive in identifying any changes to the Requirements Set. This two-role approach ensures that the requirement set is as accurate as possible in defining the current needs of the product and project.

When you are part of a smaller organization, it is easier to be kept up to date regarding changes within the business community. When the manager of the requirements engineering group is part of the executive committee, the larger changes, such as policy changes and product direction changes, will be communicated. These changes can then be reported back to the staff and they can begin to analyze the impact of these changes on existing projects. This becomes more difficult within larger organizations, especially if the manager of the requirements engineering organization is not part of the executive committee.

This is why it is so important to manage and trace requirements. Managing requirements was covered in two previous tips:

Many people, unfamiliar with the Requirements Set Pattern™, believe that the Requirements Engineer's job is complete after the owner or planner perspective has been determined. This assumption is based on the belief that the business stands still while the product is being developed! This belief creates a real risk in producing a quality product!

As recipients of the SBDi Tip of the Month, you know that this is far from reality. Businesses continue to evolve and change during product development. These changes can take many forms, from changes in the company's legal obligations, to the fact that other issues in the development process have stimulated more ideas. Another major issue is the fact that people within the organization come and go. When new members join the project team, they often have their own perception of how the product should look, feel, and operate.

Remember, the term Requirements Engineer is generic for those responsible for producing and managing requirements (refer to the March 2001 tip Requirements Engineering Related Roles, http://www.sbdi-consulting.com/mar2001.shtml). The individual responsible for developing the requirements set could change as the project evolves. Care must be taken to ensure that the transfer of responsibility is clear and understood by the entire project team. Depending on the perspective of the product evolution, this could be the traditional requirements engineer or it could be the data analyst, software engineer, or developer and so forth. This is probably not the case in smaller companies, however in larger companies, it is almost certain.

Organizations with large Requirements Engineering organizations will usually assign one individual from the initial elicitation effort to the task of identifying potential changes.

Once the Requirements Set has been approved, it is important for the Requirements Engineer to continually return to the requirement supplier to determine if anything has changed. This is an easier process if you have developed a rapport with that person. If you have not, you need to begin to build one! Good rapport always facilitates communication. (See http://www.sbdi-consulting.com/mbtipres.pdf for an SBDi presentation on dealing with different personality types or an article from Software Development "Reengineering With The Right Types," Software Development, July 1994; IEEE Software "Facilitating Communication," IEEE Software, October 1998.

When a work product, such as a design document, data structure, or code is about to begin development, it is important to go back to the suppliers of the subset of the dependant requirements. You can then provide an overview of what is about to be done. An example of this overview is as follows:

We are about to code the FDA approval received event.
You supplied the following list of requirements that are associated with this event (Reminder, the supplier may not have supplied requirements that will be impacted by this event).
Supply a list of requirement identifiers and name that requirement. A good requirements management tool will be useful in identifying and building this list. Also include the original supplier and the last approved state. Include any requirements that are impacted by association.
As a point of clarification, I would like to discuss with you any changes that may have developed since our last discussion.

This will initiate a trigger to be kept in the loop. Remember the same people who are present during the review of later work products may not be the same people who approved the requirements specifications!

Once you identify the changes, change management begins. This includes analyzing the change, identifying the impact, specifying the change and impact and validating the change through the normal review cycle.

SBDi is available to help educate teams in identifying changes in the requirement set and how to identify its impact and manage them.

Our services include:

Education of the management and development team on the value of the development, implementation and use of anti-patterns.

Teaching how to identify, develop, validate, and implement anti-patterns.

Developing project specific anti-patterns.

Developing a divisional or corporate process for the development and implementation of anti-patterns.

Review of existing anti-patterns for quality.

Pat Ferdinandi