What if project requirements depend on discoveries while designing?

Question

I asked a question where a comment pointed out:

Requirements are things that you should be drafting to figure out what you want, before you know exactly how you are going to solve it.

I was doing it backwards. I was going to define requirements after I had investigated design ideas to weigh up compromises that might be made. What I called requirements were flexible, depending on the cost vs effectiveness of design ideas.

If I do not know what I want before I consider design ideas, if the possible criteria are not requirements, then what are they?

The problem is the product fits into a larger system, ultimately the goal is profit from a business perspective, but considering the whole system's economics while designing the one product would be too complicated, so the requirement for "maximum profit" doesn't help!

Answer 1

History tends to teach us that attempting to design something without having a clear idea of what you ultimately want to achieve rarely works out well. Equally the definition of the problem to be solved should address the underlying problem, not just be an outline of a proposed solution.

There is, of course, a perfectly valid place for open-ended or speculative research and development, but this isn't quite the same thing as actually designing something.

Often, if the requirements of a design seem very flexible it's because they haven't been defined well enough. The requirements should define what you want to achieve not a wishlist of 'features' which may or may not assist in solving the core problem.

Of course context matters a lot. For example if you are a member of a design team it may well be that another designer will give you a very specific set of specifications. Say you are designing an alternator for a specific engine the lead designer may well tell you specifics like maximum current capacity, duty cycle, average current capacity, voltage tolerance, maximum mass, environmental durability metrics and life expectancy.

On the other hand if you are developing an overall design concept for a car you might be negotiating rather more diffuse goals with strategic marketing people who might very well have rather more abstract objectives in mind and it is when it comes to 'designing' a marketable product rather than a strictly engineering a solution to a well defined problem.

This ultimately comes down to the fact that the goal of 'what can I design that people will buy at a profitable price for me' is not a strictly engineering problem. In the same way that 'how can I improve the reliability of this pump without increasing its cost too much', very much is.

Similarly anyone who has worked in any kind of freelance capacity will be well aware that what a client says they want is often a statement of how they imagine the problem should be solved rather than a definition of what they actually want the design to achieve.

I think that there is a good argument that one of the defining skills of engineering is the ability properly identify what the real problem/need is without presupposing a particular solution and similarly to be able to differentiate between problematic symptoms and their underlying cause.

Answer 2

Requirements come in 2 flavours, client requirements and technical requirements. Client requirements are converted to technical requirements because they are usually too abstract to be used as absolute metrics.

For example, the client might say "light," but your technical goal is something more tangible like "0.5 kg or less." It is important to understand that something might have been lost in translation here and that this is a slight corruption of the message so it's easier for you to work with the problem.

Now while exploring the design space you might need to specify secondary considerations. These then may become specifications to secondary engineering tasks, requirements for subcomponents if you wish. The thing to notice is that the client has changed, it's no longer your original client it is your design (or worse, yourself) that has transformed into a client.

Mixing up client wishes is fine as long as you are still fulfilling the original client goals. However, dragons lie this way. You may ultimately lose sight of what the clients want. Carcasses of many businesses lie on this road. So, best not go there and keep your design realities separated from your requirements. Do not mix requirements you made up with real requirements.

Many companies will do this on multiple levels. Managers try to redefine the clients so that work is easier on them. Engineers, designers and sales specify too tight or to lose requirements. Often they bring in themselves into the process thinking their needs are client needs. Sometimes this is good sometimes bad, but ultimately you do not know if they are or not.

So, to finally answer the question: These are, most likely, not requirements but design realities, limitations and so on. The client needs something, the technical solutions something else.

TL;DR

These are not the requirements you are looking for. Move along.

Answer 3

In context of the question, the goal is to engineer a product to maximize the return on investments (ROI). In order to achieve this one has to engineer the product meet Voice of the Consumer/Customer (VOC) which essentially is the requirements. The hardest part is to understand VOC, or "What is the problem consumers are seeking a solution?".

There is no one size fits all answer to effective requirements gathering. This depend on many things such as the industry, business objectives, size of the market, and many more.

Successful companies such as Apple, Samsung are masters in understanding VOC. In most of these companies the requirements are generated by the Marketing team based on consumer insights. These consumer insights help create requirements documents which in turn are handed over to research and development to generate engineering specifications. In turn research and development develop functional prototype use for consumer testing. Consumer testing helps further refines the requirement before handing fairly well defined set of requirement including cost, and go to market timing to product engineering to fully engineer the product for commercialization.

In summary critical design requirements should be defined upfront, but it is acceptable to refine some during the design and development process. There are many good write-ups and organizations focusing on this topic and some of them are listed below.

References:

• Winning at New Products: Creating Value Through Innovation
• The Product Development and Management Association (pdma)

Answer 4

I think I wrote that comment; I think I also added quite a few examples of what requirements could look like. In that question, you asked something along the lines of "what is the best way to ...". But "best" does not exist if you don't give any guidance on how to evaluate the 'goodness' of a particular solution. What's "best" for me can be something else than "best" for you. That's why I wrote: "to figure out what you want".

In such an early stage of the development process, requirements will generally not be final and may not be very detailed. And it's fine if further investigations lead to the conclusion that the requirements were not realistic and need to be modified.

Requirements and design can be cascaded:

1. Requirement: make a profit with a factory producing N widgets per year at production cost P per widget, for a capital investment C.

2. Design: the factory should have places to a) shape the widgets out of raw materials, b) clean them, c) dry them, d) package them.

3. Requirement: the drying place may cost C/4 and should handle N widgets per year. The widgets come in clean and wet, go out clean and dry. Operation costs of the drying place is max P/10 per widget.

4. Design: we could do it with a 100 kW heater, blowing 5000 m3/h of hot air over the widgets.

Ideally, you break down the engineering tasks such that at the bottom of the chain, different engineers can be working on the different subsystems without having to be aware of all the problems that the other engineers are dealing with. In practice, it will often turn out that some of the choices at steps 2 and 3 were not right and the design (#2) and requirements (#3) have to be tweaked.

But in particular if the work is split up over multiple people, having good requirements upfront, even if not final, reduces the probability that someone comes with a design that provokes a reaction along the lines of: "But that's a ridiculous solution; technically it meets the requirements, but that's not what I meant!"