SYSTEM ANALYSIS & DESIGN
Assignment
Higher Nationals
Internal verification of assessment decisions – BTEC (RQF)
INTERNAL VERIFICATION – ASSESSMENT DECISIONS
Programme title
HND in Computing
Assessor
Unit(s)
Assignment title
Internal Verifier
Unit 34: System Analysis & Design
Automated system for E-Solutions Private Limited
Student’s name
List which assessment criteria
the Assessor has awarded.
Pass
Merit
Distinction
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
student work?
Y/N
Has the work been assessed
accurately?
Y/N
Is the feedback to the student:
Give details:
• Constructive?
• Linked to relevant assessment criteria?
• Identifying opportunities for
improved performance?
• Agreeing actions?
Y/N
Y/N
Y/N
Does the assessment decision need
amending?
Y/N
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
Internal Verifier
signature
Date
Programme Leader
signature (if required)
Date
1
Higher Nationals - Summative Assignment Feedback Form
Student Name/ID
Unit 34: System Analysis & Design
Unit Title
Assignment Number
1
Assessor
Submission Date
Date Received
1st submission
Re-submission Date
Date Received 2nd
submission
Assessor Feedback:
LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis
methodologies
Pass, Merit & Distinction
Descripts
P1
M1
D1
LO2 Produce a feasibility study for a system for a business-related problem
Pass, Merit & Distinction
Descripts
P2
M2
LO3 Analyse their system using a suitable methodology.
Pass, Merit & Distinction
Descripts
P3
M3
D2
LO4 Design the system to meet user and system requirements.
Pass, Merit & Distinction
Descripts
Grade:
P4
M4
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.
2
Pearson Higher Nationals in
Computing
Unit 34: Systems Analysis & Design
Assignment 01
3
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





The font size should be 12 point, and should be in the style of Time New Roman.
Use 1.5 line spacing. Left justify all paragraphs.
Ensure that all the headings are consistent in terms of the font size and font style.
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.
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
4
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:
(Provide E-mail ID)
Date:
(Provide Submission Date)
5
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.
6
Assignment Brief and Guidance:
*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:
1. 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.
7
Activity 01
Discuss traditional and agile system analysis methodologies used in the industry by
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.
8
Acknowledgement
Working on this assignment has been an amazing, thrilling, sometimes difficult, but
always fascinating experience. This work would not have been accomplished without the
help of several people. First and foremost, I would want to convey my heartfelt gratitude
to my lecturer, Ms. Prasadini. This work cannot be completed successfully without her
supervision and cooperation. And I would wish to take this opportunity to thank my
institute, ESOFT Metro Campus, for providing us with the required resources. I would
especially want to thank my parents, family members, and friends, all of whom I hold in
high respect, and I would like to express my heartfelt gratitude to everyone who has
assisted me.
9
10
1.1 What is System Analysis and Design?
1.1.1. A System
A system is made up of several interconnected or interacting parts that behave in a
predetermined way to generate a coherent whole. A system's limits, structure, and purpose,
as well as how it functions, all depend on and are influenced by its surroundings.
1.1.2 System Analysis
It is a procedure for gathering and analysing data, determining the issues, and breaking down
a system into its constituent parts. System analysis is done to investigate a system or its
components in order to pinpoint its goals. It is a technique for solving problems that makes
the system better and makes sure that all of its parts function effectively to serve their intended
purposes. Analysis outlines the system's actions.
1.1.3 System Analyst
In information systems development initiatives, the system analyst is significant. In order for
the team to design the correct system in an efficient manner, the systems analyst collaborates
closely with every project team member. System analysts need to be tech-savvy in order to
address business issues.
Systems analysts can also act as change agents by determining the organizational
improvements that need to be made, designing the systems to carry out those changes, and
inspiring people to adopt the systems.
This individual builds the brand-new information system and makes sure that all IS standards
are upheld while also coming up with ideas and proposals for how IT may support and
enhance business operations that are backed by IT. The system analyst will have extensive
training, experience, and programming knowledge.
11
Fig 01: System Analyst
1.1.4 Systems Design
Planning a new business system or updating an existing system involves describing its modules
or components to meet the necessary requirements. Prior to making any plans, it is important
to thoroughly study the current system and discover the most effective ways to use computers.
The goals of the system are the key focus of system design.
System Analysis and Design mainly focuses on;
a. Systems
b. Processes
c. Technology
1.2 System Development Life Cycle
1.2.1 What is SDLC?
A conceptual model for project management known as the systems development life cycle
(SDLC) details the phases of an information system development project, from the early phase
of a feasibility study to the ongoing maintenance of the finished application. Both technical
and non-technical systems can use SDLC. A system is typically an IT technology, including
12
hardware and software. Standard SDLC participants include system and software engineers,
development teams, and end users. Project and program managers are also frequently present.
Fig 02: System Development Life Cycle
Every piece of hardware or software will go through a development process, which is a series
of processes that can be thought of as iterative. The SDLC is used to provide a strict
framework and structure to specify the stages and steps required in system development.
1.2.2 Steps of the SDLC
There may be several steps in an SDLC. There aren't any certain, predetermined steps. The
typical number of steps is 7 or 8, but there can be anywhere from 5 to 12.
1. Gathering Requirements
In order to create a product that meets the needs of the consumer, all necessary information is
gathered from them during this phase. Any questions must be answered during this specific
time.
13
Fig 03: Gathering Requirements
2. Analysis
A meeting is scheduled with the client by the business analyst and project manager to obtain
all the necessary information, such as what the client wants to construct, who will be the end
user, and what the product's purpose is. A fundamental knowledge or understanding of the
product is crucial before building it.
3. Design
The requirements acquired in the SRS document are utilized as an input in this phase to
determine the software architecture needed to implement system development.
4. Development
The moment the developer receives the design document, implementation and coding begin.
The source code is converted from the software design. During this phase, the entire
software is implemented.
5. Testing
As soon as the code is finished and the modules are made available for testing, testing
begins. The software is rigorously evaluated in this phase, and any flaws are assigned to
developers to be corrected. Retesting and regression testing are carried up up till the
program meets customer expectations. To ensure that the program meets the requirements
of the customer, testers consult the SRS document.
6. Deployment
14
Depending on the customer's expectations, the product may first undergo UAT (User
Acceptance Testing) before being deployed in the production environment.
7. Maintenance
After a product has been deployed in a production environment, the developers are
responsible for maintaining the product, taking care of any issues that need to be resolved or
enhancements that need to be made.
1.3 System Development Methodology
System development methodology is a framework used in software engineering to organize,
plan, and manage the design of information systems. System development methodologies are
recommended as a way to enhance the management and control of the software development
process, structure and optimize the procedure, and standardize the development process and
end product by defining the tasks to be completed and the methods to be applied.
There are two main types of system development methodologies. They are;
1. Traditional
2. Agile
Fig 04: System Development Methodologies
15
1.3.1 Traditional System Development Methodology
Software development lifecycle stages and phases are the foundation of conventional software
development approaches. Requirements lead to design, which leads to development, which
leads to testing, which leads to maintenance in this situation.
Waterfall, Iterative, Spiral, and V-Shaped are the most commonly used traditional
Software Development Lifecycle models.
1.3.1.1 Waterfall Model
The systems development life cycle model for software engineering is widely used, and it
uses the waterfall approach. The waterfall model defines a way of development that is linear
and sequential and is frequently recognized as the traditional approach to the systems
development life cycle.
Fig 05: Waterfall Model
1.3.1.1.1 Phases of Waterfall Model
1. Requirement Gathering and Analysis
The business analyst gathers the requirements at this phase, and the team thereafter evaluates
them. During this phase, requirements are documented, and clarifications might be requested.
The project team requires answers to the following questions, which were not addressed in
the requirements document, after going over and reviewing the requirements.
16

