Three Approaches to Modernizing Legacy Applications

There are a variety of approaches to the modernization of legacy applications.   Though the business analyst may not be involved in all the technical intricacies of the discussion, it is a good idea to understand these options because they will have a direct impact on your team’s ability to implement the solution.  You should ensure that the technical groups fully understand the business requirements of the solution so that they can choose the best possible approach.

Initiatives fall into 3 main categories as follows:

  1. Cloaking – the most common form of application modernization, cloaking involves putting a new front end on an older system.  Cloaking can also be used to make enhancements to the system.
  2. Consolidation – large companies can sometimes fall victim to multiple implementations of the same system. (One company recently reported 7 instances of SAP!) Over time, the cost of maintaining so many systems is astronomical. At some point, the consolidation of multiple instances of the same application make fiscals and practical sense.
  3. Replacement – a full replacement of the legacy system with a newer technology, either via a packaged application or a custom-developed solution.

With a deep understanding of the business requirements and technical challenges of the legacy system, the best approach can be selected with confidence.

How to Detect Requirement Flaws

One of the main reasons that the requirements development process has been hard to improve is the traditional reliance on recording requirements in long documents using ‘legal style’ declarative statements. Countless errors have been traced back to stakeholders’ misunderstanding the author’s intent when reviewing requirements solely in text form. In addition, the prospect of reviewing long, complex textual documents and the huge time commitment that is needed has no doubt contributed to stakeholders’ lack of engagement in the requirements development process. This has promoted the tendency to wait until the application is under development and portions can be demonstrated before identifying errors. There are approaches that can be used when writing requirements that will make them much easier to ‘consume’ by the stakeholders during reviews and by the other downstream team members who will eventually use them as the basis for their work (developers, testers, etc.). These approaches also help analysts themselves detect requirements flaws and prevent errors from being presented in the first place.


Requirements authors can augment or sometimes even replace text with various types of diagrams that allow readers to ‘visualize’ some aspect of the requirements. Examples include Business Process diagrams, Use Case diagrams, activity (flow) diagrams, user interface mockups, and more. Complex concepts and larger volumes of information can be communicated much more easily and with more clarity in diagrams as compared to their textual equivalent. Again, imagine if instead of blueprints a building contractor was provided the same information but written solely in text.


Models allow you to define objects, their properties, and the relationships between them based on a set of rules. Depending on the type of model, this information may then be illustrated using one or more types of diagrams. Use Case models, for example, are often employed during the development of software requirements. Modeling requirements is a powerful aid when analyzing the structure and behavior of the future application, helping to expose flaws along the way. The act of modeling itself creates relationships between requirements elements. The benefits of using these relationships, for impact analysis and coverage is just as powerful as with manually traced relationships, but the maintenance burden is significantly smaller. This makes the use of models a very attractive method for identifying and removing flaws at minimal cost. The combination of models with their inherent relationships, along with manual traceability, creates an integrated set of requirements that serves as a ‘single version of the truth’ that all project members can reference.

Continue reading

Blueprint Unveils Latest Release of Blueprint Requirements Definition and Management Software Featuring New Enterprise Agile Module

New Packaged Solution Eases the Transition from Waterfall-style Development Processes to Enterprise Agile

Blueprint, the leading provider of enterprise Requirements Definition and Management (RDM) software, today launched Blueprint v5.2, the latest release of its on-premise and cloud-based solution, which addresses all aspects of the RDM lifecycle. In addition to more than 50 new enhancements and performance improvements, Blueprint v5.2 also features Blueprint for Enterprise Agile.

Blueprint for Enterprise Agile

Blueprint for Enterprise Agile is a new packaged solution and add-on to the Blueprint RDM software that enables enterprises to improve project results and deliver predictable business value by solving many of the fundamental issues encountered when transitioning from traditional waterfall-style processes to Enterprise Agile. Blueprint for Enterprise Agile provides a solid, reliable and proven foundation on which enterprises can define and manage requirements on large, distributed and complex business application projects.

“As large enterprises try to adopt Enterprise Agile practices, many are struggling with reconciling essential business functions with the new agile development approach, including business analysis, requirements definition, compliance, audit and release management,” says Dan Shimmerman, President and CEO of Blueprint. “Blueprint for Enterprise Agile creates the foundation that breaks down the barriers to collaboration in these areas, while reducing the risks associated with transitioning to an Enterprise Agile development approach.”

Blueprint for Enterprise Agile enables users to define the requirements and establish the business case for funding Agile projects. The packaged solution includes:

  • Blueprint for Enterprise Agile Getting Started Guide – provides an overview and guidance on the Enterprise Agile approach and choices that need to be made.
  • Blueprint Project Template – an Enterprise Agile optimized product configuration template to streamline customer implementation.
  • Blueprint Sample Project – illustrates a sample project based on the template configuration and requirements content.
  • Blueprint for Enterprise Agile Briefing Document – an in-depth description of how to define and manage requirements in an Enterprise Agile environment.
  • Blueprint for Enterprise Agile Mentoring Service – onsite or remote Enterprise Agile experts to help customers get up and running. 

