One-person, informal project - creating good requirements

Question

(For more backstory/explanation, see my previous question.)

I'm a middle school student working on a very, very informal project; my problem statement is as follows:

There is no way for theoreticians, researchers, and students in the field of quantum computing to simulate and test complex, large quantum circuits in an intuitive, efficient way without creating the code for the application themselves. A web application that works in popular browsers with an simple interface that could accurately produce results on the outcomes of quantum algorithms, error correction codes, entanglement, decoherence, and the other aspects of both an ideal and realistic interface would allow professionals and students alike to test their ideas and get a better understanding of the field of quantum computing.

So, as I am working through the book Code Complete, the next step was to list requirements. As I've never done this before and it is such an informal project, I am unsure if the requirements list I came up with is any good, or if there are improvements that should be made to it. So here's the list:

1. Takes in as input starting state of the qubits, each gate to be applied to which qubit, how many qubits should be used, and what implementation of quantum computing they'd like to test in (for decoherence time estimates).
2. Outputs should be current state of every qubit and probability of |0> and |1> state for every qubit.
3. Outputs should be given on the website and downloadable along with inputs in a text file.
4. State of qubits should be a vector, probability should be a number from 0 to 1, gates should be one of several commonly used gates or the custom gate option.
5. Inputs for gates should be one of several buttons (pressed).
6. Inputs for state and number of qubits should be integer input.
7. Once user inputs data and presses the button to compute, it should not take very long to produce the answer (e.g., one minute max for 5 qubit calculations is one benchmark).
8. Should be a website interface, with input blanks based on previous user input, i.e., create an account to save your simulations (takes in email and password), then a tab to look at previous text files from simulations and a tab to create a new simulation. Then, the user would input the number of qubits and starting state of qubits, click next and it will have you list gates for 1st qubit, click done, 2nd qubit, etc. If the option inputted is custom gate, a blank pops up where you can fill in the necessary data for the gate. When done, it transitions to a "calculating" style screen, and then gives the result and text file to download, with an option to save and an option to start over (last option available throughout).
9. The safety of the user's email, password, and text files must be high, as there could be important/confidential research-related information stored there.
10. Place on site to report bugs and request improvements.
11. Has common quantum gates available and a custom gate option.
12. Simulates decoherence, entanglement, and other common features of quantum computing.
13. Allows choice between ideal (no decoherence) and non-ideal (decoherence) quantum computer.
14. Generalizable to large numbers of qubits (runs as efficiently as possible).
15. Documentation on-site for users.
16. Accurate results (basic cases, at minimum, checked against accepted results.
17. Option to make text files public/private and a location to access public simulations?

Answer 1

1. Takes in as input starting state of the qubits, each gate to be applied to which qubit, how many qubits should be used, and what implementation of quantum computing they'd like to test in (for decoherence time estimates).

2. Outputs should be current state of every qubit and probability of |0> and |1> state for every qubit.

3. Outputs should be given on the website and downloadable along with inputs in a text file.

The ones above seem reasonable and testable

4. State of qubits should be a vector, probability should be a number from 0 to 1, gates should be one of several commonly used gates or the custom gate option.

Huh? How does this allow me to tell if a bad kind of gate was used? List or cite your definition of "commonly used gates".

5. Inputs for gates should be one of several buttons (pressed).

So, gate input can only ever be buttons? One of which buttons?

6. Inputs for state and number of qubits should be integer input.

You remembered that -1 is an integer right?

7. Once user inputs data and presses the button to compute, it should not take very long to produce the answer (e.g., one minute max for 5 qubit calculations is one benchmark).

Sounds like this was meant to be a performance requirement but it's turned into a requirement to have a performance requirement. If you want 5 qubits calculations to take 1 minute then just say that.

8. Should be a website interface, with input blanks based on previous user input, i.e., create an account to save your simulations (takes in email and password), then a tab to look at previous text files from simulations and a tab to create a new simulation. Then, the user would input the number of qubits and starting state of qubits, click next and it will have you list gates for 1st qubit, click done, 2nd qubit, etc. If the option inputted is custom gate, a blank pops up where you can fill in the necessary data for the gate. When done, it transitions to a "calculating" style screen, and then gives the result and text file to download, with an option to save and an option to start over (last option available throughout).

This is a use case not a requirement.

9. The safety of the user's email, password, and text files must be high, as there could be important/confidential research-related information stored there.

High? Please define high.

10. Place on site to report bugs and request improvements.

Does this just mean it's deployed so people can use it?

11. Has common quantum gates available and a custom gate option.

Again, define common quantum gates.

13. Simulates decoherence, entanglement, and other common features of quantum computing.

Here we need objective examples of what this can do when these features are working.

14. Allows choice between ideal (no decoherence) and non-ideal (decoherence) quantum computer.

This is fine

15. Generalizable to large numbers of qubits (runs as efficiently as possible).

What is large? Everything runs as efficiently as possible until something better comes along. This is an attempt at a performance requirement that in the end doesn't demand anything.

16. Documentation on-site for users.

A popup that says "ask a friend" fulfills this requirement.

17. Accurate results (basic cases, at minimum, checked against accepted results.

This would work if the cases and accepted results were included or cited.

18. Option to make text files public/private and a location to access public simulations?

This seems to be two requirements smushed into one.

Requirements are not a wish list. They are not a set of value statements. They should not be fuzzy. Each should clearly define when a feature is completed or not.