How can you effectively meet evolving software requirements?

Its interesting to consider Agile usage and the 'As a computer engineer' by reflecting on development practices in other disciplines. For example, in construction we see the usefulness of roles of the architect (design - top down) and the builder (developer - bottom-up). Consider how Agile, a methodology that improves development practices has expanded to take on many design aspects whilst still being predominantly developer focused. The question 'how can computer engineers effectively meet ...' shows the fixation of developer (bottom-up) first thinking. Perhaps we need to embrace the two roles (designer, developer) or utilise thinking modes (top down and bottom up) discretely to break the Agile cycle into something multi-dimensional.

Domain driven design around well identified behaviours in the system enables quicker adoption of change requests. Ability to change/ test and deploy only part of software independently is key design principle to be followed.

Por anos trabalhei em consultorias onde apenas construíamos software sem o entendimento completo da solu??o, ou pelo menos, o escopo principal do software que estava sendo produzido. A melhor mudan?a que tive foi entrar numa empresa de produto, onde n?o éramos apenas desenvolvedor mas sim co-autores da solu??o. O entendimento do escopo do software é crucial para definirmos os requisitos funcionais e n?o funcionais da solu??o, para gastarmos apenas o necessários e sermos assertivos na solu??o, pois n?o adianta oferecermos o estado da arte do software, com os melhores recursos se o usuário final n?o está esperando isso, ou melhor, nem sabe como usar.

Understand the evolving aspects of the requirements and try to design in a way that can abstract the underlying code functionality and externalize and abstract away parts where business may want to exert greater degree of flexibility. For example, offering users to define high-level rules while the underlying system offer a flexible engine that can adapt to user-defined configuration and conditions may keep the system less rigid and open to flexibility.

I have found 3 amigo meetings very useful for answering alot of the open questions when starting a new feature or application. Having input from business, development and testing allows for great discussions which can tease out requirements and answer open questions. Just remember to keep the group as small as possible to maximise the effectiveness of the meeting.

From a solution architect's perspective, the single most crucial aspect of communication and collaboration with users and stakeholders is ensuring alignment with business goals. This means that every decision, requirement, and feature must directly contribute to the overarching objectives of the organization. By closely aligning the software project with these strategic goals, a solution architect ensures that the resulting solution is not just technically sound but also a valuable asset that drives business success. This alignment serves as a guiding principle, enabling the team to prioritize and make decisions that have a meaningful impact on the business's bottom line and long-term growth.

Business analysts can plan a crucial role in communications, as they work to bridge gaps in understanding and terminology between computer engineers and business stakeholders and end-users.

Demo. Demo. Demo. As soon as you have code that works, even in a minor way, you need to demo that to your stake holders as often as possible. That way they can see the results and can change course early in the project to meet their actual expectations and requirements.

As also mentioned by others in the thread, communication is crucial. But it is also important to make it iterative and interactive. One-off initial meeting and another only at the end can lead to unpleasant situations. Likewise, ensure that everybody is on the same page, at least with terminologies, requirements, and definition of done/acceptance criteria of those requirements. "Same page" does not mean that all need to agree with one another, but that they understand each other's perspective and standpoint. Moreover, perhaps the most underutilized element is "guard rails". Guard rails ensure everything is within the scope and from all direction (e.g., cost, time, etc.). So establish them and bring them up in the iterations.

Can't agree more. I would like to express the above artifacts in two folds - one from the product owners as business requirements and future milestones. The second from the technical leads or TPMs to have a good understanding for products roadmap. The technical personnel could leverage upfront time to have technical designs.

These days I'm talking a lot about rolling wave planning. There's so much consternation over estimation -- the idea of rolling wave planning is a salve. It helps teams get dates for early estimations, while taking into consideration the reality that scope and complexity of those ideas, as they develop, will need to reshape estimates in later stages. Under rolling wave planning, you break down the project into phases, focusing on detailed planning and execution for the near term while keeping future phases more flexible. You provider higher-resolution estimates for near term items, and rough estimates for the projects not yet in focus. It reduces the uncertainty and enables you to deliver more accurate timelines and better quality outcomes.

Yes. To deliver short busrt functional features to the users, I found the agile methodologies the most effective way. You just need a team with competency and team/self accountibilities.

Identify the feature set, develop each feature and rollout. Some feature may take more time them others. Allocate appropriate time for each feature.

While there are many methods and ways to make development teams more agile, I've found that having the right mindset, which is Embracing Uncertainty, is the most important factor. This is especially true when a team is shifting from a waterfall framework. Simply put, agile acknowledges that we don't have all the answers at the beginning, and we expect things to change along the way. This mindset encourages learning by trying things out, focusing on what the customer really wants, handling challenges wisely, being able to adjust, and always striving to improve. It gives teams the ability to adapt to new needs, pay attention to customer feedback, and do well in an agile setup, even if they're used to a more structured way of working.

Requirements are probably at best desirements, meaning the customer currently desires all these at that time but responses to arising opportunity. The point of concentrating on what's next after additional functionality in increments. The whole point and need for Agile lightweight methods were created in stark contrast to fixed path command and control. If required, a team can respond at least once a day to changing requirements with a planned appropriate response.

