Microsoft Word - Project Report Guideline

8/12/2019 Microsoft Word - Project Report Guideline

1/21

Page 1 of 21

BOTSWANA

PROJECT REPORT AND SOURCE CODE

FACULTYOF

INFORMATIONAND

COMMUNICATION TECHNOLOGY


2/21

Page 2 of 21

Students must compile a final report that shouldcomposed of the following topics:

1. Cover Page

2. Permission to Carry Out The Project3. Declaration4. Abstract5. Acknowledgement6. Table Of Contents, Figures, Tables, Appendices7. Introduction (Project Proposal Document)8. System Requirements And Analysis9. System Design

10.System Testing11. System Implementation12. User Manual13. Conclusions14. Bibliography15. Appendices


3/21

Page 3 of 21

COVER PAGE EXAMPLE

BOTSWANA

INVENTORY SYSTEM

AME SEDITI

YEAR 2011

FACULTY OF INFORMATION & COMMUNICATIONTECHNOLOGY

LIMKOKWING UNIVERSITY OF CREATIVETECHNOLOGY BOTSWANA

NOVEMBER 2007

TitleofFinalYearProject

Typeface:Arial

FontSize:20

Name of CandidateTypeface : ArialFont Size : 16TermTypeface : ArialFont Size :12

50 MM FROM THE BOTTOM OF THEPAGE

Faculty, name of university andMonth & Year of the project

submission.Typeface : ArialFont Size : 12Font Size :12

Figure 1: Layout for the cover page of the major project


4/21

Page 4 of 21

BSc (HONS) SOFTWARE ENGINEERING WITH MULTIMEDIA

DPROJ303 Major Project

Name : AME SEDITI

Student ID# : 20703712

YEAR : 2011

THE PROJECT REPORT IS PREPARED FOR

FACULTY OF INFORMATION & COMMUNICAION TECHNOLOGYLIMKOKWING UNIVERSITY OF CREATIVE TECHNOLOGY BOTSWNANA

IN PARTIAL FULFILLMENTFOR

BSC (HONS) IN SOFTWARE ENGINEERING WITH MULTIMEDIA

FACULTY OF INFORMATION & COMMUNICAION TECHNOLOGY

LIMKOKWING UNIVERSITY OF CREATIVE TECHNOLOGY BOTSWANA

MAY 2011

Project Title : Fit To Fly Administrative Web Application

Submission Date : 12 May 2011

Supervisor : Mr. GODFREY MLAMBO

Figure 2: Permission To Carry Out The Project


5/21

Page 5 of 21

BSc (HONS) SOFTWARE ENGINEERING WITH MULTIMEDIA

DPROJ303 Major Project

Name : Ame Sediti

Student ID# : 207037123

Semester : 6

Academic Honesty Policy StatementI,

hereby attest that contents of this attachment are my own work. Referenced works, articles, art, programs, papers or

parts thereof are acknowledged at the end of this paper. This includes data excerpted from CD-ROMs, the Internet,

other private networks, and other peoples disk of the computer system.

Students Signature : _____________________________

SUPERVISORS COMMMENTS/GRADE:

for office use only

DATE : ______________

TIME : ________________

RECEIVERS NAME : _______

Title : Fit to fly administrative web application: Proposal

Submission Date : 12 March 2005

Supervisor : Mr. GODFREY MLAMBO


6/21

Page 6 of 21

Order and Contents of the Final Major Project Report(DPROJ303)

1. Permission to Carry Out The ProjectStudents should ensure that the project approval from is signed by the project supervisoracknowledging the permission to carry out the project.

2. DeclarationStudents should declare with signature saying the report has been done by them and noplagiarism has been included.

3. AbstractAbstract summary is the section written last as it is where you will step back and review what hasbeen achieved. In one page, list main features of your project, what problem you were solving andhow to solve them. Finally the achievement and nature of outcome in relation to desired intentions.

4. AcknowledgementAcknowledging is giving due gratitude and appreciation to people who have made it possible foryou to carry out this project.

5. Table of ContentsEach students contribution to the relevant chapters and section should clearly be indicated byname.

6. List of Figures

7. List of Tables

8. List of Abbreviations

9. List of Appendices


7/21

Page 7 of 21

Chapter 1: IntroductionBackgroundProblem StatementProblem JustificationAim And ObjectivesLiterature Review

