The fit criterion quantifies the performance, behavior and other qualities of a requirement.

Applying to Starbucks we have this example of a non-functional requirement TYPE -14 Maintainability and Support

Description: The new cups’ design shall be available in all the stores.

Rationale: Starbucks need to refill stores with these new cups before release this promotion.

Fit Criterion: All Starbucks coffee shops in Canada should have at least 60% of its cups for hot beverage with the new design from local artists.

What is it?

According to the book: Mastering the Requirements Process – Suzanne Robertson and James Robertson.       Functional Requirements are the things that your product does to support the work.

In order to describe the product’s functionality, we can use scenarios to help describing.

When writing the requirements description, the most common way is using “The product shall… “, this way it is easier to eliminate semantic confusion. The use of rationale is also recommended to show the reason why the requirement exist. For example, for our Starbucks new product we can describe the requirements like this:

Description: The product shall have local artists’ arts printed in the cups.

Rationale: To be able to satisfy our clients with the designs that they chose in the social media campaign and to support local artists.

A data dictionary is also important in functional requirements, it should contain the definition of the class, each attribute and association.

Avoiding ambiguity is very important when writing requirements.

The business Analyst is responsible for investigating the work before making any changes to it.

In business the term “Trawling” means sifting through a business to identify the work being done. It can be done by analyzing the business current situation, observing structures and patterns or using the Brown Cow Model which is an easier way to show a system model by dividing the model’s viewpoints. It is divided in 4 quadrants: the top left quadrant mentions what is happening now and the top right quadrant what is going to happen in the future, the left lower quadrant shows how it is now and the right lower quadrant how is going to be in the future.

Apprenticing is when the business analyst goes to the user’s workplace and actually do their work or observe and ask questions.

TRUTH 1 Requirements are not really about requirements.

TRUTH 2 If we must build software, then it must be optimally valuable for its owner.

TRUTH 3 If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software.

TRUTH 4 There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.

TRUTH 5 The requirements do not have to be written, but they have to become known to the builders.

TRUTH 6 Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs.

TRUTH 7 Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.

TRUTH 8 You can be as iterative as you want, but you still need to understand what the business needs.

TRUTH 9 There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.

TRUTH 10 Requirements, if they are to be implemented successfully, must be measurable and testable.

TRUTH 11 You, the business analyst, will change the way the user thinks about his problem, either now or later.