Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Requirements Management, Stakeholder Management, Strategy
Early alignment of design requirements with stakeholder needs
Agouridas, V., Winand, H., McKay, A., & de Pennington, A. (2006) explored the applicability of requirements engineering and management techniques, traditionally used in the development of software-intensive systems, to the development of electromechanical consumer products, the motivational rationale traceability matrix (MoRalTM) is introduced as a means to support the initial analysis of stakeholder needs and attributes, and the derivation of corresponding design requirements.
The informality of design requirements is a problem, especially in disturbed design teams, because it impacts the ability of a team to communicate. Since design requirements drive the design process, their miscommunication results in serious problems; for example, new products that do not align with the needs of the range of stakeholders to whom they are targeted. This, in turn, has a determinantal impact on traditional business performance indicators, such as market share, the volume of sales, and profit. The applicability of MoRalTM is demonstrated through application to a power solution case study. In this instance, the MoRalTM proved to be a powerful means of supporting the derivation of design requirements that are aligned with customer and other stakeholder needs and are traceable to stakeholder intents.

Why do you agree or disagree with Agouridas, V., Winand, H., McKay, A., & de Pennington, A. that MoRalTM is a powerful means of supporting the derivation of design requirements that are aligned with customer and other stakeholder needs and are traceable to stakeholder intents?

What other methods do you use in aligning design requirements with stakeholder needs?

Agouridas, V., Winand, H., McKay, A., & de Pennington, A. (2006). Early alignment of design requirements with stakeholder needs. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, 220(9), 1483-1507.
Sort By:
I'm assuming you mean "distributed" design teams. Although, disturbed design teams does describe some people I've worked with ;-)

To be honest, I haven't heard of MoRalTM and haven't been able to find any information about it. In theory, understanding customer/stakeholder needs, interests, power, and influence will help in designing a solution that meets the needs and interests of those that will help drive successful outcomes. How effective it is seems to depend on the abilities of the person collecting the information and the willingness/ability of the customer/stakeholder to share the information.

Tools like personas can be helpful, but they're usually composites and don't give a complete picture. With my first Scrum team, I thought we were getting good information on user interests/needs, but it turned out they were just the interests of the PO's manager. I encouraged the PO to talk to customer service - they were running focus groups with actual customers - but it didn't go anywhere. If you have a physical product, I find that focus groups where potential customers can handle and use a prototype is a great way to get feedback on design improvements.
I find the following statement curious: "requirements engineering and management techniques, traditionally used in the development of software-intensive systems, to the development of electromechanical consumer products."

Systems engineering has been heavily focused on requirements derivation on electro-mechanical systems since before software was a thing. Now, off the shelf systems like IBM's DOORS are used to manage and link the requirements which allows tracing up to the sources, or all requirements related to a specific source.

Tracing to customer requirements works better at a higher systems architecture level since customers don't usually think about things in terms of formal requirements. They may specify functions although those are often design solutions rather than design requirements. Once the requirements generation gets down into the details there are "derived requirements", that may describe interfaces between systems. The customer doesn't care about those other than that their product works. As an example, the FAA has a generic requirement that all equipment must perform its intended function. That may be as close to a customer requirement as you can get for the basis of many lower level design requirements.

Instead, customer needs often need to be translated into design requirements. Tools such as operational view diagrams (e.g. OV-1) may be used to describe how the system will be used, which will in turn be translated into functions, physical architecture (the parts performing functions), and logical architecture (how the system works to perform functions). Design requirements are then derived from those aspects of the systems architecture, in lieu of the customer actually providing formal requirements themselves.
I couldn't find anything about MoRalTM generally on the web but the 'motivational' aspect of it motivates me to dig deeper :-)

This subject pertains to an age old problem between requirements and design - and as Keith pointed out, in most cases, the customer requirements themselves are bleeding into the territory of design solutions due to the variety of systems/solutions the customers are exposed to before coming to the table with the product designer. While the RTMs establish the traceability and in some cases used as a defensive tool by either the customer or vendor, the best I have seen is a plain old business requirements document that inputs into the functional requirements document which in combination captures - available data inputs, expected outputs/results and the 'whys' or the business reasons/logic. The 'hows' that connects the dots should be left to the product designers who can take it to the design requirements or design solutions using the previous documents.
Agile based methods, in software, were born because of that. And those were an evolution of object oriented methods to construct solutions. The topic is not from 2006. It comes from something called "software crisis". Those methods took tools and techniques from other approaches, mainly Alexander´s patters (which comes from architecture) or Arnold´s design thinking, both created in 60'-70'. So, nothing new below the sun.
Usually the design requirements are about how the solution will work. It's not always useful to try to explain the how to a customer. (I dare you to tell an executive why SOAPv3 is better than v2!) That's why we have the functional requirements that tell us the what. Customers can understand and relate to functional requirements.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"You can't build a reputation on what you are going to do."

- Henry Ford

ADVERTISEMENT

Sponsors