How to design software architecture without solid requirements?

Question

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?

Answer 1

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.

Answer 2

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.