Agile Requirements for Application Modernization: Part 2
By Matt Morgan, Chief Marketing Officer, Blueprint
Editor's note: The first part of this article can be found here.
Requirements Definition For Application Modernization
Along with a sound understanding of what exists in terms of business process
and the applications that support it (the as-is state), it is also necessary
to determine the "future-state" business context. In other words,
given this extracted knowledge of current business processes, what derived set
of business requirements, rules, and processes will fulfill your business objectives?
Many enterprises have found that establishing this context is best facilitated
through a combination of textual statements of requirements and rules along
with a set of traceable business process diagrams. The textual statements are
usually categorized according to an appropriate taxonomy (e.g. business objective,
business rule, business requirement, etc) which collectively we'll refer to
as the "Business Needs," while business processes are best expressed
using business process diagrams that use a more basic process notation, supporting
the following element types:
1. Roles - "who" is performing the activity? This is commonly represented
2. Activities - the tasks performed by the role;
3. Decisions - the decisions made by the roles and to specify associated
4. Start & End - clear indication of where the process begins and
ends, with ability to specify any pre- or post-conditions;
5. Nesting - the ability to abstract or "nest" portions of a process
and denote it with a special symbol; and
6. Free Form Notes - the ability to add unrestricted notes (i.e. text
of any size and position).
Through the use of business process diagrams combined with traceable textual
lists, requirements authors are able to precisely establish context for the
requirements definition effort.
This business process for the future-state is something that can dramatically
affect both the modernization effort and the long-term impact of the application,
in terms of life-cycle cost and effectiveness. It is crucial at this time of
renewal that the future-state business process be made as simple as possible,
while still meeting the business objectives. Opportunities to consolidate similar
processes, remove redundancy, and streamline sequences though challenging at
times, should also be explored. Such simplifications can pay significant dividends
by reducing complexity of the application that will support those processes,
the software development effort that will create the processes, and the application's
With this business context, work can begin on determining what changes to the
as-is baseline are needed to support the future-state business. This often involves
techniques (such as gap analysis) that identify areas where support by the existing
baseline for the future-state is lacking. Another key input for this work is
empirical data from those who use the legacy system. For example, functional
areas that have been infrequently used or are redundant with features provided
by other systems (as is often the case in today's environment of mergers &
acquisitions) need to be considered for possible retirement or consolidation.
The resulting set of requirements needs to be complete, of high quality, and
rich enough to be both accurately validated by stakeholders and to provide clear
direction to project teams.
Application Modernization Projects And Requirements Visualization
Due to the complexity of application modernization projects and the demands
to deliver varied requirements assets, natural language documents typically
don't have the fidelity or traceability needed to clearly and unambiguously
communicate what is required of the modernized system. As such, for application
modernization projects, IT organizations are transitioning to richer, more visual
mediums to precisely communicate requirements.
The key enabler is the adoption of the model-based approach. Models are representations
that illustrate key aspects of the future system. They are constructed from
many parts, all interconnected to create an integral "whole" (the
model). A model can be viewed and analyzed from multiple perspectives to expose
how the real system may appear and behave. The formats used in these models
include use-cases that illustrate interactions between the system and external
entities (like users), user-interface screen mockups, and data lists. These
system-level representations are explicitly related to the higher-level business
definitions that they support. For example, business rule definitions are directly
linked to the detailed system level decisions made within use cases where that
business rule is enacted.
The benefits of models are many. Most important of all, models provide context
which greatly helps to ensure all definition work is within scope. Because all
the parts must "fit together" models help expose when elements are
missing or are redundant with other elements. Models can also be simulated,
enabling business analysts to "see" how the future system would appear
and behave if built as specified, walking requirements stakeholders through
process, data, and UI flows showing how the system should function. Stakeholders
witness the functionality in rich detail, consuming the information in a structured
way that eliminates miscommunication. This provides a dramatically improved
level of stakeholder comprehension.
The Bottom Line
Application modernization projects are some of the most challenging for a number
of reasons. One reason is that they most always involve business-critical systems
that must often remain in production until they are ready to switch over to
the modernized system. Another reason is that much of the information needed
to successfully perform the project is often embedded within the legacy application
itself. For these risk-laden projects there are some key things you can do to
make them manageable:
Key#1: "Reconstruct" using a Model-Based Requirements Tool
It is crucial on these projects to invest the time and effort needed to gain
an understanding of the legacy application - to gather and collect the information
fragments and add them to a framework to gradually expose its relevant aspects.
The key to doing this successfully is to make sure you have model-based tools
in place on which you can base this "re-construction."
Key#2: Visualize your Requirements
When trying to piece-together and synthesize lots of disparate fragments of
information as part of a discovery process, the ability to visualize requirements
is essential. There is simply no better way to expose missing information and
identify gaps in requirements that will become the 'foundation' for the modernization
Key #3: You're in a minefield - Be Agile
With the high risk profiles of Application Modernization projects, agile processes
should be used to both expose risks early and to allow for 'course-correction'
as the need arises.
Key#4: Simplify, simplify, simplify
A final key to success is to be ruthless when simplifying the business processes.
Continuing to support 'edge-cases' in your business, infrequently used features,
or groups who feel entitled to do things differently can very quickly drive
up the complexity of the application to be delivered which not only heightens
the modernization project risk but life-cycle costs as well.
Application modernization is no longer a choice - corporations must modernize
the applications to remain competitive and viable. While fraught with risk,
these are some things you can do to swing the odds in your favor.
About the Author
Matt is an experienced Marketing and Product Management executive with a strong background in corporate marketing, product marketing,, product management, and strategic alliances, with an international focus. Over a ten year period at Mercury Interactive (acquired by HP Software), he was responsible for product marketing for a $740MM product category including Mercury’s Quality Management and Performance Management products. In his early days at Mercury, Matt built and managed one of Mercury’s first pre-sales organizations in the Southeast United States. Prior to Mercury, Matt managed an IT development team at MCI Telecommunications, and started his career as a software engineer at Minolta QMS.