CHAPTER FOUR

SYSTEM ANALYSIS

4.0 Overview- Introduce the reader to the various sub sections within the chapter. E.g

4.1 Feasibility study- Identify all the feasibility study that were conducted and write a feasibility
study report which should be attached as an appendix. Don’t describe the feasibility study in
detail rather define it and explain how it was applied in the system under study.

Prepare a feasibility report and attach it in the appendix

Example: Feasibility study is defined as ( ).After carrying out a feasibility study on the existing
student registration system, it was discovered that technically the institution has enough
computers to run however, the proposed system requires upgrade of RAM and soft wares for all
the machines. Legal feasibility implies that a system should be able to meet all legal and
contractual laws ( ). The current system meets all legal and contractual laws of a country.

4.2 Description of Current System- Explain the working of the current system, citing the
functional components of the system.

Example: The current MUST student registration system allows a student to register for a current
system. The student is required to first pick a registration form which he/she fills and return to
the registration department. The student is then required to pay the entire fee…….

4.3 Summary

CHAPTER FIVE

SYSTEM DESIGN

5.0 Overview

5.1 Description of the proposed system

5.2 Functional requirement of the proposed system- you can accompany it with snap shots of
dialog boxes of the system

Examples of functional requirements

Interface requirements

1
  Field 1 accepts numeric data entry.
 Field 2 only accepts dates before the current date.
 Screen 1 can print on-screen data to the printer.

Business Requirements

 Data must be entered before a request can be approved.

 Clicking the Approve button moves the request to the Approval Workflow.
 All personnel using the system are trained according to internal SOP AA-101.

Regulatory/Compliance Requirements

 The database has functional audit trail.

 The system limits access to authorized users.
 The spreadsheet can secure data with electronic signatures.

Security Requirements

 Members of the Data Entry group can enter requests but can not approve or delete
requests.
 Members of the Managers group can enter or approve a request but can not delete
requests.
 Members of the Administrators group cannot enter or approve requests but can delete
requests.

5.3 Non functional requirements of the proposed system

Non-functional requirement is that it essentially specifies how the system should behave and
that it is a constraint upon the systems behaviour. non-functional requirements specify the
system’s ‘quality characteristics’ or ‘quality attributes’ ... Some typical non-functional
requirements are: Performance – for example Response Time, Throughput, Utilization,
Scalability, Capacity, Availability , Reliability , Recoverability , Maintainability , Serviceability ,
Security , Regulatory , Manageability , Environmental , Data Integrity , Usability and
Interoperability

Non-functional requirements describe how the system works, while functional

requirements describe what the system should do.

5.4. Logical design of proposed system

Logical Design

2
Logical design pertains to an abstract representation of the data flow, inputs, and outputs of the
system. It describes the inputs (sources), outputs (destinations), databases (data stores),
procedures (data flows) all in a format that meets the user requirements.

While preparing the logical design of a system, the system analyst specifies the user needs at
level of detail that virtually determines the information flow into and out of the system and the
required data sources. Data flow diagram, E-R diagram modeling are used.

5.5. Summary

CHAPTER SIX

SYSTEM IMPLEMENTATION

6.0 Overview

6.1 System testing- integration, unit testing. Explain how this tests were conducted.

6.2 System changeover/ installation: parallel, direct, phase , pilot

6.3 Documentation –Explain and provide evidence for all the documentation done during the
development of the system. Documentation should be both internal and external documentation.
Prepare a user/ operation manual for the developed system. Attach it as an appendix

6.4 Summary

CHAPTER SEVEN

CONCLUSION AND RECOMMENDATION

7.0 Overview

7.1Achievements

7.2 Challenges

3
7.3 Proposed system limitations

7.4 Recommendation/ future work

7.5 Conclusion

Formatting the research document

 Use Times New Roman font throughout the document
 Use font size 16 on all text appearing on the cover page
 Use font size 16 and bold for all chapter titles
 The chapter titles should be center aligned
 Use font size 12 and bold for headings and subheadings in a given chapter
 All headings and subheadings should be left aligned and numbered appropriately
 Apply double line spacing throughout your document
 Use justify alignment in your main text
 Use font size 12 for the main text throughout your document
 Margins of the paper: Left margin should be 35mm (1.3 inches) Right, top, bottom
margins should be 30mm (1.2 inches)
 When printing, use one side of the paper
 Apply this format throughout your proposal. Make sure you edit and format your work
properly before submitting. Be very keen in observing these guidelines.

4
5