The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed ... None of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach ... an agile team should perhaps enforce the SQL-92 standards.
Unclear requirements are a very common problem. I see them so often I wrote a series of articles about it. If you and your team are suffering from chronically unclear requirements, the SQL-92 standards won't save you.
Instead, you need to have the courage and honesty/transparency (often lauded in Agile) to have a serious conversation with your Product Owner, explaining that it is wasteful and disrespectful to your Dev team to ask them to proceed with unclear requirements. Be proactive: if your Product Owner is lacking resources (goes with the territory in my experience) volunteer your team to do an initial sprint with the sole goal of clarifying requirements, using some of the techniques mentioned in Building the Right Thing (Part III): Customers such as:
- Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone.
- Ask why. Understand why.
- Find the root of the problem.
- Understand the problem.
- Define the solution.
- User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
- Get the user journey right (e.g. map out how someone enters/exits a feature).
- Value-stream mapping.
- Fake it till you make it. Use a variety of Pretotyping techniques.