How do I design an application to support changeing requirements?

Question

Changed requirement is bad thing in software development process. If requirements change, we must change software structure. How do you design flexible core modules to support solving this problem? Are there other techniques for dealing with changing requirements?

Answer 1

If you face frequently changing requirements, consider using a different model for your software development life cycle. An Agile approach may be a better fit. If you want some degree of structure to your process, then consider using a methodology like DSDM, which advocates a certain degree of requirements gathering and design up front, but then embraces change throughout the development process. Other approaches you might want to look at would be evolutionary or staged delivery. Google any of these terms and you will find more information. What won't work for you, though, is any BDUF (big design up front) methodology like waterfall.

Answer 2

This is a general problem with no absolute solution.

The problem is, that if you design your initial solution, you do not know about future requirements and you will have to guess. And while your guesses might be good in some points, you will miss many other points. You might even design your code in a way that makes future changes harder, because your guess was terrible wrong.

So I would recommend to stick with the 'You Ain't Gonna Need It' principle, keep your code modular, respect seperation of concerns, and make extensive use of interfaces to keep the impact of changes manageable, but do not try to make to much assumptions on future requirements until you really know them.

I absolutly agree with cpitis on the point of requirements. Many projects lack a pricise definition of the requirements, the enviroment, or some other factors that influence the design or code. You should almost never be in doubt about what to do, because this is a clear indication of inclomplete specification.

Answer 3

Try to clarify as much as possible the requirements. Maybe the most important thing to address is "what are the needs that the system has to fulfill". Clarifying the needs determines clarifying a big part of the requirements.

Of course, this doesn't solve the problem completely, but may improve the situation.

Then, I would try to have an agile aproach, or at least short iterations, and to have something consistent at the end of the iteration, allowing the user to see and "play" with the system, to clarify what he really needs. As a result of playing, you can clarify the scope for the next iteration (or more iterations)...

Until this point, I was assuming that we are not talking about fixed-price/size projects. In that case... it is a very different story.

Answer 4

that's mean we just care about main objective of the program and use AOP,DI for separate components and wiring them together after we have exactly requirement?

Answer 5

Changing requirement is not a PROBLEM. Its reality which helps you to create most usable and matured software.

Try to adopt any Agile methods which encourages you to do bare-minimum design and change it incrementally. If after certain time in project, you might feel that your design should be changed, at that time, you can plan subsequently to change it.

Do not avoid changes but embrace them.

If you avoid change for time being by writing work around, the cost of change will increase afterward and it will be difficult to change later then now.

The plug-in based designs are the most change friendly. Here, based on the vision of the product/software you create a core design, and most of the features are developed as plug in to the core.