6 ms·
Requirements is a communication and expectation problem. Not an engineering problem. Software or hardware engineering is a solution. You can solve the same wit
by sairamkunala 5y ago
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
- eezing 5y agoWell said.
- rocqua 5y agoIsn'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.
- mook 5y agoWouldn'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 5y agoYes 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 5y agoAh 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.