Will the new banking app be utilized internationally?

Should we support multiple languages?

How many users can be expected for the app?
2. System Design
Working on the project's software architecture, high level and low level designs are the
architect and more seasoned team members.
In order to ensure that the system is always accessible, it is decided that the banking
application needs redundant backup and failover capabilities.
High level and low-level design documents are produced by the architect.
3. Implementation
The project's coding is done by the development team.
They use the design artifacts or documentation to make sure that their solution adheres to the
architecture's finished design.
They include a number of security checks and audit logging capabilities in the program
because it is a banking application and security was a top priority in the application
requirements.
They also carry out a variety of other tasks, such as having a senior developer check the code
of the junior developers for errors. The code is statically analyzed by some developers.
17
4.
Testing
The testing team runs through the entire application and looks for any bugs. The testing team
tests the fixes to make sure the faults are fixed after the developers have fixed them. To test the
application from a domain viewpoint, testers with experience in the banking industry were also
employed for the project. Teams of security testers were tasked with evaluating the banking
application's security.
5. Deployment
On the servers that were purchased for the banking application, the team constructs and installs
the program. The installation of the OS on the servers, the application of security patches, the
hardening of the servers, the installation of web servers and application servers, the installation
of databases, etc. are some examples of high-level tasks. To get the application functioning on
the production servers, they also coordinate with network and IT administrative departments,
among others.
6. Maintenance
The team makes sure the application is operating faultlessly on the servers with no downtime
during the maintenance process. After becoming live, issues that are reported are repaired by
the team and tested by the testing team.
1.3.1.1.2 Advantages of Waterfall Model:

This model is clear, understandable, and practical.

Because of the rigor of the model and the fact that each phase has a set of outcomes
and a review process, it is simple to manage.
18

This model processes and completes steps one at a time. Phases do not even cross
over.

For smaller projects with well-defined and well-understood needs, the waterfall
approach is effective.
1.3.1.1.3 Disadvantages of Waterfall Model:

It is quite challenging to go back and update something that was badly executed
during the concept stage once an application is in the testing stage.

It takes till the end of the life cycle for any working software to be generated.

Risk and uncertainty are very high.

Unsuitable as a model for complicated and object-oriented projects.

Ineffective model for continuing, protracted projects.

Not appropriate for projects where there is a moderate to high probability of
requirements changing.
1.3.1.1.4 When to use Waterfall Model:

Only when the needs are clearly visible, well-defined, and fixed is this model
applied.

Definition of the product is stable.

Technology is comprehended.

No unexplained requirements exist.

There are many resources and experts available for free.

The undertaking is brief.
19
1.3.1.2 Prototype Model
A prototype is produced, tested, and then revised as necessary under the prototyping model,
a systems development approach, until a suitable prototype is eventually achieved from
which the whole system or product may now be developed.
Fig 06: Prototyping Model
1.3.1.2.1 Phases of Prototyping Model
 Requirements gathering and analysis
Details of the system's requirements are defined.
 Design
A brief design or a preliminary design. It provides the user with a quick overview
of the system. Quick designs facilitate the creation of the prototype.
 Prototyping
Actual prototypes are created using the data acquired during quick design. It is a
scaled-down version of the necessary system.
20
 Customer Evaluation
A developed prototype is demonstrated to the client for a first inspection.
 Review and Updation
If the user is dissatisfied with the existing prototype, it needs to be improved in
accordance with their feedback and ideas.
A final system is created based on the final prototype that has been accepted once the
user is satisfied with the developed prototype.
 Implement Product and Maintain
After comprehensive testing, the final system is placed into production after being
created based on the final prototype.
1.3.1.2.2 Advantages of Prototyping Model:

Lower costs and time:
-
The quality of the requirements and specifications given to
clients is improved through prototyping. Customers can predict
greater expenses, necessary adjustments, significant project
roadblocks, and most crucially, potential disastrous final results,
with prototyping. For years to come, good prototyping can
guarantee product quality and cost savings.

User engagement has improved and grown:
-
Most clients want to feel like they are involved in all the minute
details of their project. Users can see and engage with a
functioning model of their idea through prototyping, which calls
for
their
participation.
Customers
can
adjust
model
specifications, request project revisions, and provide fast
feedback when using prototypes. Most significantly, prototyping
21
helps prevent misinterpretations and misunderstandings during
the development process.

