Before we get started, know that this is a very big topic; I’ll barely be scratching the surface. However, as there is some crossover between this project and some of the processes I'm developing at work, I felt it would be useful to explore the topic with a relatively simple project to test some concepts.
Single Statement of Requirement
Why do we need requirements for something as simple as this? Why not just start with a good idea, or a single statement to express my need:
I want to make a water rocket I can show off in schools.
With the idea fresh in my mind, I can usually make perfect sense of what is required. Let’s formalise the statement a bit and remove some ambiguity:
The user requires a STEM demonstrator based around a water bottle rocket suitable for use in secondary school activities.
That’s sufficient isn’t it? I know what I want, and what it all means...
There is some sort of “user”, but who are they and what role do they play?
The user “requires” something. OK, that seems clear enough
The something is “a STEM demonstrator” that is “based around a water bottle rocket”. There are a few details that need to be bottomed out there I think
It should be “suitable” for use in a particular environment (secondary schools). What does suitable mean? Are there any constraints that the environment might impose?
This sort of thinking is something that we often have to do at work. We talk to our customers and get a statement that expresses some aspect of their need. The context of the conversation usually enables everyone at the time to have a common understanding. But there is essential detail that will be lost unless it is written down.
Why is it important?
Sometimes it’s just nice to be rigorous for the sake of completeness. But in this case, if we can get the requirements right, we have a better chance of making the right thing in the right way, satisfying our customers or users. Or me.
Taking a look at the single statement above again:
The user requires a STEM demonstrator based around a water bottle rocket suitable for use in secondary school activities.
What would a successful demonstrator look like? Starting with the basics, we would expect some sort of water bottle rocket to be produced. And we would expect to be able to use it in schools. But beyond that, we don’t really know. Here are some more questions:
Is the demonstrator to be used only to show students, or could they use it too? Could they make their own?
What aspects of STEM need to be demonstrated?
What requirements are there for use at a school? Does it have to fit into a confined space? Are there any particular regulations or safety considerations that need to be satisfied?
Again, I have a reasonable idea about some of these points, but I haven’t yet captured them as formal requirements that will be used to inform the design.
User Requirements
We can start to understand the requirement further by decomposing it.
I took my single statement of requirement and wrote down some of my initial ideas:
The demonstrator shall be portable.
The demonstrator shall be usable for years 7 to 13.
The project design process shall be used as a higher education aid for engineering undergraduates to teach ITEA concepts.
The demonstrator shall support maths and physics lessons.
The demonstrator shall be capable of use by students.
The demonstrator shall be capable of use by teachers.
The demonstrator shall be capable of use by STEM ambassadors.
The demonstrator shall be reusable.
The demonstrator shall have minimal costs to build.
The demonstrator shall include parts for students to design and manufacture.
The demonstrator shall include parts for students to decorate.
The demonstrator shall include parts for students to modify as part of experimentation.
The demonstrator shall be suitable for use in a school field.
The demonstrator shall be suitable for use during standalone, one-off activities.
The demonstrator shall be suitable for use as part of a series of several linked activities.
Linked activities shall be presentable to a single age group across 1 or 2 terms.
Linked activities shall be presentable to multiple age groups across 2 to 3 years.
The demonstrator shall have demonstrable safety features.
The demonstrator shall be very visual in explaining key concepts of maths, science and engineering.
This is better, with more detail and the beginnings of a more rigorous approach. It’s not complete yet, but it is enough to get started. We will add more requirements as we work through these.
Note that although I have called these requirements user requirements, there is not a lot of mention of any users. For this first pass through, I could have prefaced each requirement with “the user requires that...” That would be OK, but not great. There are already hints of needing to recognise different types of user: students, teachers and STEM ambassadors. We will need to consider them each separately, but later.
System Requirements
With a reasonable set of user requirements, it would be nice to start specifying what our system requirements are:
The system shall be light enough for the user to carry.
The system shall be simple to use.
The system shall be small enough to fit into a backpack?
The system shall be small enough to fit into a car boot? Onto a bike?
Oh dear! All we’re trying to do is translate the user requirements into requirements to design our water rocket, but we’ve ground to a halt. There are several questions emerging that we cannot easily answer. We will need to discuss these with our users, but which ones? Well, it depends what roles we expect each user to have when using the system. That means we will need to sketch out who each of our users are and how they will each interact with our system.
Moving On
A few years ago I tried to approach a similar (but more complex) project in this way. I never made it past the requirements stage. Similarly here I could end up spending all my time on these requirements, get bored or frustrated and abandon the activity. In an attempt to avoid that, I am going to explore some design aspects next. I will use this work to hopefully inform a set of achievable requirements.