user requirements document (urd) · 2020. 7. 2. · m.d.v. meijer (max) 1237961 m.c. miulescu...

User Requirements Document (URD)2IPE0 SOFTWARE/WEB ENGINEERING PROJECT

June 25, 2020

GROUP 1R.T.B. Kakkenberg 1240667B.H.A.F. Krekelberg 1012598P. Kyriakou 1256416J.E.P.M. van Laarhoven 1230803S.N. Lommers 1243590M.D.V. Meijer 1237961M.C. Miulescu 1282778D. Shehu 1232758A. Vorobiova 1232883Y. Yoon 1227750I. Zenden 1222833

Version: 3.0Supervisor: dr. H. de BeerCustomers: S. Schenkelaars

J. van Sleeuwen

Abstract

This document, the User Requirement Document (URD), describes the requirements forDocuGen. DocuGen is a Learning Tools Interoperability (LTI) application that runs withinCanvas to automatically generate and distribute documents based on an external tem-plate with data originating from the Canvas LMS. This document complies with the ESAsoftware standards. [1]

Contents1 Introduction 3

1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 List of de�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 De�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 List of references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 General Description 72.1 Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 General capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Structure of templates and documents . . . . . . . . . . . . . . . . . 82.2.2 LTI App interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 General constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.4 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 User characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.1 Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2 Teacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.3 Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Environment description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.1 Integration into Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.2 Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.3 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.4 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6 Assumptions and dependencies . . . . . . . . . . . . . . . . . . . . . . . . . 152.6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Requirements 163.1 Capability requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.3 Teacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.4 Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Constraint requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Privacy & Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.5 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

A Use cases 28

B Signing page 45

0

I Document Status Sheet

I.I GeneralDocument title: User Requirement Document

Document identi�er: URD/3.0

Authors: R.T.B. Kakkenberg (Roy) 1240667B.H.A.F. Krekelberg (Bob) 1012598P. Kyriakou (Panos) 1256416J.E.P.M. van Laarhoven (Jordi) 1230803S.N. Lommers (Sem) 1243590M.D.V. Meijer (Max) 1237961M.C. Miulescu (Mara) 1282778D. Shehu (Denis) 1232758A. Vorobiova (Alina) 1232883Y. Yoon (Yeochan) 1227750I. Zenden (Ivo) 1222833

Document status: Final

I.II Document History

Version Date Authors Reason0.1 24-04-2020 Everyone Initial version.0.2 29-04-2020 Everyone Implement client and supervisors feedback, ex-

tend sections with additional information.1.0 03-05-2020 Everyone Final version.1.1 06-05-2020 Everyone Small changes before signing.2.0 03-06-2020 Roy, Mara &

PanosRevised version.

3.0 17-06-2020 Mara & Max Revised version.

1

II Document Change Record

Version Date Section Reason0.1 24-04-2020 Everyone Initial version.0.2 29-04-2020 Everyone Implement client and supervisors feedback, ex-

tend sections with additional information, add�rst choice of priorities.

1.0 03-05-2020 Everyone Implement client feedback on priorities and re-quirements.

1.1 06-05-2020 Everyone Implemented the �nal feedback of the clientsand supervisor. Small additions to and wordingchanges in chapter 2 and small overall changes inchapter 3.

2.0 03-06-2020 Roy, Mara &Panos

Fixed issues caused bymisunderstandings on doc-uments.

3.0 17-06-2020 Mara & Max Restructured much of the document because ofleftover issues from the document misunder-standings.

2

1 Introduction

1.1 PurposeThe User Requirement Document (URD) contains the user requirements for DocuGen.All requirements in this document are the result of a joint collaboration between thecustomers, S. Schenkelaars and J. van Sleeuwen, and the software development team.

The requirements in this document will be implemented according to their indicated pri-orities using theMoSCoWmodel. [2] The “Must have” requirements will be implementedin the product, other requirements will be implemented if resources permit. Changes tothis document must be approved by both parties.

1.2 ScopeDocuGen is a project developed by Typwryterz, a group of Computer Science & Engineer-ing students from Eindhoven University of Technology working on their Software Engi-neering Project. The aimof this project is to create an application that runswithin Canvasto generate and distribute documents. Drieam B.V., further referred to as “Drieam“, isthe customer for this project and is represented by S. Schenkelaars and J. van Sleeuwen.

Canvas is a Learning Management System (LMS). This platform helps teachers to orga-nize courses for students. The platform allows the teacher to share all course relatedmaterials to the students of that course and allows the teacher to keep track of theirprogress.

The aim of this project is to create a Learning Tools Interoperability (LTI) plugin for Can-vas that allows educators to generate and distribute documents for the participants ofthat course given a set of requirements. Currently, educators using Canvas have nopossibilities to generate documents from within the ecosystem. This results in lots ofmanual work for course administrators, like copying and pasting student informationfrom one system to another. Using an external template, the LTI plugin generates doc-uments based on data, for example the name of the student or the name of the course,originating from the Canvas platform and make the generated document available forthe student to download.

3

1.3 List of definitions1.3.1 De�nitions

Canvas account Organizational unit within Canvas. By default aninstitution has one account called root account.This root account may include sub-accounts andcourses.

Canvas sub-account Organizational unit within Canvas that can becreated by the root account to manage thehierarchy of an institution. For example, the rootaccount may represent a university and asub-account may represent a department fromthe university.

Administrator User assigned to oversee and manage aninstitution’s Canvas account.

Boolean condition Logic statement that is either true or false.

Document A computer �le containing information.

Field A particular area in a document where the sametype of information is recorded.

Global navigation Global Navigation is the menu that appears onevery Canvas page. Global Navigation consists ofnavigation links that direct users tofrequently-used features in Canvas. In the NewCanvas User Interface (UI), Global Navigation islocated on the left of every Canvas page.

Learning Management System Group of applications that support educators inteaching. An LMS creates an environment for e.g.announcements, online quizzes, handing inassignments and sharing grades.

Learning Tools Interoperability (LTI) Speci�cation implemented by many learningmanagement systems like Canvas to allowcommunication between the system and externalapplications.

4

Student User with the Canvas Student role for one or morecourses where DocuGen is used.

Template Schematic of a document containing data �elds,layout and structure.

Teacher User with the Canvas Teacher role in one or morecourses where DocuGen is used.

Trigger Condition that allows a document to be generatedfor a document template, if the condition is met.This condition could for example be that thestudent needs to pass the course with at least a5.5.