Chapter 2: System Requirements and AnalysisRequirements Elicitation And Methods UsedFunctional And Non-Functional RequirementsSystem Development Methods, Tools, Techniques And MethodsSystem Development Life CycleSystems Analysis Models

Chapter 3: System DesignSystems Development MethodSystems ArchitectureDatabase DesignSystem Architectural Model

System Interface DesignSystem Design Constraints

Chapter 4: System TestingSystem Testing ObjectivesSystem Testing MethodsSystem Testing PlanSystem Testing Results

Chapter 5: System Implementation Process/resultsSystems Implementation IntroductionSystems Implementation Plan

Systems Implementation OverviewSystems Implementation ScheduleSystems Implementation SecuritySystems Implementation Support

Chapter 6: User ManualSystems User Manual ScopeSystems Use SummarySystems Access

Chapter 7: Conclusions

What has been accomplished for each project objective (Students should clearly state theconclusion for each project objective). What are the major things that you learned from thisproject? What work still needs to be done and how can it be improved and /or enhanced? Do youhave any future for this software package?

Bibliography/ReferencesInclude here all bibliographic/reference materials referenced within your report. You must quotereferences at appropriate places in the report where needed.


8/21

Page 8 of 21

AppendixSome of the minute detail of the sections above can be relegated to the Appendix and referencedfrom the body of the report. Include all relevant documentation, computer coding, screen displays,business plan/research paper, etc. Final Year Project Meeting Log sheets should be attached asan appendix as well.

In summary, the Final report should be written in the style of a finished and fully polished documentthat you would be willing to show either a prospective employer or the admission of an IT graduate

school. It should follow the publications guidelines specified in the following sections.


9/21

Page 9 of 21

Chapter 1 Introduction (Project Proposal Document)

1.1. Background Informationa. What is the current situation and who is affected, how and why do you want to

develop the system. What are the symptoms of the problems or tell tale signs. Hereyou can also use some literature review to emphasis and your points and makethem clear.

1.2. Problem Statementa. What is the problem in brief.here write the summary of the problem in a

paragraph with at most ten (10) sentences.

1.3. Project Aim & Objectivesa. What is the overall goal of the system?. What are the SMART objectives of the

system i.e. what it is supposed to do either functionally or business wise in order tofulfill the goal of the system.

1.4. Project Scope and Constraintsa. Whom are you developing the system forb. How long is it going to takec. What are you general going to dod. What is it that you are going to and not do?

1.5. Feasibility Studya. Operationalwhat are the supporting factors that would make it possible to

introduce the system in the given environmentb. TechnicalIs there any existing technical equipment, skills if notwhat is needed

and state its purpose.c. SocialWill the people in the environment accept the application what are, their

attitudes and perceptions towards introducing the system, will they resist it for fearof losing jobs, what would be your measures to ensure that its an accepted systemin the environment

d. Legal..is a permitted system i.e. the function it shall perform is compliant with state

legalities and other laws.e. EconomicalThis is very vital you should do a cost benefit analysis of existingoptions like

i. The existing systemsii. The system you are developingiii. COTSiv. Consider which is the best option to take based on the factors like Return On

Investment (ROI) or another factor.

1.6. Justification or Significance of the researcha. What is the reason for developing this (should be a paragraph with at most ten

lines). Use quantitative or highly qualitative statements to give you justificationnormally extracted from the feasibility study.

1.7. Literature review of the project i.e. topic being donea. What are the current developments in this areab. What methods and technologies have been used to develop existing solutionsc. What problems are with the current systems being usedd. In which areas are the existing systems being used and howe. How are you going to approach your development i.e. any new improvements, new

things etc.

1.8. Technology and Method to use for developing your system


10/21

Page 10 of 21

a. What developing method are u going to use based on literature review or own youpreference

1.9. Project Plan and Schedulinga. Gantt chart + Schedule/WBS with Deliverables & Milestone for each project

member.

Chapter 2: System Development And Analysis.

2.1. System requirements methods used and the data gathered.a. Use appropriate relevant method (at most 3) and defend them. Make sure you show or

tabulate the results.

2.2. System functional and non-functional requirementsa. User requirements.b. Technical requirementsc. Business requirements

2.3. System Models Used

a. Functionalb. Dynamicc. Static

