Requirements Tools Don’t Do Analysis — a Business Analyst Does
The pitfall of feeding the tool
Imagine a business analyst starting a new job in a large organization. After being shown around and getting oriented, the analyst gets a demo of the new requirements management or application lifecycle management tool.
“All of our requirements are now tracked in this tool”.
“You don’t need to create documents anymore”.
“Just make sure you populate all the required fields”.
“We now have full traceability”.
“Your job is to ensure the integrity of our requirements repository”.
The analyst is happy to have joined such a mature organization. No more filling in the business requirement document templates. No more notes. No more keeping extra spreadsheets or old-fashioned writing of requirements. It’s a new age now. Insert the requirement into the tool, follow the format — and the code will write itself.
If only things were ever so simple… In practice, the monstrous tools often have high demands. Depending on how they are set up and administered, and the level of governance and oversight, there will be attributes to fill, traceability to include, names to attach, versions to assign, multiple dates to track, and…
