System Analysis Of Proposed Teaching And Learning System – High Quality Institute

Functional requirements of the Server and network infrastructure

The High Quality Institute (HQI) – an educational institution focused on providing IT related courses – wants to develop and deploy a new system for the institution. The system to be developed is a Teaching and Learning System (TLS). The development of the proposed TLS will involve among other things, the installation and configuration of a database and management server, a mail server and a web server. Additionally, the infrastructure to deploy the system on has to be established.  

The aims of this report are to present a system analysis of the requirements of the proposed system. The objectives are to analyze the requirements, establish the functional and non-functional requirements of the system. The report also seeks to outline a breakdown of tasks and activities required to implement the project in form of a Work Breakdown Structure, as well as analyze time requirements for the project by use of a PERT chart. The final objective is to establish the viability of the project by calculating the Net Present Value of the investment on the project, as well as the Payback period and return on investment.

As such, this report presents a list of functional and non-functional requirements of the proposed TLS, a Work Breakdown Structure, a PERT/CPM chart of the project, class diagram and calculations for the Net Present Value, Payback Period and Return on Investment. Finally the report sums up all the findings in a summary form on a poster.

Functional requirements describe what a given system should do; they specify behaviors or functions of a system (Wiegers and Beatty, 2013). Functional requirements are declarations of the intended functionalities of a system and its components (Pavlovski and Zou, 2008).  They specify the expected behavior that the system should exhibit and may include the business rules it will implement, reports to be generated, transactions the system has to perform, administrative functions and what interfaces it will have (Shaw and Garlan, 2012).

For the proposed TLS system at the HQI, the following are the functional requirements;

• Assign a student to an advisor
• Register student’s units
• Keep students details
• Keep details of assigned advisors
• Maintain course details
• Maintain details of units for every course
• Manage emails for staff and students

Functional requirements of the Server and network infrastructure

• High storage and memory capacity
• High network bandwidth
• Data encryption over the network

In developing the functional requirements for this system, it is assumed that the system will maintain the course and related units details, since students cannot register for units that do not already exist on the system.

Non-functional requirements describe how a software will perform the tasks it is designed to perform (Dennis, Wixom and Tegarden, 2015). These are constraints that given software should exhibit, which specifies general characteristics of a system. Some of non-functional requirements include; quality attributes and design constraints (Shah and Rogers, 2013). The main attributes which constitutes non-functional requirements include; usability of the system, scalability, maintainability, performance, reliability and security constraints (Eriksson and Penker, 2014) .These are system qualities, which ensure a system is usable, efficient and secure.

Non-functional requirements

For the proposed TLS system, the main non-functional requirements will include;

• Performance; the system should be highly responsive, with a short response time and high throughput. The designed system accompanying hardware should have sufficient capacity to ensure the system handles numerous requests and connections, without downgrading the performance of the system(Shah and Rogers, 2013).
• Security: The system should ensure data is secured especially when being transmitted between the web interface and the database (Van, 2009).
• Usability: The design should utilize simple and familiar layout to enhance the usability of the system (Dennis, Wixom and Tegarden, 2015).
• Recoverability: in case an error occurs during the normal operation of the system, the system should provide for means of recovering from such errors (Glinz, 2007).
• Capacity: the system should handle numerous concurrent connections and requests without suffering an outage or a degradation of performance of the system(Gross and Yu, 2001).
• Availability: the accompanying infrastructure that include network and servers should be designed to ensure high availability and security; with minimal or no downtime. The envisioned system should have 99.9% availability (Dennis, Wixom and Tegarden, 2015).

A Work Breakdown Structure (WBS) presents tasks of a project in small deliverable components. With a WBS, a project team’s work is organized into manageable sections (Hobel and Schutte, 2015). The scope of a project is hierarchically decomposed, to enable a project’s team perform tasks in smaller components, while providing a framework for carrying out detailed cost estimates for the project (Chung, 2012).

Use of a WBS in a project assists in defining and organizing tasks, calculation of cost and time estimates for a project, enables task assignment to team members and establishment of a control baseline (Bentley, Dittman and Whitten, 2000). Additionally, a work breakdown structure enables a project manager to objectively measure accomplishments for work done. It also plays a pivotal role in defining the relationship between project tasks, organization and costs (Chung, Nixon and Mylopoulos, 2012). For the proposed Teaching and Learning System (TLS), the following will be the work breakdown structure;

	DESCRIPTION	DURATION
	TLS System Project	62 days
	Project Initiation	3 days
A.	Initial Project Meeting	1 day
B.	Develop a business case	1 day
C.	Feasibility study	1 day
D.	Appoint a project manager	1 day
E.	Form a project team	1 day
F.	Develop a project charter	1 day
	Project Planning	3 days
G.	Develop a project plan	3 days
H.	Develop a Resource plan	2 days
I.	Financial planning	2 days
J.	Develop a risk management plan	2 days
K.	Project communication plan	2 days
L.	Develop a procurement plan	2 days
	System Analysis and Design	5 days
M.	Gather system requirements	2 days
N.	Analyze system requirements	1 day
O.	Gather infrastructure requirement	1 day
P.	Design network infrastructure	2 days
Q.	Establish servers specifications	1 day
R.	Design ULS	2 days
S.	Design PLS	2 days
T.	Design databases	2 days
	Project Implementation	32 days
