Non functional requirements: do not create a straitjacket.

This blog post is part of a series on non functional requirements, and how they take most of the effort.

The scenario

You want a third party to implement an application package to allow people to buy and sell widgets from their phone. Once the package has been developed, they will hand it over to you to sell, support, maintain and upgrade and you will be responsible for it,

At the back-end is a web server.

Requirements you have been given.

• We expect this application package to be used by all the major banks in the world.
• For the UK we expect the number of people who have an account to be about 10 million people
• We expect about 1 million trades a day.

See start here for additional topics.

The functional straitjacket

You may decide to use a facility like a particular database, because you can use a function that only that particular database provides. If you want to move from this database supplier – you are tied because of this function. It may be expensive writing this function yourself – to allow you to move with out disrupting the ongoing usage.
You may decide to use a standard level of function, such as SQL – but there are different standards. For example one standard of SQL can support JSON.

To avoid the straitjacket, you might decided on a subset of functions, and the applications cannot use functions outside this subset.

Testing for this

You might want to do most of your testing on one platform/environment, but include tests on different environments. For example run your Java web server on Windows and some on Linux, and have two different back end databases.

This may increase the development costs – but this is cheaper than trying to escape from the straitjacket when running in production.

Designing for this

Rather than scatter database calls throughout your code. Consider a component or domain which does all of the database calls. If you need to change your database, you have only to change the component, not the whole product. It allows mapping of different return codes to be done once, as well as mapping parameters.

With some databases (such as DB2) you run a program “runstats” which tells DB2 to update it’s meta-knowledge of the tables. This helps the database manager make the best decision for accessing the data, when there are multiple paths to the data. For example should it use a sequential search to access rows, or use an index. If this meta data changes, you need to rebind your applications to pick up the changes. If your SQL is isolated to one component, you just have to rebind that component, and not the whole product.

Other straitjackets

• Use of certificate authority certificates. Can you change CA chain?
• Use of computer language, and deprecated functions within that function.
• Use of a particular compiler. Your code does not compile on a different compiler or different operating system
• Use of packages for TLS – and using unsupported cipher specs.
• Use of virtualisation system
• Use of cloud provider.