About software development methods, case tools and functional design

In 1998, I started my career as a functional designer in a large company, designing all kinds of new functionality for large and complex systems. We used MS Word to document the customer requirements. We were free to decide how to do this.

A simple case tool (named SDW) was used to document the functional designs. These designs contained a description of the system functionality, as well as data structure/relationships from a logical point of view. The projects were based on the Waterfall method.

Nowadays, designers use all kind of sophisticated methods and techniques to improve speed, quality, maintainability, etc. I’ve worked in many organizations using methods like RUP, Agile and Scrum, to name a few!

All kinds of expensive tools were used, such as Enterprise Architect, Rational Rose, alongside use cases to document the functional designs. But never have I experienced the level of professionalism as during the ‘Waterfall and MS Office’ period at my first employment.

Why? I’ve been asking myself that question.

Why is it nowadays that Waterfall is often considered as a ‘bad method’? Why do functional designers use these newer design techniques like use cases? Were the classic ones not sufficient? Are these newer techniques better?

Waterfall vs. iterative methods

Waterfall is a relatively simple method for system development. It is a sequential method, that starts with defining all the requirements, then creating the functional design, which is then followed by development and testing. Each stage handles all requirements and has to be finished/approved before the next stage can be started.

The main disadvantage is that the requirements that arise at a later stage are often difficult to include in the scope. Sometimes it simply doesn’t fit the architecture. Or sometimes a chosen solution that is already programmed should be reverted before the new solution can be implemented. So adding or changing requirements at a later stage can be difficult.

A solution for this is to use an iterative method, like RUP. These methods can handle ‘progressive insight’ better than Waterfall because the changes are divided into chunks, which are implemented in phases. So the requirements do not need to be defined in an extensive way, as is done in the Waterfall method at the very beginning of the project.

But iterative methods are usually harder to manage because you have to do parallel planning, manage multiple disciplines at the same time, (re)define the stages and priorities during the whole project. Also iterative methods can lead to constantly changing requirements during the project, because the stakeholders are involved throughout the whole process. New requirements are being added regularly, or changed due to ‘progressive insight’, which makes it very hard for an inexperienced project manager to manage properly.

To sum things up…

Waterfall is relatively easy to use but is too rigid to deal with new insights. This could be an issue in fast changing markets/environments, especially when dealing with larger projects where these risks are higher. But if the requirements at the beginning are solid and usable in the long-term (compared to the project term) then Waterfall could be very suitable.

Iterative methods are harder to manage, but provide flexibility for the stakeholders to (re)define the requirements.

Office tools vs. sophisticated case tools

Case tools are very effective for performing impact analyses, drawing mock-ups, describing functionalities, and creating diagrams. But when the quality from functional design is poor, then a case tool will not improve it, if you would compare it with a text editor like MS Word, for instance.

A functional design needs to be correct, complete, and clear (CCC). As an analyst, developer, or tester, one needs to trust the information it contains. But for this CCC, you do not need a case tool, however, it might help.

So a case tool could be very beneficial when it is used properly.

But sometimes as a designer you are expected to be pragmatic (because of deadlines, for example). In this case, a designer won’t be able to deliver a full blown design. And sometime no designs are made at all, when the changes are communicated orally. This will result in the already existing design being incomplete and even more inconsistent. In this case, the benefit for case tools will not be significantly greater, if compared to a good text editor. On the other hand, an existing and complete design in a case tool will make analysis and maintenance much easier.

However, case tools will not deliver the most visually creative designs as designers are limited in their creativity. This is because of the rules upon the shared use that are agreed with other colleges. The case tool itself also demands that the design are created a certain way (according to a specific structure). But this could also be considered as an advantage because the case tool will guide a designer, making it easier to create the respective design(s).

So a case tool can deliver many advantages, but should be used properly to justify the investment (money, learning time, set up, integration, etc.).

Traditional designing vs. use case

With traditional design techniques you describe the functionalities of a system. You describe what a system does from a system perspective, as well as the logic to achieve this.

