Finding Implied Requirements
Posted by Robert Merrill on April 20, 2012 under Business Analysis and Requirements, Project Set-Up | 
Be the First to Comment
On the LinkedIn IIBA® (International Institute of Business Analysis) Group, I said I had a systematic process for finding implied requirements and was asked to share it. I wanted to write something quickly, but I intend to return and add an example and some graphics.
- Elicit the primary stakeholder (user) requirements. These are the ones that people are asking for and that will deliver business(1) benefits.
- Analyze those requirements for the underlying data and/or unstructured information that they depend upon, create, and/or modify. Work with the subject matter experts (SMEs) for the primary user requirements to verify these, using a simplified logical data model or analysis class diagram that they can understand. If they mention other information or data types in passing, add those to your model.
- Check the data model and the user requirements for consistency. Every functional requirement should have all the data it displays, searches, creates, modifies, deletes or otherwise depends upon or maintains represented somewhere on the data model. (A visual representation—even just a paper-and-pencil screen sketch—will sometimes unearth data requirements that were missed in spoken and written words). Every data type (box on your model) should be involved in one or more functional user requirements. This cross-verification will sometimes uncover small gaps. Data that were mentioned but not used or maintained by any stated requirement often lead you and the SMEs to requirements they forgot the first time through. Reviewing each functional requirement will sometimes turn up more data types.
- Now, go through each data type with the SMEs and learn its life story. Where does it come from? Who uses it next? Especially if the business is organized by function (e.g. separate departments for sales, fulfillment, procurement, and accounting), they might not know, or they might think they know but have several things missing or incorrect. Listen carefully for these organizational boundaries. “I think Procurement uses that to decide what to re-order.” Give your SMEs a gold star or an extra slice of pizza if they say, “I don’t think those data even exist,” or “I have no idea!”
- Now we’re ready to mine the mother lode of implied requirements, and potentially hit a gas pocket of company politics as well. If you uncovered data that are either produced or used by another functional area, that shows you where to go next. It’s always courteous (and in a politically charged environment, essential), that you go to your sponsor (the one receiving the benefits of the new system or enhancement), tell them about the cross-functional dependency you’d need to investigate, and seek their guidance about how to involve those other departments. Consider your own sensibilities about organizational dynamics, too. A project intended to benefit your sponsor might result in additional cost and work for other parts of the organization. Or, it might yield benefits for them as well. As an experienced business analyst (BA) you probably have a pretty good idea already, but courtesy and prudence call for checking things out.
- By now you’ve probably picked up an additional senior stakeholder, or maybe even co-sponsor, and they will help you get time with a new set of SMEs. What do you do with these data flowing into your organization? How would you create or obtain these other data that your peers in the primary sponsor’s organization need to obtain these benefits? The result is often additional system functionality to meet additional user requirements. Had you not investigated those data lifecycles, these implied requirements might not have been discovered until relatively late in implementation, causing a scope shock to your project and potentially hard feelings between your sponsor and her peers. If you’re running an Agile method, you might save the details for later, but you’ve now identified the people the development team should contact when the relevant stories come up for implementation, and their management knows what’s coming.
- Now that you’ve added more functional requirements, repeat the function-and-data cross-verification starting at Step 3. You might uncover some more data, which in turn drag in another functional area, co-sponsor or senior stakeholder, and round of work with more SMEs. You might also find that some of the explicit requirements from your original SMEs need to be revisited, in light of what’s now known about the data underneath them.
If you’re a veteran BA in your organization, you might be able to anticipate a lot of these implied requirements from the start, but you still need to be mindful of the relationships involved, and following these steps will help get them in place.
I hope you find this useful in your own business analysis work.
To give credit where credit is due, I didn’t invent this technique, although I now explain it more generically, in my own words. I first grasped the concept while reading about Robustness Analysis (Chapter 4) in Use Case Driven Object Modeling with UML: A Practical Approach, by Doug Rosenberg and Kendall Scott. It was driven home while learning Function Point Analysis (FPA). Though the goal of FPA is totally different—to quantify the functional size of a software system—the process of correctly typing data types as Internal or External, and the need to identify the File Type Referenced for every input and output, forces you to look carefully at the relationships between functional requirements and underlying data(2). That cross-validation is the key to finding implied requirements, fast and early.
(1)“Business” is meant in the broadest possible sense; the organization could just as well be academic or other non-profit.
(2)This was top-of-mind when the LinkedIn thread came up because I had just prepared a talk for the 2012 Wisconsin Business Analysis Development Day (WI BADD®) titled, “How Function Point Analysis Can Make You a Better BA.”
