Thank you all for helping !!

Hi Sonavi,

Do you also have access to the code or can work with a developer who can read the code?  Just understanding the UI and the data structure is not enough - you need to understand the business logic which, for most applications, is hard coded in the actual code.  If you don't have access to the source code then you have a tough job ahead of you since you'll have to guess/infer the business logic based on the application behavior and, perhaps, from talking to users who are familiar with the system.

The activity that you are actually being asked to perform is called "reverse engineering" where rather than trying to gather requirements from the stakeholders you are using an existing system and trying to document what it does.

Here are some things to consider:

• If you are trying to document the business processes which utilize this application you should document this using a business process notation such as BPMN (Business Process Modeling Notation).  This will help you understand the big picture and how the given application supports (or does not support) the goals of the business.
• What are the "things" of the business, that is what are the nouns which the application deals with and which are recognizable by the business?  These are also known as "business entities".  You can discover most of the business entities by taking a look at UI and the database tables.   These can be modeled using a Class Diagram which can also show the relationships among these entities. For example: in a banking application some of the business entities might be: bank account, customer, transaction, etc.
• For each business entity you should try to identify its attributes (data which describes the thing).  For example: a bank account might have: a number, creation date, current balance, etc.
• What does the application do? What are the key functions that a user can perform on the application?  Please note that most functions deal with one or more of the identified business entities by Creating, Reading, Updating, or Deleting (CRUD) business entities and related data.  You could model these key functions using a Use Case Model.
• For each key function, you will need to understand the detailed business rules and logic.  For example: It is not enough to know that the user can enter numbers on the screen, press a "Calculate" button, and view/save a result.  You will need to know what logic/formula the system uses to calculate the result.  There are many ways to capture this logic such as: use case specifications, pseudo code or structured English, activity diagram, business rules, etc.

One more note from personal experience:  The fact that the database contains a number of tables and fields, it does not mean that the system actually uses all that data.  Similarly, the fact that the user can enter a piece of data in a screen, it doesn't mean that piece of data is used anywhere.  I once worked on a legacy application which had about 1000 tables but only about 300 of them were actually used by the application.  As the system evolved, the developers and DBAs did not remove old/legacy tables out of fear of breaking something.  That is the drawback of not having up-to-date system documentation.

Hope this helps!

- Adrian