User Person that uses the application. He or she can becategorized as either an administrator, teacher, orstudent.

Multi-tenant architecture A software architecture that is characterized byhaving a single instance of software running on aserver that serves multiple tenants.

1.3.2 Abbreviations

Admin Administrator

API Application Programming Interface

LMS Learning Management System

LTI Learning Tools Interoperability

PDF Portable Document Format

UI User Interface

1.4 List of references[1] E.B. for software Standardisation and Control. ESA software standards, 1991.[2] The DSDM Agile Project Framework for Scrum. DSDM Consortium, 2012.[3] Canvas the Learning Management Platform. https://www.instructure.com/

canvas/. Accessed: 21-04-2020.

5

https://www.instructure.com/canvas/

https://www.instructure.com/canvas/

[4] PDF Generator API. https://pdfgeneratorapi.com/. Accessed: 21-04-2020.

1.5 OverviewThe remainder of the document is organized as follows. In chapter 2, we will give ageneral description of the product that has to be built. In that chapter we will discussthe product perspective, general capabilities, the constraints of the system, the usercharacteristics, the environment description, and the assumptions and dependencies.In chapter 3, the formal user capability and constraint requirements for the system willbe listed. Finally, a list of all use cases that are relevant to the product are presented inappendix A.

6

https://pdfgeneratorapi.com/

2 General Description

2.1 Product perspectiveCanvas is a Learning Management Program [3] used by many universities and othereducational institutions to support teachers. Canvas provides many supportive func-tionalities to teachers: managing groups, sharing �les, grading and announcements arejust a few examples of them. However, just like any piece of general software, there isalways something missing. Every institution has its own preferences, wishes and needsfor a large software product like Canvas.

Therefore Canvas implements the Learning Tools Interoperability (LTI) speci�cation. Itallows developers to extend any education content provider (like Canvas) with custombuilt applications. These applications can interact with Canvas and its data via the LTI.They can be viewedwithin Canvas and can use its data about people that follow a certaincourse. It looks like this application is a part of Canvas, while in reality it works on its ownwith data supplied by Canvas and possible custom added data.

Institutions havemany o�cial documents that they hand out to students, like certi�catesor grade lists. These documents are often created in a separate environment or evenmanually. All the data that is needed for these documents, needs to be exported fromsomewhere and then used somewhere else, while much of this data is already availablein Canvas (e.g. names, dates of birth, enrolled courses and grades).

Then, there is the problem of availability and consistency. Students are given many dif-ferent documents via many di�erent communication channels. Some certi�cates aresent via email, while others are sent via the regular mail and others are only availablevia digital download. Almost all of these methods cost time for employees, because ev-ery document needs to be sent one by one to every student.

Because there are many o�cial documents, it can also be di�cult to keep them consis-tent and in line with requirements and possible o�cial standards, i.e. to have them allin the same style. Many persons within an institution can create these documents anddistributing changes to the style and content can become quite a challenge.

DocuGen is a solution to all these problems. It allows administrators or teachers in Can-vas to generate personalized documents with only a few clicks. A template forms thebasis of these documents. These templates are created by administrators in the PDFgenerator API editor and use information from Canvas to personalize every documentfor every student. Documents need to use a template, so consistency and automationcan be easily enforced. Small modi�cations to a template are automatically applied toall documents, so distribution of modi�cations becomes easier as well. The distributionof documents is also easier, because all documents can be downloaded from Canvas.

These documents are created in the PDF �le format. Due to the complexity of generatingPDF �les, an external API will be used, namely the PDFGenerator API fromActual Reports[4]. An external generator is used because generating PDFs is outside the scope of theproject. Creating and distributing documents is the main goal, while building a tool todesign and generate PDFs is a whole di�erent project. Using another tool ensures that

7

we do not have to worry about e.g. formatting, input �elds and design, such that theteam can focus on distribution.

Creating andmodifying a template is done within the external PDF Generator API. Docu-Gen will simply be the bridge between Canvas and PDF Generator API: DocuGen will getdata from Canvas and send it to PDF Generator API to send a personalized PDF �le backto the user. Because we use an external tool, DocuGen needs to generate as few PDFsas possible to prevent exceeding the limit of the generator. A schematic and an exampleof the connections between Canvas, DocuGen, PDF Generator API and the user can befound in section 2.5.4.

2.2 General capabilitiesThe core of the application generates documents from a template with data from Can-vas. These templates are created by the administrator in DocuGen, but designed in PDFGenerator API. Every template can be used for multiple documents. A teacher or an ad-ministrator can use a template to generate documents. Students can then downloadthese generated and personalized documents.

DocuGen uses the roles and permissions from Canvas, and on top of that allows ad-ministrators to de�ne custom permissions for templates and documents. By default,Canvas administrators can access the administrator view, Canvas teachers can accessthe teacher view of the courses that they teach and students can access the studentview.

2.2.1 Structure of templates and documents

Document templates form thebasis for document generation andhave several attributes.First, there are its name and category. Both can be chosen freely by the administrator.The category is simply a keyword that can be used to �lter the list of templates. A pos-sible category could be Certi�cate or Proof of enrollment. Each new template also needsexactly one data type. Each data type provides the template with a list of input �elds.When a document gets generated, these �elds are �lled in with the information of astudent. There are two data types:

1. The user data type contains all kinds of information about the user. Example �eldsare his/her enrolled courses and the �nal grades for those courses.

2. The enrollment data type contains all kinds of information about a student in acourse. Example �elds are the course name, his or her grades, groups or assign-ments.

Templates can be restricted to certain courses or subaccounts from Canvas.

Triggers can be used to automate the generation of documents for students. Each tem-plate has at most one trigger. Each trigger contains at least one condition. A possibletrigger could be for example ”All students with a �nal grade equal or larger than a 5.5“ or”All students that are part of a group in Canvas“. The conditions in these triggers can be

8

de�ned by the administrator. Triggers can only be removed from DocuGen when thereare no more templates that use them.

Documents are generated by administrators, teachers or other authorized roles andare based on templates. When a document is generated in a course, it is bound to thatcourse. When it is generated in the Administrator interface, it is not. Triggers causedocuments to be generated for students automatically, but teachers or administratorsmay choose to manually generate documents as well.

2.2.2 LTI App interface

