How do you handle incomplete feature requests, when the ones asking for the feature cannot possibly write a complete request?

Consider an imaginary situation. You are a tech lead working on a piece of software that revolves around managing profiles (maybe they're contacts in a CRM-type application, or employees in an HR application), with many operations being directly or indirectly performed on those profiles — edit fields, add comments, attach documents, send e-mail...

The higher-ups decide that a lock functionality should be added whereby a profile can be locked to prevent anyone else from doing any operations on it until it's unlocked — this feature would be used by security agents to prevent anyone from touching a profile pending a security audit.

Obviously, such a feature interacts with many other existing features related to profiles. For example:

• Can one add a comment to a locked profile?
• Can one see e-mails that were sent by the system to the owner of a locked profile?
• Can one see who recently edited a locked profile?
• If an e-mail was in the process of being sent when the lock happened, is the e-mail sending canceled, delayed or performed as if nothing happened?
• If I just changed a profile and click the "cancel" link on the confirmation, does the lock prevent the cancel or does it still go through?
• In all of these cases, how do I tell the user that a lock is in place?

Depending on the software, there could be hundreds of such interactions, and each interaction requires a decision — is the lock going to apply and if it does, how will it be displayed to the user? And the higher-ups asking for the feature probably only see a small fraction of these, so you will probably have a lot of questions coming up while you are working on the feature.

How would you and your team handle this?

• Would you expect the higher-ups to come up with a complete description of all cases where the lock should apply (and how), and treat all other cases as if the lock did not exist?
• Would you try to determine all potential interactions based on existing specifications and code, list them and ask the higher-ups to make a decision on all those where the decision is not obvious?
• Would you just start working and ask questions as they come up?
• Would you try to change their minds and settle on a more easily described feature with similar effects?

The information about existing features is, as I understand it, in the code — how do you bridge the gap between the decision-makers and that information they cannot access?