New Blueprint v5.2 Features and Benefits

In addition to the Blueprint for Enterprise Agile add-on, many other new Blueprint features and performance enhancements are now available in v5.2. These include a fully supported open Application Program Interface (API) that enables third parties to build integrations with Blueprint that provide secure access to the requirements information it holds. This release also supports rich text tables in artifact description fields and rich text properties, which enables users to specify tabular data as part of their requirements. The ability to drag-and-drop requirements across projects enables users to reorganize project information within and across multiple projects. Blueprint v5.2 supports the Security Assertion Markup Language (SAML) for secure, federated authentication and Single Sign On (SSO) with enterprise directories.

“The launch of Blueprint for Enterprise Agile, plus the introduction of many significant new features and enhancements, reinforces Blueprint’s position as the most complete requirements definition and management platform available in the market today,” continues Shimmerman. “Also notable is that Blueprint v5.2 was itself developed using the Blueprint platform, enabling us to deliver this latest release on time, incorporating all the capabilities outlined in our requirements, and meeting all established quality targets.”


Blueprint is immediately available as a cloud-based offering or can be installed on-premise if preferred. For additional information please contact Blueprint at 1-866-979-2583 (BLUE) or

Blueprint v5.2 Demonstrations

Demonstrations are regularly delivered online and those interested can register at

How to make requirement walkthroughs more fun

What if requirement review sessions could actually be “fun”?  That people would actually request to be on the invite list? That attendees could feel confident about what they are signing their name to?  As the world of business analysis is maturing rapidly, so is the requirements review session.

When communicating requirements via “legal-style” documents begins to break down, think about how people begin to communicate. They become animated, talking with their hands, drawing on a whiteboard.  The existing application may be started up and they point to the areas to be changed. Block diagrams or workflow pictures start to emerge.  They may even dedicate some time to build a small prototype.  This is great stuff.  It can be very expressive and a great way to get an idea across.

The goal of any requirements walkthrough is to let your team be expressive without sacrificing the manageability of the information. Look for solutions that allow you to ensure the ongoing integrity of the information you’re dealing with, while at the same time letting you communicate it in a variety of ways to suit the message and audience.

Ideally you want a solution that enables you to both create a requirements “model”, and “simulate” that model. The model provides the “nuts & bolts” of the solution.  It lets you ensure everything “fits together”, that there are no overlaps or inconsistencies. It lets you drill down to the details or up to the big picture, and gives you a framework to maintain the information as things change.

Simulation is the ability to bring the requirements to life similar to a prototype that you can execute and interact with. Simulation lets you be highly “expressive” when it comes to communicating with stakeholders. It’s sort of like “watching the movie” instead of “reading the book”.  Ideally, you also want “multi•aspect” simulation. This is like letting each stakeholder independently control their own “camera angle” when watching the movie. While the future end-users can view the simulation from a “user-experience” perspective interacting with functioning screen mockups of the user interface, the designers & developers can view the simulation from a workflow perspective considering business rules and monitoring how data will be used and acted upon.

Seeing the requirements from these different angles lets everyone truly understand the “envisioned” application. Feedback is informed and far more valuable.  The number of review cycles, as you might imagine, drops.

Do you agree? Do you disagree? What have you used in the past for requirements walkthroughs? What are some ways that you make walkthroughs more engaging?

When is a Requirement “Flawed”?

There are three possible areas in which requirements could potentially be flawed that could dramatically impact the amount of “Rework Tax” you’re paying.

  1. Badly Formed Requirements. Industry organizations such as IEEE typically define the quality of requirements based on the degree to which they are “unambiguous, complete, correct, verifiable, consistent, modifiable, traceable, and useable.”  Falling short on any of these increases the likelihood that someone will misunderstand the intent behind the requirements and implement the wrong thing, leading to rework.
  2. Missing Requirements. When requirements are missing, either something doesn’t get built or downstream practitioners are required to ‘fill in the blanks’ with assumptions that are often invalid, once again leading to rework.
  3. Misunderstood Requirements. “Oh…I thought you meant this!”  Even the best-composed requirements that meet all the quality characteristics of Item 1 can still be misunderstood. How requirements are expressed and how clearly they are presented can determine whether or not they are understood. For example, giving end-users long text based requirements documents is akin to giving a builder a text-based description of a house instead of a set of blueprints.

The importance of having accurate, high quality requirements for the success of the application development process is often not recognized. That means stakeholders are often not as invested in the requirements development phase as they need to be to reduce the “Rework Tax” and deliver the right software, on time and on budget. Although key, lack of stakeholder involvement is just one of many challenges in producing good requirements. Others can include a lack of clear objectives, inconsistent information gathering, information overload, and poor expression.