DocuGen provides three interfaces, one for each type of user. Each interface is foundin a di�erent location in Canvas. Students can �nd the student interface inside theuser menu, by clicking on ”Account“. Teachers can �nd the teacher interface within thecourse, in the navigationmenu of the course. Administrators can access the administra-tor interface inside the administrator menu, by clicking on ”Admin“.

2.2.2.1 Administrator

When the administrator opens the interface, they can choose between listing templates,documents, users (and their generated documents) or courses, each in their own tab.

When the administrator opens the templates tab, they will see a list of all templates.They can perform the following actions with these templates:

1. Create a new template as follows:

(a) The administrator needs to con�gure the name, category and data type of thisnew template.

(b) They then get the option of being redirected to the PDF Generator Editor inorder to design the template. If they decline to design the template, they canalways still choose to do so later.

(c) In the PDF Generator they can design the new template.

(d) The administrator con�gures the data �elds on the template in the PDF Gen-erator Editor.

This new template is automatically used in DocuGen and set to inactive by default.No extra steps are necessary

2. Edit certain template properties within DocuGen, speci�cally the name and cate-gory. The data type cannot be changed.

3. Change the design of an existing template. For this they are redirected to the tem-plate in the PDF Generator Editor. They can visually edit the template here. Savedchanges are automatically used in DocuGen.

4. Delete a template. When the administrator tries to delete an existing template, thesystem checks whether there are nomore documents using this template. If this isnot the case, the request of the administrator is denied and they get a noti�cation

9

that �rst all documents related to this template should be removed. If there areno more documents using this template, the admin has to con�rm the deletion. Ifthey agree, the template is removed from both DocuGen and PDF Generator API.

5. Duplicate an existing template. Only a new (unique) name needs to be chosen. Allother attributes and the design are copied to the duplicate.

6. Set templates to inactive if they were active and vice versa. In contrast to activetemplates, inactive templates cannot be used by teachers and administrators togenerate documents.

The list of templates can also be sorted on di�erent parameters, like the name, type,active/inactive and number of generated documents.

When the administrator opens the documents tab, they get an overview of all createddocuments of their institution. The list can be �ltered on courses, students or usedtemplate. When the list is �ltered on a course, all documents created in that courseremain. When the list is �ltered on a student, all documents available to that studentremain.

When the administrator opens the users tab, they get an overview of all users in thecurrent subaccount. Just like a teacher, the administrator can also generate documents,which is done from the users tab. A document can be generated for 1 or more users.However, documents created by the administrator are not bound to a course.

When the administrator opens the courses tab, they get an overview of the number ofstudents and documents per course.

2.2.2.2 Teacher

When the teacher opens the interface, they can choose between listing enrollments anddocuments, each in their own tab.

If the teacher opens the enrollments tab, they will see an overview of all enrollments ofthe corresponding course. They can perform the following actions here:

1. Generate a new document. Every document is based on a template, so a templatehas to be chosen. Such a document can be generated for 1 or more enrollmentsand is bound to a course.

2. Delete a document. After con�rmation, the selected documents are deleted fromDocuGen. Students are not able to download the deleted documents anymore.

3. Preview a document. The teacher can download a document in name of a studentto verify that the document is what he wanted.

When the teacher opens the documents tab, they get an overview of all created docu-ments of their institution. The list can be �ltered on courses, students or used template.When the list is �ltered on a course, all documents created in that course remain. Whenthe list is �ltered on a student, all documents available to that student remain.

10

2.2.2.3 Student

Students can open the interface and are served the Student view. In this interface, eachstudent gets their own list of documents. The student can download a document fromthis page to their computer. The list of documents can also be sorted on name and dateand the list can be �ltered.

2.3 General constraintsDue to limitations there will be constraints on what DocuGen will o�er, and what canbe expected from the average user of DocuGen. In this section we will discuss the con-straints we take into account.

2.3.1 Usability

DocuGen is intended for three di�erent user roles: students, teachers and administra-tors.

Students are familiar with the Canvas platform, therefore we think it is reasonable to as-sume that students knowhow to navigate within this platform. TheDocuGen applicationshould be easy and intuitive to use without reading a user manual.

From teachers and administrators we also assume that they are familiar with the Canvasplatform. The DocuGen application should be easy and intuitive to use without readinga user manual for teachers and administrators as well.

DocuGen should be responsive at all time. The UI shall not get stuck or unresponsiveby execution of di�erent processes. This should also be made clear by providing visualfeedback to all actions of any user.

2.3.2 Environment

The DocuGen application shall operate in an LTI platform (like Canvas). These plat-forms are all web-based environments, therefore the application should be supportedby all browsers that are supported by the LTI platforms, especially the Canvas platform.Furthermore, DocuGen should also be usable from the Canvas mobile application. Theapplication should be amulti-tenant application that is compatible with U.S. English. Op-tionally, multi-language support shall be added.

2.3.3 Performance

We expect the number of users that will use DocuGen to be large. Most documents willbe awarded at the begin or end of each semester/quartile. This might result in peaksat such moments where a lot of personalized documents will be generated and down-loaded by students, which might impact the responsiveness of the application.

11

2.3.4 Reliability

DocuGen has to be reliable, as it will be used to generate documents that prove the en-rollment in or completion of a (set of) courses. These documents might be used as aproof of completion, therefore it is important that the document are reliable. All docu-ment should be generated using the data originating from Canvas without any errors.

2.4 User characteristicsWe are required to deliver certain functionalities based on the characteristics of a userand their role within this application. This section describes the user characteristics ofeach user type to be accounted for in DocuGen. These user types are not mutually ex-clusive, i.e. one instance of a real-world user could ful�ll an arbitrary combination of theuser roles mentioned in this section.

2.4.1 Administrator

The main role of the administrator is the management of templates, with the help offunctionality of the PDF Generator API integrated with DocuGen. The administrator canalso directly award documents to students, but this is limited to documents that are notbound to a course, such as grade lists of a curriculum. The following points describe thebehavioural aspects of the administrator using DocuGen.

• Able to create the document templates.

• Able to delete templates if no documents use such templates.

• Able to edit templates.

• Able to integrate the pre-stored data on Canvas with DocuGen. For example, datasuch as name and �nal grade that is already known in Canvas will be automatically�lled in the document upon the request of administrator.

• Able to manage the triggers. The administrator should be able to add, remove andedit the conditions of the trigger.

• Able to award non-course-bound documents to students.

• Able to �lter documents using an interface element such as a dropdown menu.This can �lter out the following categories: user, course etc. The document list willautomatically sorted upon clicking category.

