In the last blog post, I gave tips on how to get started writing requirements (Three Tips For Learning to Write Requirements). Once you get started writing requirements, you’ll find it’s not hard to do, although it is a lot of work. The larger your group or division for which you’re writing requirements, the longer the process will take. Today, I give you three more tips.

Once you’ve gotten start, here are three more tips to help you gather requirements:

  1. Keep harmonization in-mind. Some groups are looking to harmonize their processes. By carefully tracking requirements between each set of like processes done by various groups of people, you can get a good picture whether their needs are different. By taking these notes on what they all need, it helps understand how different (or not) their needs are and can help your group understand where harmonization is practical.
  2. Be specific and exact. Some people are afraid that if they use the real words to describe what they need that this is “geek speak.” However, when something has a term, you should use it. To give an example, if I were to tell you that I want to manage my stability protocols, most of you reading this wouldn’t really know what that is. You’d probably term it “geek speak.” But that’s because you’re not using stability protocols. For those groups using stability protocols, you MUST use that term or no-one will know what you’re talking about. The documents are meant to be understood by you and, using these industry terms, your vendor will also understand it. When they don’t, they’ll ask. If you were to spend a lot of time to put that in English, would it come out as “that template we use when we want to setup the testing at various time points to test our drugs in different conditions”? That would just be silly. On the other hand, when you use terms that are purely internal to your group, please remember to create some definition of these before you hand the documents to outside people so that each outside person doesn’t have to ask you about each internal term.
  3. Keep plugging. There’s always one more person who forgot to include something. There’s always one more group that thinks they made a mistake. It’s not the end of the world. Get them to a point where people think they’re complete and accurate and then “do something” with them, whether it’s start putting together an RFP for a vendor or doing an internal project with your own IT group. It’s an interative process and I can almost guarantee you that you’ll have to make more changes. The key is that you just have to keep at it. Do it in a controlled* manner and you’ll be fine.

* By using the word “controlled” I know that I’m about to get hit by a bunch of word police who will claim that this is going to slow-down the process. All software development processes have to be controlled. Some are controlled a LOT while others have minimal controls. But if you don’t keep some track of what people need, what their comments are, what you’re changing and why, it becomes difficult to remember who said and did what, why and when. You could be taking notes on your iPhone for a tiny project – it doesn’t matter. But if you go out and start just hacking away at your system every time someone suggests it and don’t keep track of it, you’ll eventually just have a lot of junk around.

Gloria Metrick
GeoMetrick Enterprises