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.

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.

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.

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.

or:

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.

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.