• Able to set an inactive template to active.

• Able to set an active template to inactive.

2.4.2 Teacher

The main role of the teacher in DocuGen is to manage student documents. Teacherswill also share some of the permissions of the administrator in DocuGen. In contrastto administrators, who only control the distribution of non-course-bound documents,

12

teachers will generally be involved with awarding documents to students in the contextof a course, such as certi�cates when they �nish an assignment, project or exam. Ateacher does not have to manually check whether students meet a condition to access adocument if a trigger is con�gured on the corresponding document template. In case ateacherwants to change administrative settings such as assigning a trigger, it is expectedfrom him or her to contact the administrator. By default, a user is considered a teacherif they have the default Teacher role within Canvas.

• Able to award documents to students within the scope of the course (in a case ofa certi�cate)

• Able to download and delete generated documents

• Able to see which students were not awarded the document

2.4.3 Student

Students have the least permissions to DocuGen; they can only view, download and�lter documents. Students can also download the certi�cate for a course that they havecompleted. This is realized when studentsmeet a certain condition, for example passinga course above a 5.5. As a result, DocuGen will generate the corresponding certi�cateusing the trigger. Students can access this generated document at any time (Assumingstudents have access to this course and documents are available).

2.5 Environment description2.5.1 Integration into Canvas

If DocuGen is enabled for a speci�c course within Canvas, then users of Canvas thathave the Teacher role within that course will be able to enter DocuGen by clicking onthe DocuGen button in the course navigation menu. DocuGen will then be loaded in aframe from an external server. Canvas passes data on the app placement and user rolesto DocuGen as part of the initialization process, such that DocuGen is able to providethe correct interface and permissions. After this, DocuGen requests all the data it needsfrom Canvas in order to operate correctly, such as the course ID and the enrollments ofa course, by means of API calls.

2.5.2 Front-end

The front-end of DocuGen will display the user interface of DocuGen with the help of theDrieam UI framework, in which the user can interact with the interface to perform someaction. This action will be translated as a request which is then sent to the back-end.

2.5.3 Back-end

The back-end of DocuGen relies on the Drieam LTI framework. Data from Canvas is usedby means of API to map to speci�c locations on the document and to provide the means

13

by which DocuGen knows when to make a certain document available to a student. Fur-thermore, DocuGen provides API calls to request all names and statuses of documentsmade available to a user and to download a document.

To provide administrators with the means to create and edit templates, calls to the PDFGenerator API are made. Via this API, the PDF Generator Editor can be accessed for thispurpose. Besides this, students are provided with the ability to download their person-alized documents by means of an API call to the back-end, which uses PDF GeneratorAPI to create the PDF �les.

2.5.4 Schematic

Figure 1: A schematic of the position of DocuGen within Canvas and PDF Generator API

In �gure 1, the global structure of DocuGen within Canvas is given. When an user re-quests the LTI app (1), a request is sent to Canvas (2), which replies with the page andthe location of the LTI app (3). Then, the front end of the LTI app is requested by thebrowser (4) and loaded (5).

When an user performs an action (6), this action is passed on by the front end to the backend (7). If the action is for example to generate a document, the back-end of DocuGenrequests the data of the user from Canvas (8) and then requests the PDF from the PDFGenerator API (9). The back-end then returns the result of this action to the front-end(10), which returns it to the browser (11).

14

2.6 Assumptions and dependencies2.6.1 Assumptions

To function according to its speci�cation, DocuGen requires the following statements tobe true:

• The LMS Canvas API is robust and acts according to its speci�cation.

• The PDF Generator API of Actual Reports OÜ is robust and acts according to itsspeci�cation.

• An interface to LMS Canvas is available at all times.

• An interface to the Actual Reports OÜ PDF Generator API is available at all times.

• The Actual Reports OÜ PDF Generator Editor is available at all times.

• The external server on which DocuGen is hosted is available at all times.

2.6.2 Dependencies

To function according to its speci�cation, DocuGen depends upon the following:

• LMS Canvas

• Drieam LTI framework

• Drieam UI framework

• PDF Generator API from Actual Reports OÜ

• PDF Generator Editor from Actual Reports OÜ

• External server for hosting DocuGen

15

3 RequirementsThis chapter contains all requirements that have been constructed in agreement withthe customer. DocuGen will adhere to the requirements listed in this chapter. The re-quirements are prioritized using the MoSCoW method [2]. A short explanation of thismethod including abbreviations can be found below.

Priority Abbreviation Explanation

Must have M These requirements are fundamental and musttherefore be included in the product.

Should have S These requirements are important, but not as impor-tant as themust have requirements. Hence, they canbe left out if there is no other choice.

Could have C These requirements are good to have in the product,but can easily be left out. These will only be imple-mented when there is time left or if they are easy toimplement.

Won’t have W These requirementswill not be implemented into theproject, but can be realised at a later version of theproduct.

3.1 Capability requirements3.1.1 General

ID Requirement Priority

URF 1.1 When the validity date of a document has passed, the systemshall automatically delete this document within 24 hours.

C

URF 1.2 When a student satis�ed one of the conditions of a trigger,the system shall generate all documents within 24 hours.

S

URF 1.3 When the deletion date and time of a document have passed,the document shall be removed within 24 hours.

C

URF 1.4 Every template shall have a name. M

URF 1.5 Every template shall have a category. S

URF 1.6 Every template shall have exactly one data type. M

URF 1.7 Every document shall have a name. S

3.1.1.1 Data types

16


URF 1.8 The system shall provide a user data type with all informationabout a user.

M

URF 1.9 The system shall provide an enrollment data type with allinformation about a user in a course.

M

3.1.2 Administrator


URF 2.1 A Canvas user with the role Administrator shall have access tothe administrator interface.

M

URF 2.2 A Canvas user without the role Administrator shall not haveaccess to the administrator interface.

M

URF 2.3 The system shall provide the means for an administrator toassign roles that have access to the teacher interface.

C

URF 2.4 The system shall provide the means for an administrator tode�ne contact details for teachers in case teachers needsupport.

C

3.1.2.1 Templates


URF 2.5 The system shall provide the means for the administrator tocreate a template.

M

URF 2.6 When creating a new template, the system shall allow theadministrator to set a default document validity.

C

URF 2.7 When creating a new template, an administrator shall chooseexactly one data type.

M

URF 2.8 When creating a new template, an administrator shall chooseone subaccount that has access to this template.

