Skip to main content

Design Phases in Mechanical Engineering

https://www.mcgill.ca/engineeringdesign/step-step-design-process/design-phases-mechanical-engineering/problem-definition

 

Problem Definition

Problem definition is an essential initiating phase of any product development. In this phase you must

  1. understand existing problem, associating available data, images, and fundamental principles with it;
  2. generate strategies and methodology;
  3. critically evaluate state-of-the-art technologies, other machines and components available on the market.

 

Main steps of the problem definition

  • Understanding the problem

An essential requirement for an engineering design project is to formulate a problem precisely and to present a solution accurately. To formulate a problem, you must consider both real-time physical conditions (product shape, functionality, production and user environment, available resources, design, and production methods, etc.) and corresponding mathematical description.

  • Clarification of objectives

First, it is necessary to distinguish goals and objectives.

Goals are general guidelines that explain what the client (or engineer) wants to achieve undertaking a project.

Objectives define strategies and implementation steps to reach the identified goals. 

A widely used method of organizing the customer requirements is by developing an objective tree. It provides a distinct and concise method of representing the requirements of the project in the form of a diagram in which different objectives are related to each other.

 

Three steps to develop an objective tree

  1. Preparation of a list of design objectives, i.e., a list of desired attributes of a design.
  2. Sorting the list into higher-, mid- and lower-level objectives.
  3. Drawing a tree diagram of objectives, showing hierarchical (vertical) relationships and interconnections (horizontal) between the objectives.

In the following figure the blue lines represent hierarchical connections between the objectives, the red lines describe interconnections.

Hierarchical relations and interconnections in the objective tree
Hierarchical relations and interconnections in the objective tree

In practice, when drafting an objective tree, the interconnections are usually not shown.

  • Establishing of user requirements

After identifying the needs as a wish list provided by the customer, you must translate them into a set of specifications that determine how the product will function. However, for the specifications to fully address the needs, the latter should be first accurately transformed into requirements. Requirements are defined by the designer by prioritizing these needs followed by interpreting them into technical descriptions and definitions that identify the objectives of the product.

A requirement can be defined as a statement that specifies function and performance of an intended product. Usually, all requirements are divided into two major categories:

  1. Functional requirements describing what the system should do;
  2. Non-functional requirements defining constraints and limitations of the product and the development process.
  • Identification of constraints

Design constraints are conditions of a successful engineering project. They often (but not always) originate from the design requirements and help narrow down choices when developing a project. The word “constraint” bears somewhat a negative inflection; however, constraints are essential for the project to meet the exact needs of the customer.

In general, design constraint for engineering projects can be divided into several types, including but not limited to:

Scope

Scope relates to specific deliverables, defined by the customer (in coordination with the project team).

Functional Constraints

These constraints specify the limits of required functionality and technical data

Health and Safety Constraints

  1. Human – working conditions, health protection means;
  2. Environmental – land and sea condition, air quality, noise level, etc.

Manufacturability

This type of constrains applies to the final phase of the product development, its manufacturing and assembling: methods of production, preferred suppliers, installation procedure, etc.

Timing Constraints

Timing constraints in a project are based on the deadlines required by the customer and coordinated with the development team. Other time constraints may be also laid over by the team manager in the form of project schedules (Gantt Cart, milestones, etc.) and must conform to the customer’s deadlines. Project schedules can be grouped as:

  1. Development schedule (conceptual and embodiment design, detailing, compliance tests, modelling and analyses);
  2. Production schedule (manufacturing, purchase of materials and off-the-shelf components, assembling, packing, transportation);
  3. Delivery schedule (delivery date, integration and training, mode of distribution, chain of supply and distribution, etc.)

Economic Constraints

  • Cost
  • Resources

Ergonomic Constraints

In design process customer needs are defined in the initial phase of the project. The same approach must be used for definition of the end-user requirements in order to reach the best efficiency/cost rate of the product. Design process with ergonomics in mind helps reducing the end product’s cost and delays in its development, as well as ensures better safety of the end-user during product exploitation and the quality of use in general.

Ergonomics must be addressed not only for the sake of exploitation of the final product, but for the mode of its production, servicing, and testing.

Environmental Constraints

Engineering practice with ecological constraints addresses the growing need of providing society and human welfare with simultaneous protection of the natural environment in which society exists and where production of goods and services are realized.

Aesthetic Constraints

Products that have a nice- and good-looking views, as well as user-friendly and well-arranged interfaces, have better chance to get an attention of the customers and become commercially successful.

