So You Want To Be An Engineer. Ray Floyd
BCD arithmetic applications. The emulator project was funded and development completed. When the system entered Product Test, the project failed miserably. Whereas most BCD operations performed in the hardware were measured in micro-seconds to complete the desired operation, the emulator took an extremely long time. In some instances, rather than MIPS, the unit was said to perform in furlongs per fortnight. Needless to say, the emulator was never released and the hardware unit became the standard system.
In the second case, the project was a shipboard guidance and collision avoidance control system. The proposed system had international impact, and was viewed as being a great prospective revenue producer for the corporation. The product went through the normal testing process, including extensive sea trials and appeared to be an unqualified success. Unfortunately, when the Market Requirements and Product Specification were written, the Service aspect of such international travel was not taken into account. As a result, when a problem did occur, the service engineer might have to be flown from one country (where the service center was located) to another where the ship was docked. In some cases, the service engineer would have to be transported to the ship at sea via a helicopter. To further complicate the servicing aspects of the product, in some cases when the ship docked at a new location, the service engineer could not leave the ship, as his or her passport was not acceptable to that country and the engineer would have to remain on-board waiting for the next port of call. The product was not as successful as had been hoped.
Project successes can be measured by cost, time, and revenue as constituent parts. In most projects, the better the Market Requirements and Product Specification, the higher the probability that the project will be a success. This doesn’t mean a lengthy tome, but a set of documents that fully explore the anticipated market and user. Add to that the rigorous review and test processes needed, and, for each level of control, the higher the probability of success. Understand the process, work the process, and ensure your projects stay in the good regime.
A product’s success, or failure, may often depend on how well the product was defined before it was developed. Some products based on a developer’s concepts may become popular and in demand, but in most cases, because of the narrow perspective of a developer’s specific application, such products rarely hit the high revenue mark. To raise the probability of success for a newly announced product or product enhancement, both the marketing and development communities must have a road map of the direction they wish to take. These road maps are referred to as Market Requirements and Product (or Technical) Specifications, both of which are required for the Testing organization to develop a comprehensive Test Plan. The more complete and detailed these two documents are, the greater the probability that the product will succeed in the market place.
These two documents are not developed in a vacuum by each group, with Marketing (which often includes the Sales Department, which is responsible for the day-to-day-in-the-face exposure to the customer) writing the Market Requirements and Development the Product Specifications. Marketing may ask for new, not yet invented, technology, and Development too often then provides a timetable that is too long and too expensive. Such differences must be negotiated and resolved. Special features may require new algorithms, or other development work that will not meet Marketing’s expectations — and the features may be so narrow in scope that their absence will not affect the overall acceptance of the product by the user community.
In many cases, the Marketing and Development groups will modify and discuss both documents until a consensus can be arrived at in order to meet the market needs, in a reasonable time, at a reasonable cost, with the most highly desired features present. In addition to Marketing and Development, three other organizations are called upon to help ensure the product requested and the product delivered are the same. Those organizations are Product Test, Manufacturing, and Quality Assurance. The specific roles carried out by each will be investigated in later chapters.
Most successful products have their success grounded in complete market research conducted before the product is designed. Although there are a number of facets to be discussed within the Market Requirements document, perhaps first and foremost is, “Who is the intended user group?” Immediately after is the question, “What problem, or problems, will the proposed product solve?” If either question is found to lack a definitive answer, perhaps the funds for the development undertaking would be better placed elsewhere. In some cases, the breadth of the possible applications may not be fully anticipated while writing the Market Requirements document.
Consider, for example, the simple requirements for road building equipment. Two sets of extreme conditions are real-life cases of environments in which the same kinds of equipment were required to perform similar tasks under totally opposite condition extremes. Case one was road building equipment (trucks, bulldozers and graders, etc.) to build a road over forested mountains, then down through the densest jungle in the world within a war zone. There were summer monsoons of 300 to 500 inches of rain each spring-summer season, and another 100 to 200 inches during winter monsoons. Diluted fuels, rust, fungus, and so forth were daily problems that had to be overcome to complete the road. The other extreme was California’s Death Valley, which is absolutely arid, with summer temperatures in excess of 120 degrees, no rain, and limited sources of water for equipment and workers, and at times, extreme dust conditions. The intense heat coupled with the dust that infiltrated equipment wear points created havoc in the road building process.
Another example considers the Market Requirements for a new design of a desk top computer used by experienced engineers that could also be installed at airport car rental counters and used by someone hardly as computer-literate. In such cases, documentation for the system operation, if not fully specified in the Market Requirements, could result in instructions with technical jargon essentially not understandable by the less computer literate user.
There are a number of items the Market Requirements should address, among these being:
• Proposed user problem requiring a solution.
• Who is the targeted user community?
• What is the sophistication of the user community (neophyte, intermediate, advanced)?
• When can the product be delivered and at what cost?
• What are the required features and/or modifications?
• Who is the competition and how are they performing (in this product venue)?
• What are the sales expectations to ensure profit (high, median, and low)?
• What languages are required to support the user and field service personnel?
• Is there any special technology constraints that must be solved?
• Strengths, weakness, opportunities, and threats (SWOT) analysis for the product.
• Is there a growth path for the product and future model enhancements?
• What is the Mean Time Between Failure (MTBF) criteria expected/required?
• What is the Mean Time To Repair (MTTR) criteria expected/required?
• Are there any special or unique needs for testing by Product Test, Quality, and handling by the Field Service organization?
Note the word required inserted into the MTBF and MTTR list items. There is a significant difference between expectation and absolute requirement, and these differences must be understood and agreed to by Marketing and Development.
Specifications are something more than simply a passing reference when talking or learning about products and product design and development. Specifications should embody an underpinning of market requirements and existing standards, as well as use, user and maintenance requirements, and limitations, as well as performance requirements.
Product Specifications and Technical Specifications