S

URF 2.9 When creating a new template, an administrator shall choosemultiple subaccounts that have access to this template.

S

URF 2.10 When creating a new template, an administrator shall choosea course that has access to this template.

S

URF 2.11 When creating a new template, an administrator shall choosemultiple courses that have access to this template.

S

Continued on next page

17


URF 2.12 The system shall provide the means for the administrator toedit an existing template.

M

URF 2.13 The system shall provide a list of all templates for theadministrators.

M

URF 2.14 The system shall provide the means for the administrator toset an inactive template to active.

M

URF 2.15 When the administrator sets an inactive template to active,the system shall set the template to active.

M

URF 2.16 The system shall provide the means for the administrator toset an active template to inactive.

M

URF 2.17 When the administrator sets an active template to inactive,the system shall set the template to inactive.

M

URF 2.18 If a template is not used by any documents, the system shallprovide an option to delete that speci�c template for theadministrator.

M

URF 2.19 If an administrator wants to delete a template and thistemplate is not used by any documents, the system shall askfor con�rmation before executing the deletion.

M

URF 2.20 When requested by the administrator, the system shall sortthe list of templates on their names.

S

URF 2.21 When requested by the administrator, the system shall sortthe list of templates on their category.

S

URF 2.22 When requested by the administrator, the system shall sortthe list of templates on their number of documents that usethis template.

C

URF 2.23 When requested by the administrator, the system shall sortthe list of templates on their creation date.

S

URF 2.24 When requested by the administrator, the system shall sortthe list of templates on their last modi�cation date.

S

URF 2.25 When requested by the administrator, the system shall sortthe list of templates on their creator’s name.

S

URF 2.26 When requested by the administrator, the system shall �lterthe list of templates on their names.

S

URF 2.27 When requested by the administrator, the system shall �lterthe list of templates on their category.

S


18


URF 2.28 When requested by the administrator, the system shall �lterthe list of templates on their number of documents that usethis template.

C

URF 2.29 When requested by the administrator, the system shall �lterthe list of templates on their creation date.

C

URF 2.30 When requested by the administrator, the system shall �lterthe list of templates on their last modi�cation date.

C

URF 2.31 When requested by the administrator, the system shall �lterthe list of templates on their creator’s name.

S

URF 2.32 When requested by the administrator, the system shall listonly active templates.

S

URF 2.33 When requested by the administrator, the system shall listonly inactive templates.

S

URF 2.34 The system shall provide duplication of a template by theadministrator, where only a new name has to be chosen bythe administrator.

S

URF 2.35 The system shall provide recovery of deleted templates bythe administrator,

S

URF 2.36 When a template gets modi�ed by an administrator, alldocuments that use that template shall keep their old design.

W

URF 2.37 The system shall keep track of di�erent template versions. W

URF 2.38 If the system provides recovery of deleted templates, thesystem shall provide the means for an administrator topermanently delete a deleted template.

S

3.1.2.2 Triggers


URF 2.39 The system shall provide the creation of a trigger by theadministrator

S

URF 2.40 Each trigger shall have one boolean condition. S

URF 2.41 Each trigger shall have one or more boolean conditions. C

URF 2.42 If a template has not been assigned a trigger and theadministrator chooses to, the system shall assign a trigger tothis template.

S


19


URF 2.43 When requested by an administrator, the system shallremove a trigger from a template.

S

URF 2.44 If an administrator wants to delete a trigger, the system shallensure that this trigger is not assigned to any templates.

S

URF 2.45 If an administrator wants to delete a trigger and this trigger isnot assigned to any templates, the system shall ask forcon�rmation before executing the deletion.

S

URF 2.46 The system shall provide the means for an administrator tochoose the time at which all triggers are checked.

C

3.1.2.3 Documents for Administrators


URF 2.47 The system shall provide a list of all documents for theadministrator.

M

URF 2.48 The system shall provide the means for an administrator tocreate a document.

M

URF 2.49 When creating a document, the system shall enforce that theadministrator selects an active template that this documentwill be based on.

M

URF 2.50 When creating a new document, the system shall allow theadministrator to set a validity.

C

URF 2.51 The system shall provide the means for a teacher to changethe template of a document.

S

URF 2.52 The system shall provide the means to �lter all documents bya certain template.

S

URF 2.53 The system shall provide the means to �lter all documents bya certain student.

C

URF 2.54 The system shall provide the means to �lter all documents bya certain course.

C

URF 2.55 The system shall provide the means to �lter all documents bytemplate name.

S

URF 2.56 The system shall provide the means to �lter all documents bythe creator’s name.

C


20


URF 2.57 The system shall provide the means to sort all documents bytemplate name.

S

URF 2.58 The system shall provide the means to sort all documents bycourse name.

C

URF 2.59 The system shall provide the means to sort all documents bystudent name.

C

URF 2.60 The system shall provide the means to sort all documents bycreation date.

C

URF 2.61 The system shall provide the means to sort all documents bythe creator’s name.

S

URF 2.62 The system shall provide immediate deletion of documentsby the administrator.

M

URF 2.63 The system shall provide deletion of documents at a certaindate and time in the future by the administrator.

C

URF 2.64 When the administrator chooses to delete a document (bothimmediate or in the future), the system shall ask forcon�rmation before executing the deletion.

M

URF 2.65 When the administrator con�rms the immediate deletionrequest, the system shall delete a document.

M

URF 2.66 The system shall provide previewing documents with achosen user’s information by the administrator.

S

URF 2.67 The system shall provide recovery of deleted documents bythe administrator.

S

URF 2.68 If the system provides recovery of deleted documents, thesystem shall provide the means for an administrator topermanently delete a deleted document.

S

3.1.3 Teacher


URF 3.1 A Canvas user with the course role Teacher shall have accessto the teacher interface within that course.

M

URF 3.2 A Canvas user without the course role Teacher shall not haveaccess to the teacher interface within that course.

M


21


URF 3.3 The system shall provide the list of all generated documentsof the course.

M

URF 3.4 A teacher shall be able to see to the enrollments of thecourse.

M

URF 3.5 The teacher interface shall provide information for theteacher to contact an administrator for support.

C

3.1.3.1 Documents for Teachers


URF 3.6 The system shall provide the means for a teacher to create adocument.

M

URF 3.7 When generating a document, the system shall enforce thatthe teacher selects an active template that this document willbe based on.

M

