A-019730-1647417034966-137850-W.M.Supun Anjana SAD

Higher Nationals
Internal verification of assessment decisions – BTEC (RQF)

INTERNAL VERIFICATION – ASSESSMENT DECISIONS
Programme title HND in Computing
Iresha Jayarathne
Assessor Internal Verifier
Unit 34: System Analysis & Design
Unit(s)
Automated system for E-Solutions Private Limited
Assignment title
W.M.Supun Anjana
Student’s name
List which assessment criteria Pass Merit Distinction
the Assessor has awarded.
INTERNAL VERIFIER CHECKLIST
Do the assessment criteria awarded match

those shown in the assignment brief? Y/N
Is the Pass/Merit/Distinction grade awarded
justified by the assessor’s comments on the Y/N
student work?
Has the work been assessed

accurately? Y/N
Is the feedback to the student:

Give details:
• Constructive?
Y/N
• Linked to relevant assessment criteria?
Y/N
• Identifying opportunities for Y/N
improved performance?
• Agreeing actions?
Y/N
Does the assessment decision need
amending? Y/N
Assessor signature Date
Internal Verifier signature Date

Programme Leader signature (if required)
Date
Confirm action completed
Remedial action taken
Give details:
Assessor signature Date
W.M.Supun Anjana System Analysis and Design 1|

Page
Internal Verifier
signature Date
Programme Leader
signature (if required) Date

Page
Higher Nationals - Summative Assignment Feedback Form
Student Name/ID
Unit 34: System Analysis & Design
Unit Title
Assignment Number 1 Assessor
Date Received
Submission Date 1st submission
Date Received 2nd
Re-submission Date submission
Assessor Feedback:
LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis methodologies
Pass, Merit & Distinction P1 M1 D1
Descripts
LO2 Produce a feasibility study for a system for a business-related problem

Pass, Merit & Distinction P2 M2
Descripts
LO3 Analyse their system using a suitable methodology.

Pass, Merit & Distinction P3 M3 D2
Descripts
LO4 Design the system to meet user and system requirements.

Pass, Merit & Distinction P4 M4
Descripts
Grade: Assessor Signature: Date:

Resubmission Feedback:
Grade: Assessor Signature: Date:

Internal Verifier’s Comments:
Signature & Date:
* Please note that grade decisions are provisional. They are only confirmed once internal and external moderation has taken place and
grades decisions have been agreed at the assessment board.

Page
Pearson Higher Nationals in
Computing
Unit 34: Systems Analysis & Design
Assignment 01

Page
General Guidelines
1. A Cover page or title page – You should always attach a title page to your assignment. Use
previous page as your cover sheet and make sure all the details are accurately filled.
2. Attach this brief as the first section of your assignment.
3. All the assignments should be prepared using a word processing software.
4. All the assignments should be printed on A4 sized papers. Use single side printing.
5. Allow 1” for top, bottom , right margins and 1.25” for the left margin of each page.
Word Processing Rules
1. The font size should be 12 point, and should be in the style of Time New Roman.
2. Use 1.5 line spacing. Left justify all paragraphs.
3. Ensure that all the headings are consistent in terms of the font size and font style.
4. Use footer function in the word processor to insert Your Name, Subject, Assignment No,
and Page Number on each page. This is useful if individual sheets become detached for any
reason.
5. Use word processing application spell check and grammar check function to help editing
your assignment.
Important Points:
1. It is strictly prohibited to use textboxes to add texts in the assignments, except for the
compulsory information. eg: Figures, tables of comparison etc. Adding text boxes in the body
except for the before mentioned compulsory information will result in rejection of your
work.
2. Avoid using page borders in your assignment body.
3. Carefully check the hand in date and the instructions given in the assignment. Late
submissions will not be accepted.
4. Ensure that you give yourself enough time to complete the assignment by the due date.
5. Excuses of any nature will not be accepted for failure to hand in the work on time.
6. You must take responsibility for managing your own time effectively.
7. If you are unable to hand in your assignment on time and have valid reasons such as illness,
you may apply (in writing) for an extension.
8. Failure to achieve at least PASS criteria will result in a REFERRAL grade .
9. Non-submission of work without valid reasons will lead to an automatic RE FERRAL. You will
then be asked to complete an alternative assignment.
10. If you use other people’s work or ideas in your assignment, reference them properly using
HARVARD referencing system to avoid plagiarism. You have to provide both in-text citation
and a reference list.
11. If you are proven to be guilty of plagiarism or any academic misconduct, your grade could be
reduced to A REFERRAL or at worst you could be expelled from the course

Page
Student Declaration
I hereby, declare that I know what plagiarism entails, namely to use another’s work and to present
it as my own without attributing the sources in the correct form. I further understand what it
means to copy another’s work.
1. I know that plagiarism is a punishable offence because it constitutes theft.

2. I understand the plagiarism and copying policy of Edexcel UK.
3. I know what the consequences will be if I plagiarise or copy another’s work in any of the
assignments for this program.
4. I declare therefore that all work presented by me for every aspect of my program, will be my
own, and where I have made use of another’s work, I will attribute the source in the correct
way.
5. I acknowledge that the attachment of this document signed or not, constitutes a binding
agreement between myself and Pearson , UK.
6. I understand that my assignment will not be considered as submitted if this document is not
attached to the assignment.
Student’s Signature: Date:

(Provide E-mail ID) (Provide Submission Date)

Page
Higher National Diploma in Computing
Assignment Brief
Student Name /ID Number
Unit Number and Title Unit 4: Systems Analysis & Design
Academic Year 2021/22

Unit Tutor
Assignment Title Automated system for E-Solutions Private Limited
Issue Date
Submission Date
IV Name & Date
Submission format
The submission should be in the form of an individual written report written in a concise,
formal business style using single spacing and font size 12. You are required to make use
of headings, paragraphs, and subsections as appropriate, and all work must be supported
with research and referenced Please provide in-test citations, reference list and
bibliography using Harvard referencing system. Please also provide a bibliography using
the Harvard referencing system.
The recommended word limit is not less than 5000 words, although you will not be
penalised for exceeding the total word limit.
Unit Learning Outcomes:
LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis
methodologies.
LO2 Produce a feasibility study for a system for a business-related problem.
LO3 Analyse their system using a suitable methodology.
LO4 Design the system to meet user and system requirements.
Assignment Brief and Guidance:

Page
*Please note that assignment guidance is for reference only and should be more specific in
detail to meet customized needs.
Assignment brief
Case study
The new automated system is designed to replace the current, manual, error-prone process
of E-Solutions private Limited. The automation of existing process is to reduce the
company’s expenses and enhance the productivity significantly. This transformation also
would support for:
1) Successful teams working
2) Completing projects on time and within budget due to a better understanding of system
requirements and tasks to be completed
3) Starting projects on time through automated project scheduling system.
In the proposed system, the Project director creates a project and a “project profile” for each
project. The creation of the project profile includes identification of project employee costs,
the assignment of tasks to the project, and the assignment of a project manager. The project
profile is consisted of project id, project personnel cost, a list of tasks assigned, and the
project manager. The Project director also creates the teams for a given project, assigns
employees to the teams, and assigns a team leader. The Project manager is responsible for
assigning tasks to various teams working on the projects(s). The Team Leader assigns tasks
to the team members.
Additional functionality includes:

 Produce and update information about different software projects, project teams, specific
team member assignments and team skills.
 Perform function point analysis to identify the personnel cost of the project and provide
information to generate invoices upon completion of project phases.
 Monitor projects and identify completed tasks and ongoing tasks of each project.
Activity 01
Discuss traditional and agile system analysis methodologies used in the industry by
Page
comparing and contrasting the strengths and weaknesses of them. Critically evaluate two
methodologies by referring to the examples to support your answer.
Activity 2
Produce a feasibility report for the scenario given above and assess the importance of
feasibility criteria used for the system investigation. Critically evaluate the strengths and
weaknesses of feasibility study with relevant to the proposed solution.
Activity 3
Analyse and review the system requirements of the proposed solution given in the scenario
using a suitable methodology. Functional and non-functional requirements of the system
should be clearly mentioned. Assessment of the effectiveness and suitability of the chosen
methodology should be provided with proper justifications.
Activity 4
Produce a system design specification for the above scenario and assess the effectiveness
of your design and the methodology used with reference to how it meets the user
requirements.
Your system design specification should include architectural design, interface design,
database design, and program design.

Page
W.M.Supun Anjana System Analysis and Design 10 |
Page
Grading Criteria Achieved Feedback
LO1 Evaluate the strengths and weaknesses of the

traditional and agile systems analysis methodologies.
P1 Discuss the strengths and weaknesses of the traditional 15 – 23

and agile systems analysis methodologies.
M1 Compare and contrast the strengths and weaknesses of 24 – 31

the traditional and agile systems analysis methodologies.
LO2 Produce a feasibility study for a system for a

business-related problem.
P2 Produce a feasibility study for a system for a 33 – 39

business related problem.
M2 Evaluate the relevance of the feasibility criteria on the 38 – 41

systems investigation for the business related
problem.
38 – 41
LO1 & LO2
D1 Critically evaluate the strengths and weaknesses of the
traditional and agile methodologies and feasibility study.
LO3 Analyse their system using a suitable

Methodology

Page
P3 Review a system using a suitable methodology for a 42 – 51
business-related problem.
M3 Analyse the effectiveness of the methodology used in 50 – 72
providing a solution for a given business context.
LO4 Design the system to meet user and system

Requirements
P4 Design a fully functional system to meet user and 73 – 76

system requirements for the business related
problem.
M4 Assess the effectiveness of the system design with 76 – 81

reference to the methodology used and how the design
meets user and system requirements.
LO3 & LO4 50 - 97

D2 Justify the choice of the analysis methodology used in
the context of the business problem.

Page
Table of Contents
Activity 01................................................................................................................................14
1.1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis
methodologies......................................................................................................................14
1.1.4 weaknesses of traditional methodology..................................................................24
1.1.5 strengths of agile methodology...............................................................................25
1.1.6 weaknesses of agile methodology...........................................................................26
Activity 02............................................................................................................................32
Activity 03................................................................................................................................41
3.1 Analyse and review the system requirements of the proposed solution given in the
scenario using a suitable methodology................................................................................41
Analyze the effectiveness of the methodology used in providing a solution for a business
context..................................................................................................................................54
Activity 04................................................................................................................................72
4. Design the system to meet user and system Requirements...........................................72
4.1 Assess the effectiveness of your design and the methodology used with reference to
how it meets the user requirements......................................................................................72
4.2 System design specification...........................................................................................73
Content.................................................................................................................................73
Database design................................................................................................................78
References................................................................................................................................97

