elton Group 3. Michael Spetås, Lars Brekke, Sondre Wiersdalen and Richard Wangsvik System Requirements & Design (SRD)

Transcription

1 - System Requirements & Design (SRD) 1

2 Glossary ASP.net Framework by Microsoft for creating web forms C# Programming language based on the.net framework Microsoft SQL GUI VS T-SQL UML CSS HTML Microsoft Structured Query Language Graphical User Interface Visual Studio Transact-SQL Unified Modelling Language Cascading Style Sheets HyperText Markup Language 2

3 Contents 1. Introduction System overview GUI graphical user interface User requirements Technical Requirements Functional requirements: The system as a whole Equipment requirements User rights Error reports History of reports GUI Database Non-functional requirements: Architecture Unified Modeling Language Use case Class diagram Sequence diagram

4 1. Introduction The expected readership for this document is the development team itself, customers, and stakeholders. A summary of potential changes made will be listed in the bottom of the document. The main purpose for this system is to be able to register and handle equipment errors. Whether it be industrial equipment, lab equipment, workshop equipment or any other type of equipment in any workplace. This system is not restricted to any business or use, but merely a helpful tool for whoever finds it useful. All businesses utilize equipment in their everyday process for different reasons. The core issue here is that eventually equipment tends to break or otherwise malfunction. Therefore, our system aims to facilitate this process by presenting an organized way to document and handle flawed equipment. 2. System overview The system is meant to categorize and handle the errors accordingly in a database, and notifies the person responsible depending on the category of the equipment. When users are reporting malfunctioning equipment, they must write the identification tag of the equipment, give a description that may help the repairman, and choose an urgency rating for the equipment to be fixed. A work list containing equipment in need of fixing (with reported errors) will be available for users with the necessary clearance. This is greatly beneficial for the repairman, seeing as he could prioritize, fix, set status, add information/solution, etc. The system will include statistics. It will be possible to review how many reports has been made for a specific equipment identification tag, different locations, etc. All information regarding a specific error or equipment ID/name will be stored within a database. This is mandatory as it will vastly improve the functionality of the software. Using a database will also allow for the user to view the history of specific equipment at their leisure. Being able to view all the reports for a specific component or equipment, series of an equipment or even whole categories can help decrease the 4

5 repair time as it might give a clue for what is wrong or where the fault lies. It will also reveal equipment with an unusual amount of errors. We have also considered the possibility that some users will require higher authorization than others. For instance, the people responsible for the different categories or sub groups of equipment will require higher clearance. On the other hand, a worker will not necessarily need to mark errors as fixed, or perhaps delete registered errors. Admins and repairmen will be able to add a solution. They should also be able to edit/set the urgency of the error. A flowchart showing the process of the software is described in Figure Flowchart describing the use of the software. Figure Flowchart describing the use of the software 5

6 2.1 GUI graphical user interface During the early brainstorm process, this draft was created of the GUI. See Figure 2-2 GUI Draft. Figure 2-2 GUI Draft 3. User requirements The customer requires a system which enables them to register equipment errors. The report will contain a field to fill out the equipment ID, a description and a severity rating. The system notifies the person responsible via , depending on the information filed in the report by the user. A task list is automatically filled out and sorted depending on selected sorting method. The repairmen can change the prioritization, status and add a solution for the equipment on the task list. After an item has been marked as fixed, it will get removed from the not fixed or in progress task list. The system will also contain a log history regarding the registered equipment. As more and more errors are solved, the system enables the repairmen to fix equipment more efficiently, as the error symptoms and solutions for specific equipment are listed. 6

