Would you agree that requirements engineering is a wicked problem as defined in Wikipedia?


No, I don't agree at all. Nor do I agree at all with the the concept of a wicked problem.

Firstly, I view the term "wicked problem" as unprofessional and having no place in engineering - the use of emotive, value based language in counterproductive to rational thought and action, notwithstanding the accomplished people who have contributed to the use of the term.

Secondly, the definitions of a "wicked problem" are full of challengeable assertions, and thinking that I would only describe as "muddled"

I agree that requirements will always be a problem, in the sense of contributing to less than ideal outcomes from engineering. Most requirements problems reflect poor creation of requirements as a result of poor design (poor solution decision making). That is, poor design creates poor requirements on elements of the solution.

Regarding requirements engineering (as distinct from design engineering), the 90's saw major recognition of "the requirements problem". The first decade of this century saw people trying to do something about it, with mixed results. This is evidenced by the huge increase in requirements engineering literature and conferences over the decade. The decade we have just entered will be the decade in which reasonable progress is made (I predict). The next decade I expect will see major successes in addressing "the requirements problem", that is, substantial improvements in the extent and effectiveness of requirements engineering practices.

We have already seen over the last two decades considerable improvement in requirements engineering practice, as evidenced by huge improvements in requirements specification standards (DIDs). We have seen problem domain modelling to capture requirements being routinely practiced in the IT sector, with considerable benefit. We presently see a reorientation of agile development to give greater emphasis to the capture of what is already known about "the problem" - aka Scott Ambler.

The very effective requirements capture and validation techniques that I have been practicing since 1985 and teaching internationally since 2001 are starting to be practiced by many international clients - the leaders of industry worldwide. Only last week one client - Draper Laboratory at MIT, Cambridge, MA - told me that they had been using these techniques with NASA, and that NASA was in awe.

Is world enterprise now going to stop learning? Of course not.

Requirements engineering is no more a "wicked problem" than is design engineering, project management, or playing football.


"The best thing about the course was the real-life examples"

Requirements Analysis & Specification Writing Course
delegate, Australia

PPI currently presents courses on 6 continents


Featured Course

Requirements Analysis & Specification Writing
Las Vegas, NV

13 - 17 November, 2017

Requirements Analysis and Specification Writing are sciences practiced by many, mastered by surprisingly few. And yet, the payoff from achieving excellence in these areas is large. The two aspects, Requirements Analysis and Specification Writing, are treated as separate but related topics, each in a course of three and two days duration.

Brochure | Register Now

Systems Engineering NEWSLETTER

SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.