1

(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?
  • 6
    Rule of thumb: can each requirement be identified as complete using a simple test? If it can, it's a real requirement. If it can't, it's just a bullet on a wish list. Corollary: every real requirement is accompanied by an acceptance test that allows the person performing the test to unambiguously declare success. – Robert Harvey Dec 29 '16 at 3:02
  • 5
    I think you're getting carried away with how it ought to be done, at the expense of just doing it. It is not easy to write a quantum computer simulator. That's where I would start, if I were you. Start small. Don't worry about formal requirements or formal anything. Make it work and see what you missed. Then do the next version. That's known as rapid prototyping. Also, learn something about quantum computing. – Mike Dunlavey Dec 29 '16 at 3:50
  • 1
    Honestly, heather, this site is neither a blogging site nor a discussion site. You can ask clear-cut, focussed questions on software engineering (like your previous one), but anything which leads to an open-ended, opionated discussion will be closed by the community within some hours. – Doc Brown Dec 29 '16 at 5:48
  • @DocBrown, I don't see the difference between my previous question and this one. – heather Dec 29 '16 at 13:09
  • The number of bullet points alone seem to invite into an open discussion. And we cannot tell you if this list is complete, or if something is missing. However, since @CandiedOrange managed to give you an answer which avoids these problems, I think I revoke my close vote. – Doc Brown Dec 29 '16 at 13:29
2
  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

  1. 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".

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

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

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

You remembered that -1 is an integer right?

  1. 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.

  1. 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.

  1. 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.

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

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

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

Again, define common quantum gates.

  1. 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.

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

This is fine

  1. 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.

  1. Documentation on-site for users.

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

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

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

  1. 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.

  • Though I like your answer and upvoted it, I have my doubts if it is a good approach to analyse, refine, and maybe overanalyse, 18 bullet points upfront. This looks very "waterfall" for me and makes IMHO only sense if this kind of approach is explicitly required by the school for learning purposes. If I were going to build such a thing, I would probably let most of those 18 points untouched, for the purpose of having a project vision, and pick just a minimal set of 3 or 2 requirements (or ideally just one) for the first iteration. Next I would flesh out the chosen requirement ... – Doc Brown Dec 29 '16 at 15:46
  • @DocBrown can't disagree with a thing you said. – candied_orange Dec 29 '16 at 15:50
  • .. design, and implement it. Then I would take the next "interesting" one, analyse it what kind of change this would mean to my existing piece of software, design and implement it. And it will typically happen that after each iteration the list of those 18 points will be adapted and maybe rewritten, which is the reason why I think it does not make sense to invest too much time into the analysis upfront. (And yes, I think you would probably work similar, but this comment is mainly addressed to @heather: please consider to rethink your approach). – Doc Brown Dec 29 '16 at 15:50
  • @DocBrown, I began doing this because my current approach ("let's write some code!") wasn't working; I needed to do some level of planning. I seem to have gone, however, to far in that direction (partly due to what I was reading) therefore, I will try to find a happy medium. – heather Dec 29 '16 at 16:02
  • 1
    To be clear, a requirements document absolutely should not include notes on how you plan to implement. You don't know that yet so don't make unnecessary promises. It's a list of what the app should be able to do. And @DocBrown is right. You don't have to start with everything it could do. Start with only what is needed to do something useful enough that it can be tested. – candied_orange Dec 29 '16 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.