Tim Storer from St. Andrews University in Scotland presented this paper. His underlying assumption is that in large scale socio-technical enterprise systems, you are constrained by the design of the platform you select, integration to other systems, and systems of systems factors. He contends that the functional requirements in these projects are more useful in the procurement process where you select the system to implement, and specifically less useful in the actual implementation. The reason for this is that the system is already constrained by behavior based on what you select. While I don’t entirely agree with the de-emphasis of functional requirements he implied, his overall point is absolutely valid in that you often are in a situation where you must configure the system and adapt business processes around the system.

This paper discusses how beyond the functional requirements, you also need what he calls “information requirements” which help you to configure the purchased system for the given context. These requirements tell you:

• What information is needed
• Who needs the information
• Who produces information for the system
• Flexibility for access to that information
• Consequences of incorrect information flow

And these requirements influence platform configuration, organizational changes, and system integration.

To identify these information requirements, they use “responsibilities” as a starting point. They have defined “responsibility” as “a duty, held by some agent, to achieve, maintain or avoid some given state, subject to conformance with organizational, social, and cultural norms.” They are not goals, but rather more abstract and less formal. They are not concerned with specific types of agents. Then for each responsibility, they determine the resource needs, ultimately leading to information requirements.

In his example, a self service check-in terminal has responsibility of “provide boarding pass”. Then they can look at the resources needs– blank tickets, ticket database which is fed by ticket server, etc.

For the information resources, you then have to look at what happens if it the resource is unavailable, inaccurate, incomplete, late, and even early. And ultimately you get to the details mentioned above to form the information requirements.

What I found useful in this paper is helped validate some of our own thinking we are applying on projects in that we look at something very closely related with data requirements. We’ve written before about our People, Systems, Data (PSD) approach to discovering all requirements using visual models from RML™. In this case, if we break down the Data component of PSD in combination with the People component of PSD, we have something very similar to what Tim spoke to. Very briefly, we use the People models (e.g. Org Charts) to identify the people using the system and then look at what stories they need to execute in the system (e.g. User Stories). Now we can also look at the top-level data model (e.g. BDD – a Business Data diagram), and for each data entity in the diagram, we look at how it is:

• Created
• Viewed
• Changed
• Removed
• Copied
• Moved

(And yes, I deliberately did not call out the CRUD because I’m not a big fan of the acronym!). In doing this, we can actually complete the list of user stories and identify system integration points. Similar to above we would also use the user stories to cross-verify the BDD was complete. Our data actions closely map to the list in Tim’s presentation:

• What information is needed -> the BDD entities
• Who needs the information -> Who views it, changes it, copies it, moves it
• Who produces information for the system -> How is the data entity created
• Flexibility for access to that information -> Who views it
• Consequences of incorrect information flow -> exceptions in the stories that come out of the list

Now in a recent example, we were working with a system that we did not know well. There were six main data objects and a list of about 10 user stories for the system. I wanted to validate whether the list of User Stories was complete, so I proceeded to walk through each of the 6 actions above against each of the six data objects. Not every data object could have those actions performed in the system, but it was useful to deliberately check each. In the end we identified about five new User Stories.