• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Requirement Models for System Replacement Projects

We recently received an “Ask Joy” question around what models can be helpful for a system replacement project. Below is our answer, slightly modified to give proper context for all.

System replacement projects can be a challenge, since many times the systems being replaced are old and obsolete from a technology perspective, but our business counterparts know and love their existing systems!  Thus as a start, create Process Flows to understand what the business is doing today. The focus should be on the business activities, what they are and are not doing. Once you have the process flows, annotate them with Key Performance Indicator Models (KPIM). KPIMs can help you demonstrate to the business stakeholders that even if the new system behaves differently, the business outcomes will be the same or better.  KPIMs are great to capture expectations around performance in an old/existing system – so that you can prioritize feature to maintain the most important of those.

Additional requirement models that you might consider also include:

  • Roles & Permissions Matrix – this can help you understand how to move your existing users to the new system and what role they need to have in the system and what the permissions are for the role.
  • Ecosystem Map – this will help you understand what the existing systems are, how they are connected to each other and the high level business data objects that flow between them.  This is a great model to help identify the existing integrations and what integrations you may need with the new system.
  • System Flow – similar to process flows which focus on people, this focuses on the system(s).
  • Business Data Diagram – this will help all understand the business data objects and the cardinality relationship between those data objects.
  • Data Dictionary – these are terrific to capture all of the UI fields that will be required. Be careful not to capture a field just because it is there, ensure that it is being used. You may also find that through the years existing fields have been repurposed. This is a terrific time to understand those fields and ensure they are named appropriately.
  • Report Table – to help define any existing reports that are needed in the new system.

5 Responses to Requirement Models for System Replacement Projects

  1. Dane Wyrick March 3, 2016 at 2:25 pm #

    The data dictionary URL is http://seilevel.com/business-analyst-resources/business-requirements-models-templates/data-dictionaries/

    The blog is linking to business data diagram twice.

  2. edward March 3, 2016 at 4:39 pm #

    betsy, excellent article!

    The most complex project I worked on in my 38 yr development & requirements mgmt career was an 8+ yr project that was completely replacing 30+ systems that received, processed, and issued payments (via direct deposit, check, wire transfer).

    Process and system flows were invaluable to help the client/stakeholders agree on the process, variability points, business rules. A business data diagram was not totally used by the clients/stakeholders, but it was very important to my team and me to help understand and get confirmation on concepts, attributes, data model cardinalities, relationship rules, etc.

    But most important as time went on was a System Context or Ecosystem Map – all the systems that this system had to interact with. By the time I left the project, we had identified interactions w/ about 20 external systems – some were only receive data, some were sent data & expected a reply, some were just sent data. some of those interactions were time sensitive, some were “send and forget.”

    many times, the client/stakeholders had no idea of how many systems they interacted with, how they did, nor the timing of those interactions. then add in all the data formats [plain text, XML, tagged data] and communication channels [secure FTP, MQ messaging, emails, output files].

    Kind of like the business data model, the stakeholders didnt always appreciate the System Context models, but the reqs, development, and test teams sure did!

    To all who are considering using any or all of these models (and you really should, at least for your team) – dont create ONE BIG MONGO model of each type.
    Model the area that you are currently dealing with or need to present to others. Your modeling tool [if you have one] should let you easily create sub-sets (“view”) of the business data model, Ecosystem Map, process flow, whatever. When one person makes a change in one view, the modeling tool will keep the other views in synch w/ those changes.

  3. Melanie Norrell March 3, 2016 at 5:14 pm #

    thank you for the note Dane; it has been updated!

  4. Michael Schenkel March 4, 2016 at 2:31 am #

    Is there a specific reason, why you recommend an ecosystem map instead of SysML diagrams such as system context diagrams or a blog diagrams?

  5. Betsy Stockdale March 7, 2016 at 1:14 pm #

    Michael, thank you very much for your question.

    As a general rule, with the models that we use at Seilevel, they are focused on the business and end user. As a business analyst, my first focus is ensuring I understand what the business problem is, understanding the business value that any potential solution will have, and ensuring that I understand the end user point of view. All of these models are focused there. Experience has shown me that business/end users struggle to understand models that tend to be more technical in nature.

    Now having said that, as the analysis focus turns from understanding the business need to system design, many of these models can then be transformed over into other sort of models, be they SysML models, ERDs, etc. I like to think that if I have done my job properly, making the transition to other sort of models for the actual system analysis and design can be straight forward and actually help my more technical peers make that transition quickly and easily.

    I hope this helps, and thank you again for your question!


Leave a Reply

Your email address will not be published. Required fields are marked *