The usual approach is to start writing a Software Requirements Specification. This is not an easy task. Often IT gets involved in the process which is good – in most cases anyway. The goal of the specification is to get a complete description of the behaviour of the desired system. Complete being the operative word here. That's what's making it so hard and why consultants like me often gets involved.
A completed Software Requirements Specification usually contains segments like this:
F-01: The system must support single sign on
F-02: Users must be able to upload a single image
F-03: Users should be able to upload images in batches
F-04: Users must be able to search for images using categories
Once the specification is completed it's usually sent to different suppliers as a Request for Information or Proposal. Basically this is asking: ”Can your system do these things?
I've read and answered my fair share of these specifications, and I also confess to having written quite a few of them. As I said this is the usual approach. By learning the hard way I'm now convinced this is a bad way.
Specifications like this are:
- hard to write
- hard to read
- hard to answer
- incredibly boring! (which probably results in very few people actually reading them)
Besides, the only answers you are likely to get are ”yes”, ”no” or ”requires customising”. The answers won't tell you if you have to click two buttons, switch user, log back in and then click again to do what you want.
In this situation it's tempting to blame the supplier for not answering good enough, but frankly you haven't exactly made it easy for the supplier. The supplier have absolutely no idea of why you want to do these things and in what situation or context you plan to be doing it. The best they can do is assume.
So, is there an alternative?
First of all. I'm a fan of Use Case Modeling. If your IT-department is envolved they might be able to help by creating nice looking Use Case diagrams in UML that clearly illustrates ”who” can do ”what” with the system. UML diagrams are much better than the above listed requirements. But if you don't know UML there's also a third alternative.
Write scenarios or stories. Storytelling is more or less what every marketer does so this should be familiar turf. A scenario for a Brand Asset Management system could look something like this:
Meet Lisa. Lisa is a Marketing Assistant. Lisa has just received an email from a subsidiary that needs the latest photo of the CEO. This is the third email today asking for images and it's not even noon yet.
Lisa grunts a little but then heads to the ”System”, enters the search, finds the image and forwards it to the contact at the subsidiary. Lisa is really pleased by the fact that this entire process just took seconds to complete. She is also glad she didn't have to download the entire file to her local computer before sending it.
If you write scenarios like this, send them to suppliers, and – instead of asking ”Can your system do this?” – ask ”How does your system assist in this scenario” you'll get a much better answers that will help you evaluate different answers and choose the ”best fit” for your needs.