7 The system should be easy to use by the users and the repairmen. The program should be somewhat aesthetically pleasing. Task lists should not be editable by normal users, as they are not responsible for repairing equipment. 4. Technical Requirements In this chapter, technical requirements for the equipment error system are discussed. These requirements are divided into two types. Functional and non-functional requirements. Both types are to be easily tested and are specific to how the system should function and operate. 4.1 Functional requirements: The functional requirements are specific requirements related to the system behaviour that is to be programmed or designed by the developers of this project. For the sake of making the list easy to read and manage when testing, the requirements are divided into groups related to the systems key features The system as a whole Requirements for the entire system or requirements not fitting any of the divided groups following is put here. Every user must log in to operate the system. Every user of the system will be able to report faulty equipment. The system must use a database to store data Equipment requirements For the system to run, the user and server system will require to run on certain software. The user is required to use certain software to access elton: Run a reasonably new version of the web browser such as Google Chrome 26+, Microsoft Edge 38+ or Mozilla Firefox 16+. Run an operating system such as Windows 7, Windows 8 or Windows 10. Other web browsers, operating systems, smart devices and tables might work, but are not exclusively tested for using this software system. 7

8 The server system is also required to run on certain software: A Windows based server operating system such as Windows Server 2016, Windows Server 2012 R2 or Windows Server Microsoft Azure User rights The system is taking use of three user types: normal users, repairmen and admins. A list of requirements related to this is here: Users are divided in normal users, repairmen and admins. Normal users can report errors. Repairmen can report errors as well as view and edit all reports and tasks. Admins can report errors, view and edit all reports and tasks, and edit/add users. Users must follow a short guide that sent via by the system to activate their account and create password, this is to be sent after registration. There can only be one account associated with an at any given point in time Error reports Reported equipment errors are filed as a task in the database for repairmen to view and manage. Error reports are referred to as tasks in this subchapter. Here are the requirements related to this feature: Tasks should contain the equipment s ID, Location, the username of who reported the equipment, and a description with any information that may help the repairmen. The date and time for when the task was reported is also noted. Tasks will be viewable by repairmen and admins. Repairmen and admins can change the status of the task to not finished, in progress or solved. When a task is solved, repairmen can leave a note containing useful information for recycled use. 8

9 4.1.5 History of reports All reports are filed in the database, which is accessible to normal users, repairmen and admins. Here is a list of requirements related to this feature. Users can search for equipment in the database. Normal users can only view data and not edit past reports. The history feature should give the users the possibility to see the previous faults or errors about equipment if there are any GUI For this system, we will use separate web forms windows to solve the issues the requirements present. Having separate windows will allow for us to design our system the way it is intended to our specifications and the user requirements. It will also make the system more intuitive for the user and allow the developers to work on separate parts of the program during development. First and foremost, a home page is required. The home page will include a login section where the user enters their login information. This is a security measure to protect the system, the users and the data stored. It will make sure only people with proper clearance can log in and report issues. This login screen will also include a Forgot Password feature for resetting passwords of users. This will redirect the user to a reset password page. If the credentials check out, you will be logged into the system and introduced to the reporting section of the system. In case the user trying to log in is a first-time user, he/she will be required to go through an activation of the account as well as creating a password. Repairmen or admin will have access to more of the system which will be explained in the next paragraph. This window (report page) will contain radio buttons and textboxes for all the necessary information the user must enter. It will be designed in such a way that it is easy for the user to know how to report faulty equipment. In addition, it will only be possible to create reports about equipment which is already registered in the database, this reduces report time and makes it less repetitive to report equipment, 9

10 as a lot of the information is automatically filled out. The date of the report and the user responsible for reporting the task will be automatically saved in a database. Admins will be able to add equipment into the database system, along with some general information about the specific equipment in a separate web form. If the user who logs in is a repairman or admin, he/she will be greeted with a different page. This page will contain information and features otherwise unavailable to the normal user. These features will include tables and editing of the current tasks at hand. We have also considered the possibility that a supervisor or a repairman might need to report something themselves at times. This conundrum will be solved by adding a button or a feature on the website that they can click on to be sent to the reporting window of the system. There will be a window specifically made for viewing history of equipment errors. The idea here is that the user can browse the history of whatever equipment they re interested in knowing the history of, by searching for the equipment ID or other. This window will be made available by all users of the system. Admins will also be able to access a page that allows them to register users Database Functional requirements related to the database and what should be stored in the database. Functional requirements to the database: The database structure should eliminate redundant data Attributes which is used for searching in the history feature should have its own table. This prevents writing mistakes when registering equipment. The database will store: Equipment type, model name, manufacturer, equipment ID, where it is located and which department it belongs to. Users and passwords in the form of hash and salt. Equipment error reports, filed as tasks. - An equipment error report should contain an equipment ID and a comment that contains any information that could be helpful for the repairman. 10

