Reverse Engineering Requirements: Select a Business Owner and Identify Scope

If you are given license to start reverse engineering a legacy system into requirements, also known as a “current capabilities assessment”, it’s often tempting to jump right in and start documenting. But before you do that it’s important to lay the groundwork for your task.  You’ll want to identify a business owner and define scope to put your project on a path to success.

Note: This is a follow-on post from Reverse Engineering Testable Requirements (an introduction) and the #2 of a 6 post series.

Selecting a Business Owner

Identify a primary business stakeholder within your organization to oversee and “own” the project at an executive or mid-management level.  This will often be your manager, but what’s most important is that the person can provide oversight into how this work will help the organization achieve it’s other objectives.  The business owner will help you gain support from others when you need their input.  If you are starting a grass roots documentation effort, you can skip this step, but in all likelihood you’ll need to circle back later when your project stalls out due to lack of input.

Defining Scope

There are three key elements of scope when you are reverse engineering requirements. 1) Business goals; 2) Identifying Systems; 3) Identifying Deliverables. Essentially, you are looking for the why, what, and how of your project.

Business Goals

Business goals are the value the organization will realize through this project.  Be sure to think broad and outside the immediate impact this project will have for you and your team.  Since you are assessing the organization’s current capabilities, there are other people within the organization who might find this document valuable and for very different reasons.  Here are some sample business goals:

• Establish a managed testing process by creating repeatable test scenarios, thereby decreasing defects found in production
• Improve our ability to determine the downstream impact of new requirements, thereby reducing missed requirements found late in the development cycle
• Establish appropriate context by which to generate a go-forward plan for re-engineering our systems

Identifying Systems

Most organizations have more than one system supporting them.  You’ll want to select systems, and even components of systems, that are clearly tied to business value.  If bugs keep creeping up in one area of the system, then focus your attention in that area first.  Clearly state and describe each system (or component) you intend to document.  Also, identify any system integrations that need to be documented. Often a simple system-context diagram creates a visual picture of scope.

Identifying Deliverables

A Current Capabilities Assessment can be completed at varying levels of detail.  You might want to sweep through many systems with a wide brush in a few short weeks or you might need detailed test scenarios for a specific part of the system that is constantly breaking.  Again, it all comes back to your business goals.  Here are some sample deliverables that can be delivered.

• Features List: List of high-level features and brief descriptions, providing a broad-stroke functional map of the system.
• Use Case List: List of all use cases with brief descriptions.
• Actor/Use Case Diagram: Completed actor/use case diagram.
• Use Cases: Detailed descriptions of the flow between the actor and the system.  Identify the sections of the use case appropriate to the project.
• Test Case List: List of all test cases with brief descriptions.
• Test Case Scenarios: Step-by-step test scenarios for executing functional tests against the system.
• Site Map: List of all pages on a website, with their URLs and a brief description.

There is a lot of flexibility in this list.  One rule of thumb: include a “list” deliverable before the detailed deliverables. You would not want to deliver detailed use cases without first generating a use case list.  Again, select based on your business goals. For example, if the primary business goal is to make this system testable, you will probably select a use case list, test case list, and test scenarios, leaving the detailed use cases out.  If the goal is to make better requirements decisions going forward, you’d likely chose a use case list and detailed use cases.

This is post #2 in the Current Capabilities Assessment Series.

Related posts:

1. Reverse engineering requirements: Create a Work Plan
2. Reverse engineering testable requirements
3. Reverse Engineering Requirements: Synthesize, Document, and Validate!

Tagged as: Software Quality Assurance