Adapting to meet changing business requirements?

Question

Ideas on how to develop software that is capable of adapting to meet changing business requirements? Any patterns, architectures, etc. Possibly some anecdotal examples would be great. This is more of a survey than a concrete questions. Thanks

Answer 1

You will want to learn more about the entire Agile Development movement. Agile is just what it says: able to quickly adapt.

• Robert C. Martin's 2002 book - a classic.

• Agile in C# - this is what I use

• See this list of books

• You'll want to read the Agile Manifesto!

• Just one more: Kent Beck's work - especially Test-Driven Development.

Answer 2

It seems to me like specific code is much more changeable than generalized and abstract code. So if you want code that's changeable, stick to specific code and avoid the metaprogramming.

6 months from now its likely that no-one is going to understand the real use-case of those generalized and abstract methods and be scared of changing them.

Answer 3

Trying to design a generic system that can easily be tailored to changing needs just plain doesn't work. As Mark suggests, the whole agile movement has grown out of a realisation that simple specific code is easier to adapt than generic code, just so long as it is well written and maintainable.

Answer 4

(almost) every program have changing business requirements. Trying to negotiate with the customer (marketing or product manager are also costumers) is important, but never enough. the requirements always change. Scrum has a lot of techniques to manage changes in the requirements. this is a great video introduction to scrum. worth your time

Answer 5

You'll want to use an Agile development process if this is your development environment.

As part of this process, you'll probably want to continually have a working system to show your client so that they can make course corrections along the way. It will help them understand what progress is being made and where you're at. But more importantly it will give them a better understanding of how the system works with the current business requirements and what the impacts of their new changes will be.

Just be careful not to make your prototype to visually appealing. If a prototype looks graphically polished there's a good chance that your business development people will think the software is much more complete than it really is. I would instead recommend trying to make it look less polished and focus more on features. For example, if you're working in Java Swing, there's a great look & feel called Napkin that helps with this. IT allows you to build as much functionality as you want, but the screen looks like it was drawn on a napkin. So people's attention and focus are on the functionality, not the graphical details.

Answer 6

Consider at what scale are the business requirements changing:

• if small-scale requirements change frequently, i.e. people change their minds about what they want, but what they need to do has not really changed, then adopt Agile practices and keep your iterations very short (as short as 1-feature iterations, if necessary to actually get to complete something!)
• if larger-scale requirements change often, i.e. what infrastructure is needed to run the business, this may be a reflection of changing management whims (what i think of as the "last salesman syndrome" - whatever the last salesman was selling is suddenly The Way Of The Future). If you're involve in these decisions, try to reduce technical issues to the fundamentals (communication, storage, computation, interaction, access, ...) and don't get distracted by product-level bells and whistles. Remember that nothing is likely to be a 100% fit, but the cost of changing your mind too often may outweigh the benefit of changing platforms or architectures. If you've not involved in these decisions, there's not much you can do about it except learn quickly and gently encourage deeper commitment when you can ;-)
• if the natur of the business changes often, i.e. new lines of business are needed every few weeks, old lines consolidated, et al, and you are involved in discussions at this level, you can try to anticipate the future changes by probing deeper into the company plans. If you're not involve at this level, try to be flexible and invaluable until you find a job with a more stable company ;-)

Answer 7

Consider a business rules engine. Not always appropriate, but can help to seperate business logic and requirements from your technical architecture/solution. For example, imagine you had a requirement to set the safety classification of a car based on a set of test results. The tests carried out on the car could change, as could the classification criteria (including the actual number of classficiations, e.g. from a 5 star system to a 10 star system). Given this scenario a business rules engine could be a good way to classify a car.

The rules engine would be supplied with text or XML based rules that, in theory at least, could be written and maintained by non-programming staff (e.g. a business analyst). Those rules would be applied to a Car object (supposing that the Car object contains a reference to a TestResults object). The rules/rules engine would analyse the test results and set the SafetyClassification property of the Car object accordingly.

The actual rules could reside in a database or shared location, or even be supplied to the system via a messaging infrastructure or web service call. New rules could be supplied to the system and activated without recompiling/redploying the system.

Different technologies have different rules engines available. E,g, .Net has Drools.Net, the WWF rules engine, + a few others. Java has JBoss Rules plus plenty of others.

Answer 8

Domain-Driven Design is a good approach for this, with a good book to help you get going.

A big focus of this approach is tight feedback loops between the developing domain model used in the software, and the actual "real world" it's modeling, so a changing real world is fine.

Answer 9

I think the article "Coping with changing requirements" by Stephen Mellor addresses this in a very interesting way.