Software Requirements Specification

Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 2

Versie geschiedenis: Versienummer Datum Auteur Versie 1 19/11/2014 Jo De Neve Versie 2 15/12/2014 Jo De Neve

Contents 1 Inleiding 1 1.1 Doel.................................. 1 1.2 Scope................................. 1 1.3 References............................... 1 1.4 Overzicht............................... 1 2 Algemene beschrijving 1 2.1 Product perspectief.......................... 1 2.2 Product eisen............................. 2 3 Specifieke beschrijving 3 3.1 Externe interfaces.......................... 3 3.2 Functionele eisen........................... 3 3.2.1 Algemeen........................... 3 3.2.2 Guest............................. 4 3.2.3 User.............................. 5 3.3 Niet-functionele eisen......................... 8 3.4 Performantie eisen.......................... 8 3.5 Design constraints.......................... 8 3.6 Software systeem attributen..................... 8 3.7 Andere eisen............................. 9

1 Inleiding 1.1 Doel Het doel van dit document, de Software Requirements Specification, is om een gedetailleerd overzicht te geven aan de klant over de wel en niet functionele eisen van het project PEN versie 2. Voor meer informatie over dit project zie ook het Software Project Management Plan, het Software Test Plan en het Software Design Document. 1.2 Scope PEN is een een webapplicatie die het toelaat om wetenschappelijke publicaties te beheren en raad te plegen. Dit zal nuttig zijn voor studenten en doctoraatstudenten die zich bezig houden met onderzoek om informatie over hun onderwerp naar keuze te kunnen raadplegen. Het moet mogelijk zijn om publicaties up te loaden op verschillende manieren, nl. via het invullen van een formulier, via het uploaden van een BibTex bestand of via extractie van de nodige gegevens uit een PDF-bestand. Ook moet het mogelijk zijn je eigen publicaties te verwijderen. De applicatie kent aan elke publicatie een score toe. Publicaties moeten kunnen worden opgezocht, niet enkel op dit systeem, maar ook gebruikmakende van gelijkaardige systemen zoals bijvoorbeeld Google Scholar, Mendeley,... Het systeem stelt bepaalde papers voor aan een gebruiker a.d.h.v. verzamelde informatie omtrent deze gebruiker. Er kan een sociaal netwerk worden opgebouwd met de papers en gebruikers. Gebruikers kunnen tags en commentaar toevoegen aan papers alsook statistieken consulteren. Tot slot biedt deze applicatie ook ondersteuning voor een mobiele webbrowser. 1.3 References IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, IEEE Computer Society, 1998 1.4 Overzicht Hoofdstuk 2 bevat een overzicht van de algemene requirements en in hoofdstuk 3 zullen deze verder worden geanalyseerd. Er wordt gebruik gemaakt van scenarios om te beschrijven hoe de applicatie moet werken. 2 Algemene beschrijving 2.1 Product perspectief PEN is een open source project voor het beheren en raadplegen van wetenschappelijke publicaties. Het is de bedoeling een gebruiksvriendelijke applicatie 1

te maken waaraan een sociaal netwerk verbonden is. De applicatie maakt gebruik van een Wilma server om data op te slaan. 2.2 Product eisen PEN zal twee types van gebruikers hebben, een wel en een niet geregistreerde gebruiker(respectievelijk een account en een persoon). Beide zullen toegang hebben tot de home pagina, deze bevat algemene informatie en een menu met een aantal knoppen. De eerste is een knop om in te loggen op het systeem a.d.h.v. een gebruikersnaam en een wachtwoord. Hier is ook de optie voor de gebruiker om terug toegang te krijgen tot een account als hij zijn wachtwoord vergeten is. Eenmaal men is ingelogd komt de gebruiker op een nieuwe pagina met een klein overzicht. De indeling van dit overzicht moet nog bepaald worden. Eenmaal de gebruiker is ingelogd, kan hij een publicatie uploaden. Hier kiest de gebruiker voor het toevoegen van een eigen of een andere publicatie. Vervolgens krijgt hij twee keuzes. Zelf volledig de vereiste velden invullen, de nodige informatie laten extraheren uit een PDF of een BibTex. Een tweede knop is de mogelijkheid om te registreren, zowel studenten als doctoraat-studenten kunnen zich registreren. Na het confirmeren van de registratie, kunnen ze ook inloggen op de applicatie. De volgende knop opent een invulformulier met combineerbare zoekcriteria. Hiermee kan een gebruiker publicaties opzoeken, zowel in de eigen database als op gelijkaardige externe systemen. Na het opzoeken krijgt de gebruiker een lijst van zoekresultaten waaruit hij een resultaat kan exporteren in BibTex of tekstformaat. Voor resultaten van een externe bron is het mogelijk deze op te slaan in de applicatie database. Verder kunnen gebruikers ook een publicatie toevoegen. Hiervoor krijgen ze een formulier dat moet worden ingevuld. Na verificatie zal het bestand worden geüpload naar de server en is deze vanaf nu beschikbaar in de applicatie. Het invullen van het formulier kan op twee manieren, namelijk de informatie laten extraheren uit een BibTex of PDF of de informatie zelf invullen. Bij het zelf invullen van het formulier wordt deze zoveel mogelijk aangevuld door de applicatie a.d.h.v een opgegeven account uit het systeem. Als het inloggen of uploaden succesvol is, wordt een succes pagina getoond aan de gebruiker. Als dit niet het geval is wordt een error pagina getoond. In beide gevallen kan de gebruiker op een knop klikken om terug naar de home pagina te gaan. Als laatste kan een ingelogde gebruiker zijn gegevens en instellingen wijzigen. Dit doet hij door op de overeenkomstige knop te klikken. Voor het wijzigen van zijn gegevens zal er een formulier verschijnen die gelijkaardig is aan het formulier om te registreren. De instellingen in de eerste iteratie zullen bestaan uit het wijzigen van de taal en het verwijderen van een account. Voor het wijzigen van de taal wordt een cookie opgeslagen bij de klant zodat bij het volgende bezoek de keuze van de klant kan worden opgevraagd. 2

