I remember reading not long ago about advancements in the area of business rule automation and being interested in the interfaces for rules engines now that make it possible for business stakeholders to “directly author, change and validate business policy decisions using a customizable vocabulary and with tools designed for non-technical users.” I thought, wow! That type of functionality could empower business users to implement new products, pricing… all sorts of rules-based functionality without any new code, or even a phone call to IT. Pretty nifty!
Then I began to think of the technological advancements in business analysis and modeling. The new wave of requirements definition tools are making it easier to model requirements. New, drag and drop-type wireframing tools have made mocking-up screens and reports easier for all, and possible for many that wouldn’t have been able to do them in the past.
History is rife with examples of machines taking the place of humans. And so I wondered; could systems and software be used to take the place of the requirements analyst?
If a bunch of really smart, experienced software professionals and analysts got together and created a massive, master repository of requirement patterns, elicitation questions, specification and modeling techniques, historical project data, etc., and tossed in a bunch of decision logic, could they conceivably create a tool that could guide “Joe” business stakeholder through an intelligent “requirements wizard” to produce a good enough specification to serve as a basis for design and development of a product?
Granted, it might not be as good and as thorough a specification as it would be if a good business analyst took the time and did things the old-fashioned way, but the question is, could it be good enough?
If not good enough to replace the analyst role outright, what about:
- Good enough to commodotize requirements analysis skills to the point that a less-skilled worker could be employed just to fill in any gaps missed by the requirements system?
- Good enough for someone of another role to assume what was left of the analyst role in addition to other duties? Maybe a designer or developer?
- Good enough to reduce analyst headcount and just retain one or two analysts to finish off the generated specs?
And let’s talk about opportunities for savings of time and money..
If you think the business would never go for an inferior document produced by a machine, consider that the system would probably produce the specification in a matter of minutes as opposed to the days or weeks (dare I say months?) that it might take an analyst to do his/her work.
We make judgment calls like this all the time – although on a much more trivial scale. For example, my regular razor gives me a better shave than my electric does, but most mornings I’ll use the electric because it does a “good enough” job, and it’s a lot quicker and cleaner. Same goes for washing dishes or clothes by hand as opposed to using a washer… There are lots of parallels.
So, what do you think? Could you ever see something like the “requirements analysis and specification tool” being created? Will it?
I’m not worried about anything like this happening any time soon, but know that over the course of time we’ll discover new tools and automations that will require our skills to evolve and that will enable automation of things that were always done manually before and make things easier that were difficult before.
Sure, automating requirements is “Star Wars”. One day we’ll be driving hovercraft that run on nitrogen extracted straight from the air, too, right? Whatever the case may be, it’s just fun to think about and imagine.
By the way, am I the only one that thinks crazy thoughts like this? I’m anxious to find out.. Let me know what you think!
And if anyone decides to tackle creating this system, give me a call. I think it’d be a lot of run working as an analyst on that project!
Idiom promotes a variation on your theme, using decisioning as the basis and driver of requirements analysis [http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf]
We will be making the Idiom Decision Manager available for free public access this quarter.
We have also built it into a full workbench that we use in collaboration with
partners – product collateral is currently being written up.
The one point I would like to make is that when you can get an automated requirements statement, then you can test it for completeness, consistency, and correctness – after which you can generate the system components that implement it.
The Idiom Decision Manager produces PDF (English), XML, C#, and Java versions all from the same ‘requirements spec’.
Interesting stuff, Mark. I’ll take a look at your paper, there.
Well never say never, huh? I can see portions of your theory becoming a reality, with emphasis on the business rules portions. In fact we’re currently starting to utilize iLog to implement a rules database that allows users to change the rules on-the-fly without the need to alter the code. This provides great flexibility for users to implement changes.
While there are project components that can be replicated from iteration to iteration, I can’t think of two projects in general that have so much commonality that something like this would work.
I am interested to see what IDIOM is and what else is out there in this realm. Are there any discussions/studies in something like AI that could lend themselves to programming analyst logic?
Doug, I think it’s an interesting topic of discussion, too. I may try to get Mark to share some more of his ideas on requirements automation some time in the near future.
Hi JB,
I think my post replies were lost from here. I posted them sometime yesterday and the other days. In fact you replied one of those.
Rey
Yes I believe that automated requirements elicitation is possible. It is my PhD topic at the moment.
There are a number of automated requirements analysis existing nowadays but their use in the industry is still unfamiliar. I have surveyed these tools and found them very promising. I am presently finishing my PhD research on automatic object identification during requirements analysis, so, I firmly believe the this automation is really possible.
That’s fascinating, Rey. I’d certainly be interested in hearing more about your research and the available tools.
Thanks Jonathan for the comments. I am halfway through of my study. The concepts are briefly summarized at my itwebse http://www.cs.waikato.ac.nz/~rtg4/index.htm
My study focuses on object identification from requirements specs but along the way I’ve realized that my process could lead to automatically generating running codes (though not 100% of them). I’m thinking to extend my study to develop methodologies to automatically generate codes just in the case of Metafor (http://larifari.org/writing/IUI2005-Metafor.pdf)
I visited Ravenflow,USA maker of RAVEN (Requirements Authoring and Validation Environment) last year for a research study on this automated requirements definition tool. You might want to investigate at http://www.ravenflow.com
I’ve always asked: If requirements analysis could be automated, why not complete the automation task, that is automated the coding part too?
Hi JB. It's been a long time that I had not posted messages here. As for my PhD thesis update, I am on my last experiment and will proceed to sit down for the thesis writing. Sometime the end of this year, I will make available the software tool that automates requirements analysis, for everyone to have a look. The software will also map the analysis elements to design elements and program elements. In short, this tool will be an aide for analysts, designers and programmers. The input is the requirements specifications texts and the output are 1) design elements in a form of UML class diagram and sequence diagram 2) actual program code (C# or Java) With this tool, your analysis elements are synchronized with your design and program elements. When you update your code, a backward engineering happens , i.e. the design and analysis gets updated with the changes you made in the code.
Just saw your blog entry for the first time today. I would be interested in seeing the results of the automation tool, and the syntax of the requirements specs. Sounds like quite a bit of work, and I have learned that the actual tools that actually get built are fairly limited in their flexibility, but they pave the way for others to tailor to other’s specific needs.