Right now my team is engaged in the design of the new changes for next year. The team consists of me and two new guys. Luckily the new guys are experienced in software development. We also have a documented set of requirements. There is just one problem. The new guys can't make heads or tails of the requirements.
Here is how the requirements were collected. The customer sends us the experts in the business. These people have made a career out of their work. They know the current system inside out. And they have a vision of the new stuff and changes they must have. Somebody from our requirements team transcribes what these experts say. The result is a document which makes a lot of sense to an expert in the system domain. To anybody else, including our business analysts, this document is gibberish.
Luckily I have been working on this project for a very long time. My job is to translate the requirements documents to the developers. I fill in all the expected knowledge that you need to understand the document. For example I show the new guys how the data flows through the system. I also decipher the secret codes that the document refers to. And I show how competing requirements have to work together, assigning a priority to them based on outside knowledge. The new guys are a little apprehensive, but I think we will hit our design document delivery.
Cisco Packet Tracer - I downloaded this software for free from Cisco. From the name "Packet Tracer", you would think this is some type of packet capture/analysis tool similar t...