Business software isn't about "what they want", it's about coming up with a solution to meet a business need. If the customer can't define what their business need is (the why of specs), then they have no reason to be in business.
It's not the job of the spec writer to define the business need, it's to take an existing need (after clearly defining it through consultation with the customer) and then defining the parameters of the software - inputs, outputs, business rules.
And it has absolutely nothing to do with agile vs. waterfall development. A well-written spec is crucial to ANY business software project.
We do agile development at my company (a 25 year old enterprise software company) and will not begin work until we have a well-defined spec. I continually reject spec docs if they don't have enough info or if I have questions about an aspect of it. It's your job as a developer to help the spec writer see what problems may crop up and define a solution for them.
I think you need to read Code Complete. It's absolutely mind-blowing the respect for specs you get after reading that book, even just chapter 3.
Business software isn't about "what they want", it's about coming up with a solution to meet a business need. If the customer can't define what their business need is (the why of specs), then they have no reason to be in business.
It's not the job of the spec writer to define the business need, it's to take an existing need (after clearly defining it through consultation with the customer) and then defining the parameters of the software - inputs, outputs, business rules.
And it has absolutely nothing to do with agile vs. waterfall development. A well-written spec is crucial to ANY business software project.
We do agile development at my company (a 25 year old enterprise software company) and will not begin work until we have a well-defined spec. I continually reject spec docs if they don't have enough info or if I have questions about an aspect of it. It's your job as a developer to help the spec writer see what problems may crop up and define a solution for them.
I think you need to read Code Complete. It's absolutely mind-blowing the respect for specs you get after reading that book, even just chapter 3.