Page
Figure
Figure 1 model.........................................................................................................................17
Figure 2 model.........................................................................................................................18
Figure 3 prototyping.................................................................................................................19
Figure 4 main types..................................................................................................................20
Figure 5 agile methodology......................................................................................................21
Figure 6 scrum..........................................................................................................................22
Figure 7 extreme programming................................................................................................23
Figure 8 visualizing..................................................................................................................24
Figure 9 use case diagram........................................................................................................77
Figure 10 login flow chart........................................................................................................78
Figure 11 add user flow chart...................................................................................................79
Figure 12 Database design.......................................................................................................80
Figure 13 class diagram............................................................................................................81
Figure 14 contex diagram.........................................................................................................82
Figure 15 login form................................................................................................................83
Figure 16 dashboard.................................................................................................................83
Figure 17 create_project...........................................................................................................84
Figure 18 view and edit project................................................................................................84
Figure 19 delete project............................................................................................................85
Figure 20 add tasks...................................................................................................................85
Figure 21 project manager dashboard......................................................................................86
Figure 22 team leader dashboard..............................................................................................86
Figure 23 assign task to member..............................................................................................87
Figure 24 showing complete task.............................................................................................87
Figure 25 admin dashboard......................................................................................................88
Figure 26 add user....................................................................................................................89
Figure 27 edit user....................................................................................................................89
Figure 28 delete user................................................................................................................90
Figure 29 login interface..........................................................................................................90
Figure 30 project director dashboard........................................................................................91
Figure 31 create project............................................................................................................92
Figure 32 view and edit project................................................................................................93
Figure 33 delete project............................................................................................................93
Figure 34 manager add task......................................................................................................94
Figure 35 project manager dashboard......................................................................................94
Figure 36 team leader dashboard..............................................................................................94
Figure 37 assign task to member..............................................................................................95
Figure 38 completed task.........................................................................................................95
Figure 39 admin dashboard......................................................................................................96
Figure 40 add user....................................................................................................................97
Figure 41 edit user....................................................................................................................97
Figure 42 delete user................................................................................................................98

Page
Overview Analysis and Design of Systems
Systems development can be divided into two categories: systems analysis and systems
design. The process of planning a new business system, or one to replace or complement an
existing system, is known as system design. However, before we can begin planning, we
must first gain a full understanding of the current system. And figure out how computers
may be used to make the company's operations more efficient. As a result, system analysis
involves the process of acquiring and evaluating data, as well as diagnosing problems.
Difficulties, and then recommending system improvements based on the data. The systems
analyst's job is to do just that.
System Analysis
The process of studying a system such that an information system may be examined,
modeled, and a logical alternative can be chosen is known as systems analysis. There are
three reasons why systems analysis initiatives are started: issues, opportunities, and
instructions. Systems analysts, sponsors, and users are among those participating. The
systems development life cycle can be used to explain the process of creating systems. A
methodology refers to the tasks, processes, and tools employed by the systems development
life cycle. Traditional, information engineering, and object-oriented approaches are the three
types of techniques. CASE tools are computer-assisted software applications that support
certain methodology.
System Design
A systemic approach is essential for a well-functioning and coherent system. To take into
consideration all of the system's connected variables, a bottom-up or top-down strategy is
required. A designer employs modeling languages to describe information and knowledge
in a system structure that is determined by a set of consistent rules and definitions.
Graphical or textual modeling languages can be used to create the designs.

Page
Activity 01
1.1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis
methodologies.
Discuss traditional and agile system analysis methodologies
The majority of businesses today are focused on generating high-quality products and
increasing customer happiness, and the problem is determining whether to employ
traditional development procedures or agile development processes to accomplish this.
Though all methodologies have benefits and drawbacks, making the right selection when
starting a new project is crucial. The following are the most crucial considerations when
choosing a development methodology:
1. Business Need
2. Customer Perception
3. Project Timeframe
Traditional Methodology
Project management in the traditional sense is a well-established discipline that entails

completing tasks in a sequential order. The steps in the process are inception, planning,
execution, monitoring, and closing. Traditional project management emphasizes linear
processes, documentation, upfront planning, and prioritization. In the traditional approach,
time and budget are changeable, whereas needs are fixed, resulting in financial and timeline
difficulties. Project managers must follow the PMBOK® standard methodology, which
provides tools and procedures for each step.

Page
Figure 1 model
Waterfall model
The waterfall model is a sequential technique in which each process's core activity is
represented as a discrete phase, which is then organized linearly. It is assumed that you have
finished each step completely and carefully before moving on to the next level. This is the
first time that a software development life cycle model has been widely used to ensure
project success. The waterfall model is depicted in Figure 2 in its most basic form. Consider
the sound of water cascading down the stairwell. ( mezquita,2020 )

Page
Figure 2 model
Prototyping
A prototype is a quick-built version of a system or a component of a system to evaluate

client needs or the practicality of specific design decisions. When the user is confused of the
subtleties of the input or output, as well as the demands, this paradigm comes in handy.
A prototype is used to determine software needs in the same way that a prototype is used to
determine hardware requirements. The developer and the customer define the overall aim,
then identify any existing needs and determine how much extra detail is needed. Then come
up with a quick design that will lead to the prototype being built. The prototype was
evaluated by the user, and the results were used to refine the program's requirements.
Iteration occurs as the prototype is fine-tuned to meet the customer's requirements. . (Lewis,
2019)

Page
Figure 3 prototyping
Spiral model
The spiral model is an evolutionary software process paradigm that combines the iterative
nature of prototyping with the regulated and systematic characteristics of the linear spiral
model. It enables the production of incremental software versions at a high pace.
This spiral model software was used to create a series of incremental releases. Early
iterations result in system versions that are increasingly complete. Each step creates a
finished product that is then improved in the next phase, similar to how spiral improves
each phase.

Page
Figure 4 main types
Agile Methodology
Agile methodologies are product development approaches that are consistent with the Agile
Manifesto's values and principles for software development. Agile techniques attempt to
produce the proper product through small cross-functional self-organizing teams that supply
small pieces of functionality on a regular basis, allowing for frequent customer input and
course correction as needed.
In doing so, Agile tries to address the issues that traditional "waterfall" techniques of
delivering huge goods over extended periods of time encounter, such as client requirements
changing frequently and resulting in the delivery of incorrect products (smart, john).

Page
Figure 5 agile methodology
Scrum
Scrum is a framework for facilitating teamwork. Scrum encourages teams to learn via
experiences, self-organize while working on an issue, and reflect on their victories and
losses to continuously improve, much like a rugby team (from which it gets its name).
While the scrum I'm referring to is most commonly utilized by software development teams,
the concepts and lessons it teaches may be applied to any type of teamwork. One of the
reasons scrum is so popular is because of this. Scrum is a combination of meetings, tools,
and roles that work together to help teams structure and manage their work. It's sometimes
referred to as an agile project management framework (atlassian, 2022).

Page
Figure 6 scrum
Extreme programming
Extreme programming is a type of software development process that falls under the
umbrella of agile methodologies. The purpose of XP is to allow small to mid-sized teams to
generate high-quality software while adapting to evolving and changing needs. It is based
on values, principles, and practices. XP distinguishes itself from other agile approaches by
emphasizing the technical components of software development. Because adopting
engineering principles allows teams to generate high-quality code at a sustainable speed,
extreme programming is quite specific about how engineers work. In a word, extreme
programming is about taking good practices to their logical conclusion. Because pair
programming is beneficial, let's do it all the time. Let's test before the production code is
even developed, because testing early is good (digite, 2022)

Page
Figure 7 extreme programming
Crystal
The Crystal technique is an agile software development strategy that focuses on people and
their interactions rather than processes and technologies when working on a project. Alistair
thought that people's abilities and talents, as well as their communication style, had the most
impact on the project's outcome.
The most versatile and lightest technology is crystal. It focuses on the people and
connections that emerge while working on an agile project, as well as the business-
criticality and priority of the system. The Crystal technique is founded on the notion that
each project has unique characteristics that demand a slightly modified set of policies,
methodologies, and processes. As a result, it includes Crystal Orange, Crystal Clear, and
Crystal Yellow among its agile process models. Each model has unique characteristics that
are determined by factors such as project priorities, team size, and system criticality.
(activecollab.com)

Page
Kanban
Kanban is a highly visible workflow management method that enables teams to actively
manage product creation (with a focus on continuous delivery) while reducing the stress
associated with the software development lifecycle (SDLC). It's becoming increasingly
popular among Lean software development teams.
Kanban is founded on three principles: visualizing the process, reducing the amount of work
in progress, and enhancing the flow of work. The Kanban approach, like Scrum, aims to
make it easier for teams to work together more successfully. It encourages ongoing
collaboration and strives to create the most efficient workflow possible in order to establish
an environment that supports active and continuous learning and improvement. (Brush &
Silverthorne, 2019)
Figure 8 visualizing

Page
Strengths of Traditional Methodology
Traditional project management (Waterfall Methodology) is a linear approach in which

tasks are completed in a predetermined order. The project follows a preplanned set of stages
in this strategy, with the assumption that the requirements remain constant but the budget
and project duration are flexible. This method is better suited to projects where scope
changes are unlikely.
The Project Manager's office is responsible for the entire project and is held accountable for
the outcomes. Customers have no say throughout the project implementation phase, other
from the project planning process. In the same way, team members are expected to escalate
any issues to their manager, who has the last say.
1.clear direction
Because everything is pre-planned, everyone on the team is aware of their roles and the
project's requirements. This permits them to work quickly and efficiently with little
supervision.
2. high level of control

In a typical setup, the project manager's office has nearly all control, and even minor
changes must be approved by the manager. This eliminates departures from the project's
intended scope.
3. single point of accountability

Because the project managers have complete control, they will naturally be held responsible
for the project's success or failure. Stakeholders always know who to contact during the
project to acquire all of the relevant updates, rather than having to contact many persons.
4. clear documentation
The traditional project management style relies heavily on proper documentation. The
documents not only standardize the entire process, but they can also be used as a guide for
future initiatives.

Page
1.1.4 weaknesses of traditional methodology
1. it is slow
If your client's needs aren't clear, the project will take longer to complete. Due to the
difficulty of changes in traditional project management's sequential technique. Changes can
throw the sequence off, causing the next development stage to be skipped until the
preceding one is finished.
2. no customer focal point

In every development phase, there isn't much room for the customer's feedback. Until the
product is ready, the clients are not involved in or open to the full development process. It
will be a time-consuming phenomenon if it is not in accordance with the client's
specifications. It's too late at this point to examine the product's marketing accountability.
The highest goal in today's environment is to make the consumer happy. Because their
contentment will define your application development company's true market position.
3. the absence of the central authority

There are individual subcontractors controlling the ropes of development. There isn’t any
singular dynamic teamwork and leadership as a central authority.
4. lack of coordination
The subcontractors are involved as individuals, not as a singular dynamic team. There is no
attempt is made to have unity, mutual teamwork, and commitment to the development. The
lack of coordination delays development and can cause some serious issues.
5.changes are difficult
It is almost certainly hard, time-consuming, and expensive to go back and fix an application
once it has reached the testing stage. To incorporate any changes, you may need to start
over (wadic, 2022).

Page
1.1.5 strengths of agile methodology
1. Improved quality
When using an agile methodology, teams can breakdown projects into sprints and
collaborate with one another to provide high-quality results.
This method allows teams to deal with common project pitfalls such as managing costs,
scope creep, and not respecting deadlines.
Moreover, there is a testing phase for every task which allows teams to identify and solve
issues quickly to avoid any long-term negative consequences.
2. Speed and flexibility

