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.


Waterfall versus Agile – comparing software development methodologies

One of the first decisions you need to make as a project manager before starting a project implementation is: Which development methodology should I use? There are several methodologies you can use to manage a project. This blog contains reasons and information about two methodologies which can help you make this decision.

What is Waterfall?


The Waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance. This means that when each of the eight stages are completed the developers move on to the next step. Once a step has been completed developers can’t go back to a previous step without reviewing the whole project and starting from the beginning. There is few room for changes or errors, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

What is Agile?


Instead of a sequential design process the Agile methodology follows an incremental team based approach. Developers start with a minimalistic project design, and then begin to work on small modules (sprints with a defined duration and a running list of deliverables planned one sprint in advance). The deliverables are prioritized by business value as determined by the customer. At the end of each sprint project priorities are evaluated and tests are run. These sprints allow bugs to be discovered in an early stage and customer feedback can easily be included into the design before the next sprint is run.

Comparison between Waterfall and Agile

In this picture you can see the differences between both methodologies at a glance.


Image source: Waterfall versus Agile

Advantages and disadvantages of both methodologies

Advantages Disadvantages
  • The customer knows what to expect in size, costs and timeline
  • Minimal impact in case of employee turnover due to strong documentation
  • Developers and customers agree on what will be delivered up front
  • Progress is more easily measured, as the full scope is known in advance
  • Team members can work on different projects simultaneously
  • Customer presence isn’t strictly required after the requirements phase
  • Makes it easier when multiple software components must be designed for integration with external systems due to early known design
  • Once a step has been completed, developers can’t easily go back to a previous stage and make changes
  • The initial requirements can’t be changed without heavy impact
  • Testing the whole product at the end is risky due to finding bugs in early written code
  • A customer’s evolving needs are not taken into account. When changes are demanded this will impact the deadlines and budget
  • Possibility of a dissatisfied customer with their delivered software product due to not seeing the product until it is almost finished
  • Value is added every sprint
  • Easier to add features that are up-to-date with the latest industry developments
  • Project priorities are set before every sprint and evaluated after each sprint
  • Customer feedback is allowed and will contribute to the final end product
  • Testing each sprint (also by the customer) ensures no surprises at the end
  • High level of customer involvement (strong sense of ownership)
  • Short time to market: quickly produce a basic version of working software
  • Transparency is high
  • Deviations on the final product can arise due to no existence of a definitive plan
  • Customers need to have the time for the high degree of involvement otherwise the product will not match their requirements
  • Additional sprints could be added due to added requirements, because not all these requirements are clear during the start of the sprints, this may increase costs for the customer
  • The iterative nature may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project


After putting the information together, what can we conclude from all this? Both methodologies have their own strengths and weaknesses. The choice of methodology really depends on the goals you want to achieve. This all comes down to the context of a project. In fact, will it not be better to combine aspects from both methodologies to make the best possible software development process for the project?

When should you use the Waterfall methodology?

  1. When customers will not have the ability to change the scope of the project once it has begun
  2. When a clear image of what the final product should be must be worked out in advance
  3. When definition and quality are the keys to success instead of fast delivery

When should you use the Agile methodology?

  1. When customers need to be able to change the scope of the project
  2. When there isn’t a clear picture of what the final product should look like
  3. When quick production is more important than the quality of the product
  4. When the product is intended for an industry with fast changing standards, like software development
  5. When you have skilled developers available who are adaptable and able to think independently

Ultimately, although the way in which you do your work is important, most important is delivering a solid and supportable product that satisfies the customer’s needs!