user requirements document - tu/emvdbrand/courses/se/0910/urds/urd-aqca.pdfproject manager: sander...

Project team: Eric Bataille, 0607809

Daan Gerrits, 0619172Kosmas Hatzidimitris, 0613433

Stijn Koopal, 0613671Mathijs de Langen, 0611699

Luuk Mallens, 0629109Rein Spijkerman, 0578915

Ron Vanderfeesten, 0581347Benji Vos, 0609254

Computer Science, TU/e

Project Manager:Sander Leemans, 0608896

Quality Assurance Manager:Frank Hermans, 0612291

Senior management:Mark van den Brand, HG 5.59

Lou Somers, HG 5.36

Advisor:Andrei Jalba, HG 6.85

Alexander Rulkens, ACQA

Customer:Tijn Borghuis, ACQA

Kees van Overveld, ACQA

User Requirements DocumentEindhoven, March 4, 2010 urd-1.0.219

Technische Universiteit Eindhoven University of Technology

Abstract

This document describes the user requirements for Project ICE. This project is part of theSoftware Engineering Project (2IP35) and is one of the assignments at Eindhoven University ofTechnology.

These user requirements were established according to the user requirements formulated by thecustomer, ACQA. The requirements can be divided in two parts. The first part is a new userinterface and the second part, which is the most important, is the communication between theuser interface and the existing database received from ACQA. Both parts are treated in thisdocument.

The document complies with the User Requirements Document (URD) of the Software EngineeringStandards, as set by the European Space Agency (ESA) [1].


Contents

1 Introduction 41.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 List of definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 List of references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 General description 92.1 Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 General capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 System administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Information manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.4 Security and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 General constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 User characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Environment description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Assumptions and dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Specific requirements 143.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Capability requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 User rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Input tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.4 Structure modification . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.5 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.6 Administration backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Constraint requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

A Database model 27

1


Document Status Sheet

Document status overview

General

Document title: User Requirements DocumentIdentification: Project ICE urd-1.0.219Authors: Kosmas Hatzidimitris, Luuk Mallens, Rein Spijkerman, Ron VanderfeestenDocument status: Final

Document history

Version Date Author Reason of change

0.0 26-02-2010 Kosmas, Luuk, Rein, Ron First version

0.0 28-02-2010 Kosmas, Luuk, Rein Comments of QM processed

0.0 02-03-2010 Kosmas, Luuk Comments of advisor and QM processed

0.1.188 02-03-2010 Eric Internally approved

0.1.219 04-03-2010 Kosmas, Luuk, Ron Comments of customer processed

1.0.219 04-03-2010 Stijn Externally approved

2


Document Change Records since previous issue

General

Date: March 4, 2010Document title: User Requirements DocumentIdentification: urd-1.0.219

Changes

Page Paragraph Reason to change

4 1.2 Bullet list, new tasks inserted

5 1.2 Conclusion about old app. changed

5 1.3 Changed: ACQA member, Administrator, ACQANaut, Compe-tence, Dimension, Dimension ladder, Discipline, Institute, In-trinsic involvement, Questionaire, Study element, Team, Cus-tom inspect, Custom modify

9 2.1 New application will be used ACQA members

9 2.1 2nd bullet: user friendly → flexible

5 1.2 Figure 1.1

10 2.1 Figure 2.1

11 2.2.2 Competences → Competence areas, competences and dime-nions

11 2.2.3 Section renamed, converted → included

13 2.1

14 3 Changed: UCR1, UCR4, UCR9, UCR18 - UCR25, UCR27,UCR38 - UCR41, UCR46, UCR47, UCR50, UCR57, UCR59,UCR62, UCR63, UCR65 - UCR72, UCR74, UCR83 - UCR88,UCR91 - UCR92, UCR99, UCR102 - UCR103, UCR107 -UCR108, UCR120, UCR132, UCR136, UCR139, UCR158

14 3 Changed: UCR86 - UCR91, UCR103 - UCR107

14 3 Changed: UCR25, UCR26, UCR64-UCR47, other minorchanges

3


Chapter 1

Introduction

1.1 Purpose

The user requirements document (URD) contains the requirements for ICE and states what thesoftware is supposed to do in negotiation between the customer ACQA and members of ProjectICE. All of the listed requirements, and only these, will be implemented in ICE, according to theirspecified priorities. Any changes to these requirements require the full consent of both parties.The requirements specified here can be used as a reference for verification in a later stage.

1.2 Scope

Our product is a web application called ICE. It is an application designed and developed by themembers of ICE for our customer ACQA. The purpose of the application is to support teachersand directors of education from universities, at describing what is meant by academic education.However, the question of whether a programme of study merits the predicate ’academic’ nolonger depends on the institute in which that programme is embedded, but on the content-relatedcharacteristics of that programme. Such characteristics, which characterize a university graduate,can be divided in a fixed set of academic competences. To be able to make such a descriptionfor a faculty programme at any institute, teachers have to fill in a questionaire about the courses(mentioned as study elements) they teach. The results are saved in a database. The director ofeducation can view these results by means of tables and figures.

