Non-functional requirements

Non-Functional Requirements

For anyone not familiar with the term “non-functional requirements” – this is a list of generic requirements that we will assume apply to every system.  They aren’t specifically things that system has to do, they are qualifiers about the way it has to work.

Affordable

Our IT doesn’t have to be completely free, but the total cost of all the products and services we use has to fit within a finite, sustainable budget.  In order to plan ahead, Masonry need the Kingdom and Au/NZ societies to approve an annual cap on spending.

Each new product or service that we consider implementing has to be affordable, and the collection of products and services that we buy or rent has to represent the most efficient and effective use of that money – the best bang for our bucks.

When we consider the cost of a system, we have to think about the whole-of-life cost, not just the cost of setting it up.  We need to look ahead, and make sure we will be able to pay the annual costs of using the system.

Continuity – being able to move into and out of new systems

IT products and services don’t last forever.  Each system we use will become obsolete, and we will want to move on to a new system that replaces it – so we need to plan ahead for the day when that new system becomes obsolete, in its turn.

When we look at new systems, we need to consider whether or not we will be able to import our existing records into them, because if we can’t we create a break in our history.  If there is no way we can do that, we need to make sure the superseded system can be archived, and remain accessible for when we need to look something up.

Before we load our data into a piece of software, or put our systems onto a server, we need to be sure we can get the data and software back again at the end of the product life or the contractual arrangement.

The more complicated the system, the better the export needs to be.  If we store simple files in an environment like Dropbox, we just need to be able to get them back out.  If we use a complex CRM product, and build structures in it to reflect our groups and events, then we need to be able to get the data back out again with the relationships between tables preserved, and to export both data and stored procedures.

Security

All of our systems need access control to be managed, robust, sustainable and based on roles and group membership.

  • Managed means a hierarchy of access levels, with an administrator class who are able to grant and revoke privileges. CRUD (Create, Read, Update and Delete) privileges should all be managed.
  • Robust means that we need to be able to demonstrate that the security of any system that contains any personal or financial information has been tested, and that we have demonstrated a reasonable level of due diligence that the security mechanisms will protect systems and data against probable threats.
  • Sustainable means that the process of adding and removing users, and adjusting the security settings as the kingdom changes over time, needs to be something that we can do (and keep doing) with the resources available to the masonry team.
  • A given user’s access levels should be determined by the role they hold, and the groups they belong to. A user who takes on office should get the additional system access they need to do their job automatically, once their name is linked to the office the hold.  A user who is made a member of a group should get access to all the resources relevant to the group.

Extension & Integration

Every business system Lochac runs relates to the same community of people, and the same collection of baronies, shires, cantons and colleges.  If we don’t just have one system, then we want all the systems that we do have to talk to each other, so that people don’t have to maintain their details separately in each system, and so that an update to one system (like the establishment of a new shire) is reflected everywhere.

We also need all our systems to allow for extension in the future, as we add new activities, qualifications, awards or types of member or group.

Scalability

In most respects, Lochac grows very slowly compared to software and hardware scalability.  We probably don’t need to worry too much about our databases growing so big that they slow down or run out of room, during their operational lives.

The exception to this will be around multimedia – if we start to make more use of audio and video files and streaming services, then we could run out of disk space and bandwidth.  Whenever we are considering any new system, or renewing a support contract, we need to consider how our membership is growing, and how their use of IT systems is evolving, to make sure everything we buy or build can grow with them.

Supportability

There are two ways our systems get supported: for free, or for a fee.  Whether we are talking about a paid service, or one supported by volunteers from within Lochac, we need to make sure we pick systems where there is a choice of people to support them.  We can’t afford to be tied to one vendor, and we can’t afford to be dependent on one volunteer, for any of our important tools.

Supportability means not only choosing systems that more than one person or company might support – it means planning them and managing them so that the support task can be passed on from one person or company to another.

This means using open standards, and avoiding obscure (but handy) code libraries and plug-ins.

Usability

None of our members are going to attend training courses on the use of our systems, before trying to use them.  Most of them won’t call masonry when they have a problem – and we have limited resources to support the ones who do.  So we need to minimise the need for training, the likelihood or people making mistakes, and the frequency with which they call for help.

Whether we are choosing between alternative open-source products, or building something for ourselves, we need to test it with users who are not IT-literate, and be prepared to change the user interface to reflect how they expect the system to work.  The only useful definition of “usable” is “it did what our users expected it to do.”

Accessibility and responsive design

While our websites might still be getting visited by people using full-size computer screens, more and more often the people looking up details in systems like the registry, canon lore, the roll of arms and authorisation databases will be doing it on their phones while at events.  That means the layouts need to be smart enough to accommodate people working on a five-inch screen.

Link