The second benefit of using agile is its speed and flexibility thanks to a Scrum framework.
This practice places change at the heart of its development. If there is a deviation from the
initial objectives, the approach and processes are immediately adapted to meet the new
needs.
The Scrum method was originally designed for software development teams and their
technical projects. However, today, it can be used for a wide range of projects, especially in
marketing.
Scrum is one of the most used agile methods because it can be set up very quickly.
Furthermore, it is based on an empirical approach, allowing self organizations to make room
for changes as your project grows.
3. Complete visibility of the progress of each project in real-time
Another advantage of using an agile approach is the transparency of each project thanks to
frequent exchanges with clients. This allows them to feel more involved and ask for changes
throughout the project.
Moreover, the teams that are involved can show their progress to the client along with the
obstacles that they have encountered.

Page
This establishes a relationship of trust and collaboration between the team and the client and
can lead to improved customer satisfaction and higher business value.
4. Stakeholders engagement
A key part of using an agile method is the involvement of stakeholders when completing
projects.
By collaborating with different stakeholders during each phase of the project, you will build
a dynamic system based on the trust and confidence of each team member and forge
stronger relationships within your teams.
To use this method effectively, it is recommended to have stakeholders participate actively

as the project progresses. This will allow them to make make sure that tasks are being
completed according to the plan and make changes if necessary.
5. Cost control
An agile method can also be used to improve cost control. After each stage, the team
reviews the budget when making future decisions. Then, they decide if they will continue,
suspend or cancel tasks or even the project itself.
This is an essential part of project management as it allows teams to understand the costs of
each feature with simplicity, which will then be taken into account when making strategic
decisions.
1.1.6 weaknesses of agile methodology
1: Lack of documentation
This is one of the biggest issues faced when teams transition from Waterfall project
management to an Agile framework. Agile teams condense large volumes of data into
smaller user stories, which don’t contain a great amount of detail. This can make it difficult
for a developer to grasp the exact customer requirements. Without a clearly documented

Page
plan or an official process to follow, team members can easily get confused when moving
through project stages.
2: Scope creep
Another major obstacle is scope creep. Customer needs change constantly, inevitably
leading to a widening of the project scope. Deliverables multiply quickly, and new features
are often added to the workload. Some requirements may need to be rewritten entirely or
replaced with updated ones. Teams can become overwhelmed and lose track of these
requirements, unsure of which ones to prioritize.
3: High demands on time
Time is another consideration to add to the list of Agile challenges. Team members must
make room in their schedule for daily standup meetings, which can disrupt their workflow.
What’s more, the Agile philosophy requires developers to engage in constant collaboration
with testers, clients, and other project stakeholders. This high level of interaction can place a
significant strain on Agile team members and their time management abilities.
4: Unsuitable for long-term projects
Finally, one of the most common Agile problems occurs when teams try to make the
methodology work for unsuitable projects. Agile iterations are designed to produce smaller
deliverables incrementally, which is ideal for software development. However, this level of
fragmentation would not be compatible with a long-term project. For example, in a
construction project such as building a house, the final deliverable is fixed and change is
undesirable, making it more suited to a Waterfall framework.
To limit the potential disadvantages of Agile, you should research your preferred Agile
project management framework thoroughly before implementing it in your organization. If
you already use an Agile framework, consider the question posed by professional services

Page
firm Deloitte: “How fragile is your Agile?” Document your existing pain points and
brainstorm ways to strengthen your future Agile projects.
Compare and contrast the strengths and weaknesses of the traditional and agile
systems analysis methodologies
Strengths Weaknesses
Traditional Requirements are specified in detail Reduced interaction with the
Methodology and writing business stakeholders, which can
Scope changes can be easily lead to business expectations not
analyzed being met and re work.
Rigorous detailed design works is Business members do not get to see
conducted for complex systems the development result until User
Ability to coordinate and manage Acceptance Testing (UAT), which
large distributed teams can lead to re work.
Predictable budgets, against delivery Lack of flexibility does not easy
Limited amount of time required from enable changes of business
the business key strategies points circumstances, and changes are more
difficult to implement.
Loss of intangible knowledge
between phases.
Agile Methodology Rapid feedback from users increases Difficulty in coordinating large
the usability and quality of the projects
application Lack of documentation, which is
An ability to easily roll out difficult for large complex and
functionality in stages, which meets legacy interfaced systems that can
business requirements. make support and sign off difficult.
Increased ownership by the business, Ongoing end date with lack of clarity
as the product owners more easy to as to what will be delivered when the
stop the project and use what has project finishes and for the budget
been completed as the process will be.
delivers frequent releases.
Regularly meets specific measurable

Page
objectives.
Critically evaluate two methodologies by referring to the examples to support your

answer.
Project complexity
Traditional
Because it takes a linear approach, this strategy is best suited for small or simple jobs.
Changes in the project's complexity or other factors can obstruct the entire process, forcing
the team to restart from the beginning.
Traditionally, corporate applications such as Customer Relationship Management (CRM)
systems, Human Resource Management Systems (HRMS), Supply Chain Management
Systems, Inventory Management Systems, and Point of Sale (POS) systems for retail chains
were developed using the traditional approach. The traditional method is used because it
reduces project complexity.
Agile
In the case of complex projects, this is the ideal methodology to use. A complicated project,
as contrast to a simple project, may include multiple interconnected phases, each of which is
dependent on many others. Agile techniques are suited for large and challenging projects.
Adaptability
Traditional:
This strategy is predicated on the idea that a phase will not be revisited once it is
completed. As a result, it is impossible to adapt to changes in the work schedule that occur
frequently. If an unanticipated necessity arises or a variation is necessary, the old approach
fails to respond to new developments. Only restarting the process from the beginning is an
option. A lot of effort and time is wasted in the process.

Page
Agile:
This system has a high adaptability factor because it is not linear. Complex projects are
made up of several interconnected stages, each of which can influence the others. Project
managers can take calculated risks in such environments because there is a high possibility
of high adaptability.
Scope for feedback and changes
Traditional:
Every method is explicitly documented and established from the start of the project in the
traditional approach. It is unable to handle any big change or feedback that may demand a
procedure revision. With only a few exceptions, the project delivery timeline and budget are
set in stone the majority of the time.
Agile:
This technique has a high level of feedback and adjustment acceptance. The method is
incredibly adjustable, and it allows for continuous input, which helps to produce a better
result within the project's deadline. (Carr, 2021)
Transparency
Traditional
Traditional:
In a traditional project management style, all critical decisions are made by the project
manager or a small group of senior personnel. Other members of the team are unable to
track progress in the form of deliverables from start to finish. Transparency for other silos is
sometimes lost as a result of work being done in silos.

Page
Agile:
In agile project management, every decision and plan is visible. The product owner, team
members, and clients are all involved in making decisions and modifications. While
developing, reviewing, and testing a product, the agile methodology allows team members
to see the work progress in depth and make informed judgments.
Flexibility
Traditional:
Traditional or waterfall project management employs a top-down approach. That means you
won't be able to make any last-minute changes without affecting the job process or
outcomes.
Agile:
Compared to traditional project management, agile project management is significantly

more versatile. Agile project management gives your team members the flexibility to make
changes to their product or work process while they're on the job. Agile project
management is characterized by a lack of rigid structure and a focus on the product. The
agile project management technique is popular because of its adaptability.

Page
Activity 02
Produce a feasibility study for a system for a business-related problem.
Produce a feasibility report for the scenario
Feasibility study
A feasibility study looks at the chances of completing a project successfully, taking into
account legal, economic, technological, operational, scheduling, scope, and other factors.
Before investing too much time and money in a project, project managers should do a
feasibility study to assess the project's potential negative and positive consequences.
The 05 main Feasibilities
1. Technology and System Feasibility

2. Economic Feasibility
3. Legal Feasibility
4. Operational Feasibility
5. Schedule Feasibility
Technology and System Feasibility
The technological resources accessible to the organization are the subject of this
examination. It aids companies in determining whether technical resources are adequate for
the job and whether the technical team is capable of turning concepts into operational
systems. The proposed system's hardware, software, and other technical needs are also
evaluated for technical viability. An organization, for example, would not want to try to
install Star Trek's transporters in their facility because it is currently not technically feasible.
Economic Feasibility

Page
This evaluation usually includes a cost-benefit analysis of the project, which aids businesses
in determining the project's viability, cost, and benefits before allocating financial resources.
It also functions as an impartial project assessment and boosts project credibility by
assisting decision-makers in determining the proposed project's positive economic
advantages to the business.
Legal Feasibility
This assessment looks into if any component of the proposed project violates any
regulations, such as zoning rules, data protection legislation, or social media laws. Assume a
company wishes to develop a new office building at a specified location. A feasibility study
may discover that the desired location for the company is not designated for that sort of
business. That organization has just saved a lot of time and effort by discovering early on
that their idea was not feasible.
Operational Feasibility
This evaluation entails conducting research to evaluate whether—and to what extent—the

organization's needs can be addressed by completing the project. Operational feasibility
studies also look at how a project plan meets the requirements specified during the system
development requirements analysis phase.
Schedule Feasibility
This assessment is the most important for project success; after all, a project will fail if not
completed on time. In scheduling feasibility, an organization estimates how much time the
project will take to complete.
Schedule Feasibility ensures that a proposed project are often completed before the project
or expertise becomes obsolete or unnecessary.
Can the restaurant or the IT team control the factors that affect schedule feasibility?
What is the conditions that has got to be fulfilled during the event of the system?

Page
Will the project management techniques be available to coordinate and control the project?
Will a project manager be appointed?
This system is written in java with a graphical interface (GUI). it's the power to

figure with general computer specifications as listed below and can be easy to include into
future improvements to the system.
Cost
The automation of existing process is to scale back the company’s expenses and enhance
the productivity significantly by this stuff,
Software Requirement
Operating System = Windows 10
Hardware Requirement
1.CPU = i5
2.RAM = 8GM
3.VGA = 1GB
4. MOTHERBOARD = Asus ROG Crosshair VII Dark Hero. The best x570 ever created
To Developer
This software is Rs.345,000.00. By signing a contract, you have to pay 10% of the money
first and then pay the rest after building the software.
To E-solution private limited

E-Solutions Pvt. Ltd. can reduce or maintain personal power. And successful
teamwork to increase productivity. Complete the project on time and start projects on time
through the automated project schedule system.
Developers,

Page
Here 10 software engineers have been deployed for this. Also, this project should be
completed ahead of schedule. Systems analysts should look at how long it takes to create a
system.
The project is expected to be completed in 10 months. And this must be carefully monitored
to prevent future changes.
Cost
This can be handled by one person. So the company can reduce costs by using automated
software.
Productivity
This GUI is easy for the user to handle
Solutions,
Faulty process: Problems are less here
Estimation of Software development life cycle
1.Requirement Gathering = 1 month

2.Analysis and Specification = 1 month
3.Designing = 3 month
4. Coding = 2 moth
5.Testing = 2 months
6.Release and Maintenance = 1 month
Produce a feasibility study for a system for a business-related problem
Feasibility study characteristics and best practices.
Feasibility studies don't always approve or reject projects or proposals outright. In most
circumstances, a feasibility study will give you a clear image of your financial, scheduling,
and logistical strengths, allowing you to tailor the scope of your proposal to your