2.4. Software development life cycle process adopted

You need to adopt an appropriate system development methodology

CHAPTER 3: SYSTEM DESIGN

3.1. INTRODUCTIONThe purpose of this document must be explained

System Overview summary One paragraph System requirements

o Functional Requiremento Non Functional Requirements

These should be categorized as user requirements, technical requirements and businessrequirements.

3.2. DEVELOPMENT METHODDescribe development methods or approach used for this software design, either OOD orStructured design etc? One paragraph

3.3. SYSTEM ARCHITECTURESIn this section, describe the system and/or subsystem(s) architecture for the project. Referencesto external entities should be minimal.

1. Develop your system structure diagram2. At the top-most level, describe the major responsibilities that the software must

undertake. One paragraph.3. Describe how the system was broken down into its components/subsystems

(identifying each top-level component/subsystem and the roles/responsibilitiesassigned to it). One paragraph.


11/21

Page 11 of 21

Example

Using static Model design a Technical specification that will be mapped into the architecture

Use Case Diagram: External entity and subsystem interaction

Class Diagrams (Name, Attributes and Methods). This must be in two levels which are topview and detailed view.

Package Diagrams (Group of class that equivalent to a subsystem) Relations between the mentioned Models

Static Model Dictionary Pseudo Code.

3.4. DATABASE DESIGNSpecify the requirements for any information that is to be placed into a database, including.

a. Data entities (classes) and their relationships (ERDs)

Show how classes were mapped into tables/relations. Draw and ERD of thedatabases and show all relevant information.b. Normalization must be done.c. Table relationships, Referential & integrity constraints

Develop the relational tables of the databases by showing the primary keys andforeign keys in each and every table in your database. In addition define otherbusiness constraints that are pertinent to the application being developed andspecify where its implementation level.

d. Develop your database schemae. Data Dictionary


12/21

Page 12 of 21

3.5. SYSTEM ARCHITETURES MODEL

The System Architecture Model represents the various architecture components thatComprise the system, and shows their interrelationships.

3.5.1 System Hardware Architecture

In this section, describe the overall system hardware and organization. Include a list of hardwarecomponents (with a brief description of each item) and diagrams showing the connectivitybetween the components. If appropriate, use subsections to address each subsystem.

a) Specify the use of other required software products (e.g., a DBMS or operating system),and interfaces with other application systems. Draw a diagram as shownin Figure belowto show the interface of the other products needed to launch your software. Mention portsused to interface with these applications.

Figure: The diagram for software interface of a system under development.

3.5.2 Communications/LAN Interfaces

a) Specify whether your system is stand alone system, client server based system and whatlevel is the client server level i.e. is it a one tier, two tier or three tier system.

b) Draw the typical LANset up to implement the networking environment to set up theequipment.

3.6. INTERFACE DESIGNDesign a user Interface which:

Place the user in Control Reduce the users memory load

Make the interface consistent.

3.7. DESIGN CONSTRAINTS

a) Specify requirements imposed by standards, hardware limitations, resources,software research on this. Note it has to be realistic, practical and related todevelopment environment etc.

3.8. Software System Attributes

Middleware


13/21

Page 13 of 21

Specify the software attributes of you the software you are going to develop based on thesefactors.

Reliability:- Specify the factors needed to establish the softwares required reliability.

Availability:- Specify the factors needed to guarantee a defined level of availability.Security:- Specify the factors that will protect the software from accidental or maliciousaccess, misuse, or modification. These factors may include:

i. activity loggingii. restrictions on inter- module communicationsiii. data integrity checks

Maintainability: - Specify attributes of the software that relate to ease of maintenance.These requirements may relate to modularity, complexity, or interface design.Requirements should not be placed here simply because they are thought to be gooddesign practices.

Portability: - Specify attributes of the software that relate to the ease of porting the softwareto other host machines and/or operating systems.

CHAPTER 4: TESTING MANUAL

4.1Test Objective OverviewDescribe the test objective . We test the whole system in accordance with FunctionalRequirements. We test to find errors. Test should focus on the listed Functional Requirements andNon Functional Requirements. Students are advised to write their own testing objectives

All system units should have been unit tested and passed the test. All components should havebeen integrated and integration should have been tested and passed as well. Testing environmentfor system testing should be created to resemble a working, live environment

