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?

  • I don't really know what you are asking. What information do the "higher-up" need? They want the ability to lock a profile. Ok...so do that. If they want different levels of authentication then that is a completely different requirement and it sounds like a largely orthogonal feature.
    – Pemdas
    Feb 27 '11 at 4:36
  • I'm considering a situation where those who are asking for a feature cannot describe what that feature looks like : the system is too complex for them to be familiar with all its details and consider how the new feature would affect them. How do you handle incomplete feature requests? I edited my question above in an attempt to clarify. Feb 27 '11 at 4:49
  • @Pemdas: what he means is: a programmer will need some clarification from the stakeholder or customer when the feature is being implemented. The clarification needed for this question comes down to: "When the lock is in effect, is Action X/Y/Z still allowed"? The gathering of this list of questions will take some time for the programmer.
    – rwong
    Feb 27 '11 at 7:47
  • one supplementary difficulty, those performing the security audit will probably need (at least) read-only access to the said profile. Feb 27 '11 at 20:56

The second option: "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?" is close to what I would do. I might have to discover these by working with the code, so the third option is also partially in play.

The users have to be told about all the interactions because users don't [usually] think through every possible scenario, whereas programmers do (or try to).

It sounds like all the potential operations should be enumerated and put in a configuration file or table, with the operation in one column, and whether to allow it on locked entities in another column. That way they could be changed in the future if necessary.

(Edit: Obviously you can't use a table to list hundreds of interactions, but I'm guessing that those hundreds of interactions will funnel down to a manageable number of specific operations.)


If your client is not able to express business requirements in proper terms (a pretty common situation), and the developer cannot properly guess and read between the lines (again, pretty normal), you need someone to bridge the gap.

This person is usually someone technical with strong business knowledge. If that person does not exist then you need to have an open jam session with the business guys until you find ways to communicate the intent to each other, record it in a way that makes sense to both sides and above all make sure that you understand the same thing. This can be done through drawings, diagrams, plain language, expected results, expected input, expected benefits... in other words you need to capture the business stories (use cases) that will drive the feature set.

If that still does not work, then you're down to trial and error. This is time for proofs of concept, prototypes, mock-ups, whatever will be cheap, dirty, to the point, assist in bridging the gap between technical and business people and above all whatever can be used to have a two-way iterative improvement process to efficiently get to the point (gathering requirements).

If that is still not feasible (whether that's for cost, time, expertise or operational reasons), then your last resort is to try something out, your best guess, build significant contingency, make sure you take a stepped approach that you can back track from at minimal cost (I would suggest starting with the riskier items, but that's not necessarily the best approach) and build in many check points with the client so that they can interact with it and evaluate what it does for them.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.