You’ve got it exactly right! Thanks again!

So, in this case we have “cut 70% of waste”, “keep the production ratio planned”, will be the requirements.
And we also have “reduce number of times the machine is feed”, “turn off the machine while not producing” as design (process design?)
And we also have “system that turn off the machine by using sensors and other stuff” also as design (system design?)

Are those assumptions correct?

You’ve got it exactly right with your general statements.

You may also have it right with “monitor and control energy”, but I can’t know without knowing the details. Why do you want to monitor and control the energy? What benefit do you get from that.

You could easily argue that the benefit (lower cost, longer operating life, better process control – whatever it is) is more of a requirement, and “monitor and control energy” is more of a design decision (how you design your process to meet the requirement). Better process control would also force a “why?” question – higher yields? products that look better (and can garner a higher price in the market)? faster production?

What does faster production get you? Higher return on assets? Reduced cost per unit? Take a look at Defining Problems with Cause and Effect Diagrams and see if that helps.

I look forward to hearing more from you – your explanation about the difference between requirements and design is spot-on.

I was looking here to find some hints, and I found this article great. A lot of good resources also.

Yesterday I was asked about the differences between a requirement and a functionality.

My answer to that question was that a requirement is the “what capability does we need” and for the functionality was “How we implement that capability”. And also pointed that a Requirements is a output of a process called “Requirements Elicitation” whereas Functionality is an output of design and build.
Let me try to explain. A user want a system X that allow him to perform monitoring and controlling the energy consumption of some machine. Here “Monitor and control the energy…” is a requirement whereas the screens with a dashboard is a functionality to meet that requirement.

Are my assumption correct, or am I completely wrong?

Looks like some interesting content – it’s in my feed reader now, looking forward to checking it out.

Scott

I just came here from this blog.
http://thebusinessanalyst.blogspot.com/

Seems to be talking the same thing.

Requirements and design are two separate areas.

Cheers

Your lockdown idea is a good one – I’ve used it in a “past life” when working on a large engagement. It is easiest to use when you are either part of the organization (especially if you have some juice), or as an outsider with a strong reputation and good relationships. I would caution folks to not try the lockdown approach when they are relatively unknown. If that’s the case – get a project sponsor within the organization to create the lockdown, and then just facilitate it for them. If the group is resistant, take some cues from the movie, Twelve Angry Men, and be the jury foreman. Create an association of “we all have the same goal” – not – “You must tell me”.

Getting to ‘right’ not ‘perfect’ is another great piece of advice.

Keep sharing your thoughts with us!

Depends on Product process in a product company versus new business application inside an a company working with IT.

Mock up screens normally come into play for the end user experience. In your article these would be design. But the reality is that humans normally have a picture in mind (expectations). And expectation mgmt is key to any product/project.

My guidance for function requirements within a company with IT: If the product/businss application has a road map – write down everyhting you are willing to pay for (whether it is ver 1, or ver 2, or ver3) – as design for ver 1.0 must not limit ver 2or3.
Items where you need an impact analysis (can not determine until we get more information from design pass ) are clearly handled in DESIGN.

The line does blur inside large companies when dealing with learge business units.

Another item – requirements gathering has a tendancy to go on forever. If the group is no skill at requirements (and most businss units are not) change tactices. Get them in a room for a week. And force a lock down deadline. The document can and will change – but as long as you have address or identifed all reasonable issues that could inmpact scope/timeline – you must force them to a “its right not perfect” point – and then handle all future changes via formal change control in the mgmt reviews.

This one is alsways tough in business unit customers. For a Product Mgr at a product company, the line somewhat easier to handle.

I generally agree with what you’re saying – especially the part about not specifying implementation details. I do, however, believe that the process of creating a PRD does involve some articulation of what the software is expected to accomplish. I’ve just written a separate response (with more diagrams) titled Software requirements – process and roles.

I believe there are synergies in the process that require some steps to be performed by the same person, and some to be performed by different people.

Thanks again for reading and especially for commenting on several of our posts!

I think the “ideation” step you describe is critical. Would you characterize it as a form of scoping; i.e. deciding what “system(s)” (software, hardware, manual procedure, documentation) will achieve the business goals?

Taking your example goal of reducing average support call time to five minutes per call, we might choose to achieve this goal partially through support rep training and partially via software. In doing so, we essentially are designing, at a very high level, a solution to the problem. You can almost think of it as “business process architecture”.

Once we complete that design step, we now are faced with specifying the responsibilities of the systems. I think it’s fair to characterize this next step as a requirements activity (correct me if I’m wrong, but you would call such a specification a PRD).

However, specifying the requirements at the scope of the software system does not mean we should mention any user interface or process entities. In fact, we can simply further scope the original business requirement.

The original requirement:

“The average support call should take no longer than five minutes.”

becomes something like:

“Assuming all support call representatives have x amount of training, the average support call should take no longer than five minutes.”

Thus you can see we still do not yet need to “design” any interface or interaction with the software system, even after we decide software will be part of the solution.