4.2Different Kinds of TestingMost of these tests are mandatory in all most every system.

4.2.1. Unit TestingThis is carried by programmers to ensure that individual modules are working fine on their ownbefore combining them. Each module has own requirements that programmers must test beforereleasing the module to be integrated.

4.2.2. Usability TestingThis is the black box testing. It is basically a test done by the user to check if the system is whatthey need and expected as outlined in the functional requirements or in the analysis phase. Thistesting basically focuses on ease of the use of a system. Usability testing is carried on a realisticenvironment. It is advisable that it be done by a number of users to in order to get multiple

responses.

4.2.3. Compatibility TestingWill your system be run on different OS, Browsers, servers and clients. These are the things whichcompatibility should be tested. Different versions of OS, check your application/system on all ofthese.

Does the system maintain data as required, is it secure as intended. This covers issues likeconfidentiality, Integrity, Authentication and Authorization and Availability. The tester here has tothink like an attacker to the system/application and try to exploit it further.


14/21

Page 14 of 21

4.2.4. Installation TestingIt becomes even more critical now as there are different means to distribute the software. Insteadof traditional method of distributing software in the physical CD format, software can be installedfrom internet, from a network location or even it can be pushed to the end user's machine. Whatplatforms will you be using, how do u distribute your software. Installation Testing tries to identifythat all parts of the system are installed and working.

4.2.5. Performance TestingDoes the system meet the expected response time, factors to consider here may be a number ofusers connected to the system or how the system responds to a heavy load.

4.2.6. Integration TestingThis proves that the system works well as intended as a whole, interface, logic, database and anyother subsystem concerned.

4.3Test PlanA test plan consists of, but not limited to the following

4.3.1. ApproachHow do want to test your system/application

4.3.2. System functionsIdentify the functions to be tested The levels of testing i.e user testing, integration, etc.

4.3.3. ResourcesWhat do you have to enable you to carry an effective test.

4.3.4. HumanDo you have the personnel to carry the tests, do they have the expertise. This may range fromdevelopers to independent companies specializing in testing.

4.3.5. Hardware

Do you have enough hardware, the high performance machines that you outlined in your projectproposal.

4.3.6. SoftwareDoes software exists that can enable you to have an automated test? What role does softwareplay in your testing environment.

4.4Test Schedule.Design a schedule depending on the approach you took. You can divide the schedule pertaining tolevels of testing or in any way you deem efficient to enable to have a successful test.

4.5Testing Scope

We identify the breath and functionality of the system we need to test, pertaining to the systemarchitecture; aspects may be more than the ones listed below

4.5.1. FunctionalThe aim here is to measure the quality of the business components of the system. We verify if thesystem performs in accordance with the analysis and design detailed before. Does it achieve thecore functionalities the user/customer expects to see.

4.5.2. Interface


15/21

Page 15 of 21

Focuses on ease of use of the interface. Interface is basically the item that the user communicatewith to use the system. Interface items are linked together and tested to see if they work togetheras expected and outlined in the analysis and design stages. Tests can be done by developers asthey are the ones who can understand what is wrong if a certain interface cannot work.

4.5.3. DatabaseFocuses on database planning, design and implementation. Its compliance with logic and businessconstraints and other operational and configuration matters.

4.6 Test ResultsThis section provides the executive summary of the test, and should provide a quick summary ofthe test results and the recommended actions to be taken.

4.7Requirements Verified or FailedExplain requirements that either passed or failed the test. There are three types of failurecategories:

1) Fail-Repair, which requires retesting;2) Fail-Deviation Required;3) Fail-Waiver Required.

This explanation is followed by a summary table listing the number of requirements in eachcategory.

4.8Comments and RecommendationsTo decide on how to proceed for the implementation, explain how critical they are to thedeployment and operation of the system.

4.9Critical FailuresCritical failures must be fixed before further testing of the system can continue. The system cannotbe deployed or operated with a critical failure. These are sometimes referred to as showstoppers.

This section explains what a critical failure means and is followed by a three-column

table identifying the requirements, the text of the requirement, the reason it failed, and why it iscritical that it be f ixed before continued testing or operation takes place

