Requirements are fundamentally important as they are about building the right system.
Yet the failure of requirements is the primary cause of project failure.
How many times do we forget passwords AND user names? This is a clear example of the risk associated with the reliability of the human memory and associated human error. Let's consider the management of the myriad detail accumulated throughout the requirements planning process and the steps of Eliciting, Documenting, Analysing and Communicating. Oh, and let's not forget Tracking, Validating and Verifying!
So spare a thought for the Business Analyst, whose whole focus is on capturing requirements, to ensure successful project outcomes. Or to put it another way, the task of translating the needs, wants and expectations, of all user stakeholders, into technical language for the developers and others, to ensure that they - the users - are are going to get the functionality, that they need, want and expect from a system. This is not a petty task and it can take months. Meanwhile, there is the probability, due to complexity, that not all of the requirements are going to be addressed because of a number of factors, not least, their having been lost or forgotten.
However if effectively managed, requirements identification and supporting traceability improves the overall project outcome, simply because time will be saved, less money will be spent, and most importantly, the customer will be happier.
The Requirements management process has seen much change in the past 20 years and two of the most obvious are the involvement of the customer in all phases of the process and that the requirements process itself is now dynamically linked into an agile culture of continuous integration and delivery. The increase in software defined business, is driving the growth and importance of application delivery within encumbent enterprise and with ever more startups disrupting their industries, enterprise needs greater levels of automation to compete and to deliver quality, quicker than competitors.
In the past Requirements were captured in hand written paper documents, which in time, were augmented with spreadsheets and word documents. The rigour of the process left space for improvement. Today, requirements associated material is held in a central repository and updates are visible to all stakeholders. Enterprise Architect can capture all of the different information that records requirements information, be it from Word, Excel, Visio, handwritten notes, video or audio.
In the past Requirements was an isolated process that had built in “wait” or handover periods before being consumed by the other phases of the project life cycle. Today these gaps are closed with automation and requirements are integrated across the development life cycle, with many other functions. The end result is less time to delivery.
Organisational cultures of resistance to change, identified by a bulwark of divisional and departmental silos and a reluctance to co-operate, increased the risk of failure for the change process. Today, technology based collaborative platforms are increasingly being adopted as they are inclusive, breaking open silos, empowering stakeholders and drawing them together.
The progress of development projects lacked transparency for most key stakeholders, right to the point when business took delivery. Whatever visibility the stakeholders had, was gathered from assumptions, rather than from objective data. Today, key stakeholders form an integral part of the development team and have access to progress charts and dashboard metrics.
In the past, the management of shareholder supported organisations held tightly to the overarching goal of ensuring change was minimised or avoided, so as to maintain the value of their shares. Today the digital imperative, as opposed to the business imperative, says be prepared to change, or risk oblivion.
These examples are a reflection of the changes in the Requirements Management process, which in the development model of today, supports iterative requirements gathering and continuous delivery of software. It has become an Agile practice approach, being adopted to address the challenge of digital transformation. This collaborative, iteration based business lifecycle, between requirements and stakeholders, has given rise to DevOps, a strategy for managing continuous change.
Enterprise Architect is unique in its ability to support Requirements throughout the development lifecycle and to deliver the benefits of the Agile practice approach. Requirements can be defined in the model, or imported from other tools including Visio.
Recently, through agreement with IIBA, Sparx Systems is in the process of developing the Enterprise Architect Guide to BABOK Implementation. Through the power of this collaborative, visual modeling platform, the extension provides the Business Analyst with a fully augmented BABOK user experience.