Page
capabilities.
These studies also provide many other benefits including.
Providing analysis into team trends and characteristics

Enhancing the success rate of your projects
Increasing insight for better project deciding
Clarifying the necessity for the project
Bringing to light new opportunities that weren’t obvious from the beginning

Improving the main target of your team members
A feasibility study has several qualities, the most important of which are the key questions
of feasibility. Most feasibility studies must answer these five issues in order to justify a
replacement project, strategy, or method:
is that this plan technically feasible?
To begin, this question will help you decide whether your organization has the
technical resources necessary to complete this project successfully.
This entails assessing all of the gear, software, and other technical assets you have available
and determining whether they match the needs of your new project.
is that this plan legal?
Is your company able to meet all of the project's requirements, laws, and regulations? If
your project doesn't match the legal barrier for completion, which includes everything from
data protection rules to putting together specifications, it's a complete no-go. Otherwise,
you'll be halfway through your project before realizing that your team isn't following some
obscure rule, which will waste time and money later.
is that this plan operationally feasible?
Will this suggested project address the challenges you're hoping to address? Is that a
dependable, maintainable, and cost-effective solution? It's pointless to invest time, money,
and effort into a project that won't deliver high-quality results for your team or stakeholders.

Page
is that this plan feasible within an inexpensive period of time?
Finally, we reach the foremost obvious of the feasibility questions.
This is where you'll assess whether or not this project will provide the supposed value
needed to justify its cost. you'll assess this area of feasibility supported several various
factors , including:
Projected profitability
The total cost of completion
Estimated investment by outside parties
No matter how incredible a project could seem , if the numbers don’t add up, then either
you’ll need to hunt down larger budgets or the plan isn’t well worth the riskInvalid source
specified.
Evaluate the relevance of the feasibility criteria on the Systems investigation for the
business-related problem
Investments in information technology have become crucial for firms to improve the quality
of their products and services. Investment in information technology or information system
has increased over a decade. “IT spending has grown 166 percent per decade since the
1970s as companies looked to technology as the “silver bullet” to spur their business
growth” (Cohan 2005). Investing in IT/IS is very crucial for all businesses in every
industries. For example, “The foodservice operators must adopt technology as more than
simply a cost of doing business. They must view it as a tool to help them attain their
strategic business objective.” (Rubinstein 1997) At the same time, there are numerous
possible IT projects that firms could invest in, such as, e-commerce, ERP system, new
software development, etc. Due to the limited resources and time, companies must wisely
choose to invest in the projects that match their business and economic goals. Therefore, the
feasibility study is an integral part during the planning phase of the system development life
cycle (SDLC).One of the feasibility factors that need to be assessed is economic feasibility.
Management can assess economic feasibility by doing the cost-benefit analysis, as well as
using financial techniques, such as time value of money or break-even point analysis. In

Page
addition to the economic feasibility analysis, this paper will also look at some other
feasibility factors, such as technical, operational, scheduling, legal and contractual, and
political feasibility.A feasibility study, also known as feasibility analysis, is an analysis of
the viability of an idea. It describes a preliminary study undertaken to determine and
document a project’s viability. The results of this analysis are used in making the decision
whether to proceed with the project or not. This analytical tool used during the project
planning phrase shows how a business would operate under a set of assumption, such as the
technology used, the facilities and equipment, the capital needs, and other financial aspects.
The study is the first time in a project development process that show whether the project
create a technical and economically feasible concept. As the study requires a strong
financial and technical background, outside consultants conduct most studies. (Matson
2000).According to the CHAOS report (2004) by the Standish Group, 15% of IT projects
were canceled before they ever got completed in 2004. 20% of the projects were cost over
43% of their original estimate. Also, only 34% of the software projects were complete on
time and on budget (even though it’s up from 16.2% in 1994).
Therefore, before investing in the proposed project, one must determine whether that IT
projects can be economically viable and the investment advantages outweigh the risks
involved (Matson 2000). Also, many IT projects are quite expensive to conduct and it also
involve unfamiliar risks.
“IT spending has grown 166 percent per decade since the 1970s as companies looked to
technology as the “silver bullet” to spur their business growth. Yet, with all the billions
spent, the returns on those investments are hard, if not impossible, to fully gauge. (Cohan
2005)
Moreover, there are numerous possible IT projects that firms could invest in. If companies
had unlimited resources and infinite time, all projects would be feasible (Pressman 2005).
However, in the real world business, there are problems of scarcity of both time and
resources. Management is constantly faced with a wide array of possible investment
alternatives and forced to choose one project over the others. Also, most projects must be
developed within the time constraints and under the limited budget.
The feasibility study allows us to preview the potential outcome and to decide whether they
should continue. Although the cost of conduct this study may seem high, there are relatively

Page
minor when compared with the total project cost. This small initial expenditure on
feasibility study can help to prevent larger loss later.
The right marketing strategy also can be uncovered with a feasibility study.

Determining the way to properly reach the tragic audience may be a vital step in creating a
viable business in any region. the situation of the business and the way accessible to
the audience also will be an element . A late night pizza delivery
business wouldn't perform well if based out of a mall that closes at 9 pm.
Finding out if your product or service is needed , if the buyer is capable and can ing to
spend thereon and will they need access thereto once they want is can all be determined
with a feasibility study. If a business skips this step within the development of their
product, they alright might be throwing their investment dollars awayInvalid source
specified..
Critically evaluate the strengths and weakness of the feasibility study
Conducting a feasibility study
1) Conduct a Preliminary Analysis. ...

2) Prepare a Projected Income Statement. ...
3) Conduct a Market Survey, or Perform Market Research. ...
4) Plan Business Organization and Operations. ...
5) Prepare an Opening Day Balance Sheet. ...
6) Review and Analyze All Data. ...
7) Make a Go/No-Go Decision. ...
8) Feasibility Analysis Definition.
Cons of conducting feasibility study
At first the analysis is just on paper and this will not highlight any real practical problems
resulting a total failure of the business idea. To overcome this problem you should make
better simulations and reiterations to minimize any gap between the predicted and actual
situations.
another cons is the analysis may take some time & effort.,Finally it may be costly
depending on the industry type.

Page
method basically put more specialise in quality development , simplicity and enhancing
knowledge
from change incorporation. Several Agile methodologies like Scrum, eXtreme programing
(XP), and Lean
work well with the organization but even have potential risks related to them. These Agile
methodologies are often easily misunderstood. it's also difficult to manage methods like
Scrum in an
organization because it requires all team players to be motivated.
The core engineering processes are well defined and followed properly
because they're usually life
critical products. Consider an example of the engineering discipline, it's important that the
engineers
properly design and deliver whatever they create . People think software development is
different from the
engineering design practice. While every other discipline follows almost an
equivalent engineering process,
software development has different approaches towards development. If these engineering
design
approaches are integrated within the present software development practices, then there
would be less failure
and the process would end up to be more advantageous.
The rest of the paper is organized as follows – section 2 consists of the research process that
was wont to
do this systematic review. It provides keywords that were wont to look for research
papers and therefore the
inclusion and exclusion criteria wont to select important papers. Section 3 consists of the
research question.
Section 4 has the related work and section 5 is that the conclusion and future
directionsInvalid source specified..

Page
Activity 03
3.1 Analyse and review the system requirements of the proposed solution given in the
scenario using a suitable methodology
Requirement’s analysis, often known as requirements engineering, is a method for

determining a new product's needs and expectations. It entails constant communication with
the product's stakeholders and end-users to establish expectations, manage issues, and
document all of the product's important requirements. Sharing the vision of the finished
product with clients is one of the most difficult tasks every company has. As a result, a
business requirements study necessitates collaboration among all key stakeholders, software
engineers, end-users, and customer managers in order to arrive at a shared understanding of
what the product should accomplish. This is always done at the start of a project to ensure
that the end product meets all of the specifications.
From What to How: Software engineering task bridging the gap between system
requirements engineering and software design.
3 Orthogonal Views: Provides software designer with a model of:
system information (static view)

function (functional view)
behavior (dynamic view)
Software Architecture: Model are often translated to data, architectural, and component-

level designs.

Page
Iterative and Incremental Process: Expect to try to to a touch little bit of "> little bit
of design during analysis and a touch bit of analysis during design.
What is Requirement?
Requirement analysis techniques
A software requirement could be a feature that the user requires to solve a problem or
achieve a goal. To put it another way, a requirement might be a software feature that a
system or system component must meet or possess in order to comply with a contract,
standard, specification, or other formally enforced paperwork. Finally, we want to produce
high-quality software that satisfies clients' real-world requirements on time and on budget.
The ability to convey the vision of the final product with the customer is maybe the most
difficult problem that software engineers confront.
During the course of a project, all stakeholders - developers, end users, software managers,
and customer managers - must agree on what the product will be and do, or someone will be
surprised when it arrives. Software surprises virtually never turn out to be good news. As a
result, we'd like to find a technique to accurately capture, interpret, and convey the voice of
the customer while expressing software requirements.
Activities for Requirement Analysis
Software requirement refers to a requirement that software must meet in order to improve
the quality of the software product. These requirements are a form of user expectation from
a software product that is crucial and must be met by the software. To analyze something
implies to look at it in a systematic and detailed manner in order to learn all of the
information about it.
As a result, software requirement analysis simply entails a thorough examination, analysis,

and description of software needs in order to satisfy actual and necessary requirements in
order to solve a problem. Analyzing Software Requirements entails a number of processes.
The following are a few of them:

Page
Eliciting requirements
the task of communicating with consumers and users in order to determine their needs. This
is sometimes referred to as needs collecting.
Analyzing requirements.
Requirements analysis entails regular communication with system users to determine

specific feature expectations, resolution of conflict or ambiguity in requirements as
demanded by various users or groups of users, avoidance of feature creep, and
documentation of the entire project development process from beginning to end. Rather of
attempting to bend user expectations to match the criteria, energy should be devoted into
ensuring that the finished system or product adheres to client needs.
Requirements modeling.
Requirements modeling is a method used in software development projects to continuously

evolve requirements and solutions through collaboration and teamwork. You may ensure
that your team meets the specific needs of the stakeholders by employing this strategy of
cross-functional and self-organizing teams.
Review and retrospective.
Requirements could be documented in various forms, like natural-language documents, use

cases, user stories, or process specifications.
Review and retrospective: Team members reflect on what happened within the iteration

and identifies actions for improvement going forward.
Requirements analysis may be a team effort that demands a mixture of hardware, software
and human factors engineering expertise also as skills in handling people. Here are the
most activities involve in requirement analysis:

Page
Identify customer's needs.
Evaluate system for feasibility.
Perform economic and technical analysis.
Allocate functions to system elements.
Establish schedule and constraints.
Create system definitions.
Requirement Analysis Techniques
The process of identifying the expectations of users for an application that is to be built or
upgraded is known as requirements analysis. It includes all of the tasks that are carried out
in order to determine the demands of various stakeholders. As a result, the term
"requirements analysis" refers to the process of analyzing, documenting, validating, and
managing software or system requirements. High-quality requirements are written,
actionable, quantifiable, tested, and traceable, and they aid in the identification of business
possibilities. They are also defined to make system design easier.
Two types of questionnaires:
Fixed-format questionnaires:
The purpose of fixed-format questionnaires is to collect information from the predefined