URF 3.8 When generating a document, the system shall allow theteacher to manually override the default trigger of thetemplate with a desired trigger of the teacher.

W

URF 3.9 When generating a new document, the system shall allow theteacher to set a �nal validity date.

C

URF 3.10 The system shall provide immediate deletion of documentsby a teacher.

M

URF 3.11 The system shall provide deletion of documents at a certaindate and time in the future by a teacher.

C

URF 3.12 When a teacher deletes a document (both immediate or inthe future), the system shall ask for con�rmation beforeexecuting the deletion.

M

URF 3.13 When a teacher con�rms the immediate deletion request, thesystem shall delete a document.

M

URF 3.14 The system shall provide �ltering of the table of alldocuments of the course by student name.

S

URF 3.15 The system shall provide �ltering of the table of alldocuments of the course by the used template’s name.

S

URF 3.16 The system shall provide �ltering of the table of alldocuments of the course by the creator’s name.

C


22


URF 3.17 The system shall provide �ltering of the table of alldocuments of the course by creation date.

S

URF 3.18 The system shall provide sorting of the table of all documentsof the course by student name.

C

URF 3.19 The system shall provide sorting of the table of all documentsof the course by the used template’s name.

S

URF 3.20 The system shall provide sorting of the table of all documentsof the course by the creator’s name.

S

URF 3.21 The system shall provide sorting of the table of all documentsof the course by creation date.

S

URF 3.22 The system shall provide manual generation of a documentto a student of the course.

M

URF 3.23 The system shall provide manual generation of a subset ofstudents of the course by a teacher in bulk.

M

URF 3.24 The system shall provide manual generation of a documentto all students of the course by a teacher.

S

3.1.3.2 Enrollments


URF 3.25 A teacher can see the enrollments table of the course withthe generated documents for each enrollment.

M

URF 3.26 The system shall provide deletion of a single generateddocument by a teacher.

M

URF 3.27 The system shall provide deletion of multiple generateddocuments at once by a teacher.

M

URF 3.28 The system shall provide the means to generate a documentto a single student by a teacher.

M

URF 3.29 The system shall provide the means to generate a documentfrom the enrollment table to a subset of students by ateacher.

M

URF 3.30 The system shall provide the means to generate a documentfrom the enrollment table to all students by a teacher.

S

URF 3.31 The system shall provide sorting the table of all enrollmentsof a course by student name for a teacher.

S


23


URF 3.32 The system shall provide sorting the table of all enrollmentsof a course by generated documents for a teacher.

C

URF 3.33 The system shall provide �ltering the table of all enrollmentsof a course by generated documents for a teacher.

S

URF 3.34 The system shall provide previewing documents with achosen user’s information by a teacher.

S

3.1.4 Student


URF 4.1 The student shall have access to the student interface M

URF 4.2 The student shall be provided with an overview of documentsthat are available to download.

M

URF 4.3 The system shall provide the means to download thedocuments that are available by the student.

M

URF 4.4 The system shall provide the means to download a singlegenerated document in PDF format.

M

URF 4.5 The system shall provide the means to download multiplegenerated documents in zip format.

M

URF 4.6 The system shall send the student an email if a document hasbeen generated for that student.

W

URF 4.7 The system shall send the student an email if a generateddocument will be deleted in the future.

W

URF 4.8 The system shall provide �ltering of the table of all generateddocuments of the student by course name.

S

URF 4.9 The system shall provide �ltering of the table of all generateddocuments of the student by the creator’s name.

W

URF 4.10 The system shall provide �ltering of the table of all generateddocuments of the student by creation date.

S

URF 4.11 The system shall provide �ltering of the table of all generateddocuments of the student by validity date.

S

URF 4.12 The system shall provide sorting of the table of all generateddocuments of the student by course name.

S

URF 4.13 The system shall provide sorting of the table of all generateddocuments of the student by the creator’s name.

W


24


URF 4.14 The system shall provide sorting of the table of all generateddocuments of the student by creation date.

S

URF 4.15 The system shall provide sorting of the table of all generateddocuments of the student by validity date.

S

3.2 Constraint requirements3.2.1 Privacy & Security


URC 2.1 DocuGen shall verify that the user has the correct accessrights before allowing access to data.

M

URC 2.2 When an user failed veri�cation, DocuGen shall give noaccess to the data.

M

URC 2.3 DocuGen inherits access rights from Canvas. M

URC 2.4 DocuGen shall check input �elds for SQL injection. C

URC 2.5 DocuGen shall check input �elds for Cross-Site Scripting. C

3.2.2 Usability


URC 3.1 User can perform an implemented use case withoutinstruction within 10 minutes.

M

URC 3.2 User can perform an implemented use case withoutinstruction within 5 minutes.

S

URC 3.3 The UI of the system shall provide noticeable feedback to allaction triggered by the user.

S

URC 3.4 The UI of the system shall take into account the choices usershave made in the past.

W

URC 3.5 The UI of the system shall be consistent. M

URC 3.6 The UI of the system shall provide defaults choices that areusable by the user.

C


25


URC 3.7 The UI of the system shall contain easily understandablevisual alerts about the risks associated with a certain action, ifthere are any.

S

URC 3.8 The UI of the system shall not impose fear on the user. C

URC 3.9 The UI of the system shall blend in with the style of the usedCanvas installation.

C

URC 3.10 All non-text content in the UI of DocuGen shall have textalternatives.

C

URC 3.11 All elements in the UI of DocuGen will not rely solely on color. C

URC 3.12 The UI of the system shall use clear and helpful page titles. C

3.2.3 Environment


URC 4.1 DocuGen shall be available in English. M

URC 4.2 DocuGen shall be available in Dutch. W

URC 4.3 DocuGen shall provide an interface to easily implement newlanguages.

W

URC 4.4 If the user has permissions to see the interface, the studentinterface shall be embedded in the user’s pro�le tab.

M

URC 4.5 The teacher interface shall be embedded in the global coursemenu for users that have the teacher role.

M

URC 4.6 The administrator interface shall be embedded in theadministrator menu bar for users that have the administratorrole.

M

URC 4.7 The student interface shall be embedded in the users pro�letab.

M

URC 4.8 DocuGen shall display correctly on the latest stable version ofGoogle Chrome.

M

URC 4.9 DocuGen shall display correctly on the latest stable version ofMozilla Firefox.

S

URC 4.10 DocuGen shall display correctly on the latest stable version ofMicrosoft Edge.

C


26