Blueprint publishes essential Requirements Definition and Management resource for Business Analysts

New “For Dummies” book offers practical insights and best practice recommendations on how to author, validate and manage software requirements

Toronto, ON – April 29, 2013: Blueprint, the leading provider of enterprise Requirements Definition & Management (RDM) software, is pleased to announce the launch of its new desktop reference guide, Requirements Definition & Management For Dummies. This addition to the popular “For Dummies” series is jam packed with meaningful information about the critical role of the Business Analyst, and the vital role they play in the application development lifecycle.

“This comprehensive yet easy-to-read book is the definitive guide to understanding requirements definition and management and its direct impact on software project quality and delivery,” said Dan Shimmerman, President and CEO of Blueprint Systems. “Business Analysts, their managers and anyone involved in the requirements process will want to consult this resource to understand how the business environment is changing and what Business Analysts need in order to do their job more effectively.”

As a market leader, Blueprint saw the need to elevate awareness of the critical role of the Business Analyst and explore the emerging Requirements Definition and Management software category. This easy to read guide, covers the key concepts related to the Business Analyst’s role, job function and overall impact on software development and delivery success.

Requirements Definition & Management For Dummies examines:

  • The critical role of the Business Analyst
  • How Business Analysts are transforming business
  • The ways in which Business Analysts are changing how requirements are defined and managed
  • What Business Analysts need to succeed
  • Tips to improve Business Analyst productivity

“Business analysis is a relatively new, but fast-growing corporate function and in fact, the number of Business Analyst positions has increased dramatically in recent years,” said Tony Higgins, Vice President of Product Marketing, Blueprint, and co-author of the book. “But in spite of the growing numbers and strategic importance of the role, Business Analysts still spend far too much time on low-impact clerical activities due to inadequate, inefficient tools that impair their ability to do their job. This book gives Business Analysts the information they need to help others better understand their role and what they need to do their job effectively and to focus on what matters most – business analysis.”

This pocket guide, published by John Wiley & Sons was authored by Tony Higgins, Blueprint’s Vice-President of Product Management, Keith Barrett, Blueprint Senior Systems Engineer, and Robert Schneider, a technology consultant and writer based in Silicon Valley. The content is based on hundreds of Blueprint client implementations and decades of collective expertise in RDM. The book is available in hardcover or as an eBook.

A complimentary copy can be downloaded at

About Blueprint

Blueprint develops requirements definition and management (RDM) software purpose-built to resolve the errors and inefficiencies encountered in RDM today. Blueprint solves many of the time-consuming, costly, error-prone elements of defining requirements, resulting in better business applications with far less rework. Headquartered in Toronto, Blueprint has global sales, operations and partner presence. Visit

Media Contact:

Jennifer Bentley
Blueprint Systems

Does Requirements Gathering Take Too Long?

In a recent social media poll by Doreen Evans Associates, business analysts (BAs) reported that their top obstacle to success was the perception that requirements gathering takes too long. The truth is that requirements gathering and requirements management—when done correctly—are essential to producing outcomes that meet the needs of users. And, because the process is so necessary, it takes time.  In fact, BAs believe (and analysts like Gartner agree) that more time, not less, should be spent conducting business analysis. While it may be hard to convey the message that a process that is already perceived to be too long may not be taking long enough, you do have some great arguments that support this somewhat unpleasant message. For DEA’s persuasive arguments and tactics to support them, click here.

5 Critical Steps to Business Analyst Competency, Improved Performance in Insurance & Banking — Thursday, April 5 at 1 p.m. EDT

Celent and Doreen Evans Associates cover business analyst competency—Research results and practical advice. During this 60-minute informational and interactive webinar, Celent will not only let you know where your competition stands, but having worked for over 20 years helping insurance and banking firms establish BA Competency, DEA can show you how you can gain a competitive advantage through improved BA performance:

  • Discover how the Insurance and Banking industries judge the competency of their own BAs
  • Understand why projects fail—and what you can do about it
  • Learn how to gain critical leadership buy-in and empower agents for real change

Click here to register:

Do We Really Need a Business Analysis Center of Excellence

Demand for increased business analyst involvement throughout the system development life cycle has fueled the recognition and growth of the business analysis profession.  As a result you may be considering how to formalize your business analysis practice.  To determine if a Business Analysis Center of Excellence (BACoE) is right for your organization, start with a discovery and planning effort focused on understanding your current situation. We find that discovery and planning is well worth the investment as it provides a clear picture of the organization’s business analysis maturity and the effort it will take to reach a higher level. At Doreen Evans Associates, we help organizations establish, institutionalize and maintain best-in-class business analysis competency. Click here to download a practical approach to determine the need for a BACoE in your organization.

— The industry consortium for business analysis.