Requirements
Project Background
Knowledge 4 All Foundation has two main streams of activities, on one side pioneering Machine Learning methods of pattern analysis, statistical modelling, and computational learning and on the other, transforming these into technologies for large scale applications in Open Education. We were asked to combine these two streams of activities and create an automatic question generation API with a website
Project Goal
Our project goal is to develop an API and a web application that can generate different types of questions from educational material. The API will be usable by anyone. Our API will be connected to a database and to a web application. The database will be used to store information related to users' progress and metrics to improve question generation. The web application is for displaying and allowing the users to interact with the generated questions. The API should be able to generate questions about any text that was written by the user as long as it is educational. Also, it should give the option to the user on which type of question to generate.
Client Requirements
With the knowledge of the project background, we met our clients to discuss what features our API should have. We also agreed on meeting weekly, when we could report our real-time progress and get feedback from the client. The client requirements are the following:
Generate questions out of educational text/material
Have an interactive website to display the questions
Track user progress
On top of the client requirements, we also considered the requirements users can provide us. We gathered the user requirements by conducting semi-structured interviews. The interviews can be found here. The main user requirements are the following:
Give the option to pick how many options each question should have
Will have the option to see the educational material while the question is displayed
Users will be able to see statistics on their performance
User Interviews
After evaluating the different methods of capturing requirements, we decided to conduct a semi-structured interview as it allows us to go in-depth and probe where necessary. We both interviewed students and teachers which our system is aimed for.
Student Interview
Q: Have you tried different online testing platforms to revise the content you have learned?
Yes, I have.
Q: Would you prefer an app where you can generate randomized questions off a piece of text and don’t have repeating questions?
Yes definitely. Especially the content of the questions can be very repetitive on most online platforms. It sometimes feels like a waste of time.
Q: Would you prefer it if the difficulty of the question was stated before you attempt it?
I would prefer it if I had the option to know the difficulty of the question before I attempt it. That way it can be my choice.
Q: Do you think multiple-choice questions are a good way to test your knowledge?
For factual knowledge, it is quite useful but for the type of content that is more subjective, the multiple-choice questions won’t be sufficient.
Teacher Interview
Q: Do you prefer writing your questions or do you use online resources?
I usually prefer writing my questions but sometimes I do get inspired by other questions I come across online.
Q: Do you ever run out of unique ideas for questions?
Yes, it can be hard to come up with different types of questions out of the same content.
Q: Would you use automated question generation software that creates questions out of a piece of text?
Yes, I would consider using it as a resource or maybe as small-scale assignments for my students.
Q: Would you like to have the questions generated to be shareable?
Yes, it would be better if I could share the questions with my students or colleagues.
Personas
After conducting the interviews, we created two personas for our target users. One representing teachers and another representing students
Use Cases
We created a very simple use case diagram that shows the functionality behind question generation and tracking user progress. These are all the options the user can choose but in a very simplified way.
MoSCoW List
Lastly, we held a meeting with our client with the finalised functional and non-functional MoSCoW lists:
Functional Requirements:
| Requirements | Priority |
|---|---|
| Web application that can interact with a user and have a back end database | Must Have |
| An API endpoint that will host the database and QG logic, but will communicate with a front end application | Must Have |
| Independent front end application that talks to the API | Must Have |
| Processes educational and factual text, generates questions out of the text input | Must Have |
| We need to be able to store the questions in the database (with the text extract) | Must Have |
| Users can login to access and track their progress | Must Have |
| Responsive User Interface | Must Have |
| For each question, it can check if the user's answer is right or wrong and warn the user | Must Have |
| Gives the option to see the text input when on the question page (optional to the user) | Should Have |
| The user can attempt the question again or skip to the next question | Should Have |
| A Dashboard that shows the number of right and wrong answers | Should Have |
| Can choose the number of options the question should have | Could Have |
| Decides the difficulty of the question and gives the user the option to see it | Could Have |
| Generates different types of questions (such as drag and drop or fill in the blank) | Could Have |
| Wikipedia based wordcloud for correct answers and wrong answers | Could Have |
| Questions that require long written answers | Won't Have |
| Questions with answers beyond the input text | Won't Have |
| Questions with Images or non-textual media | Won't Have |
Non-functional Requirements:
| Requirements | Priority |
|---|---|
| The web app shall be accessible by anyone | Must Have |
| The API shall have a plug and play structure and shall be able to use different algorithms | Must Have |
| There shall be clear documentation on how to use the API | Must Have |
| The API shall have a extensible structure for new the addition of new features | Should Have |
| The database shall have a large capacity | Should Have |
| The API shall be reliable and should always generate a question | Could Have |
| The system should ask for permission before storing the performance of the user | Could Have |