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:

  1. 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
  2. make use cases
  3. present it all to the stakeholders for feedback
  4. derive requirements from that
  5. get feedback on the list
  6. make a backlog
  7. and then we discuss & pick tools, languages, frameworks, standards etc.

1-2 members agree with me, vast majority votes against it. Majority wants to:

  1. discuss capabilities of several kinds of tools
  2. then make use cases
  3. then derive requirements
  4. then backlog
  5. 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?

  • 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 Fantastic! That way you will have 2 kind of problems: 1. those related to the inadequate tools and 2 those related to the domain. Given this rationale, I would add a 3rd, dealing with the lack of rationale.
    – Laiv
    Jan 31, 2019 at 9:50
  • Good thing you are all still students and can learn from this. In the real world, Petras' approach below is the way to do it. Jan 31, 2019 at 10:10
  • I have zero idea how "discussing capabilities of several kinds of tools" is helpful unless you're just trying to put tools together to see what they do ... Start with what the stakeholders or customers know how to communicate to you. If it's a picture of a UI, start there. If it's a functional requirement, start there. If they want you to build something - anything - in jquery ... uhh ... well ok. Start there.
    – svidgen
    Jan 31, 2019 at 20:56
  • Define "tools". Do you mean your whole development eco system? Or just some minor tools?
    – Doc Brown
    Jan 31, 2019 at 22:09
  • @DocBrown In our case, the group is talking about "Is React Native good for Android and iOS development and is it easy to use? Is C# better than Java? Can we mix webRTC with some bank application? Video streaming sounds difficult in C++, which languages solve that easily? Can it be done in front-end languages?", stuff like that. Feb 1, 2019 at 15:53

3 Answers 3


From a real-life business standpoint, tools come in the back of the to-do list. I agree with your suggested list, though I'd move some things around a bit:

  1. Functional requirements. I'm not talking about the amount of RAM the software is going to require but the stuff it is expected to perform. Getting requirements wrong can single-handedly throw your hard work out of the window because... well, you might build stuff no one wanted. And no one in the real world is going to pay money for that. Get the requirements straight. You should also ask your stakeholders to give examples of what they actually want to do, this will then be a good starting points for making "use cases".

  2. Based on what you learned on task #1, make use cases - break down the stuff the customer wants into separate scenarios. They don't have to be long, it can be just a simple list (or a list of lists of) things the customer wants to do, for example: log in, upload an avatar, save a shopping cart, leave a comment...

  3. Now, based on #2, you can make rough GUI sketches.

  4. Meet with the stakeholders and get their feedback on the use cases and the GUI sketches. Make changes and meet again if needed.

  5. When you agree on the initial functionality, start picking the tools that could deliver that. Someone might really really want to use some cool AI framework but if the project is a simple shopping-website, you probably aint going to need that.

This list is just a suggestion. Having an argument-based discussions with your fellow students is a very important part of the process, be it in the classroom or office.

  • [Depending on the product,] rearrange these steps in whatever order is needed to drive the discussion and produce done-able requirements. ... For some products, in some orgs, I've found that stakeholders don't know what they want until you're at a whiteboard drawing potential UI's with them ...
    – svidgen
    Jan 31, 2019 at 20:51
  • @svidgen For the project I am currently on the stakeholders do not want to listen to reason and are adamant as to what they want (and that's putting it nicely). And the sales people caved on the requests because they wanted the sale. The stakeholders will be in for a rude shock when we deliver what they asked for and not a bit more, no matter how bad it is. (And I am suffering because it really hurts my professional pride to have put out what I have been forced to do)
    – Peter M
    Jan 31, 2019 at 23:19
  • With the comment that you often have to moderate your GUI designs based on what is practical/common/feasible in toolkits that you or your team know. Although it's nice to design in isolation, this can lead to things which simply can't be done in practice. I saw this happen (at many millions of design cost) just recently.
    – O'Rooney
    Jul 19, 2019 at 4:28

The most important thing is to not decide on anything for as long as you can afford.

It does not matter that much what you do first as long as you are willing and capable to change it a couple of times in the course of development. It is supposed to be an iterative process. The more important the decision, the longer you will want to wait before making it final. Because you ultimately want it to be the right one.

So you can pick a tool based on a hunch and start prototyping. You can start writing a design document. You can create a database schema. None of which should limit the choice of any other part until you have a firm understanding of the problems you are to solve.

Gradually some pieces should fall into place.

Pouring an arbitrary part into concrete before understanding what you are up to is a recipe for failure.


When you say this is a large group project for school, I assume you mean an assignment that ten or more students are supposed to work on together. In which case:

Learning how to work collaboratively is the whole point.

Successful commercial software hasn't been the result of individual effort since the days of Atari video games and early Apple II office tools. Software projects today are collaborative efforts. (Read the credits on a modern video game if you don't believe me.) Academic assignments where the students are asked to do large(er) scale collaboration for the first time often result in one person doing all the work and everyone else grumbling. You should consider that a failure outcome.

A successful outcome for this project is one where everyone on the team is engaged and productive, and the resulting work product is better that any one of you could accomplish by yourself.

You aren't going to get there by trying to convince a "vast majority" that their work plan is wrong and yours is right. Rather, the whole team needs to realize that there are a bunch of things to figure out, some of which are interdependent, and your instructors are deliberately not giving you complete information up front.

Specifically regarding the GUI question in the title: It can be helpful to have sketches of possible GUIs early, because many people (including business stakeholders) are more comfortable discussing requirements and features in the context of a visual reference (as opposed to in the abstract). But in those discussions you may learn that the underlying GUI metaphor is wrong, or that the users would be better served by a phone app rather than a desktop webapp (or vice versa), or that some other initial working assumption is off base. Don't confuse early sketches with a finished design.

No matter what you start with (GUIs, tools, functional requirements, etc) the initial steps are provisional. They're ideas the team members are pitching to each other, and then to the stakeholders. The eventual solution will probably be a combination of some of them plus other stuff you haven't thought of yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.