Transition Requirements: The Requirements Gathering “Underdog”

/

In gathering requirements, analysts tend to focus more on functional and non-functional requirements. This is largely because in the end, that’s how we get paid – by delivering systems that work the way stakeholders want them to. In the midst of tight deadlines and limited resources, it’s easy to delay gathering transition requirements until all solution requirements have been gathered. In extreme cases, leaving transition requirements until you’ve got “everything else covered” could easily lead to disaster. Requirements (no matter how transient) not discovered on time can introduce delays, risks and cost more money. 

IIBA’s BABOK V2 defines transition requirements as, ”A classification of requirements that facilitate transition from the current state to the desired future state, but that will not be needed once that transition is complete.’

I call them the “requirements underdog” because:

  • They can easily be overlooked
  • They receive less attention at the beginning of the project because a higher priority is placed on establishing the business need and gathering solution requirements (functional and non-functional). In practice, they cannot be defined until the solution has been designed
  • They are not always visible to stakeholders/business users and may not come up for discussion during elicitation sessions
  • They are transient – that is, they disappear after the solution has been deployed
  • They may not be needed at all - for example, in cases where there's no existing solution to move from

So, as you’re gathering requirements and designing strategies to build or buy, think “KYE” – Know Your Environment. Think about what structures you need to put in place. Training, data migration and data cleaning are just one portion of it. Think about user interfaces, interfaces to and from external applications or system-to-system interfaces and hardware interfaces.

  • What systems or software will interact with your proposed application?
  • What user interface functionalities and layout are required?
  • What hardware devices will your new system connect to?
  • What platforms will your proposed application run on?

How can you stay ahead of all these?

By conducting Interface analysis as early as possible in your project.

Here are 3 reasons why you shouldn’t wait till the end:

  • To ensure the interoperability of your application with existing/legacy systems  - Whatever solution (software/hardware) you select (to buy) has to be compatible with your existing hardware platforms, operating system and legacy applications. If you’re buying commercial-off-the-shelf software, you’ll need to ensure you send RFPs to only those vendors with solutions that are compatible with your platform.
  • Collaboration – Consider other software projects in your organization that may be impacted by what you’re doing. Conducting interface analysis early on in your project can prevent re-work, work duplication and potential clashes of stakeholder interests. When you examine existing systems or interfaces that may potentially provide data to or retrieve data from your proposed new system, you may discover similarities. This will save costs, time and significant resources down the line.
  • Planning for integration – Interface analysis gets you thinking about what you need to facilitate integration. How would you support connections between your software and other applications? Defining integration requirements from scratch can save you from complications. Conducting interface analysis early on will also help you define how data mapping will be done and what security and operational requirements are necessary to facilitate seamless integration.

Do Remember:

  • You may use the context diagram to scope your system. The context diagram outlines the external entities you receive inputs from and send outputs to. Think about the interfaces between your system and these external entities
  • Data modelling helps you identify your data requirements, which in turn can lead you to consider data sources and how these data will be integrated with your new system
  • Ask for help when you need it. Integration and interoperability issues are usually technical. Don’t hesitate to ask for help from experts in defining these needs.

Transition requirements, fleeting as they seem, can make or break your project. Start planning for them as soon as your solution components are defined.

Useful Links

Investing in Interface Analysis - EBG Consulting Site