Attending the recent IBM Rational Conference, I listened to some very interesting conversation around the subject of requirements – Rational now has not one, not two but three different “Requirement” tools – its ‘legacy’ product, Requisite Pro, the newly acquired Doors product from Telelogic (now an IBM company) and a newly announced “Requirements Composer”, part of its new software development portal dubbed “Jazz”.
Wow, you may think, these guys are deadly serious about Requirements. But a pretty experienced IBM Rational guy said to me today, “I am not sure anymore what requirements really are. I think they are screens, data models, perhaps object models, process models and use cases, and business rules” (I had just been evangelizing him on the point of business rules, so he mentioned them. I am not sure they would have been in his catalog had that not been the case). So he continued by questioning the necessity for the classic textual statements that have historically been used to express requirements: and once he raised that question, he asked the important question – “Do we need requirements tools? Why don’t we just use the models?”
Indeed.
Now to be fair, Rational’s new requirements tool is not necessarily a third (!) Requirements tool – it is explained to me as a sort of sketch pad where screens and models and JAD sessions can be captured (or so I’m told, I’ve yet to see the demo. ) and not meant to replace the existing requirements tool(s). This sounds like a good idea, but seems to point to some confusion. Why could this sketch pad not be included in the Requirements tool?
So the question remains – what really constitute requirements for system development? In the past some waterfall methodologies required that requirements be expressed as so-called “shall” statements ( “The system shall…..”), sometimes expressed as “The ability to…”. I am aware of many government agencies that require this approach.
On the other hand, in commercial projects we are today seeing far broader use of models as the principal approach to requirements. An architect friend of mine with a large SI said to me recently that as far as she is concerned there are just three legs to the requirement “stool” – the process model, the object model, and the business rules. Now, I personally wouldn’t be that dogmatic, but I will admit that process models and object models can be very richly expressed, and that they contain a very wide scope of material which, if properly presented, can go a long way towards satisfying the shared understanding that needs to take place for all stakeholders and IT can be sure that they are envisaging the same “thing”. And, the great thing about models, they can be enriched in an iterative manner, with all stakeholders participating in each advancing step. This is the impulse that leads us down the promising path toward model based architecture, or better yet, model based development.
But the hitch in the gitalong, as we say here in the south, is that business rules comprise a huge portion of what will become the system. And unless these can be modeled in a way that is meaningful and understandable to all, then the whole notion of modeling requirements is unlikely to be realized.
This becomes even more true in agile development and this is true whether we are speaking about Agile development or just plain agile development. Where the “prototype is the requirement”, the lack of a separation of the business logic (which is the way I prefer to think of business rules), and a means to create a readable, understandable catalog of that business logic (hopefully in a model form) is potentially a project killer. When we go from small iterations to larger and larger iterations, over time, as is the case of agile methods, then the loss of traceability to the business logic is just as serious as if it resulted from waterfall development. We just get to chaos faster.
My ‘perfect’ requirements tool would be a repository of repositories, a model of models, with views of the system for every stakeholder (including the highest levels of management), in the context that that stakeholder can understand. It would provide traceability from view to view of all the key artifacts such that in each context the stakeholder can understand the impact of change; and finally it would be connected to the system such that a change, once agreed and accepted in the model, would be instantiated into the system.
Come to think of it, the requirements tool would be the system itself!
While waiting for that particular Godot, I would settle for a set of models that provided a comprehensive view of the proposed system and that was rich enough to ensure a true shared understanding. I would also hope and expect a really rock-solid governance and version control system to ensure that change was carefully managed and controlled at both the model and system level. And, oh yes, I would definitely INCLUDE a comprehensive model of the business logic.
