Requirements Defined

*Special Guest Contributor*

Featured Article

Data, Data Everywhere

As a requirements guppy, I focused on the user experience when developing requirements - when were messages displayed, what options were available, what were all of the things they could do? I was a hard-core use case junkie. Use cases seemed so simple to conceive and so simple to write. I loved meetings with users where we deconstructed what they did. I loved thinking of all the different scenarios, all the different paths to achieve their goals.

And then I had my first requirements review with the technical team. They had a lot of annoying questions – questions I hadn’t expected. In fact, I didn’t expect questions at all. What I expected was them to look admiringly at me and say, “How did you think of all this great functionality? This is going to be the best software EVER. I can’t wait to start coding all these fantastic options.” Instead I got this:

“How many characters can they enter for person name?”

“What are the valid values for a numeric result?”

“What if the ordering tech changes the person’s age – wouldn’t that affect the valid numeric values available when they enter results?”

“What if a user is entering results for a person, and they don’t have security to see all of the person’s demographics? What will be displayed instead?”

And the hits just kept on coming. I stared blankly and stammered. I felt like I was drowning in all the data details I had missed. All the flows to meet the user’s goals would mean nothing if the information wasn’t handled or displayed accurately. The next day I tried to figure out what I had done wrong.

1. I hadn’t specified the functional details of the information the user was viewing and entering.

2. I hadn’t handled the exceptions. What does the system do if information is modified, is entered incorrectly, or is missing?

3. I had expected the technical team to not only value, but compliment my requirements.

I developed a method for helping me think of everything related to the functional details of data and help me catch the exceptions. I even have been complimented on my data requirements. No, really, it happened once.

So, for your consideration, I present my Data Digging Questions (DDQs for the acronym-lovers):

1. What information needs to be displayed to the user?

a. Where does the information come from?

b. Does the information need to be filtered?

c. When is the information displayed? What if the information changes during a user action and that changes what the user can do?

d. In what format is the information displayed? What if the details don’t match the display format? Are there user, system, or regional preferences for how that information is displayed?

e. What should happen if the user doesn’t have security to see part or all of the information displayed?

2. What information needs to be captured from the user?

a. Is the information required or optional?

b. Does the information need to be unique? Does it need to be unique for the record or the system?

c. In what format is the information entered? Does the user need to be able to flex the entry format? What coded values are available? How are the coded values organized? Can the user select more than one value?

d. How is the information validated? What information needs to be validated immediately, and what information can be validated later? Does an entered value need to be within a certain range? Are all characters valid? What is the minimum number of characters that need to be supported?

As I transition from a requirements guppy to shark, these have served me well. If nothing else, they get my thoughts going so that I can make the data flow like, well, water.

POSTED BY: Ginger Nedblake