NFR Type	Requirements	Implications on Design and/or operation
Example Availability	· The solution will be accessed by users during business hours and outside of business hours. · The system must be available up and running 24/7 * 365. In all cases, availability should be at least equal to 0.999 ·	Possible solution or workaround

Scalability	·	Possible solution or workaround ·

5. System Design

5.1. Solution Concept

<<example> The major solution concept for solution is having it built and deployed as a web-based application. etc

5.2. Proposed System Architecture

<< proposed architecture>>

5.2.3 etc

Which alternative your team has chosen and why? Performance, cost, simplicity , other factors

5.2.4 Production and Staging Environments

Example << explain if you need this staging environment or not >>

5.3. Component Design

The system will consists of << off-the-shelf hardware component>> <<custom components>> self developed << explain>>

5.3

5.3.2 Software Components

5.3.2.1 User Interface – Web client

· Based on the system requirements listed in the previous sections, we present the system use case diagram as shown in Figure x

Figure 5 Use-Case Diagram

For each of the identified use cases, we provide, in Table 3, a more detailed description. Use case description shows how users will interact with the solution. It describes, from a user’s point of view, the solution’s behavior as it responds to user requests.

Table 3 System Use Case Description

5.3.2.3. Back-End Database

Does the system use a back-end database, file system explain and provide the required data models

4.4. Design Evaluation

Table 4 shows a comparison between the On-Cloud Option and the On-Site Option

Where do you want to host your system << on-cloud vs on-site and why>>

Table 4 Comparing On-Cloud and On-Site Options

6. Implementation

In order to facilitate the understanding of the system that contains several major components, we start with high level architecture. The source code for this project is provided in Appendix C.

6.1 System Implemented Architecture

Figure 7 shows the major components of the system.

Figure 7 High Level Implementation Architecture

6.1

6.1.1

6.2 Access Levels

6.2

6.3

6.1.

The solution pays attention to security. The solution categories the users into << how many>> different categories.

<< explain >>.

Figure 14 Security Domains Access Levels

6.3 System Services or Functionalities

<<Provide snapshots and explain>>

7. Testing, Analysis and Evaluation

7.1 Testing Methodology

<< the following is an example of a testing methodology you can use your own>>

Our team has developed the test plan shown in Appendix A. We have built acceptance test scenarios for the system features that we have already identified in the project design phase. For each feature, we have provided the test description and expected outcome for all of the success and alternate scenarios. After we completed the development phase, the test plan is executed. We record and resolve each test outcome for each test case.

· Target System: <<your system>>

· Features and functions:

· Test approach: .

· Key process: if bugs are discovered we will

· Bookkeeping and Documentation: We are going to use .

· Test Schedule:

· Exit criteria: The test will be considered complete

7.2 System Analysis and Evaluation

<< how to test non-functional requirements>>

7.3 Test Execution and Test Results

The execution performed according to the already identified methodology and carried against the test plan.

<<provide details about results>>

7.3.1 Integration Testing

After modular testing, we moved to the integration testing.

<< explain how you performed integration testing>>

7.3.2 Functional Testing

<< provide examples on function testing>>

We identified the features of the system in the design document so we have went through each feature to make sure it is already satisfied by the delivered solution. The functional testing used manual exploratory testing in which we run each required scenario and evaluate the results.

7.4 Examples on testing

7.4.1 Check password Strength

<< this might be an example of testing password strength>>

The system is programmed to check for password strength. We have decided to have the password strength fair; that is being longer than 8 characters.

Figure 59 Password Complexity

8. Issues, Engineering Tools and Standards

8.1. Issues

<<We have faced several issues during the design and development of this project. We list three examples on these issues.>>

8.2. Engineering Tools and Standards

<<this is an example: Explain about your own tools and standards

In this project, we have used the open-standard technology and internet standard protocols and components>>

9. Teamwork

Without teamwork we would not be able to fulfill the requirements of this demanding project. Our team was able to work well together.

<<explain details>>

Appendix B. For each task listed in the appendix, we, we show owner, description, timespan, and status. Status will have the following values: in progress, completed, waiting for another task or delayed.

Table 7 shows the responsiblites, Contributions, and expertise of each of the team members.

Table 7 Team responsiblites, Contributions, and expertise

Student	Responsiblities	Contribution	Expertise
Student 1			·
Student 2			·
Student 3			·
Student 4			·

10. Conclusion

In this section, we list the conclusion and future work respectively.

10.1. Conclusion

We have reached the following conclusions

10.2. Future Work

We believe there are still rooms for future advancements of this proposed solution. We list few hints of what can be done differently in a similar project.

Appendix A: Test Plan

Solution Name	Team Leader:	Student 1
		Student 2
		Student 3
Test No. ID	Related Feature	Pre-conditions	Test Description (steps)	Expected Outcome	Test Outcome
1	Register	Not Applicable	1. user clicks on the "Register" button 2. user Fills valid data for all of: Id, name, email, phone number, and password. 3. user submit the form	System Database will create a record for the user with the entered data

20 | Page

Appendix B: Progress Report-Teamwork

Table 5 Progress Report

<< This is an example>> use your own>>

ID Task Name / Owner Timespan - Week # Status Mitigation Action

Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Risk Likelihood Impact Severity

of the Risk if the based on Occurring Risk Impact

occurs and likelihood

1.0

Project Plan

Team

Completed

5.1

ER Diagram

Project ERD is incomplete

Low

High

Moderate

Completed

Make Team review session

Cross check with Proj. Requirements

5.2

Use Case Diagram

Use cases do not reflect

actual requirements

Low

Moderate

Low

Completed

Review with someone that can represent stakeholders

22 | Page

8.3

Final Report

Team

Do not complete the report on time

Moderate

High

Completed

Team will reflect changes to the Final Report as we go. By the deadline Team should have the major parts of the final report already

in place

Appendix C- Attachments and Source Code

In this appendix we list the source code of different pieces of the solution where applicable.

References

[1] M. A. Gottfried, “Chronic Absenteeism and Its Effects on Students’ Academic and Socioemotional Outcomes,” J. Educ. Students Placed Risk, vol. 19, no. 2, pp. 53–75, Apr. 2014, doi: 10.1080/10824669.2014.962696.

24 | Page