Nowadays, use cases have become a very popular method to replace the traditional designing method. There is only one problem. Use cases do not describe the system functionality. But they are used to describe the interaction between systems and actors. So you often still need to design the system logic. But the ‘problem’ is that many designers aren’t aware of this and consider the use cases as the final stage for designing. It is very helpful for work-flow and/or a scenario driven system, and in many cases offer enough information for the developers. But it is not practical to always use use cases. Try to design Excel by using use cases, for instance. That just doesn’t work.

There is also another problem. Readers need to be familiar with use cases, so you need to learn to read them. Designers often undergo training to learn to this method. The readers (customers, testers, developers) do not. There are also many interpretations about how to create a use case properly. For instance, include and exclude relations between use cases. These are very much debated (also on the Internet). This can lead to ambiguous designs. One can guess the consequences.

But under the right circumstances, it is a very powerful method for designers to describe the functionalities (from actor’s perspective), especially when combined with a case tool.


All these new methods, techniques, and tools can be helpful. But this doesn’t mean the old ones aren’t sufficient anymore. Depending on the situation, the right method has to be chosen.

Some things to consider…

Define the requirements for the requirements. In other words, what do you need to gather and document the requirements in the most efficient way.

Investigate the environment:

  • Is the environment fast changing or not?
  • Consider the level of IT expertise within the company. Do the developers/testers/stakeholders understand use cases. How experienced are the project managers?
  • Consider the company culture. How much does the business control the IT department? Does the company demand that everything is documented or do they prefer not to document too much?
  • What are the needs? Speed above quality or vice versa.

Then make the right decision. BUT use the advanced one properly, or otherwise keep it simple.


Functional Design: Why making requirements matters

Within our daily life, changes come along, as do the decisions on how we deal with them. These changes appear in your personal life and also in your professional life. And this is no different at LeaseWeb. Technology is changing and so are the wishes of our customers (and customers can come from within LeaseWeb and from the outside). And sometimes the changes that are requested are big and sometimes the changes are smaller.

But at the start of every change there’s always the same question: “Why do you want this change?” This can be to sell more products, to increase customer satisfaction, to keep ahead with the competition, to lower the manual actions so less hours are spend and more money can be earned and so on.

When the reason of the change is clear, it must be made clear what needs to be changed and what the change should look like. Say, for example, that you are a woodwork shop and a customer tells us he wants a new bed. As a woodworker, how do I know how this bed must look like? As I start building the bed with only this information, there is a big chance I will build something like this:


Image source: IKEA, FJELLSE Bedframe

How do I know, before I start to build it, the customer is thinking about this:


Image source: Rocking Bed – Private Cloud 

Obviously, LeaseWeb does not make beds, but we do run into this kind of problem, when we try to build software.

So all this comes down to the problem of making requirements. By asking the customer what he wants in detail, the chance is bigger that the development of the product will possess the correct critical properties and not possess the properties that were not requested. Expectations will be met more precisely and any rebuilding of the product will be less. So the costs will be lower (at the end) and time will be saved (by not rebuilding and remodeling the product). And most importantly, the customer will be more satisfied with the result. So, the most important activity in starting to build a (new or changed) product is to properly gather the requirements for the product.

There are four core activities within the requirements engineering process:

  • Elicitation: defining and refining the needs and wishes from different stakeholders in a most detailed way
  • Documentation: the elicited requirements are described adequately
  • Validation and negotiation: requirements are checked if they meet the predefined quality criteria; requirements that are inconsistent, are negotiated between stakeholders
  • Management: measures that are necessary to structure requirements, to prepare them so they can be used by different roles, to maintain consistency after changes, and to ensure their implementation

These are also well described on the requirementskenniscentrum website (in Dutch) and in the post called “requirements engineering explained” by Mike Polga.

So, the next time, when someone from functional design is at your desk and you’re thinking: “Why all these questions? I only want a bed”. Then realize that these questions are asked to understand the requirements: what kind of bed you want, what you’re going to use it for, how long you want to use it, for what purpose and for which costs? By telling him (or her) everything you’re thinking about (and more), you increase the chance that you get a product that meets your expectations, within time and within your budget.