This means that our product will be responsible for the following (global) tasks:

• Providing a user interface for the teachers to fill in the results of the questionaire.

• Providing a user interface for viewing results (obtained from the database) in histograms,radarplots and tables.

• Providing a user interface to modify the academic structure.

• Providing a user interface to make and modify user accounts.

• Connect the two user interfaces with the existing database.

4


In figure 1.1 one can see a schematic overview of the structure of the old application.

Figure 1.1: Structure of the old application. ACACIA is the name of the current web application.

As we can conclude from figure 1.1 the old application lacks the administration tool where admin-istrators can set up new user accounts. At the moment only ACQA has access to the application.Furthermore the old application is not flexible enough and the currently used data format is notsufficient anymore. At last, the old application makes use of MAGNAView for visualization of theresults.

1.3 List of definitions

ACACIA ACACIA is the name of the current web application.

ACQA ACQA is the name of the customer from which through interviews this document is setup.

ACQA member Employee of ACQA.

ACQANaut Members of an academic study programme that collect input data, on behalf ofACQA.

Administrator Administrator is short for ”system administrator”. It refers to a responsible personwho’s task is to manage and maintain the system (the web application itself and the serverwhere the database is installed) and use his/her privileges given to him/her to achieve theearlier mentioned task. A administrator is a member of the ACQA team.

Area of competence A set of competences that characterize a university graduate. Teachers

5


will indicate the level of relevance towards their study element. (is competent in one ormore scientific disciplines, is competent in doing research, is competent in designing, hasa scientific approach, possesses basic intellectual skills, is competent in co-operating andcommunicating, takes account of the temporal and the social context)

Co-Teacher Co-Teacher is anyone who will help a (responsible) teacher during the teaching of astudy element, such as instructors.

Competence A statement about knowledge, skills, attitude that a student should have.

Create Create is the first term of CRUD. Being able to create (insert) new information of thedatabase.

CRUD Create, Read, Update and Delete (CRUD) are the four basic functions of persistentstorage.

Curriculum An arbitrary selection of Study Elements.

Delete Delete is the fourth term of CRUD. Being able to delete (remove) information of thedatabase.

Dimension An aspect of academic thought and action. (analytic, synthetic, abstract, concrete)

Dimension ladder A scale to measure a dimension within a discipline.

Director of education Director of education is another term for Chief Education Officer. Thisperson is an official who is the chief administrative officer of a Local Education Authority.

Discipline A discipline is a branch of science.

ECTS The European Credit Transfer and accumulation System is a student-centered systembased on the student workload required to achieve the objectives of a programme, objectivespreferably specified in terms of the learning outcomes and competences to be acquired.

ESA European Space Agency.

i18n The Innodata Isogen Internationalization (I18N) support library provides a set of servicesthat support language- and locale-specific processing of documents, in particular, the man-agement of localized generated (static) text strings and locale-specific index and glossarygrouping and sorting.

Project ICE Project ICE is the name of our project. It refers to the participating developmentteam.

ICE ICE is the name of our product, consisting of a user web interface with the connectionbetween the interface and the given existing database.

Inspect Inspect is another term of the second term of CRUD (Read). Being able to read (select)information of the database.

— Custom Inspect Custom Inspect is a special way of Inspect. With custom inspect, auser can give some extra constraints on what he/she wants to inspect.

Institute An organization founded for education.

6


Interview Procedure of asking questions concerning the academic competences to the involvedteacher.

MAGNAView MAGNAView is the company which did the visualization so far in the old applica-tion.

Modify Modify is another term of the second term of CRUD (Update). Being able to modify(update) information in the database.

— Custom Modify Custom Modify is a special way of Modify. With custom modify, auser can give some extra constraints on what he/she wants to modify.

Programme A programme is a curriculum for which a student, that follows this curriculum, willget a official academical certificate. A programme will be a bachelor or a master programme.

Propel Propel is a free, open-source (LGPL) object-relational mapping toolkit written in PHP.Propel will be used as a layer to access the existing database.

Questionaires The term questionaires refers to the completed or uncompleted interview (set ofall relevant questions) about the competences for a certain study element. The results willbe given by the (co-)teacher in the application.

Radarplots A radarplot is a graphical method of displaying multivariate data in the form of atwo-dimensional plot of three or more quantitative variables represented on axes startingfrom the same point. The relative position and angle of the axes is typically uninformative(see figure 1.2).

Study Element Study Element is another name for study course or other study-related activity,for which a student can get ECTS.

Teacher The responsible teacher of a Study Element.

URD User Requirements Document.

