How can you adapt to changing or ambiguous software requirements? This is a common challenge for software designers, especially in agile environments where feedback and iteration are essential. In this article, you will learn some strategies and best practices to cope with uncertainty and deliver high-quality software solutions.
Before you jump into designing or coding, you need to understand the problem you are trying to solve and the goals you are trying to achieve. Ask questions, clarify assumptions, and gather as much information as possible from your stakeholders, users, and domain experts. You can use techniques like user stories, personas, scenarios, and use cases to define the scope and context of your software requirements.
If requirements are unclear, don’t make assumptions; you own this task, you should ask the product team to further clarify it. This is an integral part of executing this task. Also, never forget that this task is part of the bigger picture. Never forget how it fits in, and how to build upon it. You’ll then be able to extend it and augment it in the near future.
Before designing or planning a solution for any problem, understanding of problem is required and for that - three question should be cleared and understood - What, Why, How. What solution they are going to develop, Why solution is required, how they can do it best way. And these three question can be cleared to everyone in at the time of story discussion, sprint planning and kick off calls. Communication is the key of understanding, a person do as much as communication he will understood the problem in depth
While there is a responsibility to understand what is being asked, it is equally important to put some onus on stakeholders. Publish and follow a development ruleset that encourages clear and specific requirements while penalizing vague requirements. For example, make it a rule that well-defined requirements receive a higher priority for implementation, thus shortening the time to delivery. Over time, stakeholders will realize that providing clear and specific requirements will result in their features being implemented more quickly.
Changing Requirements may be due to -Evolving needs of the users / stakeholders - Lack of understanding of the needs in the first place In case of the former, make small impactful changes. Ensure there is adoption and make more impactful changes based on feedback. Prevent gold plating. In case of the latter, try reaching out to customers / users to understand needs. Do A/B testing using capability prototypes (wireframes etc). Check to see if the product owner has a clear understanding of the product market fit.
These are 2 quite different challenges; changing requirements should be BAU in an agile methodology once stakeholders have feedback of the initial implementation. This will result in redesign and re-prioritisation of subsequent sprints in an Agile landscape or possibly a formal change request in a contractual landscape. Ambiguous requirements are a much more dangerous beast as it implies that one party has submitted a requirement with either not a clear idea of what is needed, or a clear idea which hasn't been communicated. This should be caught by tech leads / architects as it could be manifested as ambiguous functional or non functional requirements. Strategies for avoidance could include templates with headings for req capture.
Depending on the nature and complexity of your software requirements, you can choose a suitable design approach that balances flexibility and simplicity. For example, you can use a top-down approach to decompose a large problem into smaller and manageable subproblems, or a bottom-up approach to integrate existing components and modules into a larger system. You can also use a hybrid approach that combines both strategies and adapts to the changing requirements.
Choosing a design approach is like picking a cooking style for your recipe. Top-down is building a tiered cake, starting with the big layers; bottom-up is simmering a flavorful stew from existing ingredients. A hybrid approach blends both strategies, adapting to changing tastes. Stay flexible, prototype early, and document your "recipe" for a deliciously functional outcome. It's a collaborative kitchen, so iterate with your team until you've cooked up a masterpiece!
One of the key 12 principles of agile is preferring simple over complex. Simple can become complex and it hardly works backwards. Another focal point is that requirements tend to change constantly and adjusting something is only possible while it's simple. Keeping all of that in mind, only the hybrid approach is flexible enough to balance between complexity of real requirements and simplicity of turning them into life.
First. Don't stop focusing on the "why" just because you have a clear understanding at a high-level. Every step of decomposing a large-problem or associating existing components becomes an opportunity to build clarity and address the mission or business need. Second. By creating a common lexicon around user-centric mission and business terminology, the designing of a solution becomes more egalitarian. A technical writer can contribute just as effectively as a senior architect... and the overarching process becomes more natural and collaborative.
Decentralized, Iterative Software Design can be highly successful, when guiding or governing principles are in place to ensure the coherence and big picture of the overall system.
To ensure that your software design is robust, maintainable, and extensible, you should apply some fundamental design principles and patterns. For example, you can use the SOLID principles to guide your object-oriented design, or the GRASP principles to assign responsibilities to your classes and objects. You can also use design patterns to provide reusable solutions to common problems, such as the creational, structural, and behavioral patterns.
These abbreviations themselves are only useful for passing a software design interview, whilst the principles beyond them are based on clear logic and common sense. And these ones shall be the main design principle, everything else is tooling. You may KISS or GRASP in any SOLID manner to get things DRY, but don't forget that eventually YAGNI (you ain't gonna need it).
Design patterns are a helpful means to structure and organise code in a flexible manner, but caution should be taken that they do add value. A simple problem can be overcomplicated by getting carried away, or by using patterns innapropriately, making the application harder to understand and maintain.
To communicate and document your software design, you should use diagrams and models that represent the structure, behavior, and interaction of your software components. You can use standard notations like UML or BPMN to create diagrams that are easy to understand and modify. You can also use tools like Sketch, Balsamiq, or Visio to create mockups, wireframes, or prototypes that illustrate the user interface and functionality of your software.
As they say a " picture is worth a thousand words " Documenting the flow is a crucial part of software development, one - it's easier for anyone to grasp the system and remember or recap at later point of time. To make these designs one uses various tools, but the important part is to discuss regioursly with revelant stake holders over time and again to fine tune and refine it over the period Note it's also important to think where we collate these diagrams, some prefer the code repository to add these but later never touch it , others use some document management sites such as confluence,twiki..
Visualizing a solution is helpful... if there's a sufficient level of complexity to warrant it. Diagrams and models are tools to solve a problem, but the problem may not exist. In all cases, I'd recommend that generating artifacts for planning to be limited to only that which will be used and that provide value to collaboration or understanding. Otherwise, teams can get mired in perfecting the approach vs. making progress towards a stated objective.
I've found that C4 Models can be useful for visualising software, as it supports navigating between dependencies and levels of architecture. For program flow, I prefer UML. However, there is a cost in creating and maintaining all artefacts. Diagrams should provide value, and are not a substitute for well-structured, readable, self-documenting code.
Watching and hearing feels more complete than just watching or hearing. The same idea applies to any other form of communication. Diagrams may help to backup and communicate a complex idea in a visual manner. Hard to negate that different diagram types may be more or less appropriate for specific tasks. Meanwhile diagram notation standards are like human languages. If two persons understand each other, no one cares what the language is.
I'm a fan of modelling, as it constitutes vital documentation of aspects from requirements to code, but it comes at the cost of time taken to keep the model up to date. I think this problem, including verifying its consistency with the artefact, would benefit from further research.
To ensure that your software design meets the requirements and expectations of your stakeholders and users, you should validate and verify your design before and after implementation. You can use techniques like reviews, inspections, walkthroughs, or audits to check the quality and consistency of your design documents and artifacts. You can also use techniques like testing, debugging, or analysis to check the correctness and performance of your code and software.
I have found that starting work on functional test design during the first requirements establishment phase will in fact help clarify the initial requirements, rooting out misunderstandings and contradictions. Security (as part of software quality) should also be included throughout development. Unfortunately, QA and security testing is too often left as something to rush through at the very end of the process.
Frequent, or continuous feedback for your software design is crucial. And validating and verifying your design is much simpler with an agile, iterative software design approach - not months advance, but as part of the user story implementation.
Finally, you should embrace change and feedback as opportunities to improve your software design and deliver value to your customers. You should be open to new ideas, suggestions, and criticisms from your stakeholders, users, and peers. You should also be willing to refactor, revise, or redesign your software as needed to accommodate changing or ambiguous requirements. You should adopt an agile mindset that focuses on delivering working software incrementally and iteratively.
Technical Co-Founder @ Kubar.io | Kubernetes & Cloud Solution Architect | Ex-Microsoft
Expecting users/customer feedback isn't always enough. We have to implement multi facet approach to gathering feedback - telemetry, usage, scenario usability, perform surveys, performance, etc. All these will help develop complete picture of the state of your system and will also be your first signs of a changes that are required.
The agile mindset requires to slice requirements much smaller than traditionally, ideally in the form of a user-story being implementable within an iteration (e.g. 2 weeks), including software design, implementation and release potentially to production. The scope for such an iteration is agreed before starting and typically can't be changed during the iteration itself. With a clear, ranked backlog of small, not-dependent stories, re-prioritization of the backlog is quite simple: The business (represented by the Product Manager) can re-prioritize before any new iteration planning. And changed requirements can be addressed directly in the next iteration.
Change and feedback are not roadblocks; they're signposts guiding you towards a better product. Being open to feedback—from users, stakeholders, or team members—can provide invaluable insights that you might not have considered. It's like having multiple pairs of eyes reviewing your work, catching what you may have missed. Agility in software development is about being able to pivot or refine your approach based on new information or feedback. By adopting an agile mindset, you’re committing to improvement and adaptability. This allows you to produce not just any solution, but the right solution, iteratively and incrementally.
Build the smallest iteration possible to solicit feedback from stakeholders and end users. Take an outside in approach. Give users a preview of how they would use the solution, with dummy data and services, then flesh out the solution after confirmation. The sooner you can get feedback, the better. That way you can easily correct. I often say users don't always know what they want, but they definitely have thoughts about what they don't want!
The bigger question here is who is "you"! How can "you" adapt to changing or ambiguous software requirements? Depending on your role within the organisation the answer to the question could be vastly different. If you're a stakeholder managing financial obligations then you need to consider any change carefully, as it could have a direct impact on the bottom-line of your organisation if R&D teams need to change direction. If you're a product-owner, and just want to deliver what the customer requires, then your adopted agile process should already be able to factor in any change or ambiguity. The issue, as always, is then the battle between agile and finance.
With the changing requirements, you need to have a backup of your developed code. You have to always think and start with a new perspective of how you can adapt/top-up with the new requirements in your current code. If nothing comes into your mind, then you have start from stratch. You have think different ways to accommodate the new requirements with your code in a tight deadline. You have to be smart that's all it needs.
Clearly map your requirements to functionalities We can't design a requirement so to fullfill requeriments we need to map requirements to the functionalities we want to provide for our customers. A way forward is to use User Stories as an agile practices which also has the benefit of communicating and getting alignment within our organisation as well as with the customer.
I think you got this, AI. I agree with the six suggestions. The only thing that I would add is patience. Hasty hands on the keyboard may result in costly reworks. Spending time to understand requirements usually leads to getting things right the first time. As the old adage goes, plan 80% of the time and execute 20%!