format of questions. Users are allowed to settle on the result from the given answers. There
are three sorts of fixed-format questions: multiple-choice questions (Yes or No type), rating
questions (Strongly Agree, Agree, no opinion, Disagree, strongly disagree), ranking
questions.
Free-format questionnaires:

Page
In free format questionnaires, users are allowed to answer questions freely without an
instantaneous response. The results also are useful in learning about the emotions,
opinions, and experiences of the respondents.
Interview
"An interview could be a method of predicting future job performance based on applicants'
oral responses to oral questions."
The interview is the most important part of the entire selection process.
It's the first step in gathering more information about a candidate. It's a concept for
evaluating a candidate's job-related knowledge, skills, and abilities. Its purpose is to
determine whether a private should be interviewed further, hired, or dropped from
consideration (iedunote, n.d.).
Structured Interview
A structured interview is a quantitative research approach in which the interviewer asks a

series of closed-ended questions from a script that he or she reads out exactly as written.
Strengths of Structured Interview
1.Structured interviews are simple to repeat because they use a set of closed questions that
are easy to quantify - implying that they are simple to verify for dependability.
2. Structured interviews are relatively quick to perform, implying that a large number of
interviews can be completed in a short period of time. This shows that an oversized sample
is frequently obtained, resulting in conclusions that are representative and have the ability to
be generalized to a large population.
Unstructured Interview
Unstructured interviews are the most adaptable, with plenty of potential for improvisation.
The questions and the order in which they are presented are not predetermined, unlike in a
structured interview. Rather, the interview moves forward based on the participant's past
responses.Unstructured interviews are unstructured and unscripted.

Page
This lack of structure can aid you in gathering precise information on your subject while yet
allowing you to spot trends during the analysis stage.
Strengths Unstructured interview
Even if the interviewer has some unstructured interview questions to investigate, the entire
pattern may be adjusted based on the dialogue with the candidate, or the interview may
progress based on the candidate's reaction. This type of interview is more like a non-
directive interview and is conducted in a friendly manner. Unstructured interviews are
similar to a free-flowing chat that is relaxed and open to discussion. Typically, these kind of
interviews are conducted at random by higher-ranking people in the business who have
authority. Even though an unstructured interview is more informal, it serves many of the
same functions as a structured interview.
It is up to the interviewer to make good use of an unstructured interview. The interviewer
would be able to assess the candidate very well because of the sudden free-flowing
questions and mainly because questions are raised from the candidate’s reply.
Software development life cycle method for-E-Solution
The Software Development Life Cycle, or SDLC, is a method for producing high-quality,
low-cost software in the least amount of time. SDLC is a well-structured flow of stages that
enables a company to swiftly develop high-quality software that has been thoroughly tested
and is ready for production. As stated in the introduction, the SDLC is divided into six
phases. The waterfall model, spiral model, and Agile model are all popular SDLC models.
6 Software Development Life Cycle models
Agile
Lean
Waterfall
Iterative
Spiral
DevOps
Each of those approaches varies in some ways from the others, but all have a

Page
standard purpose: to assist teams deliver high-quality software as quickly and cost-
effectively as possible.
1. Agile
Since its inception in 2001, the Agile model has been the de facto industry standard. Some
companies place such a high importance on the Agile technique that they use it for non-tech
projects as well.
Fast failure is a good thing under the Agile methodology. This method results in continuous
release cycles with tiny, incremental changes from the preceding release. The product is
tested after each iteration. The Agile methodology assists teams in identifying and resolving
minor difficulties on projects before they become larger issues, and it involves business
stakeholders in providing input throughout the development process.
Many teams use an Agile framework known as Scrum to help structure more complicated
development projects as part of their adoption of this technique. Scrum teams perform
assigned projects in sprints, which typically span two to four weeks. Daily Scrum meetings
allow the entire team to keep track of the project's progress. The ScrumMaster's job is to
keep the team focused on their goal.
2. Lean
The Lean software development paradigm is based on "lean" manufacturing concepts and
practices. Eliminate waste, magnify learning, decide as late as possible, deliver as quickly as
feasible, empower the team, build in integrity, and see the entire are the seven Lean
principles (in this sequence).
There is no place for multitasking in the Lean process because it focuses on only what has
to be done at the time. Project teams are also looking for ways to save money at every stage
of the SDLC process, from eliminating superfluous meetings to decreasing documentation.
The Agile model is essentially a Lean approach to the SDLC, with a few major exceptions.
One difference is how each emphasizes customer happiness: Agile puts customer
satisfaction first from the start, allowing project teams to respond swiftly to stakeholder
feedback throughout the SDLC. Lean, on the other hand, stresses the removal of waste as a
means of increasing overall value for consumers, which helps to improve satisfaction.

Page
3. Waterfall
Some experts say that the Waterfall approach was never intended to be used as a project
management methodology. Waterfall, on the other hand, is commonly regarded as the oldest
of the formal SDLC approaches. It's also a fairly simple strategy: complete one phase before
moving on to the next. There's no turning back now. Each step builds on the preceding
stage's material and has its own project plan. Waterfall's drawback is its rigidity. It is,
without a doubt, straightforward to comprehend and manage. However, early delays can
knock the entire project off schedule. Problems can't be solved until the maintenance stage
because there's minimal room for adjustments once a stage is completed. This paradigm
does not perform well when there is a need for flexibility or if the project is long-term.
The associated Verification and Validation model, sometimes known as the V-shaped
model, is even more rigid. The Waterfall approach inspired this linear development style.
For each level of development, there is a corresponding testing phase. Each stage, like
Waterfall, begins only after the preceding one has ended. If your project has no unknown
requirements, this SDLC paradigm can be useful.
4. Iterative
The Iterative model embodies repetition. Rather than starting with completely defined
requirements, project teams implement a set of software requirements before testing,
evaluating, and identifying more requirements. With each phase, or iteration, a new
version of the software is created. Rinse and repeat until the entire system is up and
running. The Iterative model has advantages over other standard SDLC approaches in
that it generates a workable version of the project early in the process and makes
change implementation less expensive. One downside is that repetitive activities can
quickly deplete resources. The Rational Unified Process (RUP), developed by IBM's
Rational Software division, is an example of an iterative paradigm. RUP is a project
management tool that helps teams work more efficiently on a variety of tasks.
RUP divides the development process into four phases:
Inception, when the idea for a project is set

Elaboration, when the project is further defined and resources are evaluated
Construction, when the project is developed and completed

Page
Transition, when the product is released
Each phase of the project involves business modeling, analysis and design, implementation,
testing, and deployment
5. Spiral
Spiral is one of the most adaptable SDLC approaches, drawing on the Iterative model and
its repetition. The project is iterated through four phases (planning, risk analysis,
engineering, and assessment) until it is finished, allowing for several rounds of revision.
For major projects, the Spiral model is commonly employed. It allows development teams
to create a highly tailored product while also incorporating early consumer feedback. Risk
management is another advantage of this SDLC strategy. Each iteration begins by
anticipating potential risks and determining the best way to avoid or reduce them.
6. DevOps
The DevOps methodology is a very recent addition to the SDLC landscape. It arose from
two trends: the application of Agile and Lean methods to operations work, and a general
change in business toward appreciating the value of collaboration between development and
operations personnel at all levels of the SDLC process.
Developers and Operations teams collaborate closely — and sometimes as one — under a
DevOps paradigm to speed up innovation and the deployment of higher-quality, more
dependable software products and features. Product updates are minor but frequent. The
DevOps paradigm emphasizes discipline, regular feedback and process improvement, and
the automation of manual development processes.
DevOps, according to Amazon Web Services, is a set of cultural philosophies, practices,
and tools that improves an organization's ability to deliver applications and services at high
velocity while also evolving and improving products at a faster rate than traditional software
development and infrastructure management processes. DevOps, like many SDLC models,
is not only a method for planning and executing work, but also a philosophy that
necessitates a shift in an organization's thinking. Selecting the best SDLC approach for your

Page
software development project necessitates deliberation. Keep in mind, however, that a
model for planning and steering your project is only one part of the puzzle. Even more
crucial is putting up a strong team of talented individuals dedicated to moving the project
ahead despite any setbacks.
What is RAD (Rapid Application Development)
Rapid application development (or RAD) is a more flexible method of software

development. RAD is predicated on flexibility and the ability to adjust with new knowledge,
whereas traditional plan-based techniques require a fixed framework with specific
requirements.
The Waterfall model was the most popular technique to software development in the 1970s
and 1980s. This strategy divides a project into a series of steps, each of which feeds into and
consequently relies on the completion of the prior phase. When it comes to engineering
industries like building, a strict method like the Waterfall model is understandable, but it is
unsuitable when it comes to software development in a fast-paced setting.
However, if you expect to revise and adjust depending on feedback during the creative
process, a plan-driven process may not be the best option. A project that follows a rapid
application development paradigm is more adaptive and flexible, and any feedback obtained
may be simply incorporated into future development. RAD effectively emphasizes the
design process as well as the knowledge that can be obtained from it. As a result, in a RAD
approach, creating basic prototypes and involving users in the design process are critical
tasks. As a result, unlike the Waterfall approach, the end user is aware of the entire process
rather than just the start and finish. RAD attempts to deliver a product that more closely
mimics the user's through constant testing and adjusting.
Functional and Non-functional Requirement
Functional Requirements:
These are the core features that the system should provide that the end user directly
requests. As part of the contract, all of these functionalities must be included into the

Page
system. These are expressed or described as input to be delivered to the system, operation to
be conducted, and expected output. They are the user's expressed requirements that, unlike
non-functional criteria, can be seen immediately in the completed product.
Non-functional criteria:
These are the quality requirements that the system must meet in order to fulfill the project
contract. The importance of these aspects, as well as the amount to which they are
implemented, varies from project to project. Non-behavioral requirements are another name
for them.
They basically deal with issues like:
Portability
Security
Maintainability
Reliability
Scalability
Performance
Reusability
Flexibility
Following are the differences between Functional and Non Functional Requirements
User Requirements
When a project's use cases are discussed, user requirements are usually written. The
customer or product managers who know how the embedded system will be utilized by the
user define the requirements.
Many user requirements are concerned with how a user will interact with a system and the
expectations the user has. A user requirement may be predicated on what happens when the
user selects an action on the screen if the system has a screen or human machine interface

Page
component. Perhaps pressing a button not only initiates a process, but also transitions to a
different screen and emits an aural notification.
When user needs like these are set down, they can easily devolve into several system
requirements later owing to screen switching, the longest delays in starting the process, and
eventually, what the next screen should look like. Trying to write system requirements
during a user requirement meeting is a common problem. This frequently detracts from
obtaining insight into the user's needs, and crucial functionality components may be
overlooked.
In reality, as previously stated, it is generally preferable to keep user and system

