The Odd Jobs Limited System Analysis and Design

This article discusses the system analysis and design for Odd Jobs Limited, a company that provides skilled staff and vehicles to do customer jobs on an hourly basis. The article covers the background to adaptive methodologies, advantages and disadvantages of Scrum and Extreme programming methodologies, and recommendations for the proposed system. It also includes a memo on the plans for requirements gathering and a part B that covers the event table, domain model class diagram, design class diagram, use case diagram, and use case description.

1
The Odd Jobs Limited System Analysis and Design
:
THE ODD JOBS LIMITED SYSTEM ANALYSIS AND DESIGN
By (Student names)
[Course Name]
[Lecture Name]
[University Name]
[City where the university is located]
[Date]

2
The Odd Jobs Limited System Analysis and Design
Table of Contents
1 Part A.......................................................................................................................................3
1.1 Background to Adaptive methodologies...........................................................................3
1.1.1 Advantages................................................................................................................4
1.1.2 Disadvantages............................................................................................................4
1.2 Scrum methodology..........................................................................................................4
1.2.1 Advantages................................................................................................................5
1.2.2 Disadvantages............................................................................................................6
1.3 Extreme programming (XP) methodology.......................................................................6
1.3.1 Advantages................................................................................................................7
1.3.2 Disadvantages............................................................................................................7
1.4 Recommendation..............................................................................................................7
2 Memo.......................................................................................................................................8
2.1 Description of requirements gathering..............................................................................8
2.2 Plans for requirements gathering OJL..............................................................................9
2.3 Discussion for OJL..........................................................................................................10
2.4 Recommendation............................................................................................................10
3.....................................................................................................................................................11
4.....................................................................................................................................................11
5 Part B.....................................................................................................................................11
5.1 Event Table.....................................................................................................................11
5.2 Domain Model Class Diagram........................................................................................12
5.3 Design Class Diagram.....................................................................................................13
5.4 Use Case Diagram...........................................................................................................14
5.5 Use Case Description (intermediate)..............................................................................14
5.6..............................................................................................................................................15
6 Reference...............................................................................................................................15

3
The Odd Jobs Limited System Analysis and Design
1 Part A
1.1 Background to Adaptive methodologies
Odd jobs limited is a business company the is situated at Sydney but recently had expanded to
other centers and it mainly give services to their customers by giving skilled staffs and vehicles
to do some customers jobs where customers pays on hourly basis.
This company was started by Colin grey and he had been responsible of planning and
managements where he is being assisted by 100 employees his main role is to manage the staffs,
customers and invoicing management system.
The company has various type of employees who entails the office staffs, contracting staffs and
the drivers, currently the office staffs allocates the jobs to the contracting staffs who then update
the completed jobs to the office staffs through the call and emails stating the amount of
completed job, the vehicle used and the hours taken to complete the task which becomes much
time consuming.
Tom smith and the entire management team had proposed the use of the mobile application that
the office staffs will be adding new customer jobs, allocating the jobs to the contracting staffs,
then the contracting staffs will then be updating any completed job details stating the details of
vehicle used ,amount of job and the hours spent on job and also he will do the completion of the
customers invoice stating all job details.
Using the proposed mobile application Tom Smith will be seeing the daily completed jobs and
also Gary Tallent will be able to run the monthly reports which summarize the completed jobs
and the level of income from every vehicle.
The development team had opted to develop the system using the standard system development
life cycle to ensure all system functionalities are fully implemented.
Adaptive methodology is software development life cycle that had been developed from the
previous rapid development life cycle and it is continuous in nature and it adapts to the current
state of affairs.
Adaptive development process had been adopted instead of the use of the waterfall system
development life cycle which tends to be lengthy and this methodology consists of three major
cycles which includes:
i. Speculate. This is the plan process for initializing adaptive cycles.