Reduced expenses and time:
-
Projects that are completed on time and under budget are always
a hit with clients. The criteria and specifications that are given to
clients are of higher quality because of prototyping.
Implementing changes that are discovered later in development
is significantly more expensive. With fast and less expensive
software, prototyping enables you to determine early what the
end user wants.
1.3.1.2.3 Disadvantages of Prototyping Model:

Time-consuming:
-
Creating the prototype model takes a lot of time. Multiple
prototypes are tested before the final product is developed, which
takes a lot of time.

Inaccurate assumption regarding the delivery of the finished item:
- At a very early stage, the customer has direct touch with the
prototype. The buyer might assume that the real product will also
arrive early as a result, which could result in confusion.
Sometimes, this may not be the case.

Make poor decisions:
-
The creator is always concerned with the quality of their
creation. However, they could make poor choices about the
22
prototype's quality while rushing to create it, which could have
an impact on the final product.

Misunderstandings about the finished product:
- Customers may become annoyed and frustrated with the
prototype model and lose interest in the final product. Customers
may believe that the final version will have the same flaws even
though it is enhanced and refine.
1.3.1.3 Spiral Model
One of the most significant models for the Software Development Life Cycle that supports
risk handling is the spiral model. In diagrammatic form, it resembles a spiral with several
loops. The spiral's precise number of loops is unclear and varies from project to project. A
phase of the software development process is referred to as each spiral loop. The project
manager might alter the precise number of phases required to build the product depending on
the project's risks.
23
Fig 07: Spiral Model
At each given point, the spiral's radius symbolizes the project's overall costs, while its
angular dimension indicates how far along the current phase is.
1.3.1.3.1 Steps of the Spiral Model
According to the above diagram, the four quadrants represent each phase of the spiral
model. The following is a discussion of these four quadrants' functions:
1. Determine the objectives and find potential solutions: At the beginning of each step,
the objectives are specified, developed upon, and analyzed while requirements are acquired
from the clients. Then, in this quadrant, other solutions that might be possible for the phase
are offered.
24
2. Risk identification and resolution: In the second quadrant, all potential solutions are
assessed in order to choose the optimal one. The risks connected to that solution are then
determined, and the risks are dealt with in the best way feasible. The Prototype is
constructed for the ideal outcome at the end of this quadrant.
3. Next-generation product development: when the identified features are developed and
tested. The following software version is accessible at the conclusion of the third quadrant.
4. Review and preparation for the next Phase: The customers assess the software's
currently created version in the fourth quadrant. Planning for the following step is then
begin.
1.3.1.3.2 Advantages of Spiral Model

The software life cycle begins with the production of software.

The Spiral model is the greatest development model to use since it incorporates risk
analysis and risk management at each stage, which is one of its key features.

Suitable for large and complex projects.

Adaptability in the needs. With this model, needs may be accurately and readily
changed at subsequent stages. Additionally, later on, more functionality can be added.

It improves client satisfaction. At an early stage of the software development process,
we can involve clients in the creation of goods. Additionally, early in the software life
cycle, software is developed.

It is appropriate for high-risk projects where business requirements could be erratic.
This can be used to create a product that is highly customized.
1.3.1.3.3 Disadvantages of Spiral Model

Due to its high cost, it is not appropriate for smaller projects.

Compared to other SDLC models, it is considerably more complex. Process is intricate.

Too much reliance on risk analysis and the need for very specialized knowledge.

