Software Capability Requirements

As stated in Business Capability Requirements, software capability requirements are correlated with a business capability requirement that answers the key questions why and how much. Systems designers, architects, and developers are better equipped to propose solutions, when they are aware of the benefits or value that a requester is expecting for their investment. They are much more likely to propose effective solutions when they understand the expectations of effectiveness (i.e. how much) from the requester as well. If we want the best solutions or designs, we should be able to provide the best guidance, to those doing the solutioning.

One of my favorite anecdotes from my early career is from a user named Bob. Bob was the director of a for-profit business, operating in a non-profit healthcare organization, selling services to doctor’s offices. Bob was very entreprenurial, and was always looking for more capabilities from any solution that we provided him. Bob’s favorite request was “Can’t you just make a button?”. When I was first confronted with this question, I really had no clue what he was asking for. “A Button to do what?” Initially, this question infuriated me, because it appeared to oversimplify the software development process (which we all know is very complicated). Over time I learned that this question was Bob’s way of asking for a direct and simple solution. I learned to ask him the following question, innocently, “What do you envision will happen when you push the button, Bob?” Which could be followed by questions about why and how much. I was never able to train Bob to speak initially in terms of business capability requirements, but I did learn how to hold a conversation with him to extract these, without getting aggravated.

 

  • Software capability requirements also are devoid of assumptions about “location” of the capability. Location implies that there is already a system, product, or application that will be “extended” to provide this capability.

Users of a product, especially a product that is their primary day-to-day application assume that every new capability will be added to this application. This is true, even when the capability is functionally separate from the core mission of this system, or when the cost of implementing the capability on that system is many times what it would cost to implement on another system. Somewhere in the system design, and more detailed requirements, we need to weigh the convenience of a single system vs. the apparent complexity of having a user use multiple systems, the cost and time to market of each option, and the support staffing model to determine what is the best fit.

 

  • Software capability requirements are devoid of assumptions about the “structure” of the capability. Structure implies that we already know what it looks like and how it works. Structure is the highest level of “how” information about a capability.

Once I was responsible for implementing a vended software product that was replacing an existing software product. I had one user insist that we develop a custom report on the new system to the exact specificiations of a report that existed in the legacy system. She insisted that her entire workflow was based around that report, and to change it would be to make her department less efficient. I tried for a while to analyze how her department used the report, and how the workflow was done, but she kept insisting that I should stop wasting her time and that all she needed was this report, and in the end, I acquiesed. I converted the existing report into detailed specifications, and asked the user to acknowledge that they were correct. Six weeks later the vendor delivered the report on time, and it was accepted. A couple months after that, we were ready to start testing the system with a workflow validation. About 30 minutes into the test, this same user came running to me, in a panic. “Where is the data entry screen that goes with this report?”, she cried. It was hard not to laugh. In specifying the structure of the capability, she had inadvertently miscommunicated. By simply calling it a report and not correlating it with a business capability requirement, she missed key information and ended up being somewhat dissatisfied. In the end, she and her staff quickly figured out that the vendor’s core capability was actually more flexible and intuitive than the legacy system, and by messing up the requirement, we actually gained some efficiency in the department. But that is not an outcome that can be relied on. And her boss was not happy to pay for a custom report that was never used. The danger of assuming structure in a software capability requirement is that it limits the solution, and those limits can impact the cost and/or the value of the solution in harmful ways.

 

  • Software capability requirements should tell you what the system should do:
    • Display information
    • Accept and validate input
    • Calculate values
    • Summarize data
    • Process transactions
    • Search for something
    • Export data
    • Format data

By expressing the “What” the software should do, without positing expectations of “How” it should be done, the software capability requirement allows business process to evolve to take advantage of every capability of a system, rather than perpetuating existing workflows intact.  And most of the time, aren’t we expecting that our new system will provide better workflows…

No Comments

Leave a Reply