U.	Procure necessary hardware	7 days
V.	Develop network infrastructure	10 days
W.	Code the application	30 days
X.	Configure Servers	3 days
Y.	Configure network	3 days
	Testing	22 days
Z.	Unit testing the application	3 days
AA.	Network testing	1 day
AB.	Testing servers	1 day
AC.	Complete system testing	2 days
AD.	Fixing bugs	5 days
	Deployment	8 days
AE.	Application deployment	2 days
AF.	User training	5 days
AG.	Go live	1 day
	Project Closure	3 days
AH.	Reviewing the project	1 day
AI.	Project signoff	1 day
AJ.	Documenting lessons learnt	1 day

Project evaluation and review technique (PERT) and critical path method (CPM) plays important roles in analysis of activities necessary to complete a project (Garson, 2001). The two methods are particularly important in identifying the least time for completing the entire project, by identifying tasks that can be performed in parallel (Burke, 2013).

For this project, the PERT/CPM chart was developed using MS Project software. The critical path is highlighted in red on the diagram and shows the shortest route to the execution of the project. 

		YEAR
	Category	0	1	2	3	4	5
1	Value of benefits		7000	7000	7000	7000	7000
2	Development Cost	-20000	0	0	0	0	0
3	Annual Expenses		-2000	-2000	-2000	-2000	-2000
4	Net benefits/costs	10000	5000	5000	5000	5000	5000
5	Discount factor	1	1	1	1	1	1
6	Net Present value	-$10,000.00	-$5,000.00	-$5,000.00	-$5,000.00	-$5,000.00	-$5,000.00
7	Cumulative NPV	-10000.00	-$5,000.00	$0.00	$5,000.00	$10,000.00	$15,000.00

From the NPV table, the payback period is exactly 2 years. This is a point where the Cumulative NPV is zero, meaning the initial cost of investment has been recovered.

• Sum of Net benefits = 25,000
• Sum of Annual Expenses= 10,000

• ROI = =  = 1.5  Translating to 150%

Conclusions 

This report has presented a system analysis of the requirements of the proposed Teaching and Learning System (TLS). The identified functional requirements for the proposed TLS include; assigning a student to an advisor, registering units, keeping track of student and advisor details and maintaining details of registered units for each student. The non-functional requirements include; high availability of the system, security of data, easily usable system, high capacity to store and process data and error recoverability. A work breakdown has been established for the project and a critical path for the implementation.

From the analysis of the project costs, it was found that the project has a positive NPV, and a return on investment of 150%, with a payback period of 2years. These results show that the project is beneficial to the institution and therefore should be implemented.

References

Burke, R. 2013. Project management: planning and control techniques. New Jersey, USA.

Bentley, L.D., Dittman, K.C. and Whitten, J.L., 2000. Systems analysis and design methods. Irwin/McGraw Hill.

Chung, L., Nixon, B.A., Yu, E. and Mylopoulos, J., 2012. Non-functional requirements in software engineering (Vol. 5). Springer Science & Business Media.

Chung, L., 2012. Representation and utilization of non-functional requirements for information system design. In Advanced Information Systems Engineering (pp. 5-30). Springer Berlin/Heidelberg.

Dennis, A., Wixom, B. H., & Tegarden, D. 2015. Systems analysis and design: An object-oriented approach with UML. John Wiley & Sons.

Garson, G.D., 2013. Path analysis. Statistical Associates Publishing.

Gross, D. and Yu, E., 2001. From non-functional requirements to design through patterns. Requirements Engineering, 6(1), pp.18-36.

Glinz, M., 2007, October. On non-functional requirements. In Requirements Engineering Conference, 2007. RE’07. 15th IEEE International (pp. 21-26). IEEE.

Hobel, B., & Schütte, S. 2015, Work Breakdown Structure. . John Wiley & Sons.

Loucopoulos, P. and Karakostas, V., 2013. System requirements engineering. McGraw-Hill, Inc..

Van L, A., 2009. Requirements engineering: From system goals to UML models to software (Vol. 10). Chichester, UK: John Wiley & Sons.

Shah, J.J. and Rogers, M.T., 2013. Functional requirements and conceptual design of the feature-based modelling system. Computer-Aided Engineering Journal, 5(1), pp.9-15.

Eriksson, H.E. and Penker, M., 2014. Business modeling with UML. New York.

Shah, J.J. and Rogers, M.T., 2013. Functional requirements and conceptual design of the feature-based modelling system. Computer-Aided Engineering Journal, 5(1), pp.9-15.

Shaw, M. and Garlan, D., 2012. Software architecture: perspectives on an emerging discipline (Vol. 1, p. 12). Englewood Cliffs: Prentice Hall.

Pavlovski, C.J. and Zou, J., 2008, January. Non-functional requirements in business process modeling. In Proceedings of the fifth Asia-Pacific conference on Conceptual Modelling-Volume 79(pp. 103-112). Australian Computer Society, Inc..

Wiegers, K. and Beatty, J., 2013. Software requirements. Pearson Education.