Requirements Gathering: DRY

So I'm on this project as an SME (Subject Matter Expert). I previously wrote a report for a warehousing application that provides a list of items that have a specific status of ready to go. So if the status of a package is ready to go and has not moved then it should show on the report. No problem. It works great.

Someone decided that this type of report needed to be in the warehousing application (ya think?). So my part in the project is to write the requirements (since I wrote the requirements for my own report, and actually coded it).

The warehouse application can be set into two different modes. The difference between the two is what events have to occur before the status is set to ready to go.

So the developer and the IT project lead had some questions about this particular requirement. The big question was does this need to perform differently based on the mode the application is set.

What do you think?

I simply responded that the requirement was agnostic to what mode the application was running under. I simply want the application to respond based on the status being set to ready to go. This created all kinds of issues. They refused to accept that as a requirement. They wanted to define the events that caused the status based on the mode. They didn't even understand DRY in the programming world, why would I think they would understand the concept requirements.

Again, what do you think? Would you need to know the events or simply the status? Could you not look at how the system gets the status?

Requirements Gathering: Shout and Scream Method

A co-worker and I just created a new and unique requirements gathering method. We are calling it the "Shout and Scream" method. It's the simplest method ever.

Step 1 - Turn off the existing application.
This is easier than it sounds, and can be completed in a few seconds no matter how complicated your application. Each application is run on some sort of server. It could be a real server class machine, or a regular pc that is set up to act as a server. Each of these servers has a button/switch on the front or back, and if not, they all have a large cable that somehow attaches to the wall for power. Depress the button, flip the switch or yank the cable (depending on the model). If you have a really large application, repeat this step for every server.

Step 2 - Sit back and wait.
This is where the shouting and screaming comes in to play. You will begin getting e-mails and phone calls regarding the relevant pieces of the application. Those are your requirements. If it's important, you will find out.

FAQ's:

• How will they know who to contact if they can't see our support page?
• What does it matter? If it's that important, they will find a way to get in touch with you.
• What if the shouts and screams are not descriptive enough.
• Reply asking for clarification.
• What if the shouts and screams never get more descriptive?
• Explain that the requirement is out of scope, and that they will be logged in the event the scope widens to include the requirement.
• What if the shouts and screams are rude or personal?
• They are not real requirements? When was the last time you saw requirements that personally attacked you?

Training:
We are considering offering a training course in the future. After evaluating the market be believe our course for $1600 USD/person would be a bargain. Let us know if you would be interested in this training, and how many participants would attend. The additional expense of traveling would be covered in a speakers fee in addition to the per person cost.

Please feel free to post any further questions below.