4
The Odd Jobs Limited System Analysis and Design
ii. Collaboration. This is where system, development efforts are balanced and prediction
of the possible changes is made which could be technological, requirement and
stakeholders.
iii. Learn. This is where the various stakeholders interact with the system during the
designing, build and testing processes which enable the developer’s team identify
errors and rectify them.
Below are the areas where the adaptive software development methodology is used:
i. In case system requires quick development.
ii. If system development requires stakeholder’s interaction.
1.1.1 Advantages
i. Produces systems of high quality. The systems developed are fully tested to be fully
functional.
ii. Customers are highly satisfied. The system clients are involved in the development
process and thus are aware of all processes.
iii. There is increased control of project. There is transparency and several sprint meetings
which are essential in development processes.
iv. It has low risk. This ensures that chances of failing of the project are very minimal.
1.1.2 Disadvantages
i. It is unpredictable .The development team cannot specify exact time and efforts to be
applied in development process.
ii. It is time consuming and need much commitment.
iii. It demands much attention of developers and clients.
iv. No end system documentations.
v. There are chances of system failure on the track of developments.
1.2 Scrum methodology
Scrum development methodology is an adaptive methodology that uses the agile framework, it is
done by a total of up to nine members and they do the work by splitting it into sprints which are
done where there progress is taken and re-planned during stakeholders scrum meetings.
The figure below shows the cycle of scrum methodology.

5
The Odd Jobs Limited System Analysis and Design
Scrum methodology is used in various areas including:
i. If system developed have no specific business requirements.
ii. If the system developed is very small.
iii. If the development team is quite small.
iv. If the system should be developed within short time.
1.2.1 Advantages
i. Is good for systems without specific business requirements.
ii. It is good in fast coding and testing of the project.
iii. It is easy to control it due to update of progress frequently.
iv. It is highly interactive.
v. It can cope with any change due to short sprints and constant feedbacks.
vi. The productivity of individuals is measurable due to daily meetings.
vii. Issues are easily resolved due to daily meeting.
viii. Quality systems are delivered within set time frames.
ix. It is applicable to fast moving projects like web and mobile applications.
x. It involves minimum overhead cost which results to quick and cheaper result.
(Wixom, 2016).
1.2.2 Disadvantages
i. The project development can be creep due to lack of fixed delivery dates.

6
The Odd Jobs Limited System Analysis and Design
ii. There are chance of inaccuracy of costs and time as a result of poor tasks definitions.
iii. System may fail due to uncommitted developers team members.
iv. It’s only best for small size projects due to small number of team members.
v. The methodology depends on only experienced development team members.
vi. The system development progress is affected in case some development team
members happen to leave the development team.
1.3 Extreme programming (XP) methodology
Extreme programming is another type of adaptive methodology which also adopts the agile
development cycle and eventually produces software of high quality.
Below is the extreme programming methodology figure.
(Singh, 2016).
Below are the areas where extreme programming methodology is used:
i. If the system being developed requirements changes dynamically.
ii. If the developers team is quite small.
iii. If the testing of units and functions is through automated technology.

7
The Odd Jobs Limited System Analysis and Design
1.3.1 Advantages
i. Developers are able to save both time and cost.
ii. The project failure risk or programming is highly reduced.
iii. There is simplicity in this methodology.
iv. There is visibility and accountability in the various processes in this methodology.
v. The development process gives feedbacks constantly.
vi. The system errors are easily and efficiently detected in stages of developments.
vii. The employees get satisfaction and retention in this methodology.
viii. It enhances teamwork in the proposed system development.
1.3.2 Disadvantages
i. This methodology is difficult to use by and not preferred by many developers.
ii. This methodology highly relies on many factors.
iii. This method emphasis on code more than the system designs.
1.4 Recommendation
To develop the proposed system I do recommend the use of scrum methodology since the team
will be able to do coding and testing quickly, the system issues can be resolved with ease, the
system can be delivered within a short period of time and only little overhead cost is incurred in
the entire system development.

