Making Quality Software: 12 non functional requirements every app should have.

• Tweet

• Tweet

When people talk about really great quality software, they usually think in terms of it’s utility, simplicity or aesthetics. But there’s more to it than that. A really great piece of software will bleed quality through and through like a piece of Brighton Rock (or Bognor Regis). What separates high quality software from mediocrity? It’s being aware of and planning for the right constraints to put on the way you develop software. Frank Lloyd Wright did his best work in tightly constrained spaces and awkward sites, and as software engineers we need to do the same to avoid flabby work. Here’s my list of twelve constraints I’d plan for on my next project:


Great architecture comes from great constraints

How I arrived at this list

I started to look at this a little while back when I was putting together our playbook for how we create software for our customers by bringing together agile and user centred design together. We articulate our requirements as User Stories, but outside of the functional aspects of the system, I realized that there are a common set of non-functional requirements that we saw the need for over and over again. Mike Griffiths has put together a great checklist of non-functional requirements, but I felt that a number of them could be covered off and scheduled in standard stories. What follows are the ones that to me are about how a development team needs to think and behave over time:

Performance

This one shouldn’t come as a surprise. Quality software has to be fast. Or at least feel fast. As a front-end guy, this is the one I always feel first. “It’s not fast enough” is a battle I never want to get into. I had this reported as a bug against one of my projects, but the client wouldn’t specify what “fast enough” was; talk about moving goalposts. When you think about an app being performant, thing about specifying the following:

1. Response times

How long should your app take to load? What about screen refresh times or choreography?

2. Processing times

Can I get a spinning beachball please? How long is acceptable to perform key functions or export / import data?

3. Query and Reporting times

This could be covered off with general reporting times, but if you’re providing an API you should probably consider acceptable query times too.

Capacity and Scalability

How much do you need to cope with now, and how much do you think you’ll need to cope with in the future. Unless you are truly blessed with an incredibly forgiving audience (or a great illustrator), you won’t be able to get away with your own fail whale.

Your audience had better be pretty charmed by you if you can get away with regularly futzing on capacity

4. Throughput

Think about how many transactions your system needs to handle. A thousand a day? A million? When Amazon solved this for their needs, they decoupled systems and created a queue service that became the foundation of AWS.

5. Storage

How much data are you going to need to store to do the awesomeness you need it to do?

6. Growth Requirements

This is a tough one, because truly you don’t know how popular your app is going to be until it’s out there. But you can bet (or hope) that someone has made predictions about how wildly successful your app is going to be. Be wary of over engineering here, but at least make sure you aren’t constantly laying down track in front of a moving train.

Availability

Does your system need to be available all the time, and to everyone? Most of the time you can get away with the occasional vacation, but knowing what’s important helps you make good decisions. Quality software ain’t quality if its down when your precious users need it

Can you get away with a product that is rarely available?

7. Hours of operation

When does your app need to be available? If you need to do a database upgrade or a system backup, can you take the system offline while you do it?

8. Locations of operation

A few things to think about here: Geographic location, connection requirements and the restrictions of a local network prevail. If you are building a killer app for use behind the corporate firewall, you’d better make damn sure you aren’t using any exotic ports.

Maintainability

When you’re running a software project you are at constant war against software entropy. This is your chance to save yourself from having to live with shitty code, or leave shitty code for others to pile more shit onto. I’m passionate about this; can you tell?

Don’t live with broken windows

9. Architectural Standards

What’s important here is that the code is going to feel like a consistent body of work, not some ad-hoc glom of a bunch of developers’ whims. Define what the standards need to be else you’ll always be discussing the merits of different styles.

10. Coding Standards

Again – decide on the coding standards for the application and stick to them!

Recovery

You are prepared for a disaster, right? Right? And if a disaster happens, how long’s it going to take to get back up and running?

Backing up your stuff somewhere is smart, but how long will it take to get it out of storage?

11. Restore time

I know you don’t want to think about the worst happening, but if it does, ask yourself how long should it take to get back up and running?

12. Backup time

Speaking of which, how long does it take to back your data?

It doesn’t need to be all doom and gloom

I know when I first put together this list, I felt a bit deflated at all the extra specification I was laying onto my magic development world. In truth though it’s not all that bad. In fact I’ve done the hard legwork for you in editing down the list. If you just think through these things early on in development, you can be pretty sure you are going to save yourself either under- or over-engineering your app, and be much more likely to produce decent quality software that you can be proud of.