requirements separate in terms of tracking and reporting. User requirements are usually
more legible and intelligible, and they give a better idea of how the system will work.
Despite the fact that user requirements may lack specifics on what exactly needs to happen
in the system, they are nevertheless useful in that they can offer the system's overall
functioning expectations.
Finally, having traceability in terms of where the user need originated is a good notion when
designing user requirements. Understanding where it came from, whether from a single
client or a product manager, is critical. There are situations when separate user sessions
produce contradictory requirements when recording user requirements. Being able to return
to the source and have a deeper understanding of the use case can aid in the decoding of
conflicting user requirements. It could come from different perspectives, such as an operator
vs. a maintenance worker, so being able to go back and reconcile those disparities is critical.
( engineering/user-requirement) (Elsevier B.V.)
System Requirement
A declaration that describes the capability that a system need in order to satisfy the
customer's requirements is known as a system requirement. System requirements are a
broad and limited topic that can be applied to a variety of objects. Whether talking about the
system requirements for specific machines, software, or business operations in general.
Taking it all the way down to the hardware and coding that operates the software. System
requirements are the most efficient way to address user needs while lowering

Page
implementation costs. System requirements have the potential to save a company a lot of
money and time, but they also have the potential to squander money and effort.
Software Reequipments Specification (SRS) Documents?
A software requirements specification (SRS) is a document that explains what the software
will accomplish and how it will work. It also outlines the functionality that the product must
have in order to meet the needs of all stakeholders (business and users).
An SRS can be simply summarized into four Ds:
Define your product's purpose.

Describe what you're building.
Detail the requirements.
Deliver it for approval
We want to DEFINE the purpose of our product, DESCRIBE what we are building,
DETAIL the individual requirements, and DELIVER it for approval. A good SRS document
will define everything from how software will interact when embedded in hardware to the
expectations when connected to other software. An even better SRS documents also account
for real-life users and human interaction.
The best SRS documents define how the software will interact when embedded in hardware
— or when connected to other software. Good SRS documents also account for real-life
users.
User Stories
A user narrative is an informal, natural language description of one or more elements of a

software system used in software development and product management. A user story is a
tool that is used in Agile software development to record a description of a software feature
from the point of view of the end user. A user story outlines the user, what they want, and
why they want it. A user story aids in the creation of a concise description of a demand.

Page
User stories are frequently written on index cards, Post-its, or in project management
software. User stories may be written by a variety of stakeholders, including clients, users,
managers, and development team members, depending on the project.
As teams and consumers gain a better understanding of the technology, requirements will
alter. Expecting project teams to work off a static requirements list and deliver working
software months later isn't exactly feasible.
We substitute huge upfront design with a "just enough" approach when we adopt the user
story approach. By emphasizing customer-centric dialogues, user stories save the time spent
on generating extensive documentation. As a result, user stories help teams deliver high-
quality software faster, which is what consumers want. Adopting a user narrative approach
to agile development has a number of advantages, including: (www.visual-paradigm.com)
Analyze the effectiveness of the methodology used in providing a solution for a

business context.
In a generally liberal framework of serving ecosystem stakeholders and performing unique

experiences while creating economic and social value, the management world is
increasingly directed by the formation of a common purpose, which is measured by
objectives, goals, and performance. In the VUCA (Volatile, Uncertain, Complex, and
Ambiguous) setting, however, the life cycle of organizations has never been so brief. As a
result, continuous transformation of the business model and supply is a necessary premise
and pillar of survival, leading companies into a continual state of mutation, as the pandemic
has lately highlighted. The labor market is also constantly altering, thus this evolution is not
restricted to businesses and business models.
It is more crucial than ever to guarantee that organizations develop sustainably, adding not
only economic but also environmental and social value. One of the most important skills for
running a successful organization is the ability to solve complex problems. Chen and Hitt
draw attention to the disparity between challenges taught in business schools and those
encountered in the real world. In order to solve the complex difficulties faced in the
business sector, it is becoming increasingly vital to teach problem-solving skills.

Page
Furthermore, to minimize biases, the method should be based on facts and carried out in an
objective and repeatable manner. ( Leiponen, A.; Helfat, C.E. Innovation objectives,
knowledge sources, and the benefits of breadth. Strateg. Manag. J. 2010, 31, 224–236.
[CrossRef] )
Software development life cycle
Software Development Life Cycle is the application of standard business practices to

building software applications. It’s typically divided into six to eight steps: Planning,
Requirements, Design, Build, Document, Test, Deploy, Maintain. Some project managers
will combine, split, or omit steps, depending on the project’s scope. These are the core
components recommended for all software development projects.
SDLC is a way to measure and improve the development process. It allows a fine-grain
analysis of each step of the process. This, in turn, helps companies maximize efficiency at
each stage. As computing power increases, it places a higher demand on software and
developers. Companies must reduce costs, deliver software faster, and meet or exceed their
customers’ needs. SDLC helps achieve these goals by identifying inefficiencies and higher
costs and fixing them to run smoothly.
How the Software Development Life Cycle Works
The Software Development Life Cycle simply outlines each task required to put together a
software application. This helps to reduce waste and increase the efficiency of the
development process. Monitoring also ensures the project stays on track, and continues to
be a feasible investment for the company.
Many companies will subdivide these steps into smaller units. Planning might be broken
into technology research, marketing research, and a cost-benefit analysis. Other steps can
merge with each other. The Testing phase can run concurrently with the Development
phase, since developers need to fix errors that occur during testing (phoenixnap, 2022).

Page
The Seven Phases of the SDLC
In this guide, we’ll break down everything you need to know about the system development
life cycle, including all of its stages. We’ll also go over the roles of system analysts and the
benefits your project might see by adopting SDLC.
7 Stages of the System Development Life Cycle
1) Planning Stage
2) Feasibility or Requirements of Analysis Stage
3) Design and Prototyping Stage
4) Software Development Stage
5) Software Testing Stage
6) Implementation and Integration
7) Operations and Maintenance Stage
Planning Stage
Before we even begin with the planning stage, the best tip we can give you is to take time
and acquire proper understanding of app development life cycle.
The planning stage (also called the feasibility stage) is exactly what it sounds like: the phase
in which developers will plan for the upcoming project.
It helps to define the problem and scope of any existing systems, as well as determine the
objectives for their new systems.
By developing an effective outline for the upcoming development cycle, they'll theoretically
catch problems before they affect development.
And help to secure the funding and resources they need to make their plan happen.

Page
Perhaps most importantly, the planning stage sets the project schedule, which can be of key
importance if development is for a commercial product that must be sent to market by a
certain time.
‍
Analysis Stage
The analysis stage includes gathering all the specific details required for a new system as
well as determining the first ideas for prototypes.
Define any prototype system requirements

Evaluate alternatives to existing prototypes
Perform research and analysis to determine the needs of end-users
Furthermore, developers will often create a software requirement specification or SRS
document.
This includes all the specifications for software, hardware, and network requirements for the
system they plan to build. This will prevent them from overdrawing funding or resources
when working at the same place as other development teams.
‍
Design Stage
The design stage is a necessary precursor to the main developer stage.Developers will first
outline the details for the overall application, alongside specific aspects, such as its:
User interfaces
System interfaces
Network and network requirements
Databases
They’ll typically turn the SRS document they created into a more logical structure that can
later be implemented in a programming language. Operation, training, and maintenance
plans will all be drawn up so that developers know what they need to do throughout every
stage of the cycle moving forward.

Page
Once complete, development managers will prepare a design document to be referenced
throughout the next phases of the SDLC.
‍
Development Stage
The development stage is the part where developers actually write code and build the
application according to the earlier design documents and outlined specifications.
This is where Static Application Security Testing or SAST tools come into play.
Product program code is built per the design document specifications. In theory, all of the
prior planning and outlined should make the actual development phase relatively
straightforward.
Developers will follow any coding guidelines as defined by the organization and utilize
different tools such as compilers, debuggers, and interpreters.
Programming languages can include staples such as C++, PHP, and more. Developers will
choose the right programming code to use based on the project specifications and
requirements.
‍
Testing Stage
Building software is not the end. Now it must be tested to make sure that there aren’t any
bugs and that the end-user experience will not negatively be affected at any point.
During the testing stage, developers will go over their software with a fine-tooth comb,
noting any bugs or defects that need to be tracked, fixed, and later retested.
t’s important that the software overall ends up meeting the quality standards that were
previously defined in the SRS document.
Depending on the skill of the developers, the complexity of the software, and the
requirements for the end-user, testing can either be an extremely short phase or take a very

Page
long time. Take a look at our top 10 best practices for software testing projects for more
information.
Implementation and Integration Stage
After testing, the overall design for the software will come together. Different modules or
designs will be integrated into the primary source code through developer efforts, usually by
leveraging training environments to detect further errors or defects.
The information system will be integrated into its environment and eventually installed.
After passing this stage, the software is theoretically ready for market and may be provided
to any end-users.
Maintenance Stage
The SDLC doesn’t end when software reaches the market. Developers must now move into
a maintenance mode and begin practicing any activities required to handle issues reported
by end-users.
Furthermore, developers are responsible for implementing any changes that the software
might need after deployment.
This can include handling residual bugs that were not able to be patched before launch or
resolving new issues that crop up due to user reports. Larger systems may require longer
maintenance stages compared to smaller systems (clouddefense, 2022).
SDLC Models & Methodologies Explained
Waterfall
Known as the traditional methodology, Waterfall is a sequential and linear flow for
developing a software application. The process is outlined by a series of finite stages, each

Page
of which must be fully completed before moving on to the next one. The Waterfall approach
follows this order: requirements, design, execution, testing, and release.
Prototyping
This methodology creates prototypes of the software application to simulate the functioning
aspects of a desired, final product. Prototyping is mainly used to visualize components of
the software solution and match them with customer requirements. There are several
variants of prototyping but they are mainly categorized into throwaway and evolutionary.
Throwaway prototyping creates a model that will eventually be discarded and evolutionary
prototyping refers to a robust prototype that will be constantly refined to reach its final
version.
Spiral
The Spiral methodology can be thought of as a combination of the Waterfall methodology

and the prototyping methodology. It is typically the methodology of choice for large and
complex projects because it uses the same stages as the Waterfall methodology but it
separates them into planning, risk assessment, and prototype building.
Agile
The iterative and incremental methodology known for excellence, Agile is a framework that
evolves through collaboration between teams. It is a dynamic and interactive methodology
that works in sprints that have a defined duration with lightweight deliverables that help
reduce the time in which software is released. It advocates for adaptive planning,
evolutionary development, early delivery, continuous improvement, and rapid and flexible
responsiveness to changes.
Iterative and incremental

The iterative and incremental methodology is designed to overcome any fault or
shortcoming of the Waterfall methodology. The iterative and incremental methodology
begins with initial planning and ends with the deployment of the solution, with cyclic
interaction in between. In essence, it develops a software application via iterative and

Page
repeated cycles that are performed incrementally so developers can learn from the
development of previous portions of the software.
V model
V model methodology is considered an extension of the Waterfall methodology, but instead

