Problem:

You are responsible for capturing and analyzing requirements for a project to enhance a legacy system however misunderstandings happen too frequently among your team members.

Context:

A maintenance project is very different to a greenfield project. The key difference is that a business analysist who is responsible for discovering requirements must be not only domain expert but also be able to communicate with technical experts very well. In other words, the business analysist must both be familiar with the legacy system workflows and have adequate technical background.

Suggestion:

1. Collect existing artifacts, including software products, user guide, administrative guide, installation guide, deployment schema, design specification.
2. Build a glossary and reference sources.
3. Get initial agreement about terminologies (terms).
4. List all system roles.
5. Walk through the existing user interfaces to determine existing roles and related core use cases.
6. Collect business problems or needs.
7. Distill navigation flow and user interfaces related to customer’s problems or needs. Try to find out the exact screens in the existing system related to customer’s problems or needs.
8. Clarify terminologies. Ask for example values, files, tools for doing something related to unclear or ambiguous terms.
9. Identify correct problems by asking for demonstration of the issues or limitations of the current system, step-by-step illustrated examples with actual existing values, drawing sketches for guessed needs using a pencil or a tool.
10. Identify correct needs by asking for user guide, video demonstration of a feature, 3rd party installation files and custom scripts if available, example input data and output reports.
11. Document business needs by creating use cases with mockups. There might be a need of review of the existing source code and database to indentify initial draft technical solutions when creating these use cases to ensure that they are feasible.
12. Identify affected features by revising the use cases with additional steps, mockups, data inputs/outputs, descriptions. There might be a need of review of the existing source code and database to indentify initial draft technical solutions when identifying the affected features.
13. Identify affected roles by revising the use cases with additional or new business rules for all related roles.
14. Some enhancemens related to technical aspects might require collecting existing technical artifacts. These artifacts might inlcude current database or data schemas, and current software products and source code if possible.
15. Install tools related to existing source code, then build and run existing source code and database if they are available.
16. Collect technical problems or needs by listing current technology issues using notes or diagrams.
17. Analyze techincal needs. These might be data integrity issue (missing or duplicated fields? missing or duplicated rows?) or performance issue (too many rows to handle by current software?).
18. Finally document technical needs by creating an existing architecture and a proposed future architecture. There is surely a need of review of the existing source code and database to indentify initial draft technical solutions when creating existing architecture and a proposed future architecture.

Things that have to be discovered and confirmed:

1. Legacy systems: Examples might be access to legacy systems, captured UI screenshots of each sub-systems, parts of database schemas, example data, example legacy source code, legacy codebase.
2. Problems: Examples might be lack of documentation and expertise, non-scalable architecture, high cost development for new features, unfriendly UI/UX, performance issue.
3. Goals: Examples might be migration of legacy system to event-driven, cloud based microservice architecture with modern UI/UX.
4. Budget: Used to select appropriate technologies. Some cloud services, e.g. Salesforce Platform or AWS relational databases, might be very expensive.
5. Initial text or diagrams: Ask for clarifications of ambiguous terms or components. Does initial proposed solution just need to be general? Should proposed architecture need to be adapted to specific problems, needs, legacy codebase, existing data, and budget?