Ruminating on Requirements Elicitation

Last night, I was ruminating on the lessons learned during my experience in business architecture, business analysis and requirements elicitation. I think at the broad level, there are 2 kinds of requirements.

The first kind is - Where we know, what we don't know: These requirements are easy to capture since we have an idea about the pain areas of the customer, we know what is the vision of the project, what is being planned to be done, etc. Hence we can ask appropriate questions, dig deeper and after a few iterations of interviews can get a pretty good understanding of the requirements.

The second kind of requirements are - Where we don't know, what we don't know !
Digging out these requirements is the most challenging task - because we never ask the right questions about things that don't know, our past memory/experiences make implicit assumptions on certain things. Such kind of requirements result in last minute suprises and everyone wonders why these points were never discussed or brought out !!!

How do we elicit these requirements? I think the following techniques during requirements elicitaiton would help:
1. Question each and every assumption - both implicit and explicit. Assumptions may not hold true in every scenario. Check if the assumption is valid for the current scenario.
2. Ask 'stupid' questions - Yes, this works !!!...I have seen that often, analyst's refrain from asking questions because they are self-conscious, are afraid of being ridiculed for lack of knowledge in a domain area, etc. i.e. they are afraid of sounding 'stupid'. But clarifying even the simplest doubt could open up a plethora of new requirements.

Migrating applications across platforms

We often require to migrate applications from one platform (OS/hardware) to an other platform - either as part of a portfolio rationalization program or because the current platform is reaching its EOL. For e.g. migrating Java apps from Solaris/SPARC to Linux/IBM Power, etc.
During such migrations, it is essential to have a well documented plan covering all the aspects, so that we do not miss anything. Listed below is a brief set of points that must be included in the brainstorming discussions during the planning phase.

1. Migration of the Runtime environment: For e.g. miration of the Java runtime from Solaris to Linux. There are many JRE's available on Linux and we need to select the appropriate one.
2. Migration of the Application Infrastructure: The application may require a webserver, application server, a Message queue, etc. These infrastructure components would need to be ported to the target platform or other alternatives selected.
3. Migration of application code: Does the code need to be recompiled/linked on the target platform? Was the application using any platform specific API for performance?
4. Migration of application configuration: What configuration needs to change on the target platform? e.g. file paths, endian-ness, max-memory settings, thread pool settings, etc.
5. Migration of development environment: Would it be required to migrate the development environment? Will the same IDE work? IDE-Runtime integration issues, etc.
6. Migration of Build and Deployment process: Need to change build scripts - ANT, Maven, Shell scripts, etc.

Also it makes sense to leverage the expertise of the target platform vendor during the migration exercise. For e.g. IBM, HP, SUN, RedHat, Novell, etc. all have guidelines, recommendations and migration kits for migrating from a target platform to their platform.