Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am not clear on this one. No matter the terminology, in the end the software fault/bug causes (according to a lot of sources):

Deviation from requirements
Devation from expectations

But if the expectations are not in requirements, then stakeholder could see a bug everywhere as he expected it to be like this or that..So how can I really know? I did read that specification can miss things and then of course its expected but not specified (by mistake).

share|improve this question
up vote 5 down vote accepted

But if the expectations are not in requirements, then stakeholder could see a bug everywhere as he expected it to be like this or that..So how can I really know?

You know what is in the requirements by reading the requirements. (There may also be unstated requirements; i.e. things that were so obvious that nobody bothered to write them down. But these can be problematic: see below.)

You know what the user's expectations were / are by asking the user.

Whether an unmet user expectation is a "bug" is really a matter for discussion between the stake holders.

Unfortunately, a lot of less than scrupulous software suppliers / contractors will play hard-ball over reasonable user expectations that are not written requirements. But the flip-side is that some less than scrupulous customers are prepared to play cost / blame shifting games by pretending that expectations are unstated requirements.

share|improve this answer
....Don't forget ambiguous requirements - I had one "System will do YXZ if A and B or C is True." – mattnz Sep 25 '12 at 3:52
@mattnz - Ambiguous requirements should be far less of a problem, Assuming that you are diligent, you notice them early, figure out what they are supposed to mean, and get the customer's sign-off ... before you even start cutting code. The expectations vs requirements conflict tends only to happen when the user start getting their hands on the system, and find it doesn't do what they think it should. – Stephen C Sep 25 '12 at 7:44

Generally, a deviation from expectations would only be considered a bug if the expectations were obvious and reasonable. For example, if the application is for scheduling medical appointments, clearly taking 10 minutes to pull up an appointment would be unreasonable. But if the requirements didn't specify a time frame, it wouldn't be a deviation from requirements.

share|improve this answer

I know it's a bit old school, but (on the whole) misunderstandings about what something is to do should be sorted by one of two documents:

  • Software Requirements Specification (This is what we think you have asked for)
  • Software Design Specification (This is how we are going to do it)

Both of these should have customer approval, and buy in.

But with more "flexible" development systems (Agile, Scrum etc) the formal life-cycle is being disapplied. This (IMHO) is a return to the "wild-west" of Software Engineering of the early days.

This has led to Andrew's Law of Project Management:

We don't have time/budget/resources to do it right the first time, but we'll find the time/budget/resources to do it a second (and probably a third) time.

share|improve this answer

In an ideal world, requirements must be as complete as possible, and there would be no deviation from expectations, since all expectations would be translated into requirements.

In the real world, on the other hand, requirements are often incomplete, which makes room to unwritten expectations. Examples:

  1. An application takes ten minutes to do the simplest task, making it totally unusable (see the answer of David Schwartz above).

  2. An application has blue buttons, while the stakeholder hates blue and her favorite color is yellow.

  3. All user's passwords are stored in plain text and shown to everyone who goes through "Forgot my password" procedure.

  4. The visual design sucks.

  5. The application sends sensitive information back to the developer. The developer also has a back door access to the application, letting him to do whatever he want.

You notice that some expectations are very easily translated into requirements. For example, the first one can be verified with a simple non-functional requirement related to performance:

The loading of [...] performs 85% of the time below 500 ms. when tested on machine with the performances specified in appendix G part 2 and the load below 15% for the CPU, below 40% for memory and no active R/W disk operations.

Others need not one, but several requirements. For example, the third one cannot be expressed as:

The system is secure.


Passwords are stored in a secure way.

since both are not the requirements: they are not precise enough and are subject to interpretation; they cannot be objectively tested. This means that you would need a requirement about the hashing algorithm, and several requirements about how "Forgot my password" procedure works by generating a password with a cryptographically secure pseudo-random number generator, then sending it by email.

Also, some expectations are close to objectiveness then others. At least, most people would agree that the fifth example illustrates something harmful: a developer doesn't have to have a full access to sensitive information, especially when he doesn't work on the project any longer. The same is not true for the point 4, and even more for the point 2: favorite color is something personal and cannot be a reasonable unwritten expectation for a project.

The objectiveness answers your question "[The] stakeholder could see a bug everywhere as he expected it to be like this or that..So how can I really know?":

  • If most people would have the same expectation for the same product, then you may want to implement the expectation. If you saved all the passwords plain text, it's up to you to correct this and to support the cost of the consequences. If, on the other hand, you hashed them with SHA512, but didn't use the salt, the stakeholder wouldn't be able declare this as a bug just because she expected PBKDF2 to be used instead.

  • If different people would have different opinions, then the stakeholder should have written more complete requirements, since you couldn't possibly know the taste of the stakeholder.

Note: remember to make the difference between common sense expectations and common practice expectations.

Some requirements are often omitted because they would cover a common practice, expected from any decent developer. Deviating from those practices, justifying it by the fact that there are no requirements, would be unprofessional. For example, I don't see a need to specify that a website must have no SQL Injection, unless I work with very inexperienced programmers.

Why those requirements are omitted? Because it would be to expensive to describe everything. Do we need to tell that a web application should use HTTP? Do we need to tell that it must use a database? Or that you don't save 1 GB-length files in a RDBMS, unless you use FILESTREAM feature of Microsoft SQL Server?

  • Example of a common sense expectation: "A website should be accessed from anywhere, not just from localhost." Well, yeah, that's what websites are for.

  • Example of a common practice expectation: "A website should use HTML 4, HTML 5 or XHTML." In fact, written from scratch HTML 3 websites are quite rare those days.

share|improve this answer
Example of a common practice expectation... that in reality is often not met - hence browser incompatibility because the developer uses a non standard add-on – Andrew Sep 23 '12 at 20:28
@Andrew: for me, common practice is very restrictive, and limited to the situations where not following it would be considered unprofessional. This means that the fact that too many people working on enterprise-scale products don't follow the practice would indicate that it's not a common practice in the context of requirements and implicit expectations. – MainMa Sep 23 '12 at 21:09
absolutely agree... but (tongue slightly in cheek) one person's common practice is not necessarily another's - hence the importance of writing them down. If nothing else, in "Standard Requirements to follow" bullet point list – Andrew Sep 24 '12 at 5:31

Requirement is the interface between expectation and developed product: Expectation --> Requirement --> Product

if a product deviate from expectation, actually, it includes two condition.

Deviation between requirement and product: it is a obvious 'bug'.

Deviation between requirement and expectation: how to define whether it is a bug? I prefer to the answer of MainMa: the requirement is often incomplete, so if most people would have the same expectation for the same product, then you may want to implement the expectation, even if it is not defined in requirement.

I add one case: The expectation was lost when it was transferred to requirement. These bugs are defined as a bug from analysis or a system level bug.

share|improve this answer

Your Answer


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.