Tag: Requirements

Specification by text

After having done a brainstorming on use cases and activities, it’s time to formulate these in textual form.

Shall, should, can

For requirement engineering often the pattern “if …, the … shall/should/can do …” is used.

  • If logged in, the user shall be able to interact with the software
  • If not logged in, the user shall be redirected to the login page
  • If user does not have an account, the user can create a new account

This already breaks down a otherwise big block of text into smaller patternized atomic actions and features. Further allowing grouping some of them and mapping them to components in following steps of design.

Gherkin

An alternative is to use Gherkin, which is a specific language for behavior driven design (BDD), designed by Cucumber.

In Gherkin single requirements are “Scenario’s” made of steps written in a specific form.

  • Given – What is the (static) precondition
  • When – Define a Trigger
  • Then – Observable resulting behavior

This pattern pretty much matches the brainstorming we started with.

The benefit, that let’s hearts of testers jump higher is, it’s an standardized format that already has multiple implementations for Testframeworks. So a tester can use the requirements directly as input for tests and can focus on implementing the necessary steps.

Specification of Idea – Usecase and Activity

The first thing to do if starting with a new thing, is to specify what it should do.

Even if your fingertips already want to write Code and you want to discover the newest and latest Features of a new framework.

This will help to stay focused on the solution and also helps to find issues or gaps early. It’s driven by the question of how the “thing” you want to create interacts with others, like users or other tools.

Specification

Specification can be done in multiple ways. Either as a long block of text, or atomic features, or visualy by using use case or activity diagrams.

In general it helps to start with a short non formal description for first focus and have a base to start. Followed by standing up from the desk, shaking the body and going to a whiteboard for brainstorming.

With whom will my thingy interact, what benefit does it give, what will be the features it provides.

After roughly defining the features and functions we need to provide, the question is on workflows. What might be the chain of actions leading to something that gives a benefit to our user?

Pitfalls

Overdoing usecases, will render use cases useless, as it’s level of abstraction may jump from verry detailed to abstract or triing to visualize to many (non related) cases at once, making the graph more confusing then helping.

The size and count of objects in the graph should be limited to roughly 7-10 elements. This can be done to either stick with one user, one specific area of use cases or a level of abstraction.