Non functional requirements: what does your support team need?

This blog post is part of a series on non functional requirements, and how the NFR 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.

Support structure

You will need to set up a support structure to handle questions and problems from your customers. The level of support covers

• Answering general use questions – such as database usage, or web server configuration. This team will usually be people who speak the customer’s language. This is known as Level one, or first level.
• Answering harder question and problems. These guys may have access to the source. They know the diagnostic tools available with the product. This is known as level 2, or second level
• Debugging code problems. This may be just one team – but with people spread around the world who can work on the problem 24 *7. They may have customer-like test systems so they can try to reproduce the customer’s problems. This is known as level 3 or third level.
• Write fixes. Once a problem has been identified, you need people to write fixes. A fix can have side effects so you may need to stop the customer problem from happening, but not give the correct solution (until a new version of your product). This team is known as the change team, or fix team.
• Test fixes. This team works with the team that writes fixes.
  • the team reproduces the problem
  • applies the fix and checks the problem is resolved
  • packages the fix for customers
  • look at their existing tests to see why there were no existing tests to capture it, then enhancing the test cases to cover the holes found.

What do the support team need?

Level 2 and level 3 need access to, and knowledge of the tools available to debug problems. This may include

• Messages on a log
• Probe-ids or First Failure Data Capture
• Traces
• Dumps of storage. If there are hexadecimal dumps, you may need tools for format the data into control blocks, and fields within the control blocks.
  • Your tools may also have smarts to report unusual situations discovered, such “The value of field ErrorsDDetected in the control block CB1 for user MYUSERS is non zero”

The teams need guidance as to which traces to turn on when. For example turning on a system wide Java trace can double the CPU cost, half the throughput, and produce giga bytes of trace data.

You need commands to be able to turn on/off the trace without restarting your product.

If just one user gets a problem, can you turn on trace just for that user?

Can you turn on trace for a component, such as the database component?

Some customers will not allow trace to be enabled in production, because of the impact on CPU and throughput, and for data privacy issues. This means you need to provide debug facilities which are low cost, cannot be disabled and do not display any personal data.

What are the non functional requirements for the support teams?

• Source for the product
  • in a source control system
  • with a build tool for all environments.
• “Internal documentation” describing the components, and what each source module does.
• Comments in the code for any non obvious code. For example describing what a function does.
• Test system so any fixes can be validated in all environments.
  • Supporting different levels (or just the lowest) of the operation system.
  • Support of national language – so you have a web server configured for Japanese.
• External facilities used by product (such as Java or database) are supported, current, and will be current for the next 12 months. You may have to pay for the support.
• Internal defect database, so the support teams can search for previously seen, or similar problems.
• All external components or dependencies are documented, and support plans agreed with the provider.

.