Sparx Systems

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.

On March 29, 2017, the public Beta launch of Tools & Techniques for BABOK Guide v3 was announced - please visit the Sparx Systems website for more details.

Veteran Project Manager and user of Enterprise Architect in 100+ projects since 2001, Herminio Lourenço has recently published some illuminating articles regarding toolsets for systems development.

This article was orginally published on Mr. Lourenço's LinkedIn profile on November 22nd, reprinted on the Sparx Systems Community site with permission from the author.

Firstly, tool is something that enables, facilitates, gives bigger productivity to one or more activities. The tool works for us. We dedicate some effort and as a result we have a lot of work done. That said, I will suggest a set of tools to give productivity and quality to systems development.

A concept being introduced is the ALM: Application Lifecycle Management. According to Wikipedia, is the marriage between business management with software engineering, which became viable thanks to tools that facilitate and integrate processes such as requirements analysis, architectural modeling, code development, change management, test management and managing of versions of products accomplished. Each one of these processes is part of a stage of a software life cycle.

This can be achieved through a framework, as the Jazz from IBM or Microsoft TFS, among other options, which integrates specialized tools to manage: requirements; code repository; construction; architecture and coding; tests and quality, versions and components.

In that effort to implement multiple tools, the company may have to invest hundreds of thousands of dollars and dozens of months in software settings and in training.One of the options that brings fastest return in productivity and quality is the Enterprise Architect (EA) from Sparx Systems. With this tool you can manage and analyze requirements, with automatic control of traceability of the requirements until the code and vice versa, besides producing the models of analysis and design and code as much classes as databases.

Support for testing and integration with configuration and release managers practically complete the required skills. Furthermore, EA has tools like KANBAN and task planning that help you plan and control the progress of work.

Other tools like Jira and Subversion can help complete the spectrum.

Of course that the biggest suppliers will try to convince IT managers that this solution may not be as good and complete as their offers, but this solution has more than 300,000 users developers across the planet. Theirs might have a few hundred followers. I will not discuss what is the perfect solution because it doesn't exist.

The adoption of a good, solid and tested set of tools is crucial to obtain the desired productivity in systems development.