Requirements Management - a supply demand approach

1. While working for corporate America I have gone through hundreds of hours of agonizing and
painful (if not outright miserable) activity of requirements gathering and analysis. Most of the
analysis was done from the demand management side (above Figure) where domain experts
came in to provide their requirements mostly in an abstract manner. (which means the
requirements were not supported by a set of business processes - though in few companies
that was not the case since they had very well-defined business processes).
The requirements gathering process mostly turned into slug fest which was far from any
engineering activity - finally finance had the say over everything and could turn everything
upside down just by invoking certain obscure compliance requirement.
In business there are both explicit and implicit activities - gathering the data for the explicit
activities are easy but gathering info about the implicit activities are rather difficult (Specially
the data-set around them - these are often employees core competency and cannot be
extracted). Explicit activities are primarily defined by transaction and boundaries, but implicit
activities have data constraints but not many transaction boundaries. For new design they often
become design parameters or boundaries for transactions or workflow control mechanism. For

2. large ERP tools like SAP, Oracle - it is the implicit process requirements which creates most of
the troubles and customization.
I was involved with the product configuration tool implementation process at a very large
capital equipment company. The entire requirements gathering process went on for 5 years
(yes, you are reading it correct 5 years). The money spend on consultants and other goblins
were in the range of tens of millions (including their business class plane fares). We never even
touched the actual tool - but now looking back I understand that we used requirements
management mostly as a risk management/mitigation procedure - which means if the project
fails then higher management (various levels of non-productive directors and VPs) can blame it
on a 3rd party. The process would have been successful if we had 2 experts leading the project
representing the supply and demand side respectively.
Below, I have listed few items that we needed for “requirements” for a configurator from
demand side (these are just 4 examples - there can be more)
1. Product configuration relationship knowledge
2. Product Ontology (in more general sense) - a more fundamental knowledge*
3. Pricing Mechanism (including customer specific mechanism)
4. Customer Specific configurations (this can be based on Technology, Country etc.)
*this is probably the crux of every configuration project - the knowledge/ontology is hidden in
brains of product managers. It is not about the product tree, which is rather simplistic but
rather the relationship between the branches of the tree. One easy reasoning is that "it's all the
existing configurator why not figure it out" - actually that logic is quite lame for 2 reasons - most
of the home grown configurators are highly technical in nature which has a million lines of
hidden codes (sometimes the latest and greatest version of the configuration profiles are in
laptops) and secondly much of the configuration activities (like custom pricing) are done
manually after the automated configuration has been completed. In this case for the demand
side we should have started with a tool like Protégé to expose the implicit knowledge of
product ontology but instead we hired few dilettantes (at $300/hr) to convert a complex set of
knowledge into a simplistic tree-based product configurator. This was fundamentally a data
problem - our consulting company (it starts with D and end with ….) did not know how to
handle a complex set of data with 5 to 6-dimensional relationship. This happened because the
so-called consultants knew how to "click" on certain buttons on a configuration tool in SAP but
did not know dimensional analysis, linearization of data, reduction of data layers etc. and other
tools used for relational databases.
From a Supply side of requirements, we need the following (may be much more)
1. Product Capability - how do end users (all types) get usage out of the tool. This is
typically feature centric or the discussion is driven by features but never ventures into
data

3. 2. Data Capability - how does the product deal with data elements - this is where a high-
level mapping between existing capabilities and future capabilities start. (Believe it or
not unless it starts at the data level you cannot move forward)
3. Import Capability - how is the existing knowledge imported to the new tool (This is a
supply side problem even though most software companies try to pretend that this is a
demand side problem).
For # 2 and # 3, it is imperative that you get the data from the demand side data in a standard
platform (that is why I mentioned Protégé because it allows the future use of semantic web
queries using SPARQL etc. and data graphs). Providing the demand data in a standard platform
often makes a data mapping a million times easier.
When developing software independent of the demand side (it can be based on broad
customer research but not any specific customer requirement) one can ensure that the supply
side capabilities drive demand - which means customers get use to what software companies
must provide. Microsoft does an amazing job with this currently. I am a beta tester for
Windows 10 new versions, and I get to test and provide feedback for their new capabilities.
Companies get better at this over years of research about customer psychology and customer
tolerance - even then they make mistakes (Read Windows 7 - what a disaster!!!)
But this last solution is mostly used by corporations - when they buy a new tool - they throw
away the demand side and completely driven by the supply side which is the product
capabilities and start everything from scratch. Most insiders then hate the tool and we call
them lazy. They are not lazy - we just discounted their entire knowledge base just to migrate to
a new tool.
Today, in my own business (which is lending money) - I work with the supply side mostly and
tweak the demand side to support the supply side. This is mostly because I use standard off-
the-self software. It works well.
Here are couple of edits based on couple of questions
1. For every requirement there must be a capability (in mathematical terms in a tuple) - I
have seen many consulting companies discount customer requirements - because they
lack the wisdom to understand the requirement in most cases.
2. There was good question regarding meeting at the demand side or supply side - I
believe in the areas where you enjoy your core competencies (like in my example
product configuration was one of their core competency) you meet at the demand side.
But in other domains (say HR, purchasing) you probably want to meet at the supply side
because the software may include some best known practices including compliance etc.