I'll take out the ellipsis to make this easier/quicker to read:
Large group project in school, stakeholders gave a fuzzy explanation as to what they want. I suggested that we:
- sketch the GUIs so we all understand what is requested, find problems, ask eachother questions, to clarify in general so we all think of the same thing
- make use cases
- present it all to the stakeholders for feedback
- derive requirements from that
- get feedback on the list
- make a backlog
- and then we discuss & pick tools, languages, frameworks, standards etc.
1-2 members agree with me, vast majority votes against it. Majority wants to:
- discuss capabilities of several kinds of tools
- then make use cases
- then derive requirements
- then backlog
- then GUI design
Pretty much the same thing except that I want design first and tools last, but they want tools first and design last. Also I want more feedback than they want(though I think I can make a case for this to them, the main issue is GUI vs. choice of tools).
They weren't convinced by my rationale(you find problems first, then pick/make solutions), I wasn't convinced by their rationale(you can't find problems without choosing how to work and you can't know how to design without first defining overall back-end functionality/API). I think we will waste time preparing to use some tool and then find that we didn't need it at all, but that we need something else which we haven't spent time reading about or preparing for, but I don't know if I'm missing something out of inexperience.
What is the right way of doing this, and why?