On structuring requirements
April 9, 2008
Requirements are frequently uncategorized or poorly categorized. Unfortunately it is not unusual to have requirements captured as an undifferentiated list in a spreadsheet, or a shallow bulleted list in a word doc.
There are a number of useful ways of structuring requirements. We’ll touch on one intially, then augment this over time.
One very useful categorization is by the frequency of change or possible change.
The laws of physics, our understanding of how the physical world works, are fundamental requirements for all projects, even if frequently not articulated. If there was a big bang, there may have been some change near the bang, but it is safe to assume the laws of physics will be stable for the lifetime of one of our software projects. Sometimes our understanding of them can change, though – if x number of objects of a given size fit in a particular box, that is unlikely to change, but the invention of a new lattice packing algorithm might do the trick. Or making all the chips the same size and shape so they stack in a tennis ball can.
Federal and state laws are generally slow to change. But they do, and if our project is potentially impacted by such changes during its lifespace, we should take the possibility of change into account.
Contracts with our business partners change at the end of the contract period – or sometimes sooner if there is a dispute.
Our technical infrastructure changes. New technologies are introduced and adopted.
Business objectives change much more frequently, driven by changes in the market or changes in leadership.
Categorize the requirements by their frequency of possible change. Qualify that with the period of the change and its nature. Find logical gaps in the resulting picture and fill them. Then account for the temporal volatility of requirements – you are designing for the lifespan of your system, not just for the snapshot of it when it rolls out.
April 23, 2008 at 9:47 pm
An interesting view on requirement specification. What are your thoughts on quantifying the sensitivity of the requirement to changes as well as the frequency of change?
April 24, 2008 at 8:40 pm
The posting is as yet a mere fragment…I will be adding to it over time, which should hopefully bring more clarity.
I called out the temporal nature of requirements because I think it is an often overlooked structuring device. I imagine a kind of Venn diagram of the overlapping requirements, where the company’s values are one circle, the laws of physics another circle, federal laws yet another, etc. Our business processes exist in the intersection.
But it is not the only useful categorization. There is an important distinction between policy and process that is based on the importance of the requirement. Requirements such as adhering to our values, obeying laws, etc, are best expressed as policies – simple rules that must always apply. Our procedures can never be changed to violate a policy. I can imagine a tool that enables the business to create or modify procedures interactively, with a BPMN editor for example, but have an edit time or run time check for policy violation that prevents any new process from being implemented that violates a policy.
So in answer to your question, changing requirements that are best expressed as policies can cause fundamental changes to the arena in which our procedures play out. Changes to contingent goals of a given process do not have the same import.