Hi Vikas,

I think you should start by talking with the implementation teams to figure out what sort of documentation and assistance they need to ensure that they are building what cilents want. Also talk to the customers and find out what documentation, if any, they want to see before approving the go-ahead with a project. This will serve as a starting point for understanding what activities you need to do in order to meet the needs of both stakeholders.

The functional requirements you mentioned describe the user interacting with a system; even if they are basic it may make sense to write up a use case, activity diagram or use some process model to describe what is occurring.  For example, 'improved search' is a general all-encompassing term for potentially several use case scenarios (e.g. user searches by tag, user searches for car model, etc.).  Alternatively you may have a single search scenario that is supplemented by several fuctnional requirement statements and/or business rules detailing the type of searches performed simultaneously or under certain conditions.

I would take care to try and come up with good basic use cases that can apply across clients, and then supplement textual requirements and/or business rules for specific clients where appropriate.  This way you won't need to re-invent the wheel each time a new customer comes along and fits into an existing type of solution you're offering.

The 'non functional requirements' you indicated to me aren't really those (i.e. they don't pertain to reliability, performance, operability, security, compatibility, maintainability, transferability) but rather technical constraints.  These need to be documented with your requirements for the specific solution you are implementing.