Legal/Ethical Constraints

These constraints reflect such aspects as:

  1. Laws, rules and regulations (e.g., traffic regulations, municipal legislation, instructions and manuals for product use, special training and procedures for product service, etc.);
  2. Ethics (engineering ethics, deontology, public safety, health and welfare);
  3. Intellectual property (non-disclosure agreements, licensing, patents, trademarks, copyrights).

Social Constraints

These constraints are defined by the potential impact on society, its unemployment rate, interconnection of social life and environment, cultural and language traditions, social habits and practices.

  • Establishment of the functions

One more step before elaborating the final problem definition is to understand and establish the functions of the product to be designed or developed. In general, the engineering functions can be classified in terms of transformation, transfer or flow of energy, materials, or information.

Without proper definition of the functions of the designed system, the latter is subject to the risk of poor performance or failure.

  • Formulation of design requirements and design specifications

Project specification, that includes formulation of design requirements and design specifications, is the step where all collected information and data are processed and the following details are defined:

  1. Project requisites;
  2. Product requirements and user needs;
  3. Market conditions;
  4. Clarification of company strategies for the product development phases.

Project specifications summarizes all information about the product, its technical characteristics, development process, available resources, production plan and postproduction goals, etc., as listed.

  • Project definition

The final step of problem definition is the project definition. In this phase the project gets final approval; real product development starts, in accordance with the company objectives and strategies, current market trends, available technologies, customer needs and the main constraints of the project.

 

Comments

Popular posts from this blog

The Difference Between LEGO MINDSTORMS EV3 Home Edition (#31313) and LEGO MINDSTORMS Education EV3 (#45544)

http://robotsquare.com/2013/11/25/difference-between-ev3-home-edition-and-education-ev3/ This article covers the difference between the LEGO MINDSTORMS EV3 Home Edition and LEGO MINDSTORMS Education EV3 products. Other articles in the ‘difference between’ series: * The difference and compatibility between EV3 and NXT ( link ) * The difference between NXT Home Edition and NXT Education products ( link ) One robotics platform, two targets The LEGO MINDSTORMS EV3 robotics platform has been developed for two different target audiences. We have home users (children and hobbyists) and educational users (students and teachers). LEGO has designed a base set for each group, as well as several add on sets. There isn’t a clear line between home users and educational users, though. It’s fine to use the Education set at home, and it’s fine to use the Home Edition set at school. This article aims to clarify the differences between the two product lines so you can decide which

Let’s ban PowerPoint in lectures – it makes students more stupid and professors more boring

https://theconversation.com/lets-ban-powerpoint-in-lectures-it-makes-students-more-stupid-and-professors-more-boring-36183 Reading bullet points off a screen doesn't teach anyone anything. Author Bent Meier Sørensen Professor in Philosophy and Business at Copenhagen Business School Disclosure Statement Bent Meier Sørensen does not work for, consult to, own shares in or receive funding from any company or organisation that would benefit from this article, and has no relevant affiliations. The Conversation is funded by CSIRO, Melbourne, Monash, RMIT, UTS, UWA, ACU, ANU, ASB, Baker IDI, Canberra, CDU, Curtin, Deakin, ECU, Flinders, Griffith, the Harry Perkins Institute, JCU, La Trobe, Massey, Murdoch, Newcastle, UQ, QUT, SAHMRI, Swinburne, Sydney, UNDA, UNE, UniSA, UNSW, USC, USQ, UTAS, UWS, VU and Wollongong.

Building a portable GSM BTS using the Nuand bladeRF, Raspberry Pi and YateBTS (The Definitive and Step by Step Guide)

https://blog.strcpy.info/2016/04/21/building-a-portable-gsm-bts-using-bladerf-raspberry-and-yatebts-the-definitive-guide/ Building a portable GSM BTS using the Nuand bladeRF, Raspberry Pi and YateBTS (The Definitive and Step by Step Guide) I was always amazed when I read articles published by some hackers related to GSM technology. H owever , playing with GSM technologies was not cheap until the arrival of Software Defined Radios (SDRs), besides not being something easy to be implemented. A fter reading various articles related to GSM BTS, I noticed that there were a lot of inconsistent and or incomplete information related to the topic. From this, I decided to write this article, detailing and describing step by step the building process of a portable and operational GSM BTS. Before starting with the “hands on”, I would like to thank all the pioneering Hackers and Researchers who started the studies related to previously closed GSM technology. In particul