Visualization With the term visualization is meant the radarplots, histograms and tables.

XML XML (Extensible Markup Language) is a set of rules for encoding documents electronically.

Figure 1.2: Example of a radarplot

7


1.4 List of references

[1] ESA Board for Software Standardization and Control (BSSC). European space agency softwareengineering standards, February 1991.

[2] Tijn Borghuis Loes Mutsaers. Research Protocol - Platform Academic Education, January2007.

1.5 Overview

The remaining part of this document describe ICE in further details. In chapter 2 ICE is generallydiscussed. First we start with a small description of the existing (old) system that ACQA currentlyuses. Then the aspects such as product description, constraints and capabilities are addressed.After this, the characteristics of the users are described as well as the environment of ICE alongwith assumptions and dependencies on it.The third chapter describes the specific requirements which are divided into two categories; ca-pability requirements and constraint requirements. In these categories we will describe what wewill implemented and how. In the third chapter will also be made clear what the priorities of therequirements to be implemented will be.

8


Chapter 2

General description

This chapter describes the environment in which the product will be used and the influence of theenvironment on the product. It does not state specific requirements, but explains and motivatesthe requirements which are specified in the next chapter.

2.1 Product perspective

ACQA already has a functioning web application. This web application is only in use by members ofthe ACQA group. These members fill in the results of the questionaire, retrieved from an interviewwith the teachers, in this web application. This information is saved in xml files. With the useof MAGNAView, members can visualize the results in radarplots and histograms. The results canalso be presented by means of tables. These tables and plots will be reported to the directors ofeducation of the investigated faculty. ICE will replace the existing web application. ICE willbasically contain the same functionality as the old application (A definition of this functionalitycan be found in chapter 3), but with some new features. The new web application will be usedby teachers, directors of education, the ACQAnauts and members of ACQA. Without the helpof ACQA they can login at ICE and do their tasks as defined in 2.4. For ICE, the services ofMAGNAView will not be used anymore. Plots will be generated by the new application itself.

In the following summary the motivation of a new application is given. The structure of the newapplication is shown in figure 2.1. The motivation aspects are:

• For maintenance purposes, the customer wants to switch from xml files to a database.

• The current web application is not flexible. ACQA has to do all the process steps bythemselves. Therefore a web interface should be developed where both ACQA and theircustomers can perform their tasks accordingly to their granted permissions.

• New features will be added.

• Become independent from MAGNAView for the visualization.

As one can see in figure 2.1, we will introduce a dashboard from which the user can reach all thetools that are available within the application. Besides the tools that already were available in theold application we will introduce an administration tool where the administrators can edit the user

9


Figure 2.1: Structure of ICE

accounts via a web interface. We will also introduce a configuration tool where it will be possibleto create new study elements and their dimension ladders. Another change in the application willbe done on the server side of the application where a database will be used instead of xml files.

2.2 General capabilities

ICE will contain the capabilities described below in order to provide a new web user interfaces forteachers, directors of education, administrator and ACQA members for viewing and editing theresults of the questionaires. All the information will be maintained in a database.

2.2.1 System administration

Administration of the system involves managing user accounts. Managing is done by adding,removing and editing users. A system administrator is a user with the capabilities mentioned insection 3.2.6 and is an employee of ACQA.

2.2.2 Information manipulation

Configuration

In order to organize the results of the questionaires for the given competences, ICE will keeptrack of the structures (Curriculae, programmes and study elements) within a academic institute.

10


These structures will change over time. That is why the application must have the possibilityto manipulate these structures. Here will also be chosen which user can see which part of thestructure.

Questionaires

The main task of the application is to gather information about the distribution of areas ofcompetence, competences and dimensions within a certain curriculum. To achieve this, teacherswill input their results to the application. Details about what is actually contained within thesequestionaires can be found in 3.2.2.

2.2.3 Views

The gathered information can be converted into usable views. These views can be made of anysubset of study elements that a user is linked to. These views consist of tables and visualizationsfor different meaningful aspects for the subset of study elements. More details about what exactlyis being viewed can be found in 3.2.3.

2.2.4 Security and users

It is required for users to authenticate on login. A table with user rights can be found in section2.4. User restrictions are necessary in order to keep users from changing or reading informationthey are not allowed to. a user will only be able to perform actions as allowed by the rights givento them in the aforementioned tables. Unless an action is mentioned in a specific requirement inchapter 3, a user will not be permitted to perform it.

2.3 General constraints

• ICE should be easily maintainable and extendable. The methods used to program ICEshould achieve this. We will implicitly assume this aspect but we will not test it.

• ICE has to use the existing database (see Appendix A.1). This database is made withPropel. Accessing the database will be done via the Propel layer.

• It is decided that the application and commentary in the code will be in English, but, dueto legal restrictions, the text in the reports should be in English OR Dutch (Choice will bemade by the user within the application).