difficulty managing one's time. Time estimation is highly challenging because the
project's starting doesn't know how many phases there will be.
25
1.3.1.4 Differences
1.3.1.4.1 Differences between waterfall model and prototype model
Waterfall Model
Prototype Model
Waterfall Model can be identified as one of
Prototype model is developed, tested and
the linear and sequential methods
process according to customer
requirements
It highlights the risk analysis
Does not give much attention to risk
analysis
Selecting waterfall model is appropriate
If the client is expected to change his
when the needs of the customer is clear
requirements in the middle of the project it
is best to select the Prototype model
Association with the user is only taken
Hight user involvement
place at the beginning
It supports automatic code generation,
It does not support the automatic
minimizing the need for manual code
generation of code
execution
It is complicated to modify the content in
The prototype model is easily adaptable
waterfall model
The complexity of an error grows as the
The difficulty of an error is minimal since
model's nature evolves; one step follows
the prototype allows the developer to
the next
identify any flaws early in the process
1.3.1.4.2 Differences between Waterfall model and Spiral Model
Waterfall Model
Spiral Model
Simple and not complicated
Mode of the Spiral model is more
complicated
Waterfall model is linear and sequential
The spiral model involves an evolutionary
method
process
Risks can be identified after completion of
Risks can be identified in the early stage
every phases.
when using the spiral model
26
Depend on clients
Spiral model is acquired by developers
Most suitable for small scale projects
Most suitable for large scale projects
The waterfall model is rather affordable
While the spiral model is rather costly
It is not difficult to update the content in
It is difficult to change the content of the
spiral model.
waterfall model.
In the Waterfall Model, engagement of the
Client participation is high in the Spiral
client is minimal.
Model.
The customer has relatively less authority
In contrast to the waterfall method,
over the administrator
customers have influence over the
administrator
1.3.1.4.3 Differences between Prototype and Spiral Model
Prototype Model
A prototype model is a software
Spiral Model
The spiral model is a risk-driven software
development method in which a prototype
development method that incorporates
is produced, tested, and refined to meet the
elements of incremental, waterfall, and
demands of the client
evolutionary prototyping techniques
It's also known as a quick or closed-ended
It is also known as a meta model
prototype
It does not place a high value on risk
It requires significant care to analyse risks,
assessment
and an alternate solution is implemented
Client contact is continuing in the
prototype model until the final prototype is
authorized
It is best suited when the client's demand is
There is no continuous client engagement
in the spiral model
unclear and has to be altered
are clear
It works best when the client's requirements
27
1.3.2 Agile Methodology
Agile methodologies in software development are collections of software development
strategies that accelerate the development process. In general, agile development-based
methodology is a different approach to managing software projects than other traditional
software methodologies.
Agile methodologies are a collection of software development activities created by
experienced software developers.
Fig 8: Agile Methodology
Agile techniques are progressive, with modest increases. In less than three weeks, the new
software product created utilizing agile methodologies is delivered and made available to
consumers. These strategies include clients throughout the development process in order to
accommodate changing requirements during the process. Agile approaches also reduce
documentation by relying on internal conversations rather than formal meetings with written
documents.
28
Fig 9: Agile methodology Phases
1.3.2.1
Scrum Methodology
Scrum is without a doubt the most popular of the several frameworks that support Agile
technique. Scrum is distinguished by development cycles or stages known as sprints, as well
as by the maximization of development time for a software product toward a goal known as
the Product Goal. This Product Goal is a higher-level value target toward which sprints
move the scrum team's product closer.
Sprint 1-n
Project Inception
TO Planning
Integration
Regression
Testing
Continuous
Integration
Transition
Development
Requirements
Refinement
Product Backlog
Sprint
Planning
meeting
Sprint
Backlog
Fig 10: Scrum Methodology
Sprint
Review
Meeting
Functionally
Tested
Software
29
In 1995 SCRUM Model was introduced by Ken Swaber as one of the lightweight
frameworks and it can be defined as a adaptable, Comprehensive product development
strategy in which a development team works together to achieve a common goal.
1.3.2.1.1
Phases of Scrum Methodology
Scrum phases refer to the various stages of a Scrum management strategy. They give a
framework for an organization and its team members to operate inside when working on a
project, as well as tools for assessing and improving the process in the future. Each element
of the Scrum process is critical to assisting the organization in maximizing the benefits that
this framework delivers.
There are five Scrum phases of good project management.
1. Initiation:
The initiation phase of a Scrum framework is when you develop a vision for your project.
This contains critical identifying points such as noting who the project's stakeholders are
and assigning the job of Scrum Master to yourself or another member of the team in charge
of carrying out the plan.
2. Planning
We intend for a sprint during this phase, which is a brief, time-boxed timeframe that can
help the team interact more successfully. As the team completes each sprint, they may
subsequently merge them to complete all of the project backlog components.
3. Implementation
The sprint is implemented as planned during the implementation phase. They keep an
updated backlog throughout this phase, eliminating things when workers finish them and
allocating new tasks from the backlog as needed. Consider holding a meeting to deliver
project updates and to go through work goals and concerns. Encourage workers to express
questions, make suggestions, or submit relevant notes for the other members to hear at this
30
meeting. This procedure, like the planning and estimating phases, can be repeated until the
project is completed.
4. Reviewing
Consider having a review meeting with the team at the conclusion of the project to discuss
the sprint to collect feedback. Based on the findings of the completed sprint, this meeting
gives a chance to review what went well and where there are room for growth. It enables the
team to make changes to processes and procedures in order to be successful as they go into
the next planning and estimate phase.
5. Releasing
The last step is the release phase, during which the team delivers any final deliverables to
stakeholders, such as releasing a product to market or offering produced technology to a
customer. Consider holding a project retrospective meeting with your team after the product
has been released to examine the success of each individual sprint and to review the overall
performance of the project. Identifying areas that function well and those that struggle will
help you choose what to aspire for and what to avoid in future Scrums to get the most out of
your next project.
1.3.2.1.2
When to use Scrum Methodology?
1. When the change probability during development is high:
Changes in requirements can be a form of common currency in software development, with
specialized protocols for managing them. Even if the requirements are well established,
there will be occasions when adjustments are necessary as the project advances. This might
happen in initiatives when there are technology advancements or in the commercial setting.
2. When the requirements are not explicitly defined:
31
Many times, a customer has a basic notion of the product he wants to create, but he lacks
precise or well-defined specifications about how it should be. There are various implications
of not having a clear definition of the criteria.
3. When it is necessary to test the solution:
This point is closely connected to the preceding ones. An MVP (minimum viable product)
may be necessary in the development of a new product in order to test specific market
qualities that we may wish to check, allowing it to be iterated based on the results of that
test.
This process generates some adjustments that have an influence on what has previously
been built, as well as new ideas and features to be developed.
4. When the team can manage themselves:
Agile working teams demand a particular amount of seniority from their members since,
while the Scrum Master is present, the project involves a lot of self-management and
communication. The right application of these sorts of approaches may become more
complicated if the development team is unskilled.
1.3.2.1.3
Roles and Responsibilities of Scrum Methodology
In contrast to traditional project management systems, Scrum does not have and does not
require a product manager, task manager, or team leader. A scrum team is slightly different
in composition than a standard waterfall project, having three distinct roles such as:

Product Owner

Scrum Master

Development Team
These three jobs are coequal, and each has specific duties.
32

Product Owner
The role of the Product Owner, who acts as a coordinator between the team and other
parties involved, is critical to the success of scrum (stakeholders). Product owners are not in
charge of the program's status. A product owner is not the same as a project manager. They
guarantee that the development team adds the maximum value to the organization. It is also
critical that the product owner be an individual. No development team wants contradictory
advice from different product owners. Furthermore, having numerous product owners may
cause confusion for both the team and the stakeholders, resulting in sprint cycle delays.
In scrum-enabled organizations, the tasks and responsibilities of each Product Owner are
never the same. The Product Owner's job is the most complex in terms of the method being
followed.
Product owners are the product's advocates. They are focused on understanding the business
and market needs and then prioritizing the work to be done by the engineering team
accordingly.
Qualities of Good Product Owners

Give the team specific instructions on which features to deploy next

The priority of each item in the Product Backlog is set

Create and maintain the product backlog

Work closely with the business and the team to ensure that everyone knows the work
items in the product backlog.
In addition, the Product Owner is accountable for the return on investment (ROI). After all,
it is his responsibility to manage the financial aspects of product development, which he
accomplishes by consistent effort and prioritization of increasing tasks.
What does it mean to be a Product Owner?

Liable for the achievement of the team's product delivery result

User stories are prepared for the growth of the team
33

Domain Knowledge is a must

Respond quickly to callbacks

Interact with all stakeholders, funders, and team members.

Taking excellent care of the project's finances.

Scrum Master
Fig 11: Scrum Master
Scrum masters are the scrum champions of their team. The Scrum Master is the specific
person in charge of ensuring that Scrum values, principles, and rules are implemented and
enforced. They train the team, the product owner, and the company on the scrum process
and search for methods to improve its implementation.