4.10 Serious FailuresSerious failures are those that need to be fixed, but an interim solution exists that can be used tooperate the system. Usually, an interim solution is a manual operation, such as entering data into adatabase directly or selecting certain system output configurations instead of letting the softwaredo it. These failures can be listed as Failure-Deviation Required. The work-around solution isdescribed, and a recommendation is made to implement the work-around and have the contractorfix the failure before the final release of the system. If it is determined that it is not cost effective tofix the failure and retest, and if the work-around solution is adequate for the long term, the failuremay be listed as Failure-Waiver Required.

4.11 Minor FailuresMinor failures do not materially affect the operation of the system, and can be fixed at a later dateor ignored. An example might be a user interface display that has a misspelling in it or the wrongcolor used for an icon on the display. These failures can be listed as Failure-Deviation Required orFailure-Waiver Required.


16/21

Page 16 of 21

CHAPTER 5: IMPLEMENTATION MANUAL

5.1. OverviewThe Implementation Plan describes how the information system will be deployed, installed andtransitioned into an operational system. The plan contains an overview of the system, a briefdescription of the major tasks involved in the implementation, the overall resources needed tosupport the implementation effort (such as hardware, software. facilities, materials, and personnel),and any site-specific implementation requirements.

5.2. IntroductionThis section provides an overview of the information system and includes any additionalinformation that may be appropriate.

5.2.1. PurposeThis section describes tile purpose of the Implementation Plan. Reference the system name andidentify information about the system to be implemented.

5.2.2. System OverviewThis section provides a brief overview of the system to be implemented, including a description ofthe system and its organization.

5.2.3. System DescriptionThis section provides an overview of the processes the system is intended to support. If thesystem is a database or an information system, provide a general discussion of the description ofthe type of data maintained and the operational sources and uses of those data.

5.2.4. System OrganizationThis section provides a brief description of system structure and the major system componentsessential to the implementation of the system. It should describe both hardware and software, asappropriate. Charts, diagrams, and graphics may be included as necessary.

5.3. Management Overview

The subsequent sections provide a brief description of the implementation and major tasksinvolved in this section.

5.3.1. Description of ImplementationThis section provides a brief description of the system and the planned deployment, installation,and implementation approach.

5.3.2. Points of ContactIn this section, identify the System Proponent, the name of the responsible organization(s), andtitles and telephone numbers of the staff who serve as points of contact for the systemimplementation. These points of contact could include the Project Manager. DatabaseAdministrator, Configuration Management Manager, or other managers with responsibilitiesrelating to the system implementation. List all managers and staff with whom the implementationmust be coordinated.

5.3.3. Major TasksThis section provides a brief description of each major task required for the implementation of thesystem. Add as many subsections as necessary to this section to describe all the major tasksadequately. The tasks described in this section are not site-specific, but generic or overall projecttasks that are required to install hardware and software, prepare data, and verify the system.Include the following information for the description of each major task, if appropriate:

5.3.4. What the task will accomplish


17/21

Page 17 of 21

5.3.5. Resources required to accomplish the task5.3.6. Key person(s) responsible for the task. Examples of major tasks are the following:

a) Providing overall planning and coordination for the implementationb) Providing appropriate training for personnelc) Providing all needed technical assistanced) Performing site surveys before implementatione) Ensuring that all prerequisites have been fulfilled before the implementation

date

f) Providing personnel for the implementation teamg) Acquiring special hardware or softwareh) Performing data conversion before loading data into the system

5.4. Implementation ScheduleIn this section, provide a schedule of activities to be accomplished during implementation. Showthe required tasks (described in Section 2.3, Major Tasks) in chronological order, with thebeginning and end dates of each task.

5.5. SecurityIf appropriate for the system to be implemented, include an overview of the system securityfeatures and requirements during the implementation.

5.5.1. System Security FeaturesIn this section, provide an overview and discussion of the security features that will be associatedwith the system when it is implemented. It should include the primary security features associatedwith the system hardware and software. Security and protection of sensitive bureau data andinformation should be discussed, if applicable. Reference the sections of previous deliverablesthat address system security issues, if appropriate.

5.5.2. Security During ImplementationThis section addresses security issues specifically related to the implementation effort, if any. Forexample, if LAN servers or workstations will he installed at a site with sensitive data preloaded onnon-removable hard disk drives, address how security would be provided for the data on thesedevices during shipping, transport, and installation because theft of the devices could compromisethe sensitive data.