2.4 User characteristics

In this section we will give an overview of the specific users within ICE.

The system defines the following roles for users:

11


• Teacher of a study element.

• Co-Teacher of a study element.

• Director of Education of a academic institute.

• ACQANaut

• Administrator

Each of these roles will grant permission to a fixed set of tasks on database entities that occurwithin the system. The database entities that occur within the system are the following. For moredetails about these elements we refer to the list of definitions 1.3.

• Curriculum: An arbitrary selection of Study Elements.

• Discipline: A discipline is a branch of science which is taught and researched at the collegeor university level.

• Institute: The academic institute for which the data (Relevant to the user) will be kept bythe application

• Programme: A programme is a curriculum for which a student, that follows this curriculum,will get an official academical certificate. A programme will be a bachelor or a masterprogramme.

• Person: A person that is affected somehow to data within the application.

• Study Element: Study Element is another name for study course or other study-relatedactivity.

The system defines the following access permissions:

• Create: Create is the first term of CRUD. Being able to create (insert) new information intothe database.

• Delete: Delete is the fourth term of CRUD. Being able to delete (remove) information fromthe database.

• Inspect: Inspect is another term for the second term of CRUD (Read). Being able to read(select) information from the database.

• Custom Inspect: Custom Inspect is a special way of Inspect. With custom inspect, a usercan give some extra constraints on what he/she wants to inspect.

• Modify: Modify is another term of the second term of CRUD (Update). Being able tomodify (update) information from the database.

• Custom Modify: Custom Modify is a special way of Modify. With custom modify, a usercan give some extra constraints on what he/she wants to modify.

The users do not all have the same rights. The CRUD-matrix in table 2.1 defines the rights ofthe users.In the matrix, teachers, co-teachers, Director of Education, ACQANaut, Administrator are userroles. Whereas Curriculum, Study Element, Programme, Person, Discipline and Institute aredatabase entities. Purpose of the table is to indicate how user rights are distributed.

12


Table 2.1: User rightsTeacher Co-Teacher Director of Edu-

cationACQANaut Administrator

Curriculum CreateDeleteInspectCustom InspectModifyCustom Modify

CreateDeleteInspectCustom InspectModifyCustom Modify




Study Element InspectModify

Inspect CreateDeleteInspectModify


Programme CreateDeleteInspectModify


Person Inspect Inspect CreateDeleteInspectModify


Discipline CreateInspectModify

Institute CreateInspectModify

2.5 Environment description

ICE is a stand-alone application and doesn’t interact with other applications. The applicationwill be executed from a web browser. ICE will only support W3C compliant browsers 1. We willexplicitly check for proper functioning. The environment is also visualized in figure 2.1.

2.6 Assumptions and dependencies

The following assumptions and dependencies were made when drawing up the specific require-ments:

• The rights for all the different user types will remain fixed. Therefore, there will be no userinterface to modify the rights and the user types.

• The way questionaires will be set up and filled in will remain fixed. The application will notprovide functionality to modify this procedure.

• The application will make use of an existing database. The relational structure of thisdatabase will be provided by ACQA in due time.

1http://www.w3.org/standards/agents/browsers

13

http://www.w3.org/standards/agents/browsers


Chapter 3

Specific requirements

In this chapter we state the specific requirements for ICE. We have categorized our requirementsaccording to the distinct actions a user can do within the system. When we mention that a usercan do a specific action, we implicitly mean that the user has the rights to do so, as indicated inthe rights table of section 2.4.

For prioritizing the specific requirements for ICE, we will adhere to the MoSCoW method. Thismethod helps us to establish the importance of each user requirement. The capital letters inMoSCoW stand for:

Must have: These requirements are essential for the product.

Should have: These requirements are not critical for the product to work, but are nearly asimportant as the must haves, meaning they must be implemented if at all possible.

Could have: Requirements which are not critical to the products success. If they can be imple-mented with little development costs, they can increase customer satisfaction.

Would have: These requirements will not be implemented in this project. However, they wouldbe nice to have in future versions of the product.

In the following paragraphs we will first mention the actors in the application. Then we willmention the requirements divided into two categories: capability and constraint requirements.At both the categories, subcategories are introduced which correspond with important parts ofProject ICE. Each requirement is identified by an identifier, followed with a description and atthe end at each requirement we will also mention one of the above four properties to clarify thepriority of each of them.

3.1 Actors

The actors in the application are specified in section 2.4.

14


3.2 Capability requirements

In this section we will state all the capability requirements. Capability requirements resemble allthe functions that the application is supposed to have. Next, a list of requirements is given thatapplies to the application in general.

UCR1 must haveThe user interface can be accessed via a web browser (see section 2.5).

UCR2 must haveUser can log out from the application and regains the possibility to log back in again with aregistered account.

UCR3 must haveDatabase will always be consistent.