of flowing down in a linear way, the steps are designed upward to form a V shape. In this
methodology, the relationships between each phase of the development lifecycle are
associated with a testing phase. The horizontal and vertical axes display the time or project
completeness (left to right) and abstraction level (coarsest-grain abstraction). (svitla, 2022)
Rapid Application Development for the scenario
What is Rapid Application Development (RAD)?
The Rapid Application Development (or RAD) model is based on prototyping and iterative
model with no (or less) specific planning. In general, RAD approach to software
development means putting lesser emphasis on planning tasks and more emphasis on
development and coming up with a prototype. In disparity to the waterfall model, which
emphasizes meticulous specification and planning, the RAD approach means building on
continuously evolving requirements, as more and more learnings are drawn as the
development progresses.
RAD puts clear focus on prototyping, which acts as an alternative to design specifications.
This means that RAD works well wherever there's a greater focus on user interface rather
than non-GUI programs. The RAD model includes agile method and spiral model.
Below phases are in rapid application development (RAD) model:
1. Business modeling: The information flow is identified between different business

functions.
2. Data modeling: Information collected from business modeling is used to define data
objects that are required for the business.

Page
3. Process modeling: Data objects defined in data modeling are converted to establish the
business information flow to achieve some specific business objective process descriptions
for adding, deleting, modifying data objects that are given.
4. Application generation: The actual system is created and coding is done by using
automation tools. This converts the overall concept, process and related information into
actual desired output. This output is called a prototype as it’s still half-baked.
5. Testing and turnover: The overall testing cycle time is reduced in the RAD model as the
prototypes are independently tested during every cycle.
However, the overall flow of information, user interfaces and other program interfaces, and
coaxials between these interfaces and the rest of data flow need to be tested as per
acceptance process. Since most of the programming components have already been tested, it
reduces the risk of any critical issue.
Steps in Rapid Application Development
A rapid application development cycle consists of four steps:
Define project requirements;

Prototype;
Rapid construction & feedback gathering; and
Finalize product / implementation.
The key principle of the RAD process is a reduction in planning to focus on a highly
iterative design and construction process, enabling teams to accomplish more in less time,
without impacting client satisfaction. The prototyping and rapid construction phases may be
repeated until the product owner and users are satisfied that the prototype and build meets
the project requirements.
1: Define project requirements.

The rapid application development cycle begins with stakeholders defining a loose set of
project requirements, equivalent to what would be accomplished during project scoping in
traditional development cycles. This planning stage is brief - emphasizing a higher priority
on prototype iterations - but critical to the ultimate success of a project.

Page
All project stakeholders - developers, clients, software users and teams - communicate to
determine the project’s requirements, and strategies for tackling potential issues that may
arise during development. Requirements include goals, expectations, timelines and budget.
The client provides a vision for the product, and in collaboration with other stakeholders,
research is conducted to finalize requirements with each stakeholder’s approval. Ensuring
every stakeholder is on the same page early in the development cycle assists teams with
avoiding miscommunication and costly mistakes. That being said, one of the key principles
of RAD is the ability to change requirements at any point in the development cycle.
2: Prototype.
Once a project has been scoped, teams begin building out the initial models and prototypes.
The goal is to rapidly produce a working design that can be demonstrated to the client.
Developers and designers work hand-in-hand with clients until a final product is ready, to
ensure the client’s needs are being met. This step is often repeated as often as is necessary
as the project evolves. During this early stage prototyping, it is common for developers to
cut corners in order to produce a working product that is acceptable to the product owner.
The use of rapidly built prototypes encourages user involvement, testing, and feedback on a
live system, rather than attempting to make abstract evaluations of a design document. The
nature of this consistent feedback enables developers to adjust models incrementally until
project requirements are sufficiently met. Stakeholders communicate and learn through
experience, quickly and easily identifying what does and doesn’t work. The rapid nature of
releases means errors are far more likely to be discovered earlier, which leads to a reduction
in errors and debugging.
Through prototyping, the development team can easily evaluate the feasibility of complex
components. Consequently, software is more robust, less error-prone, and better structured
for future design additions.
3: Rapid construction and feedback gathering.
Rapid construction is where application coding, system testing, and unit integration occurs,
converting prototype and beta systems into a working model. This phase may also be

Page
repeated as required, supporting new components and alterations. Generally, teams use low-
code or rapid application development tools to quickly progress the application.
Since the majority of user problems and client changes are addressed during the iterative
prototyping phase, developers are able to construct a final working model faster than they
would following a traditional development approach. Software and applications are
thoroughly tested during this phase, ensuring the end result satisfies client expectations and
objectives. Developers work with clients and end users to collect feedback on interface and
functionality, and improve all aspects of the product.
Clients give thorough input throughout this stage, suggesting alterations, changes, or new
ideas that solve problems as they are discovered. Clients may find that in practice, some
concepts don’t work. With this input, developers either resume prototyping, or if feedback
is strictly positive, move onto the final step.
4: Finalise product / implementation.
The final phase of rapid application development is where developers address the technical
debt accrued in early prototyping, optimising implementation to improve stability and
maintainability as they finalise the product for launch. Components are moved to a live
production environment, where full-scale testing occurs to identify product bugs.
The implementation phase is where development teams move components to a live

production environment, where any necessary full-scale testing or training can take place.
Teams write thorough documentation and complete other necessary maintenance tasks,
before confidently handing the client a complete product (codebots, 2022).
Advantages and Disadvantages of Rapid Application (RAD)
With these methods, application development may appear to be a good option for any
project, but that's a stretch. Small teams and rapid projects benefit greatly from RAD

Page
software. However, it isn't a panacea for all problems. Here are some of the benefits and
drawbacks of employing quick application development.
Advantages of RAD Model Disadvantages of RAD Model
Requirements can be changed at any

Needs strong team collaboration
time
Encourages and priorities customer

Cannot work with large teams
feedback
Reviews are quick Needs highly skilled developers
Development time is drastically Needs user requirement throughout the

reduced life cycle of the product
Only suitable for projects which have a

More productivity with fewer people
small development time

Page
Time between prototypes and iterations More complex to manage when
is short compared to other models
Only systems which can be

Integration isn’t a problem, since it
modularised can be developed using
integrates from project inception
Rapid application development.
What is Rapid Application Development (RAD) mean?
The definition of RAD is:
Rapid Application Development (RAD) is a development methodology that emphasizes

rapid prototyping and feedback over lengthy development and testing cycles. Rapid
application development allows developers to make several iterations and modifications to
software without having to restart the development process from the beginning each time.
Rapid Application Development (RAD) was conceived in the 1980s, so it’s definitely not
something new. But unlike the waterfall model, it’s not singular. It’s a continuous evolution
of development philosophies according to the requirement at that particular time.
Initially, Barry Boehm, James Martin, and a number of others saw that software was not
limited to traditional methods of engineering. It wasn’t a singular resource that required a
fixed structure. It was malleable to suit the needs of the user.
Initially, rapid application development took the shape of the Spiral model
, where one or more development models were used to work on a particular project.

Page
Over time, rapid application development changed. It molded itself to fit the requirements
of the time while retaining some core development guidelines.
1. Define the Requirements

At the very beginning, rapid application development sets itself apart from traditional
software development models. It doesn’t require you to sit with end users and get a detailed
list of specifications; instead, it asks for a broad requirement. The broad nature of the
requirements helps you give specific requirements at different points of the development
cycle.
2. Prototype
This is where the actual development takes place. Instead of following a strict set of
requirements, developers create prototypes with different features and functions as fast as
they can. These prototypes are then shown to the clients who decide what they like and what
they don’t.
More often than not, these prototypes are quickly made to work, just to show off certain
features, without proper polish. This is normal, and the final product is only created during
the finalization stage where the client and developer can both agree on the final product.
3. Receive Feedback
In this stage, feedback on what’s good, what’s not, what works, and what doesn’t is shared.
Feedback isn’t limited to just pure functionality, but also visuals and interfaces.
With this feedback in mind, prototyping continues. These two steps are repeated until a final
product can be realized that fits both the developers’ and client’s requirements.
4. Finalize Software
Here, features, functions, aesthetics, and interface of the software are finalized with the
client. Stability, usability, and maintainability are of paramount importance before
delivering to the client.

Page
Rapid Application Development vs Other Software Development Models
When compared to other software development models, rapid application development

varies by a considerable amount. Obviously, the major difference is how rapid application
development focuses on speed, when compared to other models which usually focus on
bringing a working product to the customer.
Another thing to note here is that rapid application development prefers having a single
team without too many members. This allows for fast communication with quick meetings
for quick information transfer. Other development models such as the waterfall model
prefer having larger teams divided into different specializations.
Since RAD framework is focused on speed, the development time here is less than that of
other models. But the difference is usually small, since rapid application development
prefers to churn out a lot of prototypes before the finalized product.
Rapid application development is also heavily focused on keeping the end user involved
throughout the entire stage of the development process. Other models usually only have
user input at the beginning and the end of the development cycle.
When are you able to Use Rapid Application Development Methodology?
When you’re building a skyscraper, you can’t change the design halfway through, can you?
Thanks to RAD, this is something you don’t have to worry about in software development.
Fluctuating market conditions force the landscape of software development to change
frequently. This makes it even more important to use development models that are efficient
& flexible right from the design phase.

Page
Rapid Application Development (RAD) was born as a solution to this issue. RAD helps to
rapidly develop prototypes for testing functions and features, without having to worry about
any effects on the end product. With RAD, you can change the design, add/ remove a
functionality, clean it up by removing all the extra fluff that you don’t want, all without
even harming the end-product.
But how did this model come to light? How does this model work? What are the advantages
of adopting RAD and When do you work on the Rapid Application Development software?
Basically, RAD follows 4 main phases –
1. Requirements planning
The planning phase of this methodology is relatively compressed as compared to other
methodologies. Nevertheless, this is a critical step for the ultimate success of the project. In
this this phase, developers, users and other team members connect to determine the goals
and expectations for the project. They also discuss the current and potential challenges that
may need to be addressed during development.
It is very important at this stage that everyone involved in the project has the opportunity to
evaluate the goals and expectations and make required suggestions. This avoids expensive
change orders and miscommunication.
2. User Design
This is the main course of the RAD methodology—and what sets it apart from other project
management strategies.
Once the scope of the project is chalked out, it’s time to dive into development. The user
design is built through various prototype iterations.
During this phase, users/clients join forces with the developers to ensure that their
requirements are being met at every step in the design process. It’s practically customizable
software development where the developer designs a prototype, the user tests it, and then
they collaborate on what worked and what didn’t. Ultimately, both the developers and the

Page
clients work together to make sure that there is no gap for something to slip through the
cracks.
3. Rapid Construction
In this phase, the prototypes and beta systems designed in the previous phase are converted
into working models. Since majority of the glitches and changes were addressed during the
iterative design phase, it becomes easier and quicker for developers to construct the final
working model. Nonetheless, the client can still give input anytime during the process and
suggest modifications, adjustments, or even new ideas that can solve problems as they arise.
The product is worked upon by developers, programmers, coders and testers until the final
product meets the client’s expectations and objectives.
4. Cutover
The finished product is implemented and goes for launch in this phase. During this stage all
the final changes are made, data conversion, testing, and changeover to the new system is
done. User training is also imparted during this phase.
An Example Rapid Application Development Case Study - Centric Consulting
The business sought counsel from several consulting firms, and quickly decided Centric had
the technical skills, business insights and affable style to help them through a critical
transformation of business processes. Centric was able to devise and quickly implement a
solution that not only made the client compliant, but also made them the standard by which
other vendors are measured.
A small shop (i.e. no IT department) like our client’s provides some unique development
advantages. Centric was able to utilize the Ruby on Rails development framework. Among
the many benefits was the ability to create a responsive application to meet and exceeded
the needs of the client in a remarkably short timeframe while keeping costs low. More
specifically, the Centric solution:

