Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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.) –  Grimm The Opiner Oct 16 '13 at 15:35
11  
Why wouldn't they simply be called "missing requirements". Because that's what they are. –  Dunk Oct 16 '13 at 15:41
add comment

4 Answers 4

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.

share|improve this answer
1  
'Implicit' is pretty darn good! –  djnz0feh Oct 16 '13 at 15:41
1  
I've always heard them called "implied requirements", but the gist is the same. –  Telastyn Oct 16 '13 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 Oct 16 '13 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 Oct 16 '13 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. –  AJMansfield Oct 17 '13 at 0:42
show 3 more comments

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.

However,

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

and

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.

share|improve this answer
    
That's the thing, they are requirements and will be subject to tests. –  djnz0feh Oct 16 '13 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 Oct 16 '13 at 15:47
    
@Mike: So test them. –  Robert Harvey Oct 16 '13 at 16:25
    
@DocBrown: I have clarified my answer. –  Robert Harvey Oct 16 '13 at 16:46
add comment

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.

share|improve this answer
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 Oct 16 '13 at 19:28
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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