UCR4 must haveLabels and buttons are available in English.

UCR5 should haveThere is a central point (dashbord) from which the user can access all available functionality.

UCR6 should haveThe viewing and editing of the data is clearly separated in the user interface.

UCR7 should haveWhen user logs in with incorrect data, the user will be redirected back to the login screen wherea message with the error that login has failed due to incorrect data.

UCR8 should haveData is stored as soon as database consistency after storing can be guaranteed.

UCR9 could haveLabels and buttons are available in Dutch.

UCR10 could haveA log will be generated for all the activity within the application.

UCR11 could haveUser can return to the dashboard tool at all times, when logged in.

UCR12 could haveThe web application will remember entered data in the current session.

3.2.1 User rights

The following list of user requirements is applicable on the enforcement of the user rights asdefined in 2.1.

UCR13 must haveA user has to log on for any actions assigned tot his/her account to become available.

UCR14 must haveA user can only perform explicitly allowed actions, as defined in section 2.4.

15


3.2.2 Input tool

The Input Tool is used for entering data gathered from an ACQA questionaire. Members fromACQA interview all teachers from a certain programme about their courses. For each studyelement they teach, teachers are asked which competence areas are addressed in the element,and how the study load of the element is distributed over the addressed areas. Within each ofthese areas, they are asked which separate competences from this area they teach and assess inthe study element, and on what level (Bachelor or Master as defined in “Criteria for AcademicBachelors and Masters Curricula”). In addition, teachers are asked which of the four dimensions,analytic, synthetic, abstract and concrete, apply for their study elements. For each applicabledimension, they are asked to identify the levels of the dimension ladder that occur in the studyelement, and a time distribution over the identified levels. All these results are filled in for eachStudy Element and each Teacher. They are subsequently submitted to the ICE server which thenupdates the database with the information contained within the questionaire. The exact protocolfor doing interviews is given in [2].

In the following, the requirements for the Input Tool are given. Each list of requirements willresemble one phase of the input process where one aspect of the questionaire will be highlighted.The following requirements apply to the complete process:

UCR15 should haveThe user will be notified if entered information is incomplete or incorrect.

UCR16 would haveWhen session will end suddenly, without finishing the input procedure, data will not be lost(Except for page that was not submitted.)

.

General information

In this phase of the process, the user provides general information about the relevant study element.

UCR17 must haveThe user can select the study element for which the questionaire will be filled in.

UCR18 must haveThe user can set study element keywords.

UCR19 must haveThe user can set the responsible lecturer for a study element.

UCR20 must haveThe user can set involved lecturers for a study element.

UCR21 must haveThe user can set the faculty for a study element.

UCR22 must haveThe user can set the study load (ECTS) for a study element.

UCR23 must haveThe user can set which study year(s) apply (in bachelor and/or master) for a study element.

16


UCR24 must haveThe user can modify database entities according to the CRUD matrix. (see table 2.1).

Dimensions

In this phase of the process, the user provides scores on several steps for each dimension that isrelevant for the given study element.

UCR25 must haveThe user can select the dimension ladders that occur for a selected element (analytic, synthetic,abstract and concrete) or mark them N.A. (Not Applicable).

UCR26 must haveFor each dimension ladder the user can rate, in percentage, a number of steps.

Competences

In this phase of the process, the user provides for each area of competence, the competences thatapply for the given study element.

UCR27 must haveThe user can fill in the seven areas of competences (area of competence, see section 1.3).

UCR28 must haveFor each competence area the user can fill in minimal and maximal study load (in percentage).

UCR29 must haveFor each competence area, the user can agree with a number of competences (as describedbelow).

UCR30 must haveFor each competence the user can indicate whether attention is paid to this competence or not(at bachelor or master level).

UCR31 must haveFor each competence the user can indicate whether this competence is examinated or not (atbachelor or master level).

Additional information

The user provides additional information about the set-up of a study element.

UCR32 must haveThe user can indicate whether education is individual and/or group oriented.

UCR33 must haveThe user can indicate whether examination is individual and/or group oriented.

UCR34 must haveThe user can indicate the level of influence from the student on education (low, middle orhigh).

17


UCR35 must haveThe user can indicate the level of influence from the student on examination (low, middle orhigh).

UCR36 must haveThe user can indicate the level of intrinsic involvement on education (low, middle or high).

UCR37 must haveThe user can indicate the level of intrinsic involvement on examination (low, middle or high).

UCR38 must haveThe user can indicate the repeatability of education (content, form, none).

UCR39 must haveThe user can indicate the repeatability of examination (content, form, none).

UCR40 must haveThe user can indicate whether the form of a study element resembles practice.

UCR41 must haveThe user can indicate whether the form of an examination resembles practice.

UCR42 must haveThe user can indicate whether the education is scheduled or not.

UCR43 must haveThe user can indicate whether the examination is scheduled or not.