3 Specifieke beschrijving 3.1 Externe interfaces Een Wilma server met een database die alle data zal bijhouden. 3.2 Functionele eisen 3.2.1 Algemeen De volgende vereisten gelden voor beide types van gebruikers. Functional requirement 1.1 ID=AFR1 Titel: Opzoeken van papers Beschrijving: Opzoeken van papers gebaseerd op een invulformulier met combineerbare zoekcriteria in de eigen database of op het internet. Hiervoor zullen volgende sites gecontacteerd worden: 1. http://scholar.google.be 2. http://dl.acm.org 3. http://mendeley.com 4. http://ieeexplore.ieee.org De gevonden gegevens worden weergegeven en hieruit kan de gebruiker kiezen welke hij wil laten exporteren naar een BibTex of tekstformaat. Scenario: Een gebruiker klikt op de search tab en krijgt een aantal velden, het invulformulier. Door het formulier zo goed mogelijk in te vullen en uiteindelijk op een knop te klikken zal er een lijst van resultaten worden weergegeven op basis van dit formulier. Een gebruiker kan een zoekresultaat uit de applicatie database exporteren in BibTex of in tekstformaat door op de overeenkomstige knop te klikken. Resultaat: Een lijst van zoekresultaten. Functional requirement 1.2 ID=AFR2 Titel: Downloaden van een publicatie Beschrijving: Een gebruiker kan na het opzoeken een publicatie downloaden. Prerequisite: De gebruiker heeft een lijst van zoekresultaten. Scenario: De gebruiker kan kiezen om een resultaat te downloaden in BibTex of tekstformaat. Hiervoor drukt de gebruiker op de overeenkomstige knop. Resultaat: De publicatie is gedownload. 3

Functional requirement 1.3 ID=AFR3 Titel: Taal veranderen Beschrijving: Een gebruiker kan de taal van de website veranderen. Scenario: Een gebruiker wilt de taal veranderen en doet dit door op de overeenkomstige knop te klikken in de menu balk. Eenmaal een account een taal veranderd heeft, zal dit opgeslagen worden. Zo wordt, bij zijn volgende aanmelding, de site in de juiste taal gedisplayed. Resultaat: De taal is veranderd. Functional requirement 1.4 ID=AFR4 Titel: Wachtwoord vergeten beschrijving: Als een gebruiker zijn wachtwoord vergeten is, kan hij een nieuw wachtwoord aanmaken. Scenario: Een gebruiker klikt op de log-in tab, maar hij kent zijn wachtwoord niet meer. Hij heeft dan de keuze om een e-mail te sturen naar zijn account. In deze e-mail staat een link naar een pagina waar de gebruiker zijn wachtwoord kan veranderen. Eenmaal bevestigd is het wachtwoord voor het overeenkomstige account gewijzigd. Resultaat: Een account met een gewijzigd wachtwoord. 3.2.2 Guest De volgende vereisten gelden voor niet ingelogde gebruikers. Functional requirement 2.1 ID=GFR1 Titel: Register Beschrijving: De gebruiker zal de nodige informatie moeten opgeven voor het aanmaken van een profiel. (naam, voornaam, wachtwoord, e-mail, affiliatie) Scenario: Een gebruiker klikt op de registreren tab en krijgt bijgevolg een formulier. Door op een knop te drukken zal er een mail verstuurd worden naar het opgegeven e-mail adres. Na bevestiging heeft de gebruiker succesvol een account aangemaakt en kan hij vanaf nu inloggen met zijn e-mail en wachtwoord. Uitzonderingen: Een verplicht veld leeg laten is niet toegelaten: een gebruiker kan zich niet registreren als hij een verplicht veld leeglaat. Het kader rond het verplicht veld zal rood worden en een berich zal verschijnen dat dit wel degelijk een verplicht veld is. Opgegeven informatie is niet geldig: een bericht, met de error, zal naast het veld met de foute informatie verschijnen. Resultaat: Gebruiker is geregistreerd. 4

