3 ms·

I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will hav

I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc. I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.

EliRivers 7y ago
We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements. I think having all reqs upfront is a utopia that will not happen. What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it. You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
zo1 7y ago
The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall. Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do. Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".

EliRivers 7y ago

We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements. I think having all reqs upfront is a utopia that will not happen. What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it. You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.

zo1 7y ago

The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall. Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do. Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".