8
The Odd Jobs Limited System Analysis and Design
2 Memo
MEMORANDUM
To: The O.J.L managers
From: Team of Developers.
Date: 4/10/2018
Subject: Mobile Application System Development
2.1 Description of requirements gathering
The system requirements entails all the functions that the system is required to be having while it
is fully implemented, these requirements are gathered using various methods and they are
obtained from the various system’s stakeholders where the gathered requirements will comprise
of the requirements that the users would like the system behave and they include the functional
requirements, users requirements and technical requirements. The correction of the system
requirements has some challenges since most of the stakeholders are not aware of exact needs
they have and therefore the requirements gathering technique is selected to gather, analyse and
implement the selected system requirements.
There are various methods that are used to gather system requirements which include the
following:
i. Interviews.
This is process of including the system’s stakeholders to correct the requirements and views and
ensuring all the gathered requirements covers the system’s functionality.
ii. Questionnaires.
The interview sometimes is not comprehensive since the respondents gives limited information ,
however the subjected questionnaires provides the respondents with some questions and this
enable them to answer by marking the choices or by writing the open ended questions answer.
The questionnaire uses open ended or close ended type of questions in which response from the
respondents is captured accordingly awaiting the analysis.
iii. Through making observations.

9
The Odd Jobs Limited System Analysis and Design
The interviewer can use the observation technique to correct the requirements where all daily
operations are identified and they can be added in the requirements list, however the interviewer
can analyse the existing system and get the available functionalities and choose any other
requirements that can be added in the existing system.
iv. Prototyping method.
The system requirements can be identified through the presentation of already developed system
prototype to the system stakeholders, then the system stakeholders are able to choose any
requirement that they don’t want in the prototype as they also suggest any additional
requirements they want to be added in the proposed system.
2.2 Plans for requirements gathering OJL
To correct the proposed system requirements is a major process and it requires to be planned to
ensure the requirements are corrected successfully and on time.
In gathering the system requirements the questionnaire will be used as the requirements
gathering tool as in the below requirements gathering plan.
Tasks Descriptions
Choice of respondent Initial stage is selecting the respondents who include the
managers, customers and the employees as well.
Choice of gathering tool In this case the most appropriate tool will be selected to be
used in gathering the requirements and for this case it will be
the questionnaire.
Preparation of questionnaire In this stage some questions are structured which are both
open ended and close ended questions and they will be given
to stakeholders for filling in.
Giving questionnaires to respondent The prepared questionnaires are then subjected to the
respondents who fill in the structured questions independently
according to their personal knowledge.
Capturing the data in analysis tool In this stage all the questionnaires are taken and the
information given by respondents is extracted and inserted in
the analysis tool like ms excel or spss tool.
Clean the captured data The data captured in the analysis tool is cleaned where the odd

10
The Odd Jobs Limited System Analysis and Design
figures are eliminated and the anomalies.
Analyse the clean data This is where the already clean data is analysed to get the most
preferred requirements from the stakeholder’s response.
Listing the final system requirements. This is where all possible system requirements are listed and
they will be submitted to development team for
implementation.
2.3 Discussion for OJL
The requirements gathering is done to ensure that the proposed mobile application system will be
having all the functional requirements needed which includes the following:
i. The proposed application should allow users registration.
ii. The proposed application should allow user login.
iii. The proposed application should enable recording of customers details.
iv. The proposed application should enable recording of new customer’s jobs.
v. The proposed system should enable the office staffs to assign the contracting staffs
some customer’s jobs.
vi. The proposed system should enable contracting staffs to update the customers invoice
and the completed jobs details.
vii. The proposed system should enable the managers to view the daily completed tasks
and income gained in each vehicle.
viii. The proposed application should enable manger to generate monthly reports for each
vehicle and the respective profits.
ix. The proposed application should enable the office staff to create a new vehicle
records.
2.4 Recommendation
The odd jobs limited company has been using manual way in the recording of the daily routine
processes which includes the recording of staffs, customer and new jobs details which is poor
way of managing the records and thus leading to poor decision making.
I therefore recommend the company to adopt the proposed system as it will boost good customer
relations, time management, good records storage and retrieval, efficient profit analysis and good
decision making.

11
The Odd Jobs Limited System Analysis and Design
Yours sincerely,
Development Team Leader
3
4
5 Part B
5.1 Event Table
Event name Event-
Type
Triggers Sources The Use
Cases
System
Response
Destinations
Create
customers
records
Temp Wants to create new
customer’s
Records.
customers creating new
staffs
records
Customer’s
records saved
System
Create
vehicles
Temp Wants to create new
vehicles
Office-staffs creating new
vehicles
Vehicle’s
records saved
System

