I'm looking for an umbrella term for all the nitty-gritty requirements that it's helpful to have specified up front but which the client never thinks about in his excitement about the product.

In the client's mind, they think of the headline requirements, the main user stories such as "I need to be able to view the status of all equipment" and "I need to receive automatically any notification equipment failure". But at times the mundane ones are there but the client never mentions them until the result differs from his unspoken expectations: "Well of course a user must be able to change his own password" and "Of course the user's session must time out after 30 mins"

Any development team can anticipate what's likely to be needed but is there a name for this category of requirements? Obvious/infrastructural/boring/details?

  • 1
    If it gets to the point of angrily waving contracts in which said "requirements" were never recorded, then you're well within your rights to describe them as "not requirements". :-) (I am not a lawyer, btw.) Commented Oct 16, 2013 at 15:35
  • 11
    Why wouldn't they simply be called "missing requirements". Because that's what they are.
    – Dunk
    Commented Oct 16, 2013 at 15:41

5 Answers 5


Infrastructure details are called "non-functional" requirements. It's a weird term describing those requirements that are not visible to the end-user, but are still necessary for the application to function properly.


The application shall provide a mechanism for allowing the user to change his password


The user session must time out after 30 minutes

are not non-functional requirements, and they are not obvious. Always capture such requirements, and put them in your requirements matrix.

  • That's the thing, they are requirements and will be subject to tests.
    – djnz0feh
    Commented Oct 16, 2013 at 15:41
  • Non-functional requirements are often part of the missing requirements, thus when you refer to the thing described by the OP by "they" in your first sentence, you don't hit it precisely. I am pretty sure you are aware of this.
    – Doc Brown
    Commented Oct 16, 2013 at 15:47
  • @Mike: So test them. Commented Oct 16, 2013 at 16:25
  • @DocBrown: I have clarified my answer. Commented Oct 16, 2013 at 16:46

I'd categorize those as "implicit" requirements. Like "User must be able to log in" implies that there is the notion of a User (with an associated database table/store of some sort), some notion of a password or other credentials, and the requirement to store the user ID or some other token in the session. This further implied (to me, anyway) that there must be some kind of user maintenance process for adding and removing users, and probably a report of some kind showing user name, first login date, last login date, associated e-mail account and anything else you're keeping track of.

  • 1
    'Implicit' is pretty darn good!
    – djnz0feh
    Commented Oct 16, 2013 at 15:41
  • 1
    I've always heard them called "implied requirements", but the gist is the same.
    – Telastyn
    Commented Oct 16, 2013 at 16:32
  • 10
    This actually demonstrates the danger in leaving "obvious" requirements to the ether. The very first implied requirement assumes that the application will have its own user accounts, rather than passing off authentication to a separate system like LDAP or an OAuth provider. The implication that the application should allow for user management builds off this (possibly incorrect) assumption.
    – Dan Lyons
    Commented Oct 16, 2013 at 17:17
  • 1
    This is a good word for your examples, but doesn't quite sound like what the OP is describing. More like the opposite - where "there is the notion of a User" is in the requirements in some form, but "obvious" actions like "the user can change their password" were not, and so completely missed. "implicit" requirements are A where A implies B and B was requested, not the other way around
    – Izkata
    Commented Oct 16, 2013 at 20:28
  • 1
    @Izkata When something is 'implicit' that means that that thing is 'implied' by a given, not that it implies a given. This is for the same reason that (for example) the axiom of choice is not implicit in all situations where only a weaker axiom is assumed, like the axiom of countable choice. Your reasoning would have us assume that the axiom of choice is implicit in all situations where only weaker axioms are assumed. Commented Oct 17, 2013 at 0:42

I think that the closest thing that I can think of would be a "derived requirement". These are requirements that are generated by the development team, based on a number of sources such as regulatory agencies, corporate guidelines, and past experiences on similar projects.

However, even after you derive additional requirements from the customer/user requirements, it's important to validate them with the customer/user to ensure that they are correct. After you validate them, you track them just like every other requirement. Note that just because some guideline or experience suggests a requirement doesn't mean that the customer wants it. In fact, it could be contrary to what is expected from the system.

  • 1
    +1. I have often worked together with devs which were pretty "good" in making wrong assumptions about what the customer might want. So it might be also a good idea to keep some kind of log about potential requirements which have been analysed as not needed, not important or plain wrong.
    – Doc Brown
    Commented Oct 16, 2013 at 19:28

I'd just go with assumptions (or, unwritten assumptions if it should be more precise).

Implicit, from another answer, doesn't quite work, because what was requested doesn't necessarily rely on them. For example, user must be able to change their password isn't implicit unless another requirement makes reference to a user changing their password with the assumption that it already works.

Very obvious, from the question, doesn't really work either. It could easily be something that's only obvious to someone with appropriate domain knowledge, or works very closely with the product. Or, to use the password example, it may be that users shouldn't be able to change their passwords, and only admins can.

What you're describing are things that the client assumed would be done.


I came across this from another site and wanted to add my two cents.

In my view the moment a client/manager starts using phrases like 'it is obvious' or 'it was obvious' the contract between the project owner and the developers breaks down.

When a developer implements something correctly, but misses something that was 'obvious' (but not specified) it will be the developer's fault; when they implement something that was not specified it will be their fault for not following the specification. This is how software development works in companies where the developers are blamed for every failing - usually with a weak manager who is happy to have people to offload the blame onto.

All requirements should be documented, explicitly, even if it seems that the obvious is being stated. That way there is no doubt about what is being built and a clear audit trail to explain why something is not as the client would have hoped.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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