Agile Requirements for Application Modernization: Part 2

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 using "swimlanes;"

2. Activities - the tasks performed by the role;

3. Decisions - the decisions made by the roles and to specify associated conditions;

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 ongoing maintenance.

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 project.

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.

More by Matt Morgan