Icke funktionella krav

Bildskärmslayouter - Se bilaga Språkmatris

- Skapa en språkmatris där alla ord som används i layouterna finns tillgängliga och översatta till alla utvalda språk.

- Svarstiden mellan bild byten vid ankomstregistreringen ska ske> 1 sekund efter att man har fyllt i information som krävs på den bilden man är på.

Storlek och färger

- Storleken ska bestämmas enligt hur mycket utrymme man behöver för en standard touch display.

Detta för att enkelt kunna mata in information med fingrarna och tillräckligt med utrymme mellan bokstäverna.

- Färgerna ska bestå av samma färger som ankomstregistreringen i receptionen. Dvs. flesta färgerna ska bestå av vit, svart och grå.

Två terminaler

- Två displayer ska finnas tillgängliga att registrera sig på när man kommer in i stugan. I samma station ska det finnas en skrivare för att tillhandahålla lastningslista och köranvisningar. Syftet med två är att undvika långa köer och ifall en blir ur funktion ska den andra vara tillgänglig tills den som ej fungerar är reparerad.

Printer med stort pappersfack, a4

- Inuti pulpeten ska det finnas utrymme som är tillräckligt stor för en printer. Printerns storlek ska vara beroende av att den kan innehålla ett stort pappersfack för att minska antalet gånger besök det behövs fylla på med papper.

Touch screen

- Ett tangentbord ska finnas tillgänglig hela tiden på nedre delen av rutan. När man trycker på den raden man vill ska skrivmarkeringen som blinkar dyka upp och då kan man knappa in sin information genom touch-tangentbordet.

- Ändra språk på tangentbordet?

Tangentbord som kommer upp och ned och knapp som kan döljas med en knapp.

Förenklad användning

- Systemet ska innehålla ca 12 olika språk som är valbara från början av ankomstregistreringen.

Detta för att underlätta registreringen åt chaufförerna som kan fullfölja alla steg smidigare med sitt eget språk.

- Det ska vara enkelt för chaufförerna att följa stegen, det innebär undvika mycket text på layouterna och visa simpla layouter.

Kapacitet

- När 12 bilar är inne i produktionen ska man få vänta på sin tur tills det finns ledig plats.

- Varje chaufför kan ha flera avgångsnummer vilket innebär att systemet ska kunna klara av flera Reservrutiner

- Vid olycksfall som resulterar till ett ej fungerande terminal på något sätt ska det vara möjligt att använda tidigare rutiner. Det betyder att vakten återtar ansvaret med manuell registrering av chaufförer åtminstone tills systemet är reparerat och fullt fungerande.

Display

- Blinkning av registreringsnumret av den stora displayen utanför stugan, för att tydligt visa vem som står på tur.

Finnas tillräckligt med plats att visa flera bilar samtidigt

3.5 Testspecifikation

När systemen är konstruerade och redo att testas behövs det en ett sätt som används för att validera bygget. Eftersom systemet inte hann implementeras fick det göras i en labbmiljö istället vilket ändå är bra för som det har nämnts tidigare är det bäst att undvika implementering av hårdvara innan det är säkert allting fungerar som det ska. För det så behövdes det ett utrymme i företaget som har stöd för systemtest. Dem funktioner som skulle testas är främst dem nya implementeringarna som förklaras var för sig hur dem ska testas och hur det gick till enligt bilagorna för testspecifkationerna. Dessa är:

Portkod:

Ett nytt portkodssystem skulle implementeras till truckstoppet. Utmaningen var att kommunicera den på ett smidigt sätt till chaufförerna som inte ska behöva åka/ringa till vakten för att ta reda på siffrorna. Den nya dosan ska registrera dem nya portkoderna som kommuniceras från Ellen, efter att giltighetstiden är slut ska koderna vara ogiltiga.

Ankomstregistreringen:

Kravet på ankomstregistreringen är att den ska innehålla 12 olika språk för chaufförerna.

Dessutom för att ankomstregistreringen ska vara giltig behövs det att registreringsnumret för bil och (optionellt) släp ska kunna fyllas I. Avgångsnummer ska kontrolleras både först av systemet om den existerar, sedan ska chauffören få information om lasten för att kontrollera att den stämmer. Säkerhetsåtgärder ska finnas med som skanning av körkort och verifikationstext att man läst och förstått reglerna som gäller inom SSAB.

Utskrift:

Efter att ankomstregistreringen är klar ska skrivaren testköras också. Där ska man säkerställa att rätt lastlista skrivs ut till chauffören samt att en streckkod tillkommer för att komma igenom vakten. Karta ska vara tillgängligt att skrivas ut vid begäran vilket innehåller köranvisningar både till produktionen och inom.

Display:

Detta test gäller för displayerna som ska användas I detta projekt. Två små displayer ska

monteras innanför stugan, den ena ska ha ett bildspel där säkerhetsinformationen visas. Den ska hela tiden vara igång och hela bildspelet ska inte ta längre tid än några minuter. Den andra displayen bredvid ska visa köinformationen, bl.a. antal bilar inne i produktionen och statusen på lastningen. En sista display ska monteras utanför truckstoppet som är tänkt att vara större än dem andra två för att visa vems tur det är att åka in. Den har till uppgift att blinka registreringsnumret som kommuniceras från Proview för att visa chauffören att det är dags.