5.6. Implementation SupportThis section describes the support software, materials, equipment, and facilities required for theimplementation, as well as the personnel requirements and training necessary for theimplementation. The information provided in this section is not site-specific. If there are additionalsupport requirements not covered by the subsequent sections, others may be added as needed.

5.6.1. Hardware, Software, Facilities, and MaterialsIn this section, list support software, materials, equipment, and facilities required for theimplementation, if any.

5.6.1.1. Hardware

This section provides a list of support equipment and includes all hardware used for testing timeimplementation. For example, if a client/server database is implemented on a LAN, a networkmonitor or sniffer might be used, along with test programs. to determine the performance of thedatabase and LAN at high-utilization rates.

5.6.1.2. SoftwareThis section provides a list of software and databases required to support the implementation.Identify the software by name, code, or acronym. Identify which software is commercial off-the-shelf and which is State-specific. Identify any software used to facilitate the implementationprocess.


18/21

Page 18 of 21

5.6.1.3. FacilitiesIn this section, identify the physical facilities and accommodations required during implementation.Examples include physical workspace for assembling and testing hardware components, deskspace for software installers, and classroom space for training the implementation stall. Specifythe hours per day needed, number of days, and anticipated dates.

5.6.2. Personnel

This section describes personnel requirements and any known or proposed staffing requirements,if appropriate. Also describe the training, if any, to be provided for the implementation staff.

5.6.2.1. Personnel Requirements and StaffingIn this section, describe the number of personnel, length of time needed, types of skills, and skilllevels for the staff required during the implementation period. If particular staff members havebeen selected or proposed for the implementation, identify them and their roles in theimplementation.

5.6.2.2. Training of Implementation StaffThis section addresses the training, if any, necessary to prepare staff for implementing andmaintaining the system; it does not address user training, which is the subject of the Training Plan.Describe the type and amount of training required for each of the following areas, if appropriate, for

the system:

System hardware/software installation System support System maintenance and modification

Present a training curriculum listing the courses that will be provided, a course sequence. and aproposed schedule. If appropriate, identify which courses particular types of staff should attend byjob position description.

If training will be provided by one or more commercial vendors, identify them, the course name(s),and a brief description of the course content.

If the training will be provided by State staff, provide the course name(s) and an outline of thecontent of each course. Identify the resources, support materials, and proposed instructorsrequired to teach the course(s).

5.6.3. Performance MonitoringThis section describes the performance monitoring tool and techniques and how it will be used tohelp decide if the implementation is successful.

CHAPTER 6: USER MANUALScope, .This paragraph shall contain a full identification of the system. Identification must include the

operating system platform(s) to which this document applies. State the purpose of the system and

the software to which this document applies. It shall describe the general nature of the system and

software; summarize the history of system development, operation, and maintenance.

SOFTWARE USE SUMMARY


19/21

Page 19 of 21

6.1 Software application. This paragraph shall provide a brief description of the intendeduses of the software.. Capabilities, operating improvements, and benefits expected from its use shall

be described.

6.2 Software inventory. This paragraph shall identify all software files, including databasesand data files that must be installed for the software to operate.

6.3 Software environment. This paragraph shall identify the hardware, software,equipment, manual operations, and other resources needed for a user to install and run the software.

Included, as applicable, shall be identification of:

a. Computer equipment that must be present, including amount of memory needed,amount of auxiliary storage needed, and peripheral equipment such as terminals,

printers, and other input/output devices

b. Communications equipment that must be presentc. Other software that must be present, such as operating systems, databases, data

files, utilities, and other supporting systems

d. Forms, procedures, or other manual operations that must be present

e. Other facilities, equipment, or resources that must be present

6.4 Software organization and overview of operation. This paragraph shall provide a brief

description of the organization and operation of the software from the user's point of view. The

description shall include, as applicable:

a. Logical components of the software, from the user's point of view, including

databases and data files the user can access, Database Management Systems

(DBMSs), and communications paths, and an overview of the purpose/operation of

each component

b. Performance characteristics that can be expected by the user, such as:

2) Accuracy rate of outputs that the software can produce

3) Typical response time and factors that affect it

4) Typical processing time and factors that affect it7) Reliability that can be expected

c. Supervisory or security controls that can be implemented (such as passwords) to