12
DRIVERS
ri er idD v s
ll ameFu _N s
e icle idV h s_ s
VEHICLE
e icle idV h s_ s
ll ameFu _N
e i tration noR g s s_ s
ear o man act redY _ f_ uf u
a t date mainatainedL s _ _
M M TOVE EN
Mo ement idv s_
epart re placeD u _
e tination placeD s _
Mo ement atev _D
e icle idV h s_ s
The Odd Jobs Limited System Analysis and Design
records Records. records
Create
vehicle’s
movement
records
Temp Wants to create
vehicle’s movements
Records.
Office-staffs creating
vehicle
movements
records
Vehicle
movement
records saved
System
create jobs
details
records
Ext Wants to create new
jobs
records
customers creating new
jobs
records
New-job
records saved
System
Update
completed jobs
details
records
Temp Wants to update
complete jobs
records
Contracting-
staffs
Updating
complete
jobs
records
Jobs records
updated
System
Run the jobs
reports
Ext Wants to run job’s
monthly report.
Tom Smith Running the
job’s
monthly
report.
Monthly
report
produced.
Tom-smith
(Laplante, 2013).
5.2 Domain Model Class Diagram

13
T MCUS O ERS
tomer idCus s_ s
ll ameFu _N
ine no Addre eBus ss_ ss s
Telep onen noh _
mailaddreE ss
a t o dateL s _j b_
JOBS
o idJ bs_
tomer idCus s_
o ateJ bs_D
ontractin ta nameC g_s ff_
e icle idV h s_ s
o Amo ntJ b_ u
ta idS ffs_ s
TAS FFS
ta idS ffs_ s
ll ameFu _N s
Po itions
tieDu s
JOBS
o id intJ bs_ (20)
o ate ateJ bs_D D
ontractin ta name arc arC g_s ff_ v h (200)
o Amo nt intJ b_ u (20)
ta id intS ffs_ s (20)
TAS FFS
ta id intS ffs_ s (20)
ll ame arc arFu _N s v h (200)
Po itions arc arv h (200)
tie arc arDu s v h (200)
The Odd Jobs Limited System Analysis and Design
(Karumanchi, 2012).
5.3 Design Class Diagram
(Gupta, 2015).

14
Creating new staffs records
Creating vehicle movements records
Updating complete jobs records
Creating new vehicles records
Creating new jobs records
Running the job’s monthly report.
O.J.L COMPANY USE CASE DIAGRAM
ice taOff S ff
tomerCus
Tom mitS h
ontractin taC g S ff
The Odd Jobs Limited System Analysis and Design
5.4 Use Case Diagram
(Goyal,2011).
5.5 Use Case Description (intermediate)
Use case Name: Creating job records
Scenario: Wants to create a new customer job.
Triggering
Event:
Customer has some job to submit.
Brief
Descriptions:
Customer get some job, visit his nearest office, the office staffs take his details
and job description and create the new job in the information systems.
Actors: Customers, office-staffs.

15
The Odd Jobs Limited System Analysis and Design
Related use
case:
Updating complete job records.
Stakeholders: Office-Staffs: They create customer’s and jobs records.
Customer: Gives personal and job’s records details.
Pre-conditions: Customer needs his job to be done.
Post conditions: Contracting staff do the job and update the details to the system.
(Award, 2013).
5.6
6 Reference
Award,E.(2013) Systems Analysis and Design .3rd edn.Delhi:Galgotia Publications Pvt Ltd.
Gupta,B.(2015) Power System Analysis and Design.1st edn.New Delhi: S Chand & Company.
Goyal, A. (2011) systems Analysis and Design Paperback .2nd edn.INDIA:Prentice Hall India
Learning Private Limited.
Karumanchi,N.(2012) Peeling Design Patterns: For Beginners and Interviews.5th edn.New
York:CareerMonk Publications.
Laplante,P.(2013) Real-Time Systems Design and Analysis: Tools for the Practitioner.2nd
edn.New Jersey:Wiley.

16
The Odd Jobs Limited System Analysis and Design
Singh,B.(2016) Systems Analysis and Design.4th edn.Delhi:New Age International Private
Limited.
Wixom,D.(2016) Systems Analysis and Design.2nd edn. New Jersey: Wiley publishers.