REQUIREMENTS “IBILITIES”

On the surface, the requirements definition concept seems pretty simple—identify what the customer wants and then figure out technically how to construct it. The general scope discussion to this point has had that flavor. However, there are a set of not so obvious issues that fall into the crack of the requirements definition. We call these the basic nine “ibilities”: 1. Traceability 2. Affordability 3. Feasibility 4. Usability 5. Producibility 6. Maintainability 7. Simplicity 8. Operability 9. Sustainability Project Level 0 3 2 1 1.1.1 1.1.2 1.1.3 1.1.4 3.2.1 3.2.2 3.2.3 3.1 2.1 1.1 1.2 1.3 2.2 3.2 Level 3 Level 2 Level 3

Each “ibility” represents a work unit attribute to be considered in the requirements definition evolution from concept through design. We must recognize that the project goal is not just trying to produce a stated deliverable. It must also consider a broader technical look at the resulting attributes of the result. In order to do this it is necessary to review the approach taken and adjust the scope statement according to each of the nine ibility attributes to ensure that the approach chosen appropriately matches the real requirement. In many cases, a particular solution will involve a trade-off of one or more of these attributes based on time, quality, functionality, or cost constraints. These deci- sion alternatives will present themselves along the following general lines:

1. Present versus future time aspects 2. Ease of use versus cost or time 3. Quality versus time or cost 4. Risk of approach

5. Use of new strategic technology versus a more familiar tactical approach, and so on

As the project moves through its life cycle processes of scope definition, physical design, and execution each of these considerations should be reviewed. All too often one or more of the ibilities is ignored or overlooked and the result is downstream frustration by someone in the chain of users or supporters of the item. The section below will offer a brief definition and consideration review for each of the ibility items:

Traceability relates to the ability to follow a requirement’s life span, in a forward

and backward direction (i.e., from origin, development, and specification, its subsequent deployment and use, and periods of ongoing refinement and itera- tion in any of these phases). Envision traceability this way. If a design element or WP specification is changed the configuration management process will document this and be the foundation for communicating it accordingly. As an example, if a pump has had a change made to its design how will we know later that we have the correct pump?

Affordability relates to a match of the design approach to the budget. There is

always pressure to cut costs through the design, but in many of those decisions cause some adverse impact on another of the ibilities.

Feasibility can wear many hats in the project environment. The most obvious

of these is the technical feasibility of the approach. Oftentimes, stretching to achieve some performance goal will go beyond the existing technical capabili- ties and create additional risk. In similar fashion, the lack of critical skills avail- ability can adversely affect the outcome. Think of feasibility as anything that can get in the way of success, whether that be technical, organizational, politi- cal, resource, or otherwise.

Usability is similar in concept to operability, except that in this case it more involves

the resulting value generated by the output. It is what the process or product does in the hands of the future user. This can be either reality or perception based, but is certainly a concern for the project team to deal with.

Producibility is an attribute associated how the actual item will be created. In

many cases, there is a gap between the designer and the builder, so the key at this stage is to be sure that the building community is represented in the design and probably even in the initial requirements process. Think of this as a “chain”

Scope Management • 141

of events that need to be linked together and not just thrown over the wall to the next group. Each component in the life cycle needs to consider this attribute.

Maintainability deals with the item in production. The consideration here is how

much effort is involved in keeping the device ready for operations. In the case of high-performance devices there is often a significant downtime for mainte- nance. Having a device capable of “jumping tall buildings with a single bound” sounds good, but what about if it can only do that about 10% of time, with the remaining period being down for some type of maintenance. There is clearly a trade-off consideration here. Maybe the design trade-off in this case is to design a way to perform the maintenance quicker, but certainly the best choice is not to ignore the issue.

Simplicity is an overarching concept. Complex is the natural state. The goal needs

to be finding ways to achieve the required output as simply as possible. This is a motherhood statement, but a real requirement to keep in perspective.

Operability involves the future user’s ability to easily and safely use the product

or device. Many years ago, aircraft designers found that the location of gauges, switches, and knobs had a lot to do with the safe operation of the airplane. Every device has characteristics similar to this. Think of this attribute as not chang- ing the requirement, but rather making the functionality easier to use and safer. Automobile designers in recent years have found this to be an issue with some of the new functions being installed in the modern car.

Sustainability is likely the least understood of the ibilities. This goes beyond all

the other attributes in that it evaluates the ability of the process or product to exist long term. Will the underlying technology survive? Will the design last as long as required? In high-technology projects this can be one of the most difficult factors to deal with given low predictably of the next new technology. Maybe “predictability” is in fact the tenth ibility. If the project team had an accurate view of the technical and organizational future this goal could be bet- ter achieved. All too often, an underlying technology is used in the design only to find in a much too soon that some better technology has been introduced to make the current approach obsolete.

The final word on this set of concepts is that they are important to both short- and long-term success of the project. One of the keys in both requirements and design reviews are to go through the nine ibilities list and resolve the trade-offs outlined here. This process may well be equally important to getting the user requirements correct because if the correct choices are not made here, then the user will still feel that the requirements were not met.