Maintainability, yes. Modularity, maybe? Most forms of modularity require you to have knowledge of the future requirements of your system, which is impossible. Instead, I focus on Kent Beck's Four Rules of Simple Design which allow for flexibility through simplicity. They are: - Passes all the tests - Clear, expressive, consistent - No duplication - Minimal These are deeper and more nuanced than they might seem on the surface, and that I have space to describe here.

In our fast pace Agile world Design can be easily overlooked. We think if a developer is not coding he is not productive. Taking the time for design and creating design specs is a critical part of the software lifecycle. Through good design and design patterns we reduce the lines of code, and the code becomes more maintainable with less issues.

In this case and of course for long living products I found domain driven designs or, at least, interface based development where business requirements are abstracted into a sleek service layer, a good and effective solutions. Continuous refactoring is the key to a healthy codebase. Practice of enterprise patterns will make the software withstand longer duration.

Don't reinvent the wheel, but tap into mature frameworks that already have best practices of code modularity and maintainability, such as Spring Boot for microservices development using Java/Kotlin.

Don't do too much refactoring, unless required, because it is premature optimization. Code should be enough modular but not too much. Don't just blindly follow DRY (don't repeat yourself), I think it is OK to repeat twice or even thrice. If you are repeating thrice or more than that, on then try to make sub module of that code, or otherwise you will spend lot more time just making code too much modular, giving you fake feeling that you are productive at work. And definitely use code linters to auto format your code. and know your tools whether you use gui editor or neovim or helix or whatever.

Software usability is a two-way trade, and user involvement is crucial. To ensure effective collaboration with developers, users must fulfil several responsibilities, including clear communication, active participation, understanding software capabilities, providing real-life use cases, being open to training, and offering continuous feedback. These responsibilities contribute to the development of software that is more usable, effective, and aligned with user needs. Involving users in the design process through real-life scenarios helps uncover initially unclear requirements, leading to a more valuable product. It enables developers to understand user needs better, designing software that effectively meets those needs.

In 2023 I had great experience working directly with the stakeholders in a transversal anti-money laundering solution. It was great because we focused on the usability and user experience to minimize the required steps in the process. We had meetings to discuss the solution as-is, to design the new process, to plan and prioritize features, and to test in real-time the feature (in some cases real-time adjustment). The gains were that different business areas had the opportunity to discuss and align the expectations.

As a solution architect, I prioritize two key actions for software usability: Defining Usability Goals and Conducting Usability Testing. Defining clear usability objectives from the start ensures a user-centric approach, while Usability Testing uncovers issues and guides iterative improvements. These practices collectively enhance software usability and encourage user-centered design.

Conduct regular usability testing sessions Implement analytics tools like Google Analytics or Mixpanel Use heatmap tools like Hotjar to understand user behavior Employ accessibility testing tools like WAVE or aXe Implement user feedback loops with tools like UserVoice

If you are writing a frontend code. Go and use the website yourself, if you yourself are finding hard to navigate, then it clearly means it is hard and terrible which needs to be fixed. But sadly when it comes to UI development, either it is web, app, or desktop. I will say "There is no clear solution". and you can't do much about, because different people have different definition of user friendliness. In most cases you should just accept some of the silly requirements. Like there is hard to decide between checkbox, drop-down or radio buttons. Just do whatever end user like for his satisfaction.

Implement architecture patterns that effectively future-proof the solution. This might require a bit more effort in the beginning, but once done, you will have a modular, expandable and highly performant solution that can be easily adapted for evolving future needs. As an example, you can implement a pub-sub messaging pattern between services. This pattern is easily extensible, supports real-time operations, and you can set the desired QoS.

One of the most neglected aspects when planning software requirements (especially in mobile applications) is the evolution of the platform. It is important that development work with beta versions of the platform be included in the planning, to ensure the continued progress of our applications when a new version of the operating system is available to the public.

Honestly, I feel the industry is not very effective at all in this area, even with “agile” techniques and “modular” architecture. We need to build a bridge between the unstructured, fluid nature of human language/thought and the structured, precise language/thought patterns of computers. In addition, we need to make changing computer systems much easier. I don’t have the answer for this yet, but I do know that the current techniques still fall short.

In the end, Its not as easy to develop software. and there is no silver bullet. There are lots of other unknown requirements and most of the developers are under pressure and write insecure code. If you want to be a good developer and then you have to write secure code by default. you should have good understanding of how to prevent most of the common vulnerabilities like SQL injection, XSS, buffer overflow, and path traversal. And don't develop or run your software as a root user.

Consider accessibility features to ensure inclusivity for users with diverse needs. Regularly update the software to address security vulnerabilities and maintain compatibility with evolving technologies. Implement user education and support resources to enhance user proficiency. Monitor performance metrics to identify and address any bottlenecks or inefficiencies. Foster a feedback culture, encouraging users to share insights for continuous improvement. Stay informed about industry best practices and emerging trends to stay ahead of user expectations. Finally, prioritize a seamless integration with other systems and platforms to enhance overall user experience and system functionality.