UCR44 must haveThe user can indicate whether education is within university and/or elsewhere.

UCR45 must haveThe user can indicate whether examination is within university and/or elsewhere.

UCR46 must haveThe user can indicate whether education is research and/or design oriented.

UCR47 must haveThe user can indicate whether examination is research and/or design oriented.

UCR48 must haveThe user can indicate the prevailing component of education (max. 2 elements of knowledge,skill and attitude).

UCR49 must haveThe user can indicate the prevailing component of examination (max. 2 elements of knowledge,skill and attitude).

3.2.3 Visualization

The user must be able to see the results of the questionaires that were filled in. That is why avisualization tool must be implemented in the application. Next, a list of requirements follows,that apply to the complete visualization tool.

UCR50 must haveWhen the visualization tool is started an overview of available study elements will be given(Code, Name, ECTS).

UCR51 must haveUser can manually select and deselect study elements that are presented.

18


UCR52 must haveWhen the user has selected a group of study-elements he is able to start generating plots ortables.

UCR53 must havePlots will always be accompanied with consistent caption.

UCR54 should haveFor all study elements shown, it is clear whether they match chosen criteria.

UCR55 should haveUser is able to print the curriculum over which the plot is made on the plot.

UCR56 should haveThe text in a plot will never overlap other text.

UCR57 should haveUser is able to copy the selection of study elements as strings to the clipboard.

UCR58 should haveThe user is able to load and select a previously stored curriculum.

UCR59 could haveWhen data has changed in the newly loaded curriculum, the user will be notified about this.

UCR60 could haveUser can select/deselect all study elements with one click on a button.

UCR61 could haveListed study elements can be sorted by Code, Name, ECTS, Curriculum and Programme.

UCR62 could haveWhen a user has made a selection of study elements the number of ECTS and whether itconcerns bachelor/master study elements will be displayed.

Searching criteria

To view data, the user must be able to select a subset of study elements that he/she wantsto visualize. This can be done by selecting study elements manually (as described in the lastrequirement list), and also with a searching function to filter only those study elements thatmatch the given criteria. Next, a list of requirements is given, which implements these searchingcriteria.

UCR63 must haveSelection based on basic information of a study element (name, code, faculty, year of study,teacher, description, staff, ECTS).

UCR64 must haveSelection based on dimension scoring of a study element (based on a predefined dimensionladder).

UCR65 must haveSelection based on study load with respect to a certain competence area.

UCR66 must haveSelection based on area of competence research of a study element (reformulate, attention,research plan, abstraction levels, interdisciplinarity, volatility, valuation, contribution).

UCR67 must have

19


Selection based on area of competence design of a study element (reformulate, creativity, draft,abstraction levels, interdisciplinarity, volatility, integrate, design decisions).

UCR68 must haveSelection based on area of competence science of a study element (lifelong learning, systematicapproach, models, understanding science, understanding scientific practice, documenting).

UCR69 must haveSelection based on area of competence intellectual basis of a study element (reflection, reason-ing, modes of reasoning, critical, data handling, stance, basic numerical skills).

UCR70 must haveSelection based on area of competence communication of a study element (written commu-nication, oral communication, second language, debate, professional conduct, project work,multi-team, team roles).

UCR71 must haveSelection based on area of competence context of a study element (development history, socialconsequences, environmental, ethical standards, professionalism).

UCR72 must haveSelection based on other properties of a study element (degree in which review and educa-tion applies to group size, influence, involvement, repeatability, practice, university scheduled,research oriented, dominant component).

UCR73 must haveSelection based on area of competence capabilities of a study element (knowledge, structure,formation, interpretation, experimentation, decision making, assumptions, by learning).

UCR74 should haveUser input fields for search criteria are provided with a label with the unit, or allow the user toselect one of the possible values.

UCR75 could haveUser input for search criteria is type-checked.

Curriculum management

Once the user has selected a subset of study elements, the user should be able to store this subsetas a so-called curriculum, for later use within the application.

UCR76 must haveStudy elements can be added to a curriculum.

UCR77 must haveStudy elements can be removed from a curriculum.

UCR78 must haveA curriculum can be created with a name and a description.

Radarplot

One of the aspects that can be generated from the selected curriculum are radarplots that containinformation about the selected curriculum. Next, a list of requirements is given, for everythingthat the radarplots should be able to display.

20


UCR79 must haveRadarplots can be labeled in Dutch and in English.

UCR80 must haveRadarplots can be generated for the active curriculum.

UCR81 must haveOnce a radarplot is shown, the user should gets a menu to navigate to another plot or to goback to the active curriculum.

UCR82 must haveUser can normalize the radarplot.

UCR83 must haveUser can generate radarplots with distribution of studyload (ECTS) over the basic competenceareas for the selected subset of study elements.