URC 4.11 DocuGen shall display correctly on the latest stable version ofApple Safari

C

URC 4.12 DocuGen shall be a multi-tenant LTI application. M

URC 4.13 DocuGen shall use the Drieam LTI framework. M

URC 4.14 DocuGen shall use the Drieam UI (React) framework. M

URC 4.15 DocuGen shall use PDF Generator API by Actual Reports [4]for document generation.

M

URC 4.16 DocuGen shall implement a standard to simplify thepossibility of using a di�erent PDF generator API.

W

URC 4.17 Every uniquely generated document shall be generated atmost once by the PDF Generator API.

S

3.2.4 Performance


URC 5.1 99 % of documents shall be generated within 5 seconds. S

URC 5.2 The �lters shall be applied to documents within 5 seconds. S

URC 5.3 The document list shall be sorted within 5 seconds. S

3.2.5 Reliability


URC 6.1 DocuGen shall be accessible 99% of the time in a 24 hourperiod.

S

URC 6.2 DocuGen shall be accessible 99.5% of the time in a 24 hourperiod.

C

URC 6.3 DocuGen shall be accessible 99.9% of the time in a 24 hourperiod.

W

27

A Use cases

A.1 Student interfaceA.1.1 Student views their list of documents

Goal: Student views their documents in the Document LTI view in CanvasPrecondition: The actor is enrolled as a Student for the speci�c course(s).

The actor is logged into Canvas.The speci�c course(s) has Document LTI enabled.

Postcondition: All documents of the actor for the courses the actor is enrolled aredisplayed.

Summary: The actor can see the table of generated documents sorted on cre-ation date.

Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to the DocumentLTI view in Canvas

2. The system displays the Studentinterface of Document LTI to the actor3. The documents generated for theactor are retrieved from the database.4. All documents, corresponding coursename and date of creation are displayedto the actor.

Alternative:

2B: In case the database cannot be reached, an error message is shown.2C: In case the actor has no completely generated documents in the database, then

an empty table is shown.

28

A.1.2 Student downloads their documents as zip

Goal: Student download their documents as a zip archive of PDF �les.Precondition: The actor is enrolled as a Student in the speci�c course(s).

The actor is logged into Canvas.The speci�c course(s) has Document LTI enabled.

Postcondition: The documents of the actor are stored as a zip archive of PDF �les.Summary: The actor can export their documents as a zip archive containing PDF

�les.Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to the DocumentLTI view in Canvas.

2. The system displays the Studentinterface to the actor.

3. The actor selects to export documents.4. The system retrieves the documents.5. The system outputs a zip archive.6. The actor‘s browser downloads the ziparchive in the actor‘s system.

Alternative:

2B: In case the database cannot be reached, an error message is shown.

29

A.1.3 Student �lters their list of documents by course

Goal: Student �lters their list of documents by course name.Precondition: The actor is enrolled as a Student for the speci�c course(s).

The actor is logged into Canvas.The actor has navigated to their list of documents in the DocumentLTI view.The speci�c course(s) has Document LTI enabled.

Postcondition: The actor‘s documents to which the �lter applies are displayed.Summary: The actor applies �lters to the available documents. The �lters get

applied and the documents get returned to the actor.Priority: Must have

Steps:

Actor actions System actions1. The actor selects a course name fromdropdown menu to �lter on.

2. The system parses the user choice.3. The system displays the �lteredresults.

Alternative: -

30

A.1.4 Student sorts their list of documents by name

Goal: Student sorts their list of documents by name.Precondition: The actor is enrolled as a Student for the speci�c course(s).


Postcondition: The list of documents is sortedon thedocument nameanddisplayed,such that the actor can view them.

Summary: The actor sorts their list of documents by name in ascending or de-scending order. The sorting gets applied and the sorted list gets re-turned to the actor.

Priority: Must have

Steps:

Actor actions System actions1. The actor selects sort by name option.

2. The system parses the condition tosort the list by name in ascending order.3. The system displays the actor‘s list ofdocuments sorted by name in ascendingorder.

Alternative:

2B: In case the list of documents has been already sorted by name in ascendingorder, the system parses the condition to sort the list by name in descendingorder.

3B: The system displays the actor‘s list of documents sorted by name in descendingorder.

31

A.1.5 Student sorts their list of documents by date

Goal: Student sorts their list of documents by date of creation.Precondition: The actor is enrolled as a Student for the speci�c course(s).


Postcondition: The list of documents is sorted on the document creation date anddisplayed, such that the actor can view them.

Summary: The actor sorts their list of documents by date in ascending or de-scending order. The sorting get applied and the sorted list gets re-turned to the actor.

Priority: Must have

Steps:

Actor actions System actions1. The actor selects a sort on date option.

2. The system parses the condition tosort the list by creation date in ascendingorder.3. The system displays the actor‘s list ofdocuments sorted by date in ascendingorder.

Alternative:

2B: In case the list of documents has been already sorted by date in ascending order,the system parses the condition to sort the list by date in descending order.

3B: The system displays the actor‘s list of documents sorted by date in descendingorder.

32

A.2 Teacher interfaceA.2.1 Teacher opens Documents LTI view

Goal: Teacher opens the Document LTI view in Canvas.Precondition: The actor is enrolled as a Teacher or Teacher Assistant for the speci�c

course.The actor is logged into Canvas.The actor has navigated to the speci�c course.

Postcondition: The Teacher interface of Document LTI is shown.Summary: The teacher requests the Document LTI view.

Document LTI will show the Teacher interface.Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to the DocumentLTI view in Canvas.

2. The system displays the Teacherinterface of Document LTI to the actor.

Alternative:

2B: In case the Document LTI view cannot be reached, an error message is shown.

33

A.2.2 Teacher views a table with all generated documents linked to current course

Goal: Teacher views a table with all generated documents that are linkedto the speci�c course.

Precondition: The actor is enrolled as a Teacher or Teacher Assistant for the speci�ccourse.The actor is logged into Canvas.The actor has navigated to the speci�c course.The actor has navigated to the Document LTI view.

Postcondition: A table with all generated documents that are linked to the speci�ccourse is shown.

Summary: The teacher views the table with all generated documents that arelinked to this speci�c course.

Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to the documentssection.

2. The Document LTI shows a table withall generated documents that are linkedto the speci�c course.

Alternative:

2B: In case the documents database cannot be reached, an error message is shown.

34

A.2.3 Teacher creates a new document

