Thursday, November 20, 2008

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?

No comments: