Requirements Engineering

Requirements engineering is a discipline which seems to be fairly neglected in many software organizations and likely culturally across software engineering. It seems as though unfortunately Agile is too often interpreted in a way that fosters disregarding of requirements, though User Requirements in particular offer a clear means to record and validate the delivery of whether software is valuable which is the highest priority of Agile (and requirements are also explicitly mentioned as a desirable outcome which Agile seeks to improve). This seems to be very much the case in my limited experience, as systems without clear requirements tend to be increasingly designed in terms of themselves over time, and correspondingly drift further from value which can be validated independently and weighed against possible forms of waste. A far healthier route in my opinion is for some level of requirements engineering to be a core part of software engineering, providing a framework within which both the system and its surrounding context can be understood and refined.

My introduction to the practice (at least the one that stuck) was attending Bertrand Meyer's ACM Talk on PEGS. There are unfortunately some pretty disruptive audio issues for a fair amount of the talk. I've recently started to draw on the PEGS model as it provides helpful categorization, somewhat distinct terms (trying to evangelize the difference between User Requirements and System Requirements can feel pedantic whereas "Goals" feels a bit more expressive), and the relationships allow for tracking everything back to the environment if the process is extended to include identifying those under-served needs that drive the value proposition (I'm not sure if Bertrand's approach includes that, I should pick up the corresponding book if its available now).