4. Diskussion

För att lyckas med projektet var uppgiften att utforma en systemlösning för att skapa ett kösystem som inkommande lastbilar kan använda sig av. Detta för att undvika bildning av kö utanför SSAB som är potentiellt farligt. Målet som beskrevs innan är att reda på och utforma kravspecifikationerna samt processbeskrivningar som behövdes för att projektet ska utföras så smidigt som möjligt. Dessa krav ska sen både verifieras och valideras vilket är en stor del av projektet för att kunna ta reda på från början om projektgruppen missat något eller om en funktion behöver konstrueras om.

Verktygen som valdes att beskriva systemet med var Use-case diagram i UML. Anledningen till att den valdes gentemot andra verktyg är att den visar vilka aktörer som påverkar systemet vilket kan vara båda interna och externa. Vilket passade det här systembygget bra eftersom i det här fallet interagerar både system och personer. Sedan för att beskriva framtida systemlösning användes Activity based diagram. Den beskrev smidigt och effektivt hur processen kommer att se ut när den är implementerad.

Genom att ha strukturerat arbetat fram kravspecifikation kunde de redan tidigt i projektets gång reducera möjligheten till misstag genom validering av processen. Det som märktes är en

förbättrad kommunikation mellan projektmedlemmarna vilket ledde till samarbete inom

konstruering av systemen. Eftersom när samtliga projektmedlemmar kunde förstå systemen blev det enklare att integrera systemen mot varandra.

Det som behövdes när kravspecikationerna skrevs är en genomgång med samtliga inblandade.

Enligt Sommerville skulle det ta lång tid att

Däremot det som händer är att projektet tar längre tid än väntat när problem dyker upp som måste tas itu med. Eftersom systemen inte hann implementeras blev den enda möjligheten att validera systemet någorlunda genom att bygga en labbmiljö där simulering av systembygget kunde ske inom vissa funktioner. Ett exempel på funktion som projektet hade planerat innan var att använda avgångsnumret som portkod till truckstopet. Detta för att kommunicera ut koden mycket enklare till chaufförer som blandar ihop alla olika siffror som finns i informationslistan.

Men när det upptäcktes att dosan endast kunde hantera 4 siffrig sifferkombination och kunde endast hantera ett visst antal portkoder fick kraven ändras.

Tyvärr kunde inte acceptanstesterna utföras på systemet p.g.a. att den inte hann byggas färdigt.

Därför är det svårt att veta om den verkligen hade bra nytta eller inte men det positiva är ändå att dessa användes vid labbsimulering som vägledning på hur systemet ska fungera.

Ibland kan det uppstå frågetecken kring huruvida viktigt det är med kravspecifikations process.

Både medlemmar och projektledaren kan försöka tvinga fram en snabb lösning och försöka implementera det direkt för att få snabba resultat. Detta leder vanligtvis till mer skada än nytta.

För att bedöma om projektet var lyckat eller inte behövdes det svaras på flera frågor, som: ”Hur dessa verktyg påverkade projektet?”, ”kunde andra verktyg användas för att få ett bättre

resultat?” etc. Till en början märktes det att både viktiga och mindre viktiga detaljer upptäcktes när processkarta, Use-case diagram och rutinbeskrivningarna användes. Detta gjorde att projektet kunde utföras smidigare under uppstarts fasen. Men eftersom projektet inte hann bli klart i tid blev det uppenbart att det fanns brister som det märktes av under projektets gång.

5. REFERENSER

[1] Sommerville, I. (2011). Software engineering (9. ed., International ed.). Harlow: Addison-Wesley.

[2]Jiang, L., Eberlein, A., & Far, B. (2008). A case study validation of a knowledge-based approach for

the selection of requirements engineering techniques. Requirements Engineering, 13(2), 117-146.

[3]Jiang L, Eberlein A, Far BH (2005) Combining requirements engineering techniques—

theory and case study. In: ECBS 12th IEEE international conference on the engineering of computerbased systems, Greenbelt, April 2005

[4] Adams, K. (2015). Non-functional Requirements in Systems Analysis and Design (Topics in Safety, Risk, Reliability and Quality). Cham: Springer International Publishing.

[5] Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Systems engineering principles and practice (2nd ed.). Hoboken: Wiley.

[6] Buede, D. M. (2000). The engineering design of systems: Models and methods. New York:

Wiley.

[7] Adams, K. (2015). Non-functional Requirements in Systems Analysis and Design (Topics in Safety, Risk, Reliability and Quality). Cham: Springer International Publishing.

[8] ISO/IEC/IEEE 21450:2010(E). (2010). IEEE.

[9] Proview Team (2013), Fakta om Proview, http://www.proview.se/

[10] Douglass, B. P. (2006). Real Time UML Workshop for Embedded Systems. Elsevier Science .

[11] Holt, J. (2004). UML for Systems Engineering: watching the wheels (2nd Edition). London, United Kingdom: Sciencedirect.

[12] Jon, S. (2001). Troubled IT Projects Prevention and Turnaround. London: The institution of

BILAGA A: EXTRA INFORMATION