Functional requirement 2.2 ID=GFR2 Titel: Log in Beschrijving: Gegeven een correcte gebruikersnaam en wachtwoord, zal de gebruiker worden ingelogd met de nodige rechten. prerequisite: De gebruiker heeft een profiel. Scenario: Een gebruiker klikt op de log-in tab en bijgevolg zal het log in scherm zichtbaar zijn waar hij zijn gegevens kan invullen en kan bevestigen door op een knop te klikken. Gegeven correcte informatie zal de overeenkomstige account pagina getoond worden. Uitzonderingen: Ingevoerde informatie is verkeerd. Een pop-up zal verschijnen voor de klant met een bericht dat zijn wachtwoord of gebruikersnaam verkeerd is. Resultaat: Gebruiker is ingelogd. 3.2.3 User Functional requirement 3.1 ID=UFR1 Titel: log uit beschrijving: Een gebruiker kan uitloggen. prerequisite: Gebruiker is ingelogd. Scenario: Door op de knop te klikken wordt de gebruiker uitgelogd en de homepagina zal worden gedisplayed. Resultaat: Gebruiker is uitgelogd. Functional requirement 3.2 ID=UFR2 Titel: toevoegen van een paper beschrijving: Een gebruiker kan een paper uploaden, zodat deze beschikbaar wordt in de applicatie. Een formulier bevat volgende velden: 1. type 2. titel 3. auteurs 4. titel van proceedings of journal 5. (proceedings) editors 6. (proceedings) naam uitgever 7. (proceedings) stad 8. (journal) volume 9. (journal) nummer 10. aantal pagina s 11. jaar 5

12. URL 13. keywords Scenario: Een gebruiker kiest voor het toevoegen van een eigen of een andere publicatie. Vervolgens krijgt hij drie keuzes. Zelf volledig de vereiste velden invullen, de nodige informatie laten extraheren uit een PDF of een BibTex. Bij het eerste worden de velden zoveel mogelijk aangevuld door de applicatie op basis van een account (toevoegen aan een andere gebruiker). Uiteindelijk zal, door het klikken op een knop, de publicatie worden upgeload. Uitzondering: Een verplicht veld leeglaten is niet toegelaten: als de gebruiker een verplicht veld vergeet in te vullen, zal er een bericht verschijnen da hij dit veld moet invullen alvorens te kunnen uploaden. De paper is al beschikbaar op de server: als een gebruiker een paper wil toevoegen dat al in de database zit, zal het uploaden falen. Resultaat: Een paper is toegevoegd. Functional requirement 3.3 ID=UFR3 Titel: informatie extraheren Beschrijving: Informatie laten extraheren uit een PDF of BibTex. Scenario: Een gebruiker kiest om informatie te laten extraheren uit een bestand(een PDF of BibTex). Het bestand wordt gepload en de applicatie zal zoveel mogelijk informatie extraheren uit het opgegeven bestand. Uitzondering: Niet ondersteund bestandsformaat: informatie kan enkel gextraheerd worden uit bestandstypen die ondersteund worden door de applicatie. Resultaat: Een lijst van gextraheerde informatie. Functional requirement 3.4 ID=UFR4 Titel: aanvullen van velden Beschrijving: informatie aanvullen door middel van een opgegeven account. Scenario: Een gebruiker kiest om de velden zelf aan te vullen en krijgt bijgevolg een formulier dat hij moet invullen. Dit formulier wordt aangevuld door de applicatie alvorens de gebruiker zelf verbeteringen of aanvullingen kan toevogen. De informatie wordt uit een bestaand account gehaald. Resultaat: Een lijst van informatie. Functional requirement 3.5 ID=UFR5 Titel: verwijderen van een eigen publicatie Beschrijving: Een gebruiker kan een publicatie verwijderen zodat deze niet meer beschikbaar is. Scenario: Als een gebruiker een eigen publicatie wil verwijderen, selecteert hij de publicatie en klikt op verwijderen. De applicatie zal vragen voor bevesteging van de gebruiker en, als deze akkoord gaat, wordt de publicatie verwijderd. Resultaat: De publicatie is verwijderd. 6

