[sairamkunala]

Requirements is a communication and expectation problem. Not an engineering problem.

Software or hardware engineering is a solution. You can solve the same with a pen and paper if you know what the user needs.

Agile is a way to iteratively validate expectations and revisit and update things with minimal wastage

[mook]

Wouldn't engineering encompass the communication and expectations? When you design a skyscraper, you need to know what sorts of loads is expected on each floor, any height restrictions in the area (are there airplanes around?), etc. When you design a literal engine, you need to know if you're optimizing for weight or power or raw RPMs.

Perhaps you're using the word "engineering" as a synonym of "implementation" (which could work); I'd have thought it was more "design" though (in a technical sense, though I'm sure it might cover some of the aesthetic sense too).

[sairamkunala]

Yes agreed. Assuming software engineering context here, not civil or mechanical or other mature industries which usually require millions to create, validate, test and release a new product.

Negotiation of requirements is a problem based on limitations like recources (money, people), known knows and known unknowns.

[mook]

Ah yeah, I tend to not think of what we do (or at least, what I do professionally) in the software field as engineering for that reason. What we do seems closer conceptually to carpentry rather than engineering. Not that changing things to be more engineering is necessarily better, of course; much of the benefits of software _is_ the flexibility.

[rocqua]

Isn't that a narrow interpretation of engineering? Especially because in software engineering you often have micro decisions that are unspecified, where user preference does matter.

Good engineering requires making the correct decisions in those cases. It requires knowing the 'actual' problem so you are not building a solution for the wrong thing. That means requirements are a part of engineering. Maybe not the full responsibility of gathering requirements, but understanding requirements, clarifying requirements, and feeding back what requirements are feasible or conflicting seem very much a part of engineering.

[eezing]

Well said.