Page
Used Agile techniques to understand business processes, prototype, refine, and deploy the
needed functionality via frequent releases. Valuable business functionality was therefore
deployed at regular intervals.
Utilized Ruby on Rails to simplify and thus accelerate development and test activities
Deploy open source infrastructure (LINUX, MySQL, etc.) to keep costs low
Rapidly add new functionality as mandated by the customer’s business.
Kissflow - Best RAD Application Development Platform
Without a doubt, the best way to develop software is to use rapid application development
tools. Tons has changed in the last 20 years, even though it is still the champion.
Kissflow is an example of quick application development in the next generation. It's a no-
code platform that allows anyone to create their own automated process in minutes, not days
or weeks. Kissflow is frequently used by a single individual to figure out how to construct
an application.
This is rapid application development carried to its logical conclusion–creating applications

as quickly as feasible that are available for usage by the entire firm right away. Kissflow is
designed with visual interface tools to generate models fast and easily, pre-built modules
where you don't have to do the work, and drag-and-drop code to provide a manner of
modification to individuals who don't have the right coding skills (Development, 2021).

Page
Activity 04
4. Design the system to meet user and system Requirements
4.1 Assess the effectiveness of your design and the methodology used with reference to
how it meets the user requirements.
1. Establish the basis for agreement between the customers and the
suppliers on what the software product is to do.
The thorough description of the functions to be performed by the software stated in the SRS
will aid the potential user in determining whether or not the software specified satisfies their
needs, and if so, how the program must be adjusted to satisfy their demands.
2. Provide a basis for developing the software design.

The SRS is the most significant reference document while creating a design.
3. Reduce the development effort.
Before design work begins, the SRS forces the different interested groups in the customer's
company to carefully analyze all of the requirements. A thorough and accurate SRS saves
time and effort in redesigning, recoding, and retesting. A thorough examination of the SRS
requirements can discover omissions, misunderstandings, and inconsistencies early in the
development cycle, when they are easier to fix.
4. Provide a basis for estimating costs and schedules.
The SRS's description of the product to be developed is a good starting point for calculating
project costs and can be utilized to get bids or price estimates approved.
5. Provide a baseline for validation and verification.
A good SRS can help organizations generate their test documentation much more
efficiently. The SRS serves as a baseline against which compliance can be measured as part
of the development contract.
6. Facilitate transfer.
The SRS simplifies the process of transferring software to new users or devices. Customers
will have an easier time transferring the software to other parts of their company, and
suppliers will have an easier time transferring it to new customers.

Page
7. Serve as a basis for enhancement.
Because the SRS focuses on the product rather than the project that created it, it can be used
to improve the finished product later. The SRS may need to be tweaked, but it provides a
solid framework for future product testing.
4.2 System design specification
Content
- Introduction
- Problem
- Requirements
- Proposed Solution
- Appendix
- Use Case Diagram
- Flow Chart
- Class Diagram
- ER Diagram
- Context Diagram
- DFD Diagram
- Wireframes
- User Interfaces
- Release Plan
- Used Tools
8. Introduction
The primary goal of this E solution PVT constrained design. This contains a look at the
architecture as well as a breakdown of the various subsystems. For the demonstration of
how the system will work together and where data will flow through it. UML and CLASS
diagrams will be shown. There will also be a debate of the system's technology throughout
the system.

Page
9. Current Problems in E solutions
- Facing more errors in current systems
- Limited team members
- Project planning errors
- E solution company forcing every time to do project quickly
- Spend more time for project management
- Different ideas and arguments between team members
- During project time visitors come ask about the project progress
10. Requirements
- System information’s must be Very accurate
- The system must operate every time like as 24 hours
- Every legal user if they want must be logging this system anywhere and
anytime as they want.
- If they want new project there must be space for new one
- Users must be granted to create new profile
- Must be able to assign project by individuals
- There must be a function to update every possible thing in the system
- The security of this system must be very high.
- Every information must be very reliable
- Must be restrict to handover the system to fraud
- If Employees want to see on goings they can see the ongoing projects
- This system must be user friendly and easy to access
- Every function must be values no need unnecessary functions.
11. Solutions
I opted to construct an online platform application after evaluating the specifications
provided by this organization. Because they need to be able to log this system everywhere
they want. Specifically, I created a backup component for this system as well as an
additional server for the system to upload data. And, most importantly, this system must
have a high level of security and be impenetrable to entry frauds. Because this system must
be user-friendly, we opted to employ a simple user interface. I established five primary
groups of users who may use this system, and I designed it such that each user can only
connect with the parts of the system that are relevant to their work. The following are the
five main user groups:

Page
1. Admin
2. Project Director
3. project Manager
4. Team Leader
5. Team Member
I decide to use HTML, CSS and JavaScript languages to create this system. This is because
if the system needs to be upgraded in the future, it will be much easier and with these
technologies we will be able to create a very good web application in the end.
Use case Diagram
Figure 9 use case diagram

Page
Flow chart for E solution
Figure 10 login flow chart

Page
Figure 11 add user flow chart

Page
Database design
Figure 12 Database design

Page
Class diagram
Figure 13 class diagram

Page
Context Diagram
Figure 14 contex diagram
Wireframes

Page
Figure 15 login form
Figure 16 dashboard

Page
Figure 17 create_project
Figure 18 view and edit project

Page
Figure 19 delete project
Figure 20 add tasks

Page
Figure 21 project manager dashboard
Figure 22 team leader dashboard

Page
Figure 23 assign task to member
Figure 24 showing complete task

Page
Figure 25 admin dashboard

Page
Figure 26 add user
Figure 27 edit user

Page
Figure 28 delete user
Figure 29 login interface

Page
Figure 30 project director dashboard

Page
Figure 31 create project

Page
Figure 32 view and edit project
Figure 33 delete project

Page
Figure 34 manager add task
Figure 35 project manager dashboard
Figure 36 team leader dashboard

Page
Figure 37 assign task to member
Figure 38 completed task

Page
Figure 39 admin dashboard

Page
Figure 40 add user
Figure 41 edit user

Page
Figure 42 delete user

Page
References
atlassian, 2022. atlasian. [Online]
Available at: https://www.atlassian.com/
[Accessed 21 02 2022].
Brush, K. & Silverthorne, V., 2019. Agile Software Development. [Online]
Available at: https://searchsoftwarequality.techtarget.com/definition/agile-software-
development
[Accessed 5 October 2021].
clouddefense, 2022. clouddefense. [Online]
Available at: https://www.clouddefense.ai/
[Accessed 21 02 2022].
codebots, 2022. codebots. [Online]
Available at: https://codebots.com/
[Accessed 22 02 2022].
digite, 2022. digit. [Online]
Available at: https://www.digite.com/
[Accessed 21 02 2022].
Lewis, S., 2019. Prototyping Model. [Online]
Available at: https://searchcio.techtarget.com/definition/Prototyping-Model
[Accessed 12 October 2021].
phoenixnap, 2022. phoenixnap. [Online]
Available at: https://phoenixnap.com/
[Accessed 21 02 2022].
smart, j. f., john. john. [Online]
Available at: https://johnfergusonsmart.com/behaviour-driven-development-3-minute-
rundown/
[Accessed 20 02 2022].
svitla, 2022. svitla. [Online]
Available at: https://svitla.com/
[Accessed 22 02 2022].
wadic, 2022. wadic. [Online]
Available at: https://wadic.net/
[Accessed 21 02 2022].

Page
Page

A-019730-1647417034966-137850-W.M.Supun Anjana SAD

Uploaded by

Copyright:

Available Formats

A-019730-1647417034966-137850-W.M.Supun Anjana SAD

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A-019730-1647417034966-137850-W.M.Supun Anjana SAD

Uploaded by

Copyright:

Available Formats

Higher Nationals

Internal verification of assessment decisions – BTEC (RQF)

INTERNAL VERIFIER CHECKLIST

Do the assessment criteria awarded match

Has the work been assessed

Is the feedback to the student:

Assessor signature Date

Internal Verifier signature Date

Assessor signature Date

W.M.Supun Anjana System Analysis and Design 1|

W.M.Supun Anjana System Analysis and Design 2|

LO2 Produce a feasibility study for a system for a business-related problem

LO3 Analyse their system using a suitable methodology.

LO4 Design the system to meet user and system requirements.

Grade: Assessor Signature: Date:

Grade: Assessor Signature: Date:

Signature & Date:

W.M.Supun Anjana System Analysis and Design 3|

W.M.Supun Anjana System Analysis and Design 4|

Word Processing Rules

W.M.Supun Anjana System Analysis and Design 5|

1. I know that plagiarism is a punishable offence because it constitutes theft.

Student’s Signature: Date:

W.M.Supun Anjana System Analysis and Design 6|

Unit Number and Title Unit 4: Systems Analysis & Design

Academic Year 2021/22

Assignment Title Automated system for E-Solutions Private Limited

IV Name & Date

Unit Learning Outcomes:

Assignment Brief and Guidance:

W.M.Supun Anjana System Analysis and Design 7|

Additional functionality includes:

W.M.Supun Anjana System Analysis and Design 9|

LO1 Evaluate the strengths and weaknesses of the

P1 Discuss the strengths and weaknesses of the traditional 15 – 23

M1 Compare and contrast the strengths and weaknesses of 24 – 31

LO2 Produce a feasibility study for a system for a

P2 Produce a feasibility study for a system for a 33 – 39

M2 Evaluate the relevance of the feasibility criteria on the 38 – 41

LO3 Analyse their system using a suitable

W.M.Supun Anjana System Analysis and Design 11 |

LO4 Design the system to meet user and system

P4 Design a fully functional system to meet user and 73 – 76

M4 Assess the effectiveness of the system design with 76 – 81

LO3 & LO4 50 - 97

W.M.Supun Anjana System Analysis and Design 12 |

W.M.Supun Anjana System Analysis and Design 13 |

W.M.Supun Anjana System Analysis and Design 14 |

W.M.Supun Anjana System Analysis and Design 15 |

Discuss traditional and agile system analysis methodologies

Project management in the traditional sense is a well-established discipline that entails

W.M.Supun Anjana System Analysis and Design 16 |

W.M.Supun Anjana System Analysis and Design 17 |

A prototype is a quick-built version of a system or a component of a system to evaluate

W.M.Supun Anjana System Analysis and Design 18 |

W.M.Supun Anjana System Analysis and Design 19 |

W.M.Supun Anjana System Analysis and Design 20 |

W.M.Supun Anjana System Analysis and Design 21 |

W.M.Supun Anjana System Analysis and Design 22 |

W.M.Supun Anjana System Analysis and Design 23 |