I am working on a project which does not have solid requirements, All is we have meetings with all the teams across and confluence pages. No one owns any requirements and it just float around scattered info and it is confusing and the meetings go no where and management does not care about this chaos. How a software product architect should deal with this situation? Best approaches?

  • Take control...
    – gapsf
    Commented Oct 14, 2022 at 5:04
  • 1
    Is there understanding how the project should earn money? If nothing is clear you could start from that.
    – max630
    Commented Oct 14, 2022 at 6:32
  • 9
    This is where Agile came from: develop something, show it to people, use the feedback to determine what the requirements were, make another version.
    – pjc50
    Commented Oct 14, 2022 at 8:15
  • 1
    If you cannot do what others want because they don’t tell you, invert the situation: propose something and tell those others to stop you if they think your proposal is wrong. After fair warning, do as @pjc50 recommended: build something and show it
    – Luxspes
    Commented Oct 15, 2022 at 3:24
  • 1
    Forget about "requirements" which are usually too detailed a level at this stage. Concentrate on getting a clearly defined set of "goals" i.e. what the stakeholders want to achieve as an end result of the project. If you cannot get a coherent set of goals go to your management and advise them to save money and can the project. Commented Oct 16, 2022 at 9:23

2 Answers 2


I have been a software developer for many years. The closest I've ever come to formal software requirements is a spreadsheet with one requirement per row. We do have formal Software Design Specifications where I work now, but they are written while we write the software. Big Design Up Front is a recipe for failure.

In my last job, I and a small team of developers were tasked with rewriting a custom project management application from scratch. The rewrite was justified; the old system had forms with 20,000 lines of code-behind, and was so slow it had become unusable, even on modern hardware.

This new project was a recipe for failure. The situation was much the same as yours: too many participants, not enough direction. But the software was successfully completed over a three-year period. Here's why I think it succeeded:

  • The Branch Chief assigned two people from the business team to our project. These were to become our principal stakeholders. One of them had intimate knowledge of their business processes. The other had a fundamental understanding of how software development works.

  • These stakeholders became the "gate-keepers" of the project. They got feedback and suggestions from the user community, and decided which features would get incorporated into the project, and which features would not.

  • We met once a week, for an hour or two to discuss work accomplished, engage in software design, and plan our next tasks. Sometimes a domain expert from the user community would join our meetings, sometimes several. The stakeholders would keep the meetings on track.

  • We broke our work into modules, and developed a software architecture that was modular so that each module could be worked on independently. During each weekly meeting, we scoped the work so that what was discussed could be reasonably completed in a two-week period and then reviewed. These became our informal "sprints."

  • We used a Trello board to track the work. Our stakeholders had full access to it. Communication between meetings became crucial, and the Trello board was a big part of that. The Trello board became crucial to our success. As work was completed, we moved cards into a Testing column, and then into a Completed column.

  • We developed a working relationship with the stakeholders. Everyone was professional and positive. Everyone was persistent and consistent. Everyone was committed to making the project succeed.

I once had someone from another project team visit one of our meetings. He said it was chaos. Probably one of those old-school waterfall guys.

  • 1
    Your two "principal stakeholders", who between them understood both the business processes and the nature of the software development process, should probably be recognised as a particular saving grace - so many projects lack such resources.
    – Steve
    Commented Oct 15, 2022 at 13:06

It sounds like you're working within a fundamentally broken development process, and there's probably nothing you can do on your own to work around that and create software that meets the (not clearly defined but certainly implied) requirements.

So this is likely a people problem, even if it hampers your ability to work in your software engineering profession, and it can't be solved using software engineering tools but people management. If you're not in a formal management position, you will need informal ways of changing the process. Talk to people who either have deciding power or could be possible allies as they are affected similarly.

By talking to the people around you, you also might have a chance to adjust your perception. For example, do they see the current situation as a kind of "brainstorming" phase where ideas are being discussed even though they might not actually be implemented? Users here on StackExchange can't really know, we only read your presentation of the situation, which might be influenced significantly by your emotional state.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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