UCR84 must haveUser can generate radarplots with the distribution of studyload (ECTS) over the competences,within one competence area, for a selected subset of study elements.

UCR85 must haveNumber of ECTS and name of competence area is shown on each axis.

UCR86 must haveUser can save the currently shown plot.

UCR87 should haveUser can select the competence area that is shown.

UCR88 should haveText within the plots (axis and value) can be enabled and disabled.

UCR89 could haveUser can set the axis scale of the plots manually.

UCR90 could haveUser can set the axis scale of the plots with autoscale.

UCR91 could haveUser can save an overview of all available plots.

UCR92 could haveUser can print the currently shown plot.

UCR93 could haveUser can print an overview of all available plots.

UCR94 could haveA help menu will appear with relevant information about the made plots at all times.

UCR95 would haveRadarplots are labeled using i18n.

Histogram

One of the aspects that can be generated from the selected curriculum are the histograms thatcontain information about the selected curriculum. Next, a list of requirements is given, foreverything that the histograms should display.

UCR96 must have

21


A histogram can be labeled in Dutch and in English.

UCR97 must haveA histogram can be generated for the selected subset of all available study elements.

UCR98 must haveOnce a histogram is shown, the user should gets a menu to navigate to another plot or to goback to the active curriculum.

UCR99 must haveUser can make histograms where the scores of the dimension ladders are shown for the activecurriculum.

UCR100 must haveUser can make a histogram with a percentage on every span within the relevant dimensions forthe active curriculum.

UCR101 must haveUser can make the choice between showing the histograms for the master study elements,bachelor study elements or a combination.

UCR102 must haveUser can make histograms with ECTS spent on relevant competences within a competencearea for the active curriculum.

UCR103 must haveUser can save the currently shown histogram.

UCR104 could haveText within the histogram (axis and value) can be enabled and disabled.

UCR105 could haveUser can set the axis scale of the histograms manually.

UCR106 could haveUser can set the axis scale of the histograms with autoscale.

UCR107 could haveUser can save an overview of all available histograms.

UCR108 could haveUser can print the currently shown histogram.

UCR109 could haveUser can print an overview of all available histograms.

UCR110 could haveHelp menu will appear with relevant information about the made plots at all times.

UCR111 could haveUser can select a subset of visualized competence areas.

UCR112 would haveHovering over a bar of the histogram presents a small overview of all study elements thatcontribute to the value of this bar.

UCR113 would haveEach histogram should be labeled with the dimension name and on each bar of the histogramthe percentage of score should be printed.

UCR114 would haveHovering over a bar of the histogram presents a small overview of all study elements thatcontribute to the value of this bar.

UCR115 would have

22


A histogram is labeled using i18n.

Table

One of the aspects that can be generated from the selected curriculum are the tables that containinformation about the selected curriculum. Next, a list of requirements is given, for everythingthat the tables should contain.

UCR116 must haveA table can be labeled in Dutch and in English.

UCR117 must haveA table can be generated for the active curriculum.

UCR118 must haveThe table will contain an overview all 7 competence areas and their underlaying competences.

UCR119 must haveFor all competences information is given for both the bachelor level and the master level.

UCR120 must haveFor all competences the table should contain the number of contributing study elements.

UCR121 must haveFor all competences the table should contain the number of study elements in which thecompetence is assessed.

UCR122 must haveFor all competences the table should contain the number of all ECTS that are involved.

UCR123 must haveThe study elements over which the table is generated will be shown.

UCR124 must haveThe user will have the possibility to return to the selection phase of the visualization tool.

UCR125 must haveThe user will be able to save newly generated tables.

UCR126 should haveA printout should consist of the table and a list of study elements in the active curriculum.

UCR127 could haveThe user will be able to print newly generated tables.

UCR128 would haveA table is labeled using i18n.

3.2.4 Structure modification

To modify the structure within the academic institute we will introduce a tool where the directorof education can edit the programmes and study elements within his faculty.

23


Study element editing

First of all, the set of study elements will not be fixed over time within a faculty. That is why thedirector of education must be able to edit the set of relevant study elements.

UCR129 must haveA study element can be created with certain properties (name, code, ECTS, institute).

UCR130 must haveA study element can be linked to at least one dimension ladder.

UCR131 must haveDimension ladders can be created.

UCR132 must haveDimension ladders can be deleted.

UCR133 should haveA study element can be deleted.

Programme editing

Besides the study elements, the director of education must be able to set up programmes on hisfaculty.

UCR134 must haveStudy elements can be added to a programme.

UCR135 must haveStudy elements can be removed from a programme.

UCR136 must haveA programme can be created for a institute with properties: name, language, level and director.

UCR137 should haveA programme can be deleted.

3.2.5 Dashboard

In order to reach all the tools in the application, a dashboard will be introduced where the userwill have an overview of all the tools he can reach and he will be able to go to the specified tools.