BDD with Behat for Symfony2

Behavior Driven Development is an exciting new method of creating software. At LeaseWeb we work with roles like Product Owners, Functional Designers and Testers. These people have no access to the code repository. With BDD (Behavior Driven Development) this might change. BDD allows the Product owner to write the user stories in files with a .feature extension. An example of a feature definition is written below:

Feature: customer_list
  In order to reproduce a customers problem
  As a LeaseWeb employee working in dashboard
  I need to see a list of customers

Scenario: List customers in the dashboard
  Given I am logged in as a employee with username "bob" and password "i<3alice"
  And there is a customer with number "1234567890"
  And there is a customer with number "1234567892"
  When I get redirected after login
  Then I should get a list showing:

As you can see the product owner clarified the user story by describing a scenario. He might add more scenario’s and even backgrounds. Wouldn’t it be really cool if the software developers could implement these scenario’s and the product owner could see the progress by running this file? This is exactly what Behat offers. Software developers implement the methods that Behat generates. By default all generated functions throw a PendingException:

  * @Given /^I am logged in as a employee with username "([^"]*)" and password "([^"]*)"$/
public function iAmLoggedInAsAEmployeeWithUsernameAndPassword($username, $password)
  throw new PendingException();

Software developers will replace those throw statements with real implementation like this (this example is using Mink):

  * @Given /^I am logged in as a employee with username "([^"]*)" and password "([^"]*)"$/
public function iAmLoggedInAsAEmployeeWithUsernameAndPassword($username, $password)
  $this->fillField('_username', $username);
  $this->fillField('_password', $password);

After implementing this function the product owner can run the feature with the “behat” command of Symfony2. The product owner sees the feature where every step of the scenario is colored. Green steps are implemented, brown steps are not yet implemented (Pending) and blue ones are skipped because they depend on pending steps. At the end of the run Behat shows a summary:

1 scenario (1 pending)
5 steps (1 passed, 3 skipped, 1 pending)

Why BDD might make a huge difference:

  • Stories and scenario’s are added to the repository and can: easily be found, verified and related to a version or release.
  • It enables the product owner to get a visual and understandable view of the progress of the team.
  • The team will write good user stories and scenario’s since they are an important part of the development process.

And in a way it makes user stories and scenario’s “fun” for developers and product owners.

Read more about this topic:

Installation instructions:

Add git repositories to the “deps” file and update vendors afterwards with “bin/vendors install”. If your project is based on a Standard Edition that includes vendors you cloud consider cloning the repositories manually into the target directories.

In the “deps” file add:




You also need to install pear and the required packages.
IMPORTANT: sometimes this process hangs for several minutes, be prepared to have a lot of patience!

$ sudo apt-get install php-pear php5-curl php5-dev
$ sudo pear upgrade pear
$ sudo pear channel-discover components.ez.no
$ sudo pear channel-discover pear.symfony-project.com
$ sudo pear channel-discover pear.phpunit.de
$ sudo pear install --alldeps phpunit/PHPUnit
$ sudo pear channel-discover pear.symfony.com
$ sudo pear channel-discover pear.behat.org
$ sudo pear install --alldeps behat/behat
$ sudo pear install --alldeps behat/mink

In app/AppKernel.php:

public function registerBundles()
  if ($this->getEnvironment() === 'test') {
    $bundles[] = new Behat\BehatBundle\BehatBundle();
    $bundles[] = new Behat\MinkBundle\MinkBundle();
    if (!defined('BEHAT_AUTOLOAD_SF2')) define('BEHAT_AUTOLOAD_SF2', false);
    require_once 'behat/autoload.php';
    require_once 'gherkin/autoload.php';
    require_once 'mink/autoload.php';
  return $bundles;

In app/autoload.php:

  'Behat\\MinkBundle'=> __DIR__.'/../vendor/bundles',