An efficient scrum master knows the team's work and may assist the team in
optimizing their delivery flow.

As the primary facilitator, they organize the necessary resources (both human and
logistical) for sprint planning, stand-up, sprint review, and other agile procedures.

Scrum masters help investigate and resolve barriers and distractions for the
development team.

They shield the development team from outside interruptions wherever feasible.

Another key role of the Scrum master is to ensure that the team follows the rules and
fully understands the Scrum technique.
34

Development Team
A Development Team is a group of people that collaborate to create and deliver the needed
and committed product increments. It is made up of cross-functional people who are
capable of meeting the sprint objectives. This might comprise software engineers,
architects, programmers, analysts, system administrators, quality assurance specialists,
testers, UI designers, and so on.
 The Development Team creates the product that the Product Owner specifies, such
as an application or website. Scrum teams are "cross-functional."
 Each Sprint, the Development Team contains all of the skills required to develop a
potentially shippable product.
 The Development Team self-organizes and has a high level of autonomy and
responsibility.
Fig 12: Development Team
35
1.3.2.1.4 Advantages of Scrum Methodology

Adaptable and Flexible
-

It promotes innovative techniques
-



Creativity is fostered and new ideas are likely to emerge when
Scrum teams collaborate and analyse ideas from all of its
members.
It frequently results in higher-quality work
-
Having everyone on the team accept full accountability and
ownership of their job helps foster a productive environment that
results in high-quality outcomes.
-
Adopting the Scrum model may save a company money since it
involves less paperwork and management.
It is inexpensive
Customer satisfaction rises as a result
-

Scrum is appropriate for a wide range of locations and
circumstances that do not have well defined criteria at the outset
and necessitate a flexible approach.
Everyone on the team working to the best of their ability and
continually changing depending on internal and external input
can result in customer-friendly goods and solutions.
It usually leads in job satisfaction
-
With everyone on the team assuming full responsibility for their
work, the Scrum methodology increases the likelihood that
project participants will be engaged and happy.
36
1.3.2.1.5
Disadvantages of Scrum Methodology
But, like every other methodology, scrum has its drawbacks.
Nothing is perfect, even the Scrum approach. Scrum is sometimes paired with other project
management strategies to help lessen some of these drawbacks:
 Due of the lack of a fixed end-date, Scrum frequently leads to scope creep
 If they aren't dedicated or cooperative, there's a good probability the project will fail
 Implementing the Scrum framework in large groups is difficult
 Only experienced team members can ensure the framework's success
 Team members might become irritated by daily meetings
 Any team member who departs in the middle of a project might have a significant
negative influence on the project
 Quality is difficult to implement until the team goes through a rigorous testing
procedure
37
1.3.2.2
XP (Extreme Programming)
Extreme Programming (XP) is an agile software development approach that attempts to deliver
higher quality software while also improving the development team's quality of life. In terms
of proper engineering methods for software development, XP is the most detailed of the agile
frameworks.
Fig 13: Extreme Programming (XP)
1.3.2.2.1 Steps of the XP
1. Planning
The first step involves the client meeting with the development team and presenting the
requirements in the form of user stories to explain the intended outcome. The team then
estimates the stories and develops a release strategy that breaks down the required functionality
38
into iterations. If one or more of the tales cannot be approximated, so-called spikes are inserted,
indicating that additional investigation is required.
2. Designing
Designing is a component of the planning process, although it can be separated to emphasize
its significance. It's connected to one of the primary XP values we'll go over later - simplicity.
A smart design gives the system meaning and structure while avoiding unneeded complications
and redundancies.
3. Coding
Coding is the phase in which real code is written using XP principles like as coding standards,
pair programming, team collaboration, and collaborative code ownership.
4. Testing
Extreme programming revolves around testing. It is a routine activity that includes both unit
tests (automated testing to ensure that the generated feature functions properly) and acceptance
tests (customer testing to verify that the overall system is created according to the initial
requirements).
5. Listening
Regular connection and feedback are essential components of listening. Clients and project
managers are essential in describing the intended business rationale and value.
1.3.2.1.2 When we can apply Extreme Programming?




When software needs that are always changing
When risks associated with fixed-time projects utilizing new technologies
When extended development team that is small and co-located
The technology used enables automated unit and operational testing
39
1.3.2.1.3 Advantages and Disadvantages of Extreme Programming
Extreme programming has accelerated software development, but it is not appropriate for every
case or team. At the start of the project, XP considers that the client does not have a clear vision
of the end result. In certain instances, the software can be agile, which means it can be designed
and built progressively.
Advantages
Interpersonal relationship with the client
Disadvantages
Additional effort should be given
There will be no additional programming The customer must be involved in the
labour.
process.
Continuous testing results in stable software. Considerable time investment
Pair programming helps to avoid errors.
Costs are rather expensive.
There will be no overtime; teams will Version control is required.
proceed at their own rate.
Changes may be implemented quickly.
Practice necessitates self-discipline.
1.3.2.3 Advantages of Agile Methodology
 Satisfy the client by delivering valuable software on time and on a consistent basis. The
emphasis is on customer satisfaction and high-quality deliveries
 Accept changing needs, especially if they emerge late in the development process.
Agile methods use change for the benefit of the customer's competitive advantage.
Instead of fighting change, learn to embrace it
 Deliver functioning software on a regular basis, from a few weeks to a few months,
with a preference for the shorter duration. Continuously provide outcomes throughout
a project, not just at the end
 Throughout the project, businesspeople and developers must collaborate on a regular
basis. Collaboration is essential
40
 Build initiatives around motivated people. Give them the atmosphere and support they
require, and trust them to do the task. Bring on talented and industrious team members
and get out of their way
 Face-to-face communication is the most efficient and effective way of transmitting
information to and within a development team. Reduce the number of potential for
misinterpretation as much as feasible
1.3.2.4 Disadvantages of Agile Methodology
 It is less predictable
The Agile method's inherent flexibility also implies a far lower degree of predictability.
Accurately estimating the time required or quantifying the resources and efforts required to
execute a project can be significantly more challenging. Many teams are afraid of ambiguity,
which may lead to dissatisfaction and poor decision-making.
 More time and effort