UCR138 should haveUser can proceed to the specific tools that he has access to.

UCR139 could haveDirect after login, the user will be redirected to the dashboard tool.

UCR140 could haveUser gets an overview of all tools he can access (see rights management).

UCR141 would haveUser can change his password.

UCR142 would have

24


User will get an overview of all the changes that are made by other people in the elements thathe is involved in.

3.2.6 Administration backend

An administration backend will be implemented. In this backend, the administrators of the appli-cation will be able to edit all the user accounts within the application.

UCR143 should haveThe user can create user accounts (contact and user rights).

UCR144 should haveThe user can update user accounts (contact and user rights).

UCR145 should haveThe user can delete user accounts (contact and user rights).

UCR146 could haveOnce the user has created user accounts, the user of the account will be informed by means ofan automatically generated e-mail.

UCR147 could haveOnce the user has updated user accounts, the user of the account will be informed by meansof an automatically generated e-mail.

UCR148 could haveOnce the user has deleted user accounts, the user of the account will be informed by means ofan automatically generated e-mail.

UCR149 would haveThe user can see the log of all activities within the application.

UCR150 would haveThe user is able to filter out certain activities from the log.

UCR151 would haveThe user can log out other users from the administration tool.

UCR152 would haveOnly one user can make use of the administration tool at the time.

3.3 Constraint requirements

Next, a list of requirements is given, that concerns all the predefined constraints for the application.

UCR153 must haveThe user interface is generated using PHP.

UCR154 must haveThe data is stored in a MySQL database.

UCR155 must haveThe application supports concurrent usage up to 100 users at the same time.

UCR156 must haveThe User interface is usable with W3 standards compliant web browsers.

25


UCR157 must haveUse of the database scheme as provided by ACQA.

UCR158 must haveAll visualization is made on the ACACIA client or ICE server.

UCR159 must haveThe database is accessed using the Propel framework.

26


Appendix A

Database model

curriculum

id INT(11)

name VARCHAR(255)

description TEXT

created_at DATETIME

updated_at DATETIME

Indexes

dimension_ladder

id INT(11)

step_1 DECIMAL(10,0)




















created_at DATETIME

dimension_ladder_info_id INT(11)

ladder_collection_id INT(11)

Indexes

dimension_ladder_info

id INT(11)

type VARCHAR(50)

name VARCHAR(255)

step_count INT(11)

Indexes

dimension_ladder_info_i18n

step_1 TEXT

step_2 TEXT

step_3 TEXT

step_4 TEXT

step_5 TEXT

step_6 TEXT

step_7 TEXT

step_8 TEXT

step_9 TEXT

step_10 TEXT

step_11 TEXT

step_12 TEXT

step_13 TEXT

step_14 TEXT

step_15 TEXT

step_16 TEXT

step_17 TEXT

step_18 TEXT

step_19 TEXT

step_20 TEXT

id INT(11)

culture VARCHAR(7)

Indexes

domain

id INT(11)

name VARCHAR(255)

description TEXT

Indexes

institute

id INT(11)

name VARCHAR(255)

city VARCHAR(255)

country VARCHAR(255)

link TEXT

Indexes

institute_programme

id INT(11)

institute_id INT(11)

programme_id INT(11)

Indexes

ladder_collection

id INT(11)

study_element_id INT(11)

type VARCHAR(8)

ladder_collection_info_id INT(11)

created_at DATETIME

Indexes

ladder_collection_info

id INT(11)

domain_id INT(11)

name VARCHAR(255)

Indexes

level

id INT(11)

name VARCHAR(255)

description TEXT

Indexes

permission

id INT(11)

person_id INT(11)

object_type VARCHAR(255)

object_id INT(11)

role VARCHAR(10)

Indexes

person

id INT(11)

username VARCHAR(100)

name VARCHAR(255)

institute_id INT(11)

email VARCHAR(255)

password VARCHAR(32)

root_user TINYINT(4)

Indexes

programme

id INT(11)

name VARCHAR(255)

description TEXT

language VARCHAR(2)

director_id INT(11)

level_id INT(11)

created_at DATETIME

Indexes

study_element

id INT(11)

person_id INT(11)

created_at DATETIME

updated_at DATETIME

course_name VARCHAR(255)

code VARCHAR(100)

contents TEXT

keywords VARCHAR(255)

faculty VARCHAR(255)

study_load DECIMAL(10,0)...

Indexes

study_element_curriculum

id INT(11)


curriculum_id INT(11)

Indexes

study_element_programme

id INT(11)


programme_id INT(11)

Indexes

study_element_teacher

id INT(11)


teacher_id INT(11)

Indexes

Figure A.1: Model of the database that is assumed by our application.

27

user requirements document - tu/emvdbrand/courses/se/0910/urds/urd-aqca.pdfproject manager: sander...

Documents