Software Requirements Specification
for
Thesis Management System
Version 1.0 approved
Prepared by
28/04/2020
- Table of Contents
1.Introduction 3
1.1 Purpose 3
1.2 Document Conventions 3
1.3 Intended Audience and Reading Suggestions 3
1.4 Project Scope 4
1.5 References 4
2.Overall Description 4
2.1 Product Perspective 5
2.2 Product Features 5
2.2.1 Post advertisement 5
2.2.2 Project selection 5
2.2.3 Process management 5
2.2.4 Interface with external application 6
2.3 User Classes and Characteristics 6
2.3.1 Visitor 6
2.3.2 Academics 6
2.3.3 Staff 6
2.3.4 Supervisors 7
2.3.5 Students 7
2.3.6 College 7
2.3.7 Topic coordinator 7
2.4 Operating Environment 8
2.5 Design and Implementation Constraints 8
2.6 User Documentation 8
2.7 Assumptions and Dependencies 8
3.Specific System Requirements 8
3.1 Visitors 8
3.1.1 Post advertisement 9
3.1.2 Project selection 9
3.1.3 Process Management 9
3.1.4 Interface with external application 9
3.2 Academics 10
3.2.1 Project selection 10
3.2.2 Process Management 10
3.2.3 Interface with external application 10
3.3 Staff 11
3.3.1 Post advertisement 11
3.3.2 Process management 11
3.3.3 Interface with external application 11
3.4 Supervisor 11
3.4.1 Project selection 11
3.4.2 Process management 12
3.5 Students 12
3.5.1 Project selection 12
3.5.2 Process management 13
3.5.3 Interface with external application 13
3.6 Topic coordinator 13
3.6.1 Process management 13
3.7 College 15
3.7.1 Interface with external application 15
4.External Interface Requirements 15
4.1 User Interfaces 15
4.2 Hardware Interfaces 16
4.3 Software Interfaces 16
4.4 Communications Interfaces 16
5.Other Non-functional Requirements 16
5.1 Performance Requirements 16
5.2 Safety Requirements 17
5.3 Security Requirements 17
5.4 Software Quality Attributes 18
6.Other Requirements 18
7.Reflection 19
8.Appendix A: Glossary 19
9.Appendix B: Analysis Models 20
9.1 Use Case for Visitor 21
9.2 Use Case for Academic 22
9.3 Use Case for Staff 23
9.4 Use Case for Supervisor 24
9.5 Use Case for Student 25
9.6 Use Case for Topic Coordinator 26
9.7 Use Case for College 27
9.8 Data flow diagram for Visitor 28
9.10 Data flow diagram for Student 29
9.11 Data flow diagram for Academic 30
9.12 Data flow diagram for Supervisor 31
9.13 Data flow diagram for College 32
9.14 Data flow diagram for Topic Coordinator 33
9.15 Data flow diagram for Staff 33
9.17 Data flow diagram for the software interface 35
10.Appendix C: Issues List 36
11.Appendix D: Elicitation Report 36
12.Appendix E: Team Meeting Minutes / Reflective Log 37
Revision History
| Name | Date | Reason for Changes | Version |
| Linglin | 15/05/2020 | Adding the Section 4 | |
| Linglin | 16/05/202 | Adding the Section 1,5,6,7,and appendix A, |
- Introduction
- Purpose
The purpose of this specification is to capture the requirements of enabling flinders teaching and student alumni to use a Thesis Management System effectively. Requirements include efficiency, quality of features, reliability, thoroughness of system and legal procedures.
- Document Conventions
| Particulars | Font Type | Font Size |
| Main heading | Arial | 32 |
| Subheading | Arial | 18 |
| Body | Arial | 11 |
FLO – Flinders Online Learning
CLIT – Educational Quality, learning and teaching teams
SRS – Software requirement Specification
Syllabus – Content covered through the course of a particular subject
SAS – Student Association System
RMS – Research Management System
TMS – Thesis Management System
- Intended Audience and Reading Suggestions
This document is written to make understandability of this software as straightforward as possible towards, developer, users and document writers as well as teaching staff and students. Also, the system specification covers topics of overall description, system features, functionality, non-functional requirements, glossary, external interface requirements and any additional requirements for this software.
- Project Scope
The objective of this software system is to support Flinders University in compiling and choosing topics for thesis assessments for staff and students. Through the repertoire of the University, the software for the will allow efficient ways to suggest projects and thesis areas. Additionally, this software will be student-friendly by allowing students to pick their thesis area as well as supervisors for their assignment. Through this software, topic coordinators will be given the functionality of choosing their timings for poster presentations, examinations and schedule seminars with efficiency and reliability.
- References
Admin, S., 2019. Software Requirement Specification (SRS). [online] Software Testing Class. Available at: <https://www.softwaretestingclass.com/software-requirement-specification-srs/> [Accessed 15 May 2020].
Creately Templates, 2020. Creately Templates. [online] Online e-Learning System- Data Flow Diagram. Available at: <https://creately.com/diagram/example/inl5hu5f3/Online+e+-+Learning+System+-+Data+Flow+Diagram> [Accessed 15 May 2020].
Translation, D., 2020. What Does Online Systems Mean?. [online] Definitions.net. Available at: <https://www.definitions.net/definition/online+systems> [Accessed 2 May 2020].
University, F., 2009. FLO: [online] Flo.flinders.edu.au. Available at: https://flo.flinders.edu.au/my/> [Accessed 8 May 2020].
UNSW Sydney, 2020. UNSW Sydney. [online] Create and Manage Assignments in Moodle. Available at: <https://teaching.unsw.edu.au/moodle-assignments> [Accessed 15 May 2020].
Visual Paradigm, 2020. Visual Paradigm. [online] Logical vs Physical Data Flow Diagrams. Available at: <https://www.visual-paradigm.com/guide/data-flow-diagram/logical-vs-physical-data-flow-diagrams> [Accessed 15 May 2020].
- Overall Description
- Product Perspective
It is a component of a university-wide system belong to a online system. The system called Thesis Management System. There are 4 part to combine it including post advertisement, project selection, process management, interface with external application. The user types include college, topic coordinator, staff, supervisors, academics, visitors and students. The system is managed by the topic coordinator, college. And for academics, they have limited access. It can be accessed by a university-wide system homepage. This system will leverage existing functionality from Student Two, Syllabus +, FLO and wiki to obtain the system’s functional assistance. (see below figure)
college
- Product Features
- Post advertisement
This module provides advertisement functions, this primarily suggest the project/thesis areas/titles to visitors. And for the management, allow supervisors including the uploading, modification, previewing, publish and deleting of advertisements.
- Project selection
This module allows students to select and be nominated and for the development and assessment of the thesis to be managed end to end. Management includes previewing, viewing, selecting and searching the certain project with wiki. Every single project provides their current SAM and feedback area with message area. When the fresh project uploads the selection draft file, that will be via to potential the process management directly
- This function can only support the key staff access publish forum, including Dean(Education), Topic Coordinators.
- Process management
This function gives more timely turnaround to improve the administrative efficiencies. Supervisors and students experience timely and meaningful feedback.
- This module provides schedule seminars, poster presentations, and examinations on a cohort and non- cohort basis. Manage the process of assessment including: thesis submission, examiner selection (including external examiners), reminders, amendments to thesis, signoff, grade determination, data and thesis retention.
- The project happens! Sometimes the project title and description gets amended in this module.
- The project files can be sent on the message area. The file format include the ZIP, PDF, Words.
- There is a function can support schedule seminars, poster presentations, and examination
- This module provides thesis submission, examiner selection, reminders, amendments to thesis, signoff, grade determination, and data and thesis retention.
- Interface with external application
This module provides the interface to assistant the thesis management system.
- Providing the interface with FLO and use the student systems as appropriate.
- Users can be though interface access the subsystem to modify and upload the content of post advertisement module. According to this module, user can access the maintain and monitor to protect the system running.
- Searching with wiki.
- Allow student access the students system
- User Classes and Characteristics
- Visitor
Those who have not registered in the website. Visitor has limited access, only viewing, to the post advertisement module.
- Academics
Academics supervise multiple but they will be limited by the time constraints sometimes. Thus they can only take just one student.
- Staff
Staff do not frequently use this system and they only have a few duties to do on this system. But they can not access the process management. And they can not submit any data on the project selection.
- Professional staff who use Thesis Management System to maintain and monitor the system to keep it running well.
- They can preview the content of suggested project and they can suggest project / thesis areas / titles to be advertised to students
- Supervisors
- Supervisors can use a single cohesive system on the project selection function to have a meaningful feedback with students.
- They are able to advise projects. As the project which students selected, once they have agreed with students, they can send the message on the process management. Let the topic coordinator know the details and any key dates.
- Students
They can use their FLO account or email address to enter their login and press ‘next’. They utilize the system frequently to do somethings including previewing and viewing the project, select and submitting project. Students do exactly one project.
- Students can access the simple and more streamlined process for selecting, managing, and grading coursework theses.
- Students only can use the thesis submission on the project selection. They can select a project and allow the potential supervisor to accept that nomination.
- Students can access the wiki and read through the projects on the project selection and interface with external application.
- College
College manage this system. Different college can use cross-over of some projects with other college. College and CILT only can require delete and publish the content of project on this system. They will use the system to make a decision about the examiner selection (including external examiners).
- Topic coordinator
At regular intervals, the topic coordinator uses this system, there is a fair bit of work for the Topic
Coordinator to get all this together. They need to call for thesis ideas and adjust the project list. And they will discuss with CILT about the examiner selection (including external examiners)
- Topic coordinator will impose a limit to share the load around.
- Topic coordinator can slip the student list and project task to supervisor
- Using the process module to obtain the project detail which have agreed by students and potential supervisor.
- They can schedule seminars, poster presentations, and examinations on a cohort and non-cohort basis (as examiners return assessments in an ad-hoc manner).
- The grade determination is evaluated by topic coordinator and thesis supervisor.
- Data and thesis retention should be arranged by topic coordinator
- Interface with FLO and the student system as appropriate
- Operating Environment
- Hardware: IBM R6
- JVM version 1.8.4
- Windows, MacOS, Linux
- Design and Implementation Constraints
- At this stage it is difficult to estimate the cost of a full solution
- The interface of security may result slow response.
- Some projects require Australia Security Clearance for example.
- Programming language: Java, JSP, and HTML are used to all web components.
- User Documentation
- TMS Tutorial
- TMS Manual
- Online trouble shooting service
- Assumptions and Dependencies
This system allowed the people who do not register preview the content of major function but this system is a University- wide system, only the register can access the function. If individuals who are not register access this system, this system will output the error message to the visitor. As for the security function, if people who not have a privilege to access this system try to access into it, the staff who maintain the system will receive the warning notice and the staff can block access to the user through the system.
- Specific System Requirements
Seven types of users and thirty-four distinct use cases are included in this SRS, indicating the possible situations that may happen in this TMS use case diagram and data flow diagram are provided in Appendix B.
- Visitors
A visitor is someone who accesses to the website but not yet registered and logged in. A visitor is only provided with limited functions. As for this kind of users are less important belong to secondary user. Visitors click the TSM button on the university homepage. The visitor enters a
page of Thesis Management System. They can preview the all of the functions.
- Post advertisement
Actor – Visitor
Type – Essential, Secondary
Description – This use case happens when the visitor wants to access the Post advertisement. This visitor can click the post advertisement and then they view the detail about the content of suggest projects including the titles and thesis and some suggested projects which will be highlight. They can view the category which are listed by the college name. But they are able to view the suggested project. They can click the More search and enter the wiki page to search the title or some key word for the project they interested. They can download the project.
- Project selection
Actor – Visitor
Type – Essential, Secondary
Description – This use case happens when the staff want to access the Project selection. This visitor can view the project selection function. They can view the category which are listed by the college name. They can select the project to view the content. They can download the project. But they could not access the selection. Because this function only offers to the register who are students. And then, if user can access the more search button to jump to the wiki and then they can search the information with title ,key words, and thesis.
- Process Management
Actor – Visitor
Type – Essential, Secondary
Description – This use case happens when the visitor wants to access the Process Management. Visitor only can preview the project selection module. All of the functions allow user who have already registered access it.
- Interface with external application
Actor – Visitor
Type – Essential, Secondary
Description – This use case happens when the visitor wants to access the system. User can use the wiki research the project which does not include in this function. However, the other 4 modules have a special work for the key college staff and students.
- Academics
Academics supervise is someone who has already registered by the FLO account and password. This user can access more function. As for this kind of users are slightly important belong to secondary user. Use case 3.1.1 also work on academics when they enter the system. To reduce redundancy, only distinct use cases are listed.
- Project selection
Actor – Academic
Type – Essential, Primary
Description – This use case begins when this user accesses the project selection. It has a same way with use case 3.1.1. This user will be treated as a visitor before logging in. They can view the category which are listed by the college name. After this user log in the system, they enter the selection module and then they can open the student’s project draft file. They can access the message area make the feedback and conversation with students.
- Process Management
Actor – Academic
Type – Essential, Primary
Description – This use case happens when the academic wants to access Process Management. They can preview the content of this function module. The title category list was based on the college name. User can fast find their college and click it to select the topic coordinator which are they belong to. After they click the topic coordinator, they need to log in to the system with their FLO account. Then, they can check the task area from the topic coordinator and use the message area to make conversation with the topic coordinator. All the messages in the message module could be kept, searched, and deleted in the message area by the academic.
- Interface with external application
Actor – Academic
Type – Essential, Primary
Description –This use case begins when academic access the system. When academic enter the system, they can access the research management system, wiki, and FLO. The student systems only support to the students. The security only offers to the college staff who maintain system.
- Staff
Staff has a special privilege of the TMS by managing and maintain the system running. But some of function was limited by the role which they play. Use case 3.1.1 and 3.1.2 also work on staff when they enter the system. To reduce redundancy, only distinct use cases are listed
- Post advertisement
Actor – Staff
Type – Essential, Primary
Description – This use case begins when the staff enter this system. As for the module, staff can suggest project/thesis areas / title to be advertised in the forum function to students. They can access more search jump to the wiki page.
- Process management
Actor – Staff
Type – Secondary
Description – This use case happens when the staff enter the TMS. This system support to function same with use case 3.1.1.
- Interface with external application
Actor – Staff
Type – Essential, Primary
Description – This use case happens when the staff want to access the system. Staff can access some functions including wiki, security. Before staff access security function, they can type staff ID number and password to log in and then jump to the new page. Because this function is a subsystem to support TMS to keep running normally. All of the category name in the subsystem are named by the function of TMS. When something goes wrong with the TMS, staff can select the category name to access this function, this subsystem support the modify module which include 4 kinds functions of TMS. This modify module appears the error programming code and them the staff can check and find the error code to modify.
- Supervisor
Supervisor has a high privilege in this system function. Use case 3.1.1 and 3.2.3 also work on supervisor when they enter the system. To reduce redundancy, only distinct use cases are listed.
- Project selection
Actor – Supervisor
Type – Essential, Primary
Description – This use case begins when the supervisor tries to access the system. This function could provide the message area which is a timely and meaningful feedback from the supervisor and students. User can view the SAM. They can access the thesis submission and view the project which upload by the students. When user need to send the project to Topic Coordinator, this user can download the project
- Process management
Actor – Supervisor
Type – Essential, Primary
Description – This use case begins when the supervisor accesses the process management. The supervisor can follow the category listed by the college name to find the label of the topic coordinator. When user enter themself topic coordinator page, they click the task module to check the task and make the conversation in the message area. They need to send the detail of the project which uploads by the supervisor’s student via the topic coordinator on the message area. User can send the project files on the message area. The file format include the ZIP, PDF, Words.
- Students
Students are frequently to access this TMS. This system supports the special privilege in this system. Use case 3.1.1 also work on students when they enter the system. To reduce redundancy, only distinct use cases are listed.
- Project selection
Actor – Student
Type – Essential, Primary
Description – This use case happens when the students want to access the system. Student can preview, view, and download all the project on the project selection. Students can choose projects according to the classification of the course. When they select the project as their task, they can click to selection button. At the same time, student need to use their FLO account or email address to log in. After that, they can view the SAM with potential supervisor information.
This system can provide the message area to students and supervisors, students can receive the feedback and make conversation with supervisor.
- Process management
Actor – Student
Type – Essential, Primary
Description- This use case begins when the students want to access the process management. Student can access the thesis submission and upload the draft of project in here. After student, supervisor and topic coordinator have agreed the project, student can publish the project on the thesis submission. And this user can check the feedback about the project, thesis, and assignment. And they can make a conversation in message area.
- Interface with external application
Actor – Students
Type – Essential, Primary
Description – This use case happens when the user accesses the system. They can access research management system, FLO, and student systems with their FLO account and password.
- Topic coordinator
The topic coordinator has a high privilege in this system. At regular intervals, the topic coordinator calls for thesis ideas. There is a huge of work for the Topic Coordinator to get all this together. Use case 3.1.1 and 3.4.1 also work on students when they enter the system. To reduce redundancy, only distinct use cases are listed.
- Process management
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case happens when the user accesses process management. This user can preview and view the category list by college name. Before user select the college’ name enter to the topic coordinator list, they need to use their FLO account and password to log in. And then, user can click the topic coordinator’s name. Then, this user can view the task, message forum, and assessment management.
- Task
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case begins when the user accesses the topic coordinator. After the user log in the system with their FLO account and password. They can click the task and select the supervisor name from the supervisor list and then edit the task. The user can schedule seminars, poster presentations. After finish user can click the publish button to submit the content. They can delete the content of task on task.
- Message forum
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case begins when the user accesses the topic coordinator. After the user logs in, They can click the message forum and select the supervisor name from the supervisor list and then edit, send and delete the message in different time. This system will automatically save the message. And use can send the message to academic and supervisor on the message forum.
- Thesis submission, amendments to thesis, grade determination
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case happens when the user accesses the thesis submission. This user can view the project file which already submitted project file (including thesis). When the user selects the thesis file and click the editor button, user can amend the thesis. And then user click the grade determination button and give the thesis grade. this user marks the thesis author and potential supervisor of project to view the above information.
- Examiner selection
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case begins when the user accesses the examiner selection. Topic coordinator can click the editor button and put the examiner list file into the editor box. And then user publish the examiner list in this function. The examiner list file can be spreadsheet, pdf., jpg. User can delete the list.
- Data and Thesis retention
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case begins when the user accesses the Data and Thesis retention. Once the topic coordinator, project author and supervisor has already done signoff, user can upload the project file to this function. The file type only allows the Zip.
- Signoff
Actor – Topic coordinator
Type – Essential, Primary
Description – This use case begins when the user accesses the signoff. When the topic coordination is examiner, this user enters this function and upload its own signature or use an electronic signature after evaluating the thesis.
- College
The College manage this system. They have the highest decision-making authority. Use case 3.1.1 and 3.6.1 also work on students when they enter the system. To reduce redundancy, only distinct use cases are listed.
- Interface with external application
Actor – College
Type- Essential Primary
Description – This use case begins when the College access the interface with external application. This system allows this user access almost function for key staff across all College. They can access the RSM, wiki, security, and FLO but exclude the student system.
This user can editor the content in Security function after they use their work ID number and password. When they enter Security, this user can view the constructor of major function of this system. This user can modify, add, or delete contents in the sub-directories of the functional area.
- External Interface Requirements
- User Interfaces
In this system the users involve the college, topic coordinator, staffs, supervisor, academics, visitors and students. The two main parties would be the student and the academics classified as a whole under university employees.
In reference to figure 1 in appendix B, it illustrates the data flow between the user interfaces.
The first step in which the student needs to do is access the thesis topic via the system, in this case; FLO. After which most of the communication and submission takes place via FLO. This includes submitting the thesis and receiving comments and marks via FLO.
On the other hand, the university employees also have access to FLO from an academic side. In this case they would be able to download the thesis and mark the it and subsequently upload it back via FLO with the relevant comments and marks. However, through this process, the downloading and uploading the documents will process through a data storage.
Therefore the software component required for this interface is mainly FLO.
- Hardware Interfaces
The physical characteristics of the interface between the software product and the hardware product is firstly a hardware device would be required to access the software. For example, in order to access FLO, a device such as a computer, tablet or mobile phone would be required. Secondly, having an accessible connection speed would allow FLO to be loaded onto the device’s screen. However, in order to upload the thesis, only acceptable files such as pdf or word is accepted. Therefore, in most cases, a device that has these file formats would be needed.
The logical interface would be that the all user uses a device to access FLO and all communication including uploading the thesis and marking the thesis is done via FLO.
- Software Interfaces
As mentioned above, the main users would be the students and university employees. Therefore, with reference to figure 2 in appendix B, it depicts the data flow diagram between the interaction of the users and the software.
The main software here are the research management system where the student will access to retrieve the library database and any peer reviewed articles. Wikis are another platform whereby the topic coordinator can interact with the students. An example of this is the use of Collaborate where a virtual meeting can be held. Lastly, the student system and FLO are another platform where communication is taken place in a more formal environment as compared to Wikis. Here the thesis would be submitted, and comment and marks would be returned via FLO or the student systems.
Although, in order for the students and the university employees to have access to these software, they must first be registered under the database system. Some of the required details needed include a student ID, their name and a Flinders authentication number (FAN) which is their unique key in order for the system to identify the user.
- Communications Interfaces
As part of a feature in FLO is that with any new announcement or alerts, an email will be sent to notify the user. Apart from those email communication interface, FLO also has an embedded calendar which also acts as a form of communication to the users.
To enhance security, each user must have an account to log in to FLO and through the process of creating an account, the user must have a unique identifier, which in this case is the FAN.
- Other Non-functional Requirements
- Performance Requirements
Non-functional Requirements – Performance Requirements
Performance – how fast the system will run or responds to users’ actions.
Scalability – assesses how the highest workloads of the system will meet the performance requirements.
Portability/Compatibility – the hardware the system is compatible with along with how easy it is to access (Hardware: IBM R6, JVM version 1.8.4, Windows, MacOS, Linux).
- Safety Requirements
Non-functional Requirements – Safety Requirements
Recoverability – data backed up can has the ability to be recovered using Data Integrity.
Data Integrity – the validity, accuracy and consistency of data, backing up data, validation processes stored in the database of the system
- Security Requirements
Non-functional Requirements – Security Requirements
Data Security – Authentication scheme, user must log in using their FLO account or email address to access the system and view, upload, delete work.
Privacy – data encryption and policies regarding transmission of data to 3rd parties.
- Software Quality Attributes
Non-functional Requirements – Software Quality Attributes
Availability – how the system is accessible for users 95% of the time leaving time for maintenance to ensure the system won’t fail. The system is available to students and staff with a FLO account or email address account.
Usability – how easy it is for the user to use the system.
Reliability – how dependable the system is to the users.
Maintainability – time required for a solution or component to be fixed/change to increase the performance and/or adapt to the changing environment of the program.
- Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>
- Reflection
Throughout this assignment, we faced multiple challenges. The greatest of all, collaborating and meeting up with each other. Due to the current restrictions in place, we had the disadvantage of not being able to meet up and discuss the assignment during our assigned tutorial classes and this was the barrier that hindered us from frequent communication.
Nonetheless, we managed to communicate via social media and split up the tasks to get the job completed.
Our contribution are mainly a few sections per person unless the job scope is large. To start off our report, we had Rudra putting together section 1 where the purpose of this report is introduced, and any technical terms defined. Moving on we had Linglin giving an in depth overall description of the product and it’s features as well as the requirements. After which, we had Hui Yu adding on to the external interface requirements and to sum it all up we had Ellie writing about the other non-functional requirements.
In conclusion, we all contributed to this report in some form and eventually we managed to complete the assignment together as a team.
Figure : schedule of the assignment
- Appendix A: Glossary
All terms and explanations were provided in section 1 of the SRS
- Appendix B: Analysis Models
- Use Case for Visitor
- Use Case for Academic
- Use Case for Staff
- Use Case for Supervisor
- Use Case for Student
- Use Case for Topic Coordinator
- Use Case for College
- Data flow diagram for Visitor
- Data flow diagram for Student
- Data flow diagram for Academic
- Data flow diagram for Supervisor
- Data flow diagram for College
- Data flow diagram for Topic Coordinator
- Data flow diagram for Staff
- Data flow diagram for the user interface
- Data flow diagram for the software interface
- Appendix C: Issues List
In the development of this software, developer will face many problems. First, without proper project environment infrastructure, the project will be impacted and increase time taken for software to be created. Second, expectation and outcome could be different from SRS, due to the complexity and sheer size of the project. It can over-whelm many developers and create an different outcome for the software than intended. Third quality assurance, without reviewing and checking and rechecking parts of the software completed can create errors later in finished product, like missing thesis assignments or not being able to choose thesis topic or tutors. Lastly security of thesis management software, may need to be improved due other Universities trying copy or make identical software. Security updates will need to be added to improve safety and integrity of software.
- Appendix D: Elicitation Report
Through this SRS, team members used their knowledge and research from online to create this document. With the help of tutors, questions from team members were easily solved.
- Appendix E: Team Meeting Minutes / Reflective Log
The team worked well and hard on this assignment even through this corona virus pandemic. By helping each other and communcating issues we were able to solve any issue which arised. This project was challenging and we all throguhly enjoyed solving the problems. With the help of tutors all questions were solved.
12.1 Meeting Minutes – [LHG02]
Date: 01/05/2020
Time: 30mins
Apologies and Absentees
Agenda Items
- Discuss what constitutes a software system
- Check action item status against last meeting minutes (if applicable)
- How to write the purpose of this product
Action Items
- We based the project broad statement of needs to know the product of purpose.
- We pick of the key word from the document of the project broad statement of needs and then we use it to analyze the content of section one.
12.2 Meeting Minutes – [LHG02]
Date: 07/05/2020
Time: 30mins
Apologies and Absentees
Agenda Items
- Discuss the content of 2.1Product perspective
- Discuss “what kind of system we should definite?” a new or self-contained product.
Action Items
- We based the project broad statement of needs to know the type of system.
- We pick of the key word from the document of the project broad statement of needs and then we use it to analyze
- We slip the system for 4 part: post advertisement; project selection; process management; interface with external application.
- We slip the task for everyone. We keep making discussion anytime.
- Make ourselves assignment deadline (13/05/2020)
Notice: Hui Yu and Linglin try to contact the other group mate to make meeting but it is hard thing after we contact Tutor for helping. Thus, we only have to time to discus our assignment.
The post Thesis Management System appeared first on My Assignment Online.