A Systematic Approach for More Effective Communication of Functional Requirements and Specifications

[article]

Another extension, one that proves especially helpful when dealing with new systems that implement new technology, is the addition of the infrastructure aspect of the project. The inclusion of this aspect allows the analyst to include the business processes and organizational roles and responsibilities of the MIS group that will support the new system. Just as each piece of system functionality supports a task within a business process performed by an individual or individuals within one or more groups in the business unit, each piece of system functionality is provided by one or more infrastructure components supported by an individual or individuals within one or more groups in the MIS unit. The infrastructure sheet(s) utilize the same structure as their counterparts on the business side of the documentation and will also be tied to the IT system sheet. Similarly, the structure can be extended to include the help desk aspect of the support function and the performance aspect of system functionality. These extensions can greatly improve the probability of identifying training and staffing requirements that would otherwise go undiscovered until much later in the project.

The Benefits
The key benefits of using this approach center around improved communications to increase the likelihood of identifying missing or misunderstood requirements and unintended impacts to other systems or user groups early in the project. We have to assume that everything a user tells us is important; that it contains information we need in order to succeed. By providing a container capable of holding any information we gather, the approach described here allows us to separate the data-gathering activities (focus on listening) from the analytical activities (putting the information gathered into the correct context). This allows us to focus all our energy during the interviews on active listening. By providing a matrix that encourages the enumeration of all of a system's functionality and the articulation of the past, present, and future of each of those pieces of functionality, the approach makes it easy to identify missing requirements. The first round of interviews with a user community typically ends with much of the needed information missing. Each layer of the matrix will look much like a checkerboard with some the cells filled and others empty. The structure highlights the missing information and allows the analyst to focus future interviews on obtaining the information needed to complete the matrix. The consistent use of explicit definitions that allow the information gathered to be repeated back, without modification or interpretation, within what the analyst believes is the correct context, facilitates the identification of misunderstandings.

By providing a structure that ties business processes to IT systems and organizational roles and responsibilities, the use of the matrix facilitates the early identification of unintended impacts to other user groups or to other systems. Business process diagrams may identify other groups involved in the process but not currently part of the project. Screen shots can identify fields that are not part of the current project, triggering questions about other users of the system. By identifying these things early in the project we increase the probability of success by making it clear that we need to do one of three things:

  1. Increase the scope of the project to include these systems or groups
  2. Reduce the scope of the project to exclude functionality that would
    impact them
  3. Shelve the project until business constraints allow their inclusion

Any one of these actions allows us to avoid a failure that would otherwise result.

Conclusion
Successful IT projects address all the relevant aspects of the business that need to change to solve a business problem or seize a business opportunity. Defining requirements as they relate to the development of a software application is difficult enough. But it is not enough to guarantee success. Business processes, roles, and responsibilities must also be examined for required changes. This greatly increases the complexity of the communications. Avoiding the failures that have plagued IT projects in the past requires a new approach that facilitates complex communication and the early identification of missing or misunderstood requirements and specifications. The approach described in this article uses a simple structure within which effective problem-solving communication can take place. This structure both tracks and guides communications to a complete and correct result.

About the author

Bill Walton's picture Bill Walton

Bill Walton has fifteen years of experience in software development organizations, mostly at large companies like IBM, Compaq Computers, and American Airlines/Sabre. He now works as an independent IT consultant specializing in project management, requirements definition, and software testing. He believes that advances in these areas are necessary to turn software development into a true engineering discipline. He welcomes comments, criticisms, and suggestions via email at bill.walton@jstats.com.
 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01