How do you deal with ambiguous or incomplete system requirements?

One really good and typically quick way to fill in some of the requirements blanks is to propose an absurd situation (in conversation with the stakeholders) that fits within the current requirments. That'll usually tease out some of the additional requirements and flow.

When faced with ambiguous or incomplete system requirements, I begin by initiating process mapping to visually depict existing workflows and identify gaps. This facilitates collaborative discussions with stakeholders to elicit additional requirements and clarify ambiguities. Additionally, utilizing diagrams like flowcharts aids in visualizing potential solutions and refining requirements iteratively. Regular feedback loops ensure alignment with stakeholders' expectations

Communicating effectively with stakeholders is essential in almost any project or organizational activity, as stakeholders can range from team members and customers to sponsors and suppliers. There are some key points can used such as:Identifying Stakeholders;Understanding Stakeholder Needs;Developing a Communication Plan;Choosing Appropriate Channels;Ensuring Clarity and Consistency; Feedback; Updates; Respect and Sensitivity;Managing Conflicts and Evaluation. This process requires attention, adaptation, and continuous effort. By following these guidelines and being mindful of the diverse needs of stakeholders, you can foster positive relationships, facilitate project success, and bolster your reputation as an effective communicator.

If you are finding gaps in your system requirements, absolutely, utilize diagrams and models to create a narrative for you/your team to get those answers you need. What if you took your crow foot diagram to an SME and they could see immediately what was missing? That diagram might have saved everyone from 3 or more meetings! Pictures are always worth 1000 words! Stick to the facts, and the gaps in your requirements will come together once you involve the correct stakeholders, solution making SMEs, and back it all up with great backlog and requirements writing skills.

A few things that I've learned over the years that I teach to all new developers: - Assume the requirements are incomplete - Assume the requirements will change Understanding those 2 points will help with designing for the unknown, and being able to pivot when needed. It also helps reduce conflict in the teams when things change because nobody is under the impression that the requirements are fixed. The waterfall approach always gave the team a false sense of knowing what needed to be developed. It felt intangible, inflexible to change. Moving to agile with the 2 points at the top make it easier to understand that even the requirements are a work in progress.

Moving away from the approach of getting all requirements signed off ( Waterfall) to an Agile approach would be beneficial. Working towards a MVP that would give the users a feel of the working software would be the best approach. Iterative development beyond that should help shape the product/software. Getting the key features prioritised by the Product owner (in Agile) should help shape the final product.

Irrespective of the SDLC framework you use, the requirements will always evolve and change. The trick is to gather enough to start building, and then build upon it as we go along. Requirements by prototyping helps in many situations to understand the behavior of the product we are to build. Many times I have developed calculators in MS Access to see if the business logic is programmable or something is missing. Wireframes are another technique for UI and navigation. Pseudo code helps to formulate logic when the logic flow is vague. Many techniques exist, you just have to experiment.