Reference no: EM131226745

Engineer management case study

Question:

After watching the lecture and reading the textbook on Requirements, your assignment is to come up with a list of questions to be used in an interview you will do with a new customer in your role of field engineer for a food service equipment manufacturer. A company that that manufactures baked goods (bread, cake, pretzels, confectionary goods) wants to open an additional facility to increase their production to meet a surge in demand. You are interviewing the bakery's owner, a baker, and his head of manufacturing. You need to come up with a list of questions to start your analysis so that your company can provide a proposal to outfit their new bakery. The site is not chosen yet. These questions should not be off the top of your head, but methodical based on the lecture, and the textbook which gives you SPECIFIC guidance on how to start such an exercise. The number of questions will start modestly, then likely grow. Your assignment should be written/formatted as if you are writing a memorandum to the head of engineering of your company. In a paragraph state what you are doing and why, and what your approach is, then provide your proposed list of questions to ask, then end with a paragraph that describes how you are going to use the answers ot the questions to come up with a proposal to the company. The assignment should be 2-3 pages in length.

2.1 DEFINITION OF THE PROBLEM

CURRENT DEFICIENCY

The system engineering process generally commences with the identification of a "want" or "desire" for something and is based on a real (or perceived) deficiency. For instance, suppose that a current capability is not adequate in terms of meeting certain required performance goals, is not reliable or available when needed, camot be properly supported, or is too costly to operate. As a result, a new system requirement is defined, along with a priority for introduction, the date when the new system capability is required for constrner use, and an estimate of the resources necessary for acquiring the new system capability. To ensure a good start, a complete description of the problem should be presented in specific qualitative and quantitative terms, in enough detail to justify progressing to the next step. More specifically, one should pose the following question: What is the nature and magnitude of the problem, and what are the associated risks if the problem is not addressed?

The requirement for identifying the need (as a starting point) may seem to be rather basic or self-evident. However, it often happens that a design effort is initiated as a result of a personal interest or a political whim, without the requirements being adequately defined. In the software area (in particular), there is a tendency to accomplish a lot of coding before identifying the functional need for such In addition, there are instances in which the engineer sincerely believes that he or she knows what the customer needs, without first having involved the customer in the process. In essence, the attitude "design it now, fix it later" often prevails. As a result, it is not mcormion for someone to proceed with the design and ultimately produce a product that really was not wanted (or needed) in the first place. This approach, of course, can be rather expensive.

Defining the problem is sometimes the most difficult part of the process, particularly if one is in a rush to "get going" Yet, the number of false starts and the ultimate risks can be rather significant unless a good foundation is laid from the beginning. A complete description of the need, expressed in quantitatively stated performance parameters where possible, is essential. It is important that the results reflect a true customer requirement, especially in today's environment where resources are limited.

2.2 SYSTEM REQUIREMENTS NEEDS ANALYSIS

Given the problem definition, a needs analysis must be accomplished, with the objective of translating a broadly defined "want" into a more specific system level requirement(s). At this point, the following questions should be addressed:

1. What is required of the system, stated in functional terms?

2. What specific functions must the system accomplish?

3. What are the primary functions to be accomplished?

4. What are the secondary functions to be accomplished?

5. What must be accomplished to completely alleviate the stated deficiency?

6. Why must these functions be accomplished?

7. When must these functions be accomplished?

8. Where is this to be accomplished, and for how long?

9. How many times must these finctions be accomplished?

There are many basic questions of this nature that may be applicable, we it is important to describe the anticipated consumer (customer) requirements in a functional manner in order to avoid a premature commitment to a specific design concept or configuration and, thus, the unnecessary expenditure of valuable resources at this point in time. The basic objective is to define what is required before "locking in" on the how it is to be accomplished.

Accomplishing a needs analysis in a satisfactory manner can best be realized through a team approach involving the customer, the ultimate consumer/user (if different from the customer), the prime contractor or producer, and major suppliers (as appropriate). The objective is to ensure the proper communications between the various parties involved. In particular, the voice of the customer must be heard, and the system developer must respond accordingly. Methods such as conducting surveys and interviews, the utilization of good checklists, the application of such tools as quality function deployment (QFD), and related techniques/models may be employed?

The "requirements definition process" commences from the beginning, as illustrated by the top block in Figure. On the one hand, while it may not be possible to go to the depth suggested earlier, it is essential that as much as possible be accomplish and as early as possible! On the other hand, there is always the temptation to delay such and to determine the requirements later during the system design and development process (or even during system test and verification). In such cases, program schedules are likely to slip, the resultant costs could be significant, and the ultimate needs of the customer (consumer) will not be net!