In my work, I do requirements gathering, analysis and design of business solutions in addition to coding. There are multiple software systems and packages, and developers are expected to work on any of them, instead of being assigned to make changes to only 1 system or just a few systems.

How developers ensure they have captured all of the necessary requirements and resolved any conflicting requirements?

An example of this type of scenario:

Bob the developer is asked to modify the problem ticket system for a hypothetical utility repair business. They contract with a local utility company to provide this service. The old system provides a mechanism for an external customer to create a ticket indicating a problem with utility service at a particular address. There is a scheduling system and an invoicing system that is dependent on this data. Bob's new project is to modify the ticket placement system to allow for multiple addresses to entered by a landlord or other end customer with multiple properties. The invoicing system bills per ticket, but should be modified to bill per address. What practices would help Bob discover that the invoicing system needs to be changed as well? How might Bob discover what other systems in his company might need to be changed in order to support the new changes\business model? Let's say there is a documented specification for each system involved, but there are many systems and Bob is not familiar with all of them.

End of example.

We're often in this scenario, and we do have design reviews but management places ultimate responsibility for any defects (business process or software process) on the developer who is doing the design and the work.

Some organizations seem to be better at this than others. How do they manage to detect and solve conflicting or incomplete requirements across software systems?

We currently have a lot of tribal knowledge and just a few developers who understand the entire business and software chain. This seems highly ineffective and leads to problems at the requirements level.

  • without concrete details this question is sort of too broad. I for one have seen this addressed in 3 or 4 different ways, depending on the context (and my experience in this kind of issues is rather narrow)
    – gnat
    Aug 23, 2014 at 16:56
  • A good definition of the interfaces between the system is vital "System A will accept an XML stream that verifies TLD X, and the meanings of the fields are...". And of course, test environments (although how complete they are will depend in complexity and money available).
    – SJuan76
    Aug 23, 2014 at 17:03
  • @gnat would an example help? I can't provide an exact example, but I could contrive something to demonstrate? I'm really looking for methodologies that developers use. Aug 23, 2014 at 17:25
  • @SJuan76 There are dev, test and qa environments already. Also, problems involved are rarely system crashes. It's more of a bug in expected behavior of downstream systems because some expectation of data from upstream changed. Aug 23, 2014 at 17:28
  • yes it would help. As for getting too narrow answers, I wouldn't worry about that. Good answerer will be able to draw a broader picture anyway, using contrived example as a case study to build on
    – gnat
    Aug 23, 2014 at 17:28

2 Answers 2


Two ways:

  1. By using well-defined interfaces between the connected systems having clear, unambiguous and documented behaviors, and

  2. By writing unit tests that codify behavior at the class and method level, integration tests that verify functionality across multiple systems, and acceptance tests that validate successful fulfillment of the software requirements.

The process for discovering and identifying the capabilities of an internal system, so that you can write software against it, is no different than that of evaluating any other foreign system. Documentation will take you a certain distance, but the only way to be sure is to poke the foreign system and see how it behaves.

In your example, you already know that your invoicing system needs to be able to support billing by address. So, you test the system to see if it does. In your hand is the list of functionality and features that the foreign system needs to support your new software, because you already identified them through a series of requirement gathering and software planning meetings.

Having a comprehensive test suite for each system helps this process, because the tests are a form of documentation. If they are written well, you can tell what capabilities the system (is supposed to) have, because the tests specify the desired behaviors.


In my experience two things help with this kind of challenge, which exists for pretty much every system:

  1. Deep knowledge about the system in the team. Yes it does sound scary and it actually is when the knowledge is concentrated in very few people. You want to spread that knowledge between developers. Pair programming and ensuring that multiple people work on each and every piece of the software is crucial

  2. integration tests. Every interface should have it's integration tests, which should fall flat on their face when an incompatible change happens. Good automated integration tests are difficult to create and maintain, so they are often manual, although automatic tests are to be preferred.

Stuff that doesn't help:

  1. Documentation. Ok it does help, but only a little, because most of the time it is either out of date or gets ignored, or both.

  2. Unit Tests. They by definition don't test this kind of behavior between systems.

  • 1
    1.Documentation. Ok it does help, but only a little, because most of the time it is either out of date or gets ignored, or both. So you are basically saying that if you do not document properly, then the half-baked, outdated documentation is not very useful? That is true, but it seems like getting a gym membership, never actually going to the gym, and then complaining that your gym membership is not useful as you are getting fatter. If your team were not putting effort into integration tests, they would not be useful, either.
    – SJuan76
    Aug 23, 2014 at 22:16
  • @SJuan76 of course you are right. But at least in my experience the chances to succeed by relying on documentation or much slimmer then with the first two options I mentioned. To compare it with your gym example: A gym membership might help you get fit, if you actually use it. But selling your car and forcing yourself to use your bike has better chances. If documentation goes stale nobody noticed (unused gym membership), failing integration test on your CI server are highly visible (not showing up at work, because you're to lazy to use your bike and don't own a car anymore). Aug 24, 2014 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.