Hi Prasad,

You are mixing things here beyond simple requirements.  First, understand that requirements are not just textual statements. They can be models that communicate the user need as well.  Ultimately your requirements should explain WHAT the application is intended to do, not so much HOW it should do it.  So, WHAT are the goals of the user, which leads to WHAT the application should accomplish to deliver value to the user.

You wrote: When the user clicks on the phone icon, a separate window should be displayed to enable the user to report BAD phone numbers.

The requirement is: The user shall be able to report bad phone numbers.  

HOW the screen is designed or structured to achieve this (phone icons, pop-ups, etc) is a design decision that should be decoupled from your requirement. The HOW usually occurs after the requirements are documented (and is determined by a UX designer, though BA can do this role if they are skilled or if it is required because the team is small). 

Documenting the information or data inputs required to meet the user goal is part of the requirements, but I would capture the detailed data requirements separately and only reference data at an aggregate level.  

For instance, you mentioned a search feature. I'm not sure I understand what you are trying to search but I'll invent a requirement here for you as an example.

Requirement: The system shall provide search capability which receives Customer Address data as input and returns Jurisdiction as output.

You can then define WHAT "Customer Address" data is separately (Name, Address Line One, Address Line Two, State, Country, Zip Code). You can also define the rules of the search by creating test cases which validate that your requirement is correctly implemented. 

Test Cases for Search:

1) IF any of the following are missing: State, Country, Zip Code, THEN the system shall create an error notification which reads "The following data is missing..."

2) IF two jurisdictions are available THEN ...

Hopefully you get the idea.

In all of these cases, I haven't referenced anything about how the screen will look or where the data will be presented. That's UI/UX design.  These feature may occur on 1 screen or multiple screens. Inputs could be input into text fields or selected from dropdowns, etc..

So remember, keep the requirements decoupled and separate. They describe WHAT goal or value the system provides to the user.