Communication and collaboration are good, but they require more time and energy from
everyone involved.
 Greater expectations of developers and clients
Agile Methodology requires commitment from all parties involved in order to be effective.
Anyone who is not on board can have a detrimental influence on the project's quality.
 There is a lack of relevant documents
Because tasks are frequently finished only in time for progress under the Agile Method,
documentation is generally less extensive, which might lead to confusion and challenges later
on.
41
 Projects can quickly get off track
Because Agile Methodology is less regimented, projects can readily deviate from their initial
scope.
2.1 What is Feasibility Study?
A feasibility study, as the name implies, is intended to determine if a project or proposal is
viable. It is an evaluation of the feasibility of a given project or plan. A feasibility study is a
component of any project's or plan's early design stage. It is carried out in order to discover the
strengths and weaknesses of a prospective project or an existing firm objectively. It may aid in
identifying and assessing the natural environment's potential and risks, as well as the resources
needed for the project and its chances of success. It is carried out in order to answer the
following questions:

Is the firm equipped with the necessary resources and technology?

Will the corporation get a good enough return on its investment?
2.2 Importance of using feasibility study
Uncertainty is a reality that all businesses encounter on a daily basis. Getting clients in the
door, encouraging them to spend, and eventually turning a profit are fundamental goals that
might be tough to execute at times. Changing, adapting, and introducing new goods and ideas
into your company mix are methods to reduce some of the uncertainties you encounter, but
such processes may be exceedingly unpredictable without sufficient preparation and
planning. Enter the feasibility study: an opportunity to ask and receive answers to questions
that will help you assess potential and predict success or failure.
 Most Likely to Succeed
42
The phrase "feasible" refers to an action or occurrence that is likely, likely, or viable to occur
or occur. A feasibility study is the sum of the actions you perform and the questions you ask
to establish the viability of an idea, theory, or strategy. Effective research can help to decide
whether to proceed with the concept, tweak it, or trash it entirely and start again.
 Specific and focused
Feasibility studies are specific and targeted. They begin with a single question - if the concept,
event, or action is a feasible solution - and require you to focus entirely on that subject,
digging down to investigate alternative possibilities.
 The Entire Picture
Feasibility studies are significant because they force employees to think about the large
picture first, then think top-down. In this manner, one or two generic beginning questions lead
to a slew of subsequent, more comprehensive inquiries that narrow in focus as you approach
closer to an eventual response.
 Alternative Possibilities and Solutions
Feasibility studies provide the opportunity to "get it right" before devoting time, money, and
corporate resources to a concept that may not function as expected, necessitating more
investment to repair flaws, eliminate limits, and then simply try again. Feasibility studies may
also introduce you to fresh options, opportunities, and solutions that you may not have
explored otherwise. There are no right or incorrect answers to your inquiries, but a response
that you don't necessarily want or expect might open up new profit opportunities.
2.3 Elements of Feasibility Study
A business case study for a project is an important stage in the project lifecycle since it depicts
the foundation of the project's inception. In most corporate organizations, the completion of a
business case is the first step toward project start.
Any good feasibility study for a business case consists of six sections. They are,
43
1. The Project Scope:
The project scope defines the business problem or
opportunity that will be handled. The scope should be clear and to the point, and it
is also vital to describe aspects of the company that are directly or indirectly affected
by the project, such as project participants and end-user regions.
2. The Current Analysis: The current analysis is used to define and comprehend
the current way of implementation, which might be a system, a product, or
something else. The existing approach's strengths and drawbacks should also be
acknowledged.
3. Requirements:
The technique by which the requirements are defined is
determined by the project's focus.
4. The Approach: The approach describes the suggested solution or plan of action
to meet the requirements. Various possibilities are examined here, along with an
explanation of why the preferred approach was chosen.
5. Evaluation: Examine the cost-effectiveness of the chosen technique. This
begins with an analysis of the project's expected overall cost. Other options are
estimated in addition to the recommended solution in order to provide an economic
comparison.
6. Review: that all of the preceding parts are then gathered into a feasibility study
and a formal review is undertaken with all stakeholders concerned. The evaluation
serves two purposes: to prove the depth and correctness of the feasibility study, and
to make a project selection.
2.4 Types of Feasibility Study Criteria
There are several categories of feasibility studies, each of which has a distinct
amount of influence on a project. Some of them are,
44

Technical

Operational

Economic

Schedule

Cultural

Legal/Ethical
 Technical Feasibility
The feasibility study examines if the existing technical resources are sufficient for the project
and whether the available technical resources are capable of implementing the planned
system. This assesses the available technical resources and their skills in relation to the
technical needs of the proposed project. This comprises the hardware, software, and other
technical requirements of the proposed system.
 Operational Feasibility
This is a measure of how effectively a suggested solution addresses the client's problems or
how well the project can satisfy the needs of the company. This also includes an examination
of how a project plan fits the criteria provided during the system development requirements
analysis phase.
 Economic Feasibility
Economic feasibility examines if the needed software can generate financial rewards for a
company. It includes the cost of the software development team, the expected cost of
hardware and software, the cost of conducting a feasibility study, and so on. Furthermore, the
benefits that may be obtained by designing the program must be considered. Software is
considered to be economically viable if it focuses on the following challenges.
 The expense of developing software to provide long-term benefits for a company
 cost of performing a complete software investigation
 Hardware, software, development team, and training costs
45
 Schedule Feasibility
the process of determining how well the projected time frame and completion dates for all
main activities in a project satisfy organizational deadlines and restrictions for effecting
change.

Cultural Feasibility
The cultural viability of the proposed project includes its compatibility with the project's
cultural surroundings. In labour-intensive projects, planned activities should be blended with
local cultural beliefs and customs.
what effect will it have on both local and global civilization?
environmental consequences does the feasibility study have?