Goal: A new document is created by the teacher.Precondition: The actor is enrolled as a Teacher or Teacher Assistant for the speci�c

course.The actor is logged into Canvas.The actor has navigated to the speci�c course.The actor has navigated to the Document LTI view.The actor has navigated to the enrollments section.

Postcondition: A new document is created and saved in the database.Summary: The teacher creates a new document using a chosen template for a

chosen student.Priority: Must have

Steps:

Actor actions System actions1. The actor selects a student fromenrollment list and selects Generatedocument.

2. The system opens a form where theactor can choose a template.

3. The actor chooses a name, categoryand template.

4. The system creates the document andsaves it in the database.

Alternative:

1B The actor selects multiple students from the enrollment list.4B The system creates the document for each selected student and saves them in

the database.

35

A.2.4 Teacher views a table with all students of the course and their linked documents

Goal: Teacher views a table with the enrollments of the course and thelinked generated documents.

Precondition: The actor is enrolled as Teacher or Teacher Assistant for the speci�ccourse.The actor is logged into Canvas.The actor has navigated to the speci�c course.The actor has navigated to the Document LTI view.

Postcondition: A table with all enrollments and linked generated documents isshown.

Summary: The teacher views the table with all enrollments of the speci�ccourse, including all linked generated documents.

Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to the enrollmentssection.

2. The Document LTI shows a table withall enrollments and linked generateddocuments of the speci�c course.

Alternative:

2B: In case the enrollments database cannot be reached, an errormessage is shown.

36

A.2.5 Teacher deletes a generated document

Goal: A document linked to an enrollment is deleted by the teacher.Precondition: The actor is enrolled as a Teacher or Teacher Assistant for the speci�c

course.The actor is logged into Canvas.The actor has navigated to the speci�c course.The actor has navigated to the Document LTI view.The actor has navigated to the documents section.

Postcondition: A student document is deleted from the database.Summary: The teacher deletes a generated document from the database.Priority: Must have

Steps:

Actor actions System actions1. The actor selects a document.2. The actor selects the delete option.

3. The system asks for con�rmation.4. The actor con�rms the deletion.

5. The system removes the documentfrom the database.

Alternative: -

37

A.3 Admin interfaceA.3.1 Admin views generated documents

Goal: Admin views all the documents that have been generated.Precondition: The actor has an Admin account.

The actor is logged into Canvas.The actor is currently on the Admin placement in Canvas.The actor has opened the Documents LTI view.

Postcondition: The actor sees an overview of which documents were generated andwhich students they were assigned to.

Summary: All generated documents are visiblePriority: Must have

Steps:

Actor actions System actions1. The actor navigates to Documents.

2. The metadata of the �rst 50 generateddocuments appearing in the list areretrieved from the database.3. The �rst page with 50 documents, withcorresponding course name,corresponding student name and date ofcreation are displayed to the actor.

Alternative:


38

A.3.2 Admin �lters generated documents by student

Goal: Admin views only documents generated for a selected student.Precondition: The actor has an Admin account.


Postcondition: The actor sees an overview of which documents were generated forthe selected student.

Summary: Admin selects one student by entering the student name in a searchbar.Only documents generated for the selected student are visible.

Priority: Must have

Steps:


2. All generated documents are retrievedfrom the database.3. All documents, corresponding coursename, corresponding student name anddate of creation are displayed to theactor.

4. The actor navigates to View perstudent.5. The actor enters student name to �lteron.

6. The documents are �ltered on theselected student.7. All documents generated for theselected student, corresponding coursename and date of creation are displayedto the actor.

Alternative:


39

A.3.3 Admin �lters generated documents by course

Goal: Admin views only documents generated for a selected course.Precondition: The actor has an Admin account.


Postcondition: The actor sees an overview of which documents were generated forthe selected course and which students they were assigned to.

Summary: Admin selects one course by entering the course name in a searchbar.Only documents generated for the selected course are visible.

Priority: Must have

Steps:



4. The actor navigates to View percourse.5. The actor enters a course name to�lter on.

6. The documents are �ltered on theselected course.7. All documents generated for theselected course, corresponding studentname and date of creation are displayedto the actor.

Alternative:


40

A.3.4 Admin deletes an existing document

Goal: Admin deletes a document.Precondition: The actor has an Admin account.


Postcondition: A document is deleted from the database.Summary: The admin deletes a document from the database.Priority: Must have

Steps:



4. The actor selects a document.5. The actor selects the delete option.

6. The system asks for con�rmation.7. The actor con�rms the deletion.

8. The system removes the documentfrom the database.

Alternative:


41

A.3.5 Admin creates a new template

Goal: Admin opened a template in pdfgeneratorapi.com.Precondition: The actor has an Admin account.


Postcondition: A template is opened in pdfgeneratorapi.com.Summary: The admin creates a new template.

A new template is opened in pdfgeneratorapi.com.Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to Templates

2. All available document templates areretrieved from the database.3. All available document templates aredisplayed to the actor.

4. The actor selects Create a newtemplate.5. The actor selects a data type for thetemplate

6. A template is opened inpdfgeneratorapi.com

Alternative:


42

A.3.6 Admin edits an existing template

Goal: The admin edits a template in pdfgeneratorapi.com.Precondition: The actor has an Admin account.


Postcondition: An existing template is opened in pdfgeneratorapi.com.Summary: The admin selects edit on an existing template.

The existing template is opened in pdfgeneratorapi.com.Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to Templates


4. The actor selects a template.5. The actor selects Edit template.

6. The template is opened inpdfgeneratorapi.com.

Alternative:


43

A.3.7 Admin deletes an existing template

Goal: The admin deletes an existing template from the database.Precondition: The actor has an Admin account.


Postcondition: The deleted template is removed from the database.Summary: The admin selects delete on an existing template.

The template is removed form the database.Priority: Must have

Steps:

Actor actions System actions1. The actor navigates to Templates.


4. The actor selects a template.5. The actor selects Delete template.

6. The system asks for con�rmation.7. The actor con�rms the deletion.8. The system removes the documentfrom the database.

Alternative:

2B: In case the database cannot be reached, an error message is shown.6B: In case documents are lined to the template, an error message is shown.

44

B Signing pageHereby the customer and Typwryterz agree upon the requirements stated in this docu-ment.

Customer Supervisor

Name: Name:

Date: Date:

Signature: Signature:

45

Stef Schenkelaars

Stef Schenkelaars

Stef Schenkelaars

29 June 2020