manage the software

6.5 Security and privacy. This paragraph shall contain an overview of the security andprivacy considerations associated with the software. A warning shall be included regarding making

unauthorized copies of software or documents, if applicable.

2.6 Assistance and problem reporting. This paragraph shall identify points of contact andprocedures to be followed to obtain assistance and report problems encountered in using the

software.

6.2 ACCESS TO THE SOFTWARE

This section shall contain step-by-step procedures oriented to the first time/occasional user.

Enough detail shall be presented so that the user can reliably access the software before learning the

details of its functional capabilities. Safety precautions, marked by WARNING or CAUTION, shall

be included where applicable.


20/21

Page 20 of 21

6.2.1 Access control. This paragraph shall present an overview of the access and security

features of the software that are visible to the user. The following items shall be included, as

applicable:

a. How and from whom to obtain a password

b. How to add, delete, or change passwords under user control

6.2.2 Installation and setup. This paragraph shall describe any procedures that the user must

perform to be identified or authorized to access or install software on the equipment, to perform theinstallation, to configure the software, to delete or overwrite former files or data, and to enter

parameters for software operation.

6.3.3 Initiating procedure. This paragraph shall provide step-by-step procedures for beginning

work, including any options available. A checklist for problem determination shall be included in

case difficulties are encountered.

6.4 Description of inputs.

6.4.1 Input formats. This paragraph shall illustrate the layout formats to be used in the

preparation of inputs to the software and shall explain the information that may be entered in the

various sections and lines of each format.

6.4..2 Composition rules. This paragraph shall describe any rules and conventions that must be

observed to prepare inputs. The rules of syntax, usage of punctuation, etc., shall be explained. The

rules shall include the following, as applicable:

a. Input transaction length, such as 100 characters maximum

b. Format conventions, such as all input items must be left-justified

c. Labeling, such as usage of identifiers to denote major data sets to the software

d. Sequencing, such as order and placement of items in the input

e. Punctuation, such as spacing and use of symbols (virgule, asterisk, character

combinations, etc.) to denote start and end of input, of data groups, and of fieldsf. Restrictions, such as rules forbidding use of particular characters or parameter sets

6.4..3 Input vocabulary. This paragraph shall explain the legal character combinations or codes

that must be used to prepare inputs. An appendix may be provided containing an ordered listing of

these codes.

6.4..4 Sample inputs. This paragraph shall provide examples that illustrate and explain each type

or class of input acceptable by the software. Included shall be information on the following types

of inputs, as applicable:

a. Headers denoting the start of input

b. Text or body of the inputc. Trailers denoting the end of input

d. Portions of the input that may be omitted

e. Portions of the input that may be repeated

6.5 Description of outputs.

6.5.1 General description. This paragraph shall provide the following information, as

applicable, for each type or class of output:


21/21

a. Reasons why the output is generated

b. Frequency of the output, such as monthly, on demand

c. Any modifications or variations of the basic output that is available

d. Media, such as printout, display screen, tape

e. Location where the output will appear, such as in the computer area or remotely

f. Any additional characteristics, such as priority, security and privacyconsiderations, or associated outputs that complement the information in this

output

6.5.2 Output formats. This paragraph shall illustrate and explain the layout of each type or class

of output from the software. The following aspects shall be explained, as applicable:

a. Security and privacy markings

b. Data that may appear in headers

c. Information that may appear in the body or text of the output, including column

headings and subsets or sections in the output format

d. Data that may appear in trailers

e. Additional characteristics, such as the meaning of special symbols

6.5.3 Sample outputs. This paragraph shall provide illustrations of each type or class of outputfrom the software. A description of each sample shall be provided, including, as applicable:

a. Meaning and use of each column, entry, etc.

b. Source, such as extracted from database, calculated

c. Characteristics, such as when omitted, range of values, unit of measure

6.6 Recovery and error correction procedures. This paragraph shall list the error codes

generated by the software, give their meanings, and describe the corrective actions to be taken by

the user. Also included shall be the procedures to be followed by the user with respect to restart,

recovery, and continuity of operations in the event of emergencies.

6.7 Stopping and suspending work. This paragraph shall describe how the user can cease orinterrupt use of the software and how to determine whether normal termination or cessation has

occurred.

Documents

Microsoft Word - Project Report Guideline