Legal/Ethical Feasibility
The project team must do a detailed examination of the legal concerns surrounding the project
on several levels. A thorough legal due diligence should be performed to guarantee that all
expected legal needs, which have not or will not be addressed in earlier assessment
procedures, are satisfied for the project's progress.
46
2.5 Advantages and Disadvantages of Feasibility Study
Advantages
Disadvantages
It enables stakeholders to quickly recognize Since this study was conducted by gathering
the benefits and drawbacks of the proposed information rather than addressing a realproject.
world scenario, the feasibility results may
result in poor decision making.
Feasibility studies give investors useful This is a time-consuming and expensive
information that can help them make sound process.
business decisions.
A
feasibility study can
identification
of
project
aid
in
hazards
the It may take some time and effort to conduct
and an analysis.
associated contingency plans.
Feasibility studies also assist corporations in
the establishment of new businesses, such as
identifying how the business will work,
potential barriers, competition, market
analysis, and the amount and source of
capital required to build the business.
Considering the legal structure of the
company.
2.6 Desirability, Viability and Feasibility of the System
2.6.1 Desirability:
Customers or consumers desire or require products that match the attractiveness requirements.
After all, if you don't create a product that people want to purchase, you won't make any money.
To ensure your product's appeal, it must address an issue for someone in an intuitive and
pleasing manner.
47
2.6.2 Viability:
Products that satisfy the viability requirements make good commercial sense. These are goods
that, both immediately after their release and over time, will bring in money or save money
for a business.
A product's viability must be assessed by corporations by looking at:

who will be prepared to purchase the project?

if the sum equals profitability

how they intend to pay for it
2.6.3 Feasibility:
A product must be feasible in order to be constructed, either by the firm that developed it or
by a third party with the necessary technical skills. A corporation must be confident in the
ability to create the technology required to manufacture the product for it to be viable. They
must also have faith that it can be accomplished in a fair amount of time and at a cost that
will keep the product in demand.
Feasibility doesn't just consider if a technology can be used in practice. It also relies on
whether the product can be disseminated in a way that will guarantee it reaches the correct
clients, whether additional team members are required to produce the product, and whether
the new technology might help the company's existing goods.
2.7 Investigation Techniques
The following are the primary techniques employed to conduct system investigations:
o
o
o
o
Investigations
Interviews
Document Analysis
Observations
48
Investigations
During an inquiry, data is acquired using a professionally constructed questionnaire. After a
brainstorming session and after considering the goal of the preliminary survey, the
questionnaire is created.
Interviews
To obtain information directly from the users of the system under study, interviewing is a
face-to-face approach. To get information from the interviewee that would be helpful, the
interviewer will ask them a few pointed questions.
Document Analysis
The document analysis approach entails looking at the data, records, documentations, and
procedure manuals that are currently in use for the system.
Using this technique, the analyst may get accurate and realistic information on the system.
Observations
This approach entails watching how processes are carried out. The analyst uses the current
system to examine how work is done and how procedures are followed. This allows the
analyst to see first-hand how the job is actually done and what it entails.
2.8
Feasibility Report
Automated Project Management System for E-solutions private limited
Introduction:
This feasibility study assessed E-solutions Private Limited's ability to execute the proposed
Automated Information Management System.
Details of the Project:
Budget - LKR 1,000,000.00
49
Schedule Duration - 5 months
Technical Feasibility
Users would be able to access the proposed online application using widely used web
browsers as Google Chrome, Microsoft Edge, Firefox, etc. Local servers will be used to host
the application on-site. The connection is sufficient thanks to the current LAN infrastructure.
Internet access won't be allowed for the system. The development team have all the technical
skills necessary to put the system into operation.
Infrastructure
The program cannot be hosted on the currently available hardware, hence new server
environments are needed for the web server and the database server.
Operational Feasibility:
When the proposed system is deployed, personnel should get appropriate system training
that satisfies all of E-solutions private Limited's workflow criteria.
Legal Feasibility:
According to each client agreement, the system has the capacity to store project-related data
from E-solutions private Limited.
Economic Feasibility:
Evaluation of the cost elements as follows
Cost Item
Value (LKR)
Development Cost
600,000
Software Cost
150,000
Hardware Cost
420,000
Miscellaneous Cost
100,000
50
Total
1,270,000
3.1 Functional Requirements:
Functional requirements are descriptions of needed product characteristics or capacities of a
proposed system. These criteria indicate system-provided user amenities. Functional
requirements explain the behaviour of a system under certain situations.
Eg: E-solutions Private Limited's Project Director would want to start a project in the system.
Both the development team and the stakeholders must have a clear and detailed
understanding of the functional requirements; otherwise, the final system may not fulfil the
expectations of the customer.
A system's functional requirements should include the following elements:
 Details of procedures performed on each screen
 Details of procedures performed on each screen
 It must include descriptions of system reports and other outputs
 Comprehensive information on the system's processes
 It should specify who is authorized to create/modify/delete data in the system
 The functional document should provide information on how the system will meet
applicable regulatory and compliance requirements.
3.2 Non-functional Requirements
Non-functional Requirements define a software system's quality attributes. They evaluate
the software system based on its responsiveness, usability, security, portability, and other
non-functional characteristics that are crucial to its success.
Eg: Each web page has to load in less than 3 seconds
51
Non-functional requirements for the new system might be thought of as constraints,
objectives, or control mechanisms. They specify how well or to what standard the planned
system should function. A certain system, for example, should be able to execute 120
transactions per minute. Therefore, at the system analysis stage, it is critical to pay close
attention to non-functional needs as well as functional requirements.
3.3 Assessment of the effectiveness and suitability of the agile methodology in relation to
the proposed system
Product Quality
Agile methodology improves product quality in software development through,
 At the end of each sprint, do a retrospective to focus on ongoing improvement
 Defining and developing requirements in a timely way so that product knowledge is
as relevant as possible
 Embracing technical brilliance, improved design, and strategies for sustainable
development
 Product increases are continuously integrated and tested
 Maintaining improved team communication
 Use automated testing tools during the day, test overnight, and debug in the morning
 At the end of each sprint, there is continuous customer involvement and product
demonstration to the client
 It is simple to fix problems and flaws due to concurrent development and testing
 Having a product owner who is knowledgeable about the product's specifications