Functional requirement 3.6 ID=UFR6 Titel: applicatie instellingen veranderen Beschrijving: een gebruiker kan de standaard instellingen van de applicatie veranderen. Scenario: Een gebruiker kan eventueel na registratie zijn instellingen veranderen. Dit doet hij door op een tab te klikken en een nieuwe pagina zal openen waarin de gebruiker zijn instellingen kan aanpassen. Deze worden weggeschreven als de gebruiker op het einde zijn veranderingen bevestigt door op de overeenkomstige knop te klikken. Resultaat: Een account met gewijzigde instellingen. Functional requirement 3.7 ID=UFR7 Titel: Voorstel om publicatie toe te voegen Beschrijving: Een gebruiker die zich voor het eerst aanmeld op ons systeem, krijgt een voorstel om een publicatie toe te voegen. prerequisite: De gebruiker meldt zich voor de eerste keer aan. Scenario: Een gebruiker meldt zich voor de eerste keer aan en krijgt de mogelijkheid om eigen publicaties toe te voegen aan het systeem. Hij heeft ook de keuze om dit te annuleren en direct door te gaan naar de accountpagina. Resultaat: De gebruiker heeft al dan niet een publicatie toegevoegd. Functional requirement 3.8 ID=UFR8 Titel: persoonlijke gegevens veranderen Beschrijving: Een account kan zijn persoonlijke gegevens veranderen zoals zijn affiliatie, e-mail addres,... Scenario: Een gebruiker drukt op een knop en zal vervolgens op een pagina komen waar hij zijn gegevens kan aanpassen. Hij kan de veranderingen bevestigen door op de overeenkomstige knop te klikken. Resultaat: De gegevens zijn permanent gewijzigd en opgeslagen in de applicatie. Functional requirement 3.9 ID=UFR9 Titel: Account verwijderen Beschrijving: Een gebruiker kan zijn account verwijderen. Scenario: Een gebruiker klikt op de knop voor het verwijderen van zijn account. Er komt een bericht om te bevestigen en eenmaal bevestigd, is het account verwijderd. Resultaat: Het account bestaat niet meer. Functional requirement 3.10 ID=UFR10 Titel: Automatisch inloggen Beschrijving: Een gebruiker kan zich automatisch inloggen als hij terugkomt naar de website. prerequisite: De gebruiker moet al eens zijn ingelogd op het systeem. 7

3.3 Niet-functionele eisen Non Functional requirement 1.1 ID=NFR1 Titel: Hashen van wachtwoorden Beschrijving: Wachtwoorden in de database worden opgeslagen met behulp van een hash. Non Functional requirement 1.2 ID=NFR2 Titel: Session management Beschrijving: Elke gebruiker krijgt een eigen sessie id zodat bij het verlaten van de applicatie alle gegevens i.v.m. de huidige sessie verwijderd kunnen worden. Non Functional requirement 1.3 ID=NFR3 Titel: tabs Beschrijving: een menu Scenario: Een gebruiker klikt op een tab in het menu en de applicatie stuurt de gebruiker naar de correcte pagina. Resultaat: De juiste pagina wordt gedisplayed. 3.4 Performantie eisen Geen vooropgestelde eisen voor dit project, maar we hebben wel als doel het project zo performant mogelijk te maken. 3.5 Design constraints De applicatie moet een responsieve design hebben zodat ze kan draaien op een android browser. De source code moet, voor zowel server als client side, geschreven worden in Javascript. Er mag ook alleen open source software gebruikt worden. 3.6 Software systeem attributen betrouwbaarheid De applicatie moet werken zoals ze hoort te werken op elk moment. Bijvoorbeeld bij het opzoeken van een paper verwachten we dat het de resultaten teruggeeft die horen bij de opgegeven zoekterm. beschikbaarheid De applicatie is beschikbaar voor de gebruiker als ze toegang hebben tot een webbrowser. Aangezien het werkt met een externe server, kan de beschikbaarheid niet gegarandeerd worden. We verwachten dat de applicatie meer dan 98 procent van de tijd beschikbaar is, hierbij nemen we het netwerk falen niet in overweging. 8

veiligheid Berichten tussen de client en server die gevoelige informatie, zoals gebruikersnamen en wachtwoorden, bevatten, worden geencrypteerd. Ook kunnen gebruikers niet inloggen met verkeerde log-in informatie. Er zal dan een bericht worden getoond dat het inloggen faalt. Verder is de database beschermd tegen sql-injecties. draagbaarheid De applicatie is beschikbaar op elke browser die het uitvoeren van javascript toelaat. 3.7 Andere eisen De applicatie moet minstens beschikbaar zijn in twee talen. We hebben gekozen voor het Nederlands en het Engels. 9