11 - The responsible person in a department is to be notified every time a report is made, by . The should contain useful information. - Each report is to be filed as a task that administrators/repairmen can view. - All equipment errors along with the report information should be stored and categorized in a database, which is viewable from the application. The solution to the task should also be viewable in this page. - Only admins/repairmen should be able to delete and mark equipment errors as solved. - Users will be categorized as normal users, repairmen and admins. 4.2 Non-functional requirements: The non-functional requirements are requirements that are related to how the system operates. These requirements are also divided in the same manner the functional requirements are divided. User experience: The system should be easily learned. It should not take more than one hour for normal users and two hours for admins to know how to operate the system. With the use of login and protected user passwords the aim is to have a secure database and work platform. 11

12 5. Architecture The architecture of this software is sketched in a simple manner, please see Figure 5-1 Sketch of system architecture. The user will be able to register and view errors and data that is to be stored in an SQL Database. The application is to be built with ASP.NET which is a framework for developing web applications using VS/C#. Figure 5-1 Sketch of system architecture 12

13 The software architecture is based on the thin architecture and uses three tiers. By using the thin architecture, the most demanding processing is done by the server. This makes using the software more lightweight and flexible, it also makes it simpler from a code and design perspective, as the client does not directly access the processing. This should also make it possible to access the program using several different operation systems and web browsers. The three tiers are separated into the following: Presentation tier. Logic tier. Data tier. Presentation tier is what the user accesses using a web browser. This tier is coded in HTML with visual styling from CSS. The logic tier is where most of the processing happens, this tier is server side and coded in C# ASP.NET. The data tier is mainly where data is stored, but it also contains some logic. This tier is hosted server side in SQL and coded in T-SQL. A visual presentation of the software architecture can be seen in Chapter 5. Architecture. 13

14 Figure 5-2 Software architecture 14

15 6. Unified Modeling Language This chapter contains documents and diagrams describing the software modeling. The purpose of UML is to plan and visualize the software design in advance, before programming. By using this approach, the developer will spend less time wondering how something works, or how to organize the code. This enables the developer to spend more time on effective development by programming more. 6.1 Use case The use case shows a high overview of the users relation to the different components in the software system. In this way, use cases create a better understanding of the system for all parts involved. Simple and repetitive actions such as redirections to other pages have been left out of these. As the web application is divided into several pages that serve specific purposes, we ve made use case diagrams for the following pages: Login page Tasks page Report page Equipment registration page User registration page The use case diagrams can be seen below in the same order. 15

16 Figure 6-1 Use case, login page Figure Tasks Page 16

17 Figure Report Page Figure Equipment registration 17

18 6.2 Class diagram The class diagram shows the classes used in the system, the methods they contain, the variables, properties, and the association between the classes. This helps visualizing how the system is divided and makes it easier to separate tasks and sub tasks within the software development process. See class diagram, Figure 6-5 Class diagram. Figure 6-5 Class diagram Most of the actions the software does are involving the database in some way. Therefore, all the classes are associated with the class SQLHandler. SQLHandler is a general-purpose class for communicating with the database, so most of the classes use an object of this class. Both the Task and Equipment class are to extract individual tasks/equipment and add tasks/equipment to the database. 18

19 6.3 Sequence diagram The sequence diagram shows what order different objects interact with another. This helps the software developers see an order based overview of how the systems sub tasks should work. Based on this overview the software developers will easier know how to proceed during the development process. Please see the sequence diagrams in the figures below. Figure 6-6 Sequence diagram, login page 19

20 Figure 6-7 Sequence diagram, tasks page Figure 6-8 Sequence diagram, report page 20

21 Figure 6-9 Sequence diagram, Equipment Registration 21