and the demands of the consumer
Motivated Team
An agile team is a self-organizing, cross-functional group. Being a member of a selfgoverning team encourages people to become creative, inventive, and to support the
52
development of multidisciplinary abilities. A scrum master protects the team from outside
influences and obstructions. Agile approach encourages team members to work effectively
together and to communicate with one another as well as with the product owner and
clients.
Enhanced Performance Visibility
In an Agile environment, every member of the team has the ability to gain an understanding
of how things are progressing on the project at any given time. The Project status is visible
thanks to daily scrums, progress charts, and visual boards.
Agile Team Structure
The number of team members in an agile team is restricted. It is a cross-functional team,
and they have all of the competences required to do their task without relying on those who
are not members of the team.
Improved Predictability
To increase project predictability, Agile methodology incorporates various best practices,
artifacts, and tools, which include,
 Time-boxed sprints of equal duration throughout the project lifetime provide an
estimate of cost each sprint
 The agile team velocity enables the project team to set release timelines and budgets,
as well as the remaining product backlog
 The project team may assess the performance of each sprint by using information
from daily scrum meetings, sprint burn down charts, and task boards
Reduced Project Risk
Agile methodology minimizes project risk by,
53
 Sprint development ensures a short period between initial project investment and
either falling quickly or understanding that a product or method will succeed
 Having a functional product from the very first sprint ensures that no agile project
fails altogether
 Developing requirements to the definition of worn out for each sprint so that project
sponsors have finished, useable features regardless of what happens with the project
in the future
 Self-funding initiatives generate money early, allowing groups to take control of a
project with minimum initial investment
4.1 System Design
The process of specifying technical characteristics of a proposed software system, such as
modules, system architecture, components, user interfaces, integration points, database
specification, and other essential technical concerns, is known as systems design.
4.2 Design Specification Document
The design specification document includes detailed descriptions of the software that will be
built, such as the proposed system's architecture, components to be implemented, database
design, suggested system interfaces, and so on. A senior technical member of the project team,
such as a software architect or technical lead, generally writes the design specification. This
document is regarded as the project team's primary technical reference source throughout the
project's life cycle. The software design document aids in ensuring that the program's design
specifications are properly understood and clear to the project team.
54
E-Solutions Private Limited Software Design Specification for an Automated Project
Detail Management System
1. Introduction
This paper details the Automated Project Detail Management System's Detailed Technical
Design, which includes system architecture sub-systems, components and their related
interfaces, database schemas, design goals, and the reasoning for the selected design. This
paper includes both high-level and low-level designs. This paper should be read by someone
who has expertise with data flow diagrams, control flow diagrams, interface designs, and
technical requirements.
2. Design Considerations
 Meet the customer-defined system performance targets
 Make a user-friendly, robust application
 Provide a dependable and expandable system
 Meet the customer-defined system security objectives
3. Architecture Design
Architectural Design gives an overall perspective of the system, including its subsystems,
which are produced from the requirement model's analytical packages. Software
development initiatives aiming for quick, sustainable delivery are merging agile and
architectural approaches to balance opposing goals of short-term speed and long-term
stability.
55
Architecture Diagram
Requirements
Reports
Deliverables
Strategic Planning and Control
Status Reports
Outline Plan
Work Directives
Work Schedule
Monitoring
Detailed Planning and
Scheduling
Technical
Development
Configuration
Management
Deliverables
Development Reports
Unchecked
Deliverables
Quality Control
56
Component Diagram
The component diagram depicts the structural links and interactions between the
components.
Project
Specification
(Project Overview)
Accounting & Cost
(Manage the
project cost)
Administration & Security
(set up and manage new
projects & users)
Visualization tool
(Visualize the project
cost, resources &
status)
Project Cost
Project Status
Content management
(manage the project
content)
Collaboration
Documents
Process Management
(manage the project
process)
Work flow
management
Meeting notes
Resource Management
(manage the project
resources)
task status report
Project
members
services
task & scheduling
equipment
57
Interface Specification
Form for login:
LOGIN
User Name:
Password:
Login
Save Login Info
Main Menu:
Project
Project Member
Project Category
Project Manager
Project Member
Assignment
58
Project form:
Project
Project
Company
Category
Project Name
Start Date
End Date
Remarks
PROJECT MEMBER
Member ID
Member Name
Member No.
E-mail
Member No.
Password
Status
Add
Update
Delete
59
Justification of using agile methodology in the context of the business problem
System design approach
The system was designed using the Agile Design process. Agile employs an iterative design
approach that begins with the first stage and progresses to the final level. The result is then
analysed, and several iterations are performed to further enhance it. The steps of the agile
design process happen concurrently. You start by breaking down the functionality into little
bits that can be supplied individually and working on them. This allows for speedier design
and faster feedback on work.
The agile design method includes the following characteristics:
Quick Responses: It is simpler to know what the consumer wants sooner rather than
supplying him with a complete prototype and then asking for feedback.
Change Management: Design changes are becoming easier and less expensive. There is no
squandering of time or money.
Quick Development: Providing tiny bits of design to the development team allows for faster
implementation. The development team does not wait for the design to be completed before
beginning implementation.
The Agile Analysis Method was utilized to create the Automated Project Management
System at E-solutions Private Limited for the reasons stated above.
60
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
and agile systems analysis methodologies.
M1 Compare and contrast 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.
P2 Produce a feasibility study for a system for a
business related problem.
61
M2 Evaluate the relevance of the feasibility criteria on
the systems investigation for the business related
problem.
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
P3
Review a system using a suitable methodology for a
business-related problem.
M3
Analyse the effectiveness of the methodology used in
providing a solution for a given business context.
LO4 Design the system to meet user and system
Requirements
62
P4 Design a fully functional system to meet user and
system requirements for the business related
problem.
M4 Assess the effectiveness of the system design with
reference to the methodology used and how the design
meets user and system requirements.
LO3 & LO4
D2 Justify the choice of the analysis methodology used in
the context of the business problem.
63
64
1. System Analysis and Design
1.1 What is a System?
The word "system" comes from the Greek word "systema," which denotes a structured interaction between any group of components working
toward a single goal or purpose.
A system must adhere to three fundamental restrictions.
2. A system needs to have some kind of structure and behavior that is planned to accomplish a specific goal
3. The system's component parts must be interdependent and interconnected
4. The organization's goals are more important than the goals of its subsystems
1.2 Systems Analysis
65