1

Course Title: Fundamentals of Software Development

(Course Code: 4331604)
SUGGESTED PRACTICAL EXERCISE

Sr.
No
INDEX
Select a software project and identify the process model with proper
1
justification.
Collect the functional requirements for the project. (Questionnaires/
2
stakeholders’ interview questions)
Analyse functional and non-functional requirement and prepare SRS
3
document for the project.
4 Prepare GANTT chart for selected system.
5 Prepare PERT chart for selected system.
6 Design DFD(context, level-1/2) for function oriented design.
7 Design data dictionary of the selected system.
Prepare User-case diagrams of the selected system for object oriented
8
design.
Prepare Activity diagrams of the selected system for object oriented
9 design.

10 Design appropriate User Interface based on the type of project.

Prepare the test cases to test the functionalities of the modules.
11
 2

Practical 1:
AIM: Select a software project and identify the process model
with proper justification.

1. Software Process: Process and

project Process :

A process is the sequence of steps executed to achieve a goal. A process is

defined by cycles. Similar to a project, a process also has a beginning, middle,
and end; however, this cycle repeats itself over an average period of time.

Project :

A project is defined by a fixed time, scope, and resources. When

implementing a project, the goal is to execute change usually some strict and
powerful changes to incorporate that change into the day-to-day processes
of the company.

Both projects and process are important for running and improving a

business. However, depending on the end result trying to be achieved, one

may be more suited than the other.

1. Component software process:

 The processes that deal with the technical and management

issues of software development are collectively called the
software process.

 As a software project will have to engineer a solution and properly

manage the project, there are clearly two major components in a
 3

 software -- process a development process and a project

management process.

 The development process specifies all the engineering activities that

need to be performed, where as

 the management process specifies how to plan and control these activities so
that cost, schedule, quality, and other objectives are met. Effective
development and project management processes are the key to achieving the
objectives of delivering the desired software satisfying the user needs, while
ensuring high productivity and quality.

 The objective of this component process is to primarily deal with

managing change, so that the integrity of the products is not
violated despite changes.

 product engineering processes, their main objective is to produce the

desired product.

 The basic objective of the process management process :to improve

the software process.

 By improvement, we mean that the capability of the process to

produce quality goods at low cost is improved. For this, the current
software process is studied, frequently by studying the projects that
have been done using the process. The whole process of
understanding the current process, analysing its
properties, determining how to improve, and then affecting the
improvement is dealt with by the process management process.

 The relationship between these major component processes is shown in

Figure 2.2. These component processes are distinct not only in the type
of activities performed in them, but typically also in the people who
perform the activities specified by the process. In a typical project,
development activities are performed by programmers, designers,
testers, etc.; the project management process activities are performed
by the project management; configuration control process activities are
performed by a group generally called the configuration controller; and
the process management process activities are performed by the
software engineering process group (SEPG).
 4

Figure 2.2:
Software
processes.

Explain Software Development life cycle

 A software life cycle model (also called process model) is a descriptive
and diagrammatic representation of the software life cycle.
 A life cycle model represents all the activities required to make a software
product.
 Software process models are adjusted to meet the need of software
engineers and managers for specific project.

 Communication: This activity involves

communication with customer to gather requirements and
other related activities.
 Planning: it required to define resources, timelines, describing
technical and management risks.
 Modeling / Designing: A model will be created to better
understand the requirements and design to achieve these
requirements.
 5
 Construction /Building: Here the code will be generated and tested.
 Deployment and testing: Here, a complete or partially complete
version of the software is represented to the customers to
evaluate and they give feedbacks based on the evaluation.

DIFFERENT PROCESS MODELS:

 Waterfall model (linear sequential model)

 Incremental process model
 Prototyping model
 The spiral model
 Rapid application development model (RAD model)

Define SDLC model. Provide a diagram representing

waterfall model. Also, explain various phases of
waterfall model.

Feasibility study

Requirement analysis
and specification

Design

Coding and unit

testing

Integration and
system testing

Maintenance

Design
 During the design phase the software architecture is derived from the SRS
document.
 6
 The customer requirements are broken down into logical modules for the
implementation.
 Hardware and software requirements for every module are identified.
 Also the inter relation between the various logical modules is established
at this stage.
 Algorithms and diagrams defining the objective of each logical model are
developed.

Coding and unit testing (Implementation)

 The purpose of the coding and unit testing phase of software
development is to translate the software design into source code.
 Each module of the design is implemented as a program module.
 The result of this phase is a set of program modules that have been
individually tested.

Integration and system testing

 Integration of different modules is done once they have been coded and
unit tested.
 During the integration and system testing phase, the modules are
integrated.
 All the modules have been successfully integrated and tested, system
testing is carried out.
 The goal of system testing is to ensure that the developed system
conforms to its requirements specifies in the SRS document.
 System testing usually consists of three different kinds of testing
activities.
 α – testing: It is the system testing performed by the development team.
 β – Testing: It is the system testing performed by a friendly set of
customers.
 Acceptance testing: It is the system testing performed by the
customer himself after the product delivery to determine whether to
accept or reject the delivered product.

Maintenance
 Maintenance involves following three kinds of activities:
 Correcting errors that were not discovered during the product
development phase. This is called corrective maintenance.
 Improving and enhancing the functionalities of the system according
to the customer’s requirements. This is called perfective
maintenance.
 Porting the software to work in a new environment. For example,
porting may be required to get the software to work on new
 7
operating system. This is called adaptive maintenance.

Advantages:

 Simple to implements and manage

Disadvantages:

 Unable to accommodate changes at later stages, that is required in most

of the cases.
 Working model not available during development. This can lead the
development with major mistakes.
 Not suitable for large projects.

Example of waterfall model:-

Previously waterfall model is used to make an application like CRM (Customer

Relationship Management), HRM (Human Resource Management), Supply Chain
Management System and Retail Chains, etc. Now a day’s waterfall models are
replaced by other models like Agile Methodology and iterative Model etc.

Factors in choosing a software process

. If you know your requirements well, it will be easier to select a model that best
matches your needs following factors in mind when selecting your software
process model:

Project requirements

Before you choose a model, take some time to go through the project requirements
and clarify them along side your organization’s or team’s expectations. Will the
user need to specify requirements in detail after each iterative session? Will the
requirements change during the development process?

Project size

Consider the size of the project you will be working on. Larger projects mean
bigger teams, so you’ll need more extensive and elaborate project management
plans.

Project complexity

Complex projects may not have clear requirements. The requirements may change
often, and the cost of delay is high. Ask yourself if the project requires constant
monitoring or feedback from the client.
 8
Cost of delay

Is the project highly time-bound with a huge cost of delay, or are the timelines
flexible?

Customer involvement

Do you need to consult the customers during the process? Does the user need to
participate in all phases?

Familiarity with technology

This involves the developers’ knowledge and experience with the project domain,
software tools, language, and methods needed for development.

Project resources

This involves the amount and availability of funds, staff, and other resources.
 9

Practical 2:
AIM : Collect the functional requirements for the project.
(Questionnaires/ stakeholders’ interview questions)

What are functional requirements?

 Functional requirements are product features that developers must

implement to enable the users to achieve their goals. They define the
basic system behaviour under specific conditions.
 Functional requirements in an SRS document (software requirements
specification) indicate what a software system must do and how it must
function; they are product features that focus on user needs.
 As an SRS document contains a detailed description of software
requirements and lays the ground work for technical teams, investors,
managers, and developer’s function requirements is a big part of writing
it.

Why functional requirements need to be documented

 The stakeholders have a single source of truth. Clearly documented

requirements keep all developers, designers, and QA testers on the
same page and working towards the same goal, avoiding
misunderstandings.
 Projects become more predictable.
 Detailed, high-quality requirements allow the team to estimate the
development time and cost more accurately and develop a product that
meets the expectations.

What is a Requirements Questionnaire?

A requirements questionnaire is a list of questions about the project

requirements.The questions are organized by feature (or business requirement
or project objective).
 1

How requirements questions

 How will you use this feature?

 How might we meet this business need?
 How might we think about this feature a bit differently?

Where Requirements questions

 Where does the process start?

 Where would the user access this feature?
 Where would the results be visible?

When requirements questions

 When will this feature be used?

 When will the feature fail?
 When will we be ready to start?

Who requirements questions

 Who will use this feature?

 Who will deliver the inputs for the feature?
 Who will receive the outputs of the feature?

What requirements questions

 What is the end result of doing this?

 What are the pieces of this feature?
 What needs to happen next?
 What must happen before?

Functional requirements examples

1. Functional requirements need to be clear, simple, and unambiguous.

2. Examples:
3. The system must send a confirmation email whenever an order is
placed.
4. The system must allow blog visitors to sign up for the newsletter by
leaving their email.
5. The system must allow users to verify their accounts using their phone
number.
 1

6. User story: As an existing user, I want to be able to log into my account.

 Functional requirements:
o The system must allow users to log into their account by
entering their email and password.
o The system must allow users to log in with their Google
accounts.
o The system must allow users to reset their password by clicking
on "I forgot my password" and receiving a link to their verified
email address.
7. User story 3: as an applicant, I must be able to view job opportunities
and explore them by using different filters.

 Functional requirements:
o Applicant’s dashboard page
o A page with a list of the posted jobs
o A feature to filter and organize the posted jobs based on skill,
date, and other descriptions
o A feature that enables applicants to explore different jobs and
organize them based on company, scale, pay rate, or other
descriptions

8. Website Building

Functional requirements for a website explain the features a website needs.

 how users can access webpages, what happens when users click on
certain parts of the webpage and how the website appears in a browser.
 The background colour for the main page is light yellow.
 Each product has an "add to cart" button that places that item in a
virtual shopping cart.
 The checkout securely processes credit cards from all major vendors.
 The software passes all security requirements.
 The website allows company administrators to access order data.
 Users can click the side navigation page to browse different website
sections.
 A web page contact form sends emails directly to the sales manager's
inbox.
 1

Stakeholders’ interview questions.

Interviewing stakeholders provides helpful information about their context,

allows us to identify business goals they are concerned with, and increases
their support.

What is Stakeholder:

A stakeholder is anyone who has interest in your project or with whom you
need to work with in some way to complete the project. Understanding your
stakeholders and their perspectives is key to your project’s success and is
commonly done through stakeholder interviews.

Definition: A stakeholder interview is a conversation with a person who has a

vested interested in a project with a goal of gathering insights to drive the
project’s success.

In a user interview, a researcher asks a user questions about a topic of interest

(e.g., use of a system, behaviours and habits) with the goal of learning about
that topic.

Similarly, in a stakeholder interview, the team member asks an stakeholders

questions meant to shape the design process, define success metrics, and
ultimately meet their expectations.

Examples:

1. What are the goals, values, and vision of your company?

2. What are your growth metrics for the next 1, 5, and 10 years?
3. Who are your users? What are you trying to help them achieve?
4. What are the deadlines for the project? What is the process of approval
for design and who will be approving them?
 1

PRACTICAL : 3
AIM : Analyse functional and non-functional requirement
and prepare SRS document for the project.

 Non functional requirements describe the general characteristics of a

system. They are also known as quality attributes.
 Functional requirements describe how a product must behave, what its
features and function

Benefits of defining the functional and non-functional requirements.

 It brings the team and the stakeholders on the

same page:

Once you have a well-defined and clear business requirement, you can explain
the same in-depth to the stakeholders and bring them on the same page as you
are.

 It gives you a more precise budget estimation:

A detailed understanding of the project requirements allows you to give a

precise estimation of the project.

 Develop a bug-free application:

It is often observed that any variation or change in functionality at later stages,

often leads to error in the system. On the other hand, if you identify and rectify
these errors at the inception phase, then you can develop a bug-free
application on time.

All in all,

 Defining functional requirements and non functional requirements helps

you know what the missing requirements are;
 It makes the entire project management task easy and accessible for the
entire team;
 1

 Describing the requirements, you make sure that you are meeting the
legal and compliance rules;
 It gives you a chance to bide by the security policy and deliver an
extravagant user experience.

How to define a functional requirement?

 Purpose: This section will include all the background, definitions, and
system overview;
 Describe the scope of product, the expectations, and the business
rules;
 Define the database requirements, system attributes, and functional
requirements;
 Include the use cases, which means describe how a user will interact
with the system.
 Define the role of every actor participating in the interaction; describe
in detail how a user will engage with the developed product step by
step.

How to define a non-functional requirement?

 Define the availability of the application, which means will it function 24

by 7.
 Determine the performance of the product solution for various
functionality. This means, in how much time the user should see the list,
how long the user will be connected with the app if there is no internet
connection, etc.
 Define the security requirements of the system.

How are the functional and non-functional requirements written and

represented?

 Both Requirement like brainstorming the idea of the product. You can
collect the requirements and prepare a document individually.
 You can prepare a system requirement specification (SRS), where both
the requirements are mentioned in a single document.
 This document is highly narrative and defines the purpose and objective
of the product clearly.
 The functional requirements of the solution can be broken down into the
Work Breakdown Structure (WBS) structure, where the entire process is
 1

divided into components. These components are so small that they can
not be divided further.

Example:

What are the functional and non functional

requirements of a library management system?

Functional Requirement
The Librarian does the following function(s):-
1. Add Article : New entries must be entered in database
2. Update Article : Any changes in articles should be updated in case of update
3. Delete Article : Wrong/Expiry/Un-usable entry must be removed from
system
4. Inquiry Members : Inquiry all current enrolled members to view their details
5. Inquiry Issuance : Inquiry of all database articles

Non-Functional Requirement
1.Safety Requirements : The database may get crashed at any retain time due to
virus or operating system failure. Therefore it is required to take the database
backup.

2. Security Requirements : develop a secured database for the university .

Depending upon the category of user the access rights are decided. It means if
the user is an administrator then he can be able to modify the data, delete,
append etc., all other users rights to retrieve the information about database.

3.Software Quality Attributes : The Quality of the database is maintained in

such a way so that it can be very user friendly to all the users of the database

4.Hardware Constraints
The system requires a database in order to store persistent data. The database
should have backup capabilities.

5. Software Constraints
The development of the system will be constrained by the availability of
required software such as database and development tools.
 1

Practical 4)
AIM: Prepare GANTT chart for selected system.
What is a gantt chart?: Definition & overview

A gantt chart is a horizontal bar chart used in project management to visually represent a
project plan over time. Gantt charts typically show you the timeline and status as well as
who’s responsible for each task in the project.

When should you use a gantt chart?

list. Here are a few sure signs you’re going to need a gantt chart to get the job done:

 Your project has a hard deadline.

 Multiple people or teams are involved in the project and need to be coordinated.
 A boss, client, or team member wants to see a visual timeline of the project from
beginning to end.
 Your project involves even just a little complexity, such as tasks that need to be done
in a specific order.
 Team members work on multiple projects at a time, and you need to manage their
workloads.
 You have a good idea of roughly how long each task should or can take.

Creating Your Own Gantt Chart

1. Understand the work breakdown structure.

A Gantt chart is a chart that displays a timeline for a project along with all the
different phases, tasks, and jobs that are part of the project. A separate bar is used
to illustrate when each phase, task, or job of a project starts and ends.
 1

2. Gather information about all tasks and processes within the project.
You will need to know each of the different phases (summary elements) of a project
and all the tasks (terminal elements) that need to be accomplished in each phase.

o Learn about terminal and summary elements. Terminal elements are smaller
tasks that make up a larger task. The larger task that the terminal elements
make up is called the summary element. For example, if you are filming a
movie, one of the summary elements may include each scene that needs to
be shot. The terminal elements may include planning, set design, filming,
editing, and animation for each scene.[1]
 1

3. Evaluate dependency and relationships between different phases and tasks.

Some tasks and/or phases of a project may be able to be accomplished
independently of other tasks and phrases. Others phases and tasks may depend on
other processes being completed first. For example, in movie production, casting
must be finished before filming can begin.
 1

4. Create a timeline on a graph.

Draw a horizontal timeline for the Gantt chart at the top of the graph. The timeline
represents the entire project with the start date on the left and end date on the
right. You will then need to break up the timeline into increments that represent
days or weeks of the timeline.
 2

5. List each task of the project on the left side of the graph.
Each task should have it's own line in the graph. To make the Gantt chart look more
organized, be sure to list each task in the order they need to be completed in. You
also need to know how long it will take for each task to be completed.
 2

6. Arrange bars for each phase and/or tasks within the timeline.
Use a highlighter or colored bars to highlight when each task starts and finishes
within the timeline. When you are finished, you should have a list of staggering bars
for each task below the timeline. Some bars may have overlapping dates, bars that
represent tasks that are dependant on other tasks will need to start after the
dependent task is completed.

o Try using different color bars for each summary task.

7. Implement the Gantt chart in software. After you have created a rough draft of your
Gantt chart, use software to print a clear and professional looking final copy.
Microsoft Project is software specifically made for project management that has the
ability to create and print Gantt charts. You can also create Gantt charts in Microsoft
Excel, PowerPoint, Word, Photoshop, or Adobe Illustrator and many other programs.
 2

Practical 5
AIM: Prepare PERT chart for selected system.
What is Project Evaluation Review Technique (PERT)?
 In project management, the Project Evaluation Review Technique, or PERT, is used to
identify the time it takes to finish a particular task or activity.
 It is a system that helps in the proper scheduling and coordination of all tasks throughout
a project.
 It also helps in keeping track of the progress, or lack thereof, of the overall project.
 PERT is a technique in project management that we apply to manage uncertain activities
of any project.
 On the other hand, a Critical Path method – CPM is a statistical technique where we have
a set of well-determined project activities

 Creating a PERT Chart

 A flowchart is used to depict the Project Evaluation Review Technique. Nodes represent
the events, indicating the start or end of activities or tasks. The directorial lines indicate
the tasks that need to be completed, and the arrows show the sequence of the activities.
 2

There are four definitions of time used to estimate project time requirements:
• Optimistic time – The least amount of time it can take to complete a task
• Pessimistic time – The maximum amount of time it should take to complete a task
• Most likely time – Assuming there are no problems, the best or most reasonable estimate
of how long it should take to complete a task.
• Expected time – Assuming there are problems, the best estimate of how much time will
be required to complete a task.

To implement a PERT chart:

• • Identify the different tasks needed to complete a project. Make sure to add these in the
right order and indicate the duration of each task.
• • Create a network diagram. Use arrows to represent the activities and use nodes as
milestones.
• • Determine the critical path and possible slack.

Advantages of PERT:
1. It helps maximize the use of resources.
2. It makes project planning more manageable.
3. It’s useful even if there is little or no previous schedule data.
4. It enables project managers to better estimate or determine a more definite completion date.

Disadvantages of PERT:
1. In complex projects, many find PERT hard to interpret, so they may also use a Gantt Chart,
another popular method for project management.
2. It can be tedious to update, modify, and maintain the PERT diagram.
 2

Practical 6:
Design DFD(context, level-1/2) for function oriented
design.

What is DFD?
A data-flow diagram (DFD) is a way of representing a flow of data of a process or a system
(usually an information system), for example:

 Where data comes from

 Where it goes
 How it gets stored

In other words, it shows how data is processed by a system in terms of inputs and outputs.
DFD is built using standardized symbols. There are several notations for displaying data-flow
diagrams.

The Elements of a DFD

DFD uses 4 basic symbols to represent the flow of the diagram. They are

1. Process
2. Data Store
3. External Entity
4. Data Flow (Arrow)
 2

How to Create a Data Flow Diagram?

To create a valid DFD, follow the 4 rules.

1. Every single process should have at least one input and one output.
2. Each data store should have at least one data flow in and data flow out.
3. Every system’s stored data has to go through a process.
4. Every process in a data flow diagram must link to another process or data store.

follow five steps:

1. Identify the major inputs and outputs in your system

This step gives a macro view of your system and clear the broadest tasks the system should
achieve. Again, the rest of the DFD is built on these elements.

2. Build a context diagram (Level 0 DFD)

You could achieve this by drawing a single process node and connecting it to related external
entities. The node represents the general process information undergoes in a system from
input to output.

3. Expand the context diagram into a level 1 DFD

Level 1 DFDs are more of a general overview, but they give more detail than a context
diagram. Break the single process lump into detailed processes. This brings out where the
information starts and what needs to happen to it.

4. Expand to level 2 DFD

This breaks the processes down into more detailed subprocesses. Ensure you add any
necessary data stores and flows at this point.

5. Ascertain the accuracy of your final DFD

Walk again through your diagram as you pay close attention to the flow of information. If it
makes sense and all necessary data stores are included, then thumbs up. Other parties should
find your diagram comprehensible.

DFD
Both Data Flow Diagrams (DFD) and Flowcharts are used to make it easier to understand the
way a process is taking place or data is being processed.

A Data Flow Diagram shows how data flows through a system which is processed as well.
The flow of the data from an external or internal source as well as where the data will end up
 2

is shown in a DFD. A DFD has no control flow, there are no decision rules and no loops.
Specific operations based on the data can be represented by a flowchart.

Top-Down Decomposition Technique in DFD

In DFD, the top-down decomposition, also called leveling, is a technique used to show more
detail in lower-level DFDs. Leveling is done by drawing a series of increasingly detailed
diagrams until the desired degree of detail is reached. As shown in the Figure, DFD Leveling
is first displaying the targeted system as a single process, and then showing more detail until
all processes are functional primitives.
 2

 DFDs that are at a higher level are less detailed

 High-level DFDs are to be decomposed into more detailed DFDs at lower levels
 The Context Diagram is the highest in the hierarchy (see DFD Creation Rules). The
so-called zero level is followed by DFD 0, starting with process numbering (e.g.,
process 1, process 2).
 In the next, the so-called first level – DFD 1 – the numbering continues. E.g. process
1 is divided into the first three levels of the DFD, which are numbered 1.1, 1.2 and
1.3.
 Similarly, processes in the second level (DFD 2) are numbered e.g. 1.1.1, 1.1.2, 1.1.3
and 1.1.4.
 The number of levels depends on the size of the model system. Each of the processes
in level 0 may not have the same number of decomposition levels.

DFD Examples – Customer Services System Example

The data flow diagram is a hierarchy of diagram consist of:

1. Context Diagram (conceptually level zero)

2. The Level-1 DFD
3. And possible Level-2 DFD and further levels of functional decomposition depending
on the complexity of your system

Context DFD

The figure below shows a context Data Flow Diagram that is drawn for a railway company’s
Customer Service System. It contains a process (shape) that represents the system to model,
in this case, the “CS System“. It also shows the participants who will interact with the system,
called the external entities. In this example, the CS Assistant and Passenger are the two
 2

entities that will interact with the system. In between the process and the external entities,
there is data flow (connectors) that indicate the existence of information exchange between
the entities and the system.

Context DFD is the entrance of a data flow model. It contains one and only one process and
does not show any data store.

Level 1 DFD

The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the
CS System process shown in the context DFD. Read through the diagram and then we will
introduce some of the key concepts based on this diagram.
 2

Practical 7
AIM: Design data dictionary of the selected
system.
What is a data dictionary?

 A data dictionary contain metadata i.e. data about the database.

 A data dictionary is a collection of descriptions of the data objects or
items are used in data model to which programmers and others can refer.
 It contain information such as
 What is in database
 Who is allowed to access it
 Where is the database physically stored etc,
 Its play important role in building a database.

How and Why data dictionary is used

 A data dictionary is a collection of descriptions of the data objects or

items are used in data model to which programmers and others can refer.
 The user of the database normally don’t interact with the data dictionary,
it is only handled by the database administrator.
 data dictionary is a centralized metadata repository.

 For example, a bank or group of banks could model the data objects
involved in consumer banking. They could then provide a data dictionary
for the bank's programmers. The data dictionary would describe each set
of data in its data model for consumer banking, such as "account holder"
and "available credit."
 3

The data dictionary is contain following information

 Name of all table in the database
 Name of each field in the table of the database
 Contains defined on the tables
 Physical information about tables such as storage
information/location

Types of data dictionaries

 There are two types of data dictionaries: active and passive.

1. Active data dictionaries are created within the databases they describe
and automatically reflect any updates or changes in their host databases.

o This avoids any inconsistency between the data dictionaries and

their database structures. also known as integrated data dictionary.

2. Passive data dictionaries are created separately from the databases.

When the DBMS maintains the data dictionary separately and to be updated manually
then the data dictionary is an passive one. Also called non-integrated data dictionary.

o In this case, there is a chance of mismatch with the database object and the
DD.

Advantage of data dictionary

 3

 It gives the well structured and clear information about the database.
 One can analyse the requirement and redundancy like duplication
columns, table etc.
 It is helpful for the administrator or any new DBA to understand the
database. Since it has all the information about the database, DBA can
easily able to track any data in the database.
 Since database is a very huge and will have lost of table, views,
constrains, index etc, it will be difficult for anyone to remember. Data
dictionary helps user by providing all the detail in it.
 3

Practical 8
AIM: Prepare Use-case diagrams of the selected
system for object-oriented design.
What is the use case Diagram?

 Use Case Diagram captures the system’s functionality and requirements

by using actors and use cases.
 Use Cases model include services, tasks, function that a system needs to
perform. Use cases represent high-level functionalities and how a user
will handle the system.

Use-case diagram notations

1) Actors

Actors are the entities that interact with a system.

Actors are used to represent the users of system, actors can actually be
anything that needs to exchange information with the system.

A use case diagram shows the interaction between the system and external
entities or user.

2) Use Cases
 3

It used to describe the interaction between user and system within a use case
by creating a sub-sequence diagram under a use case.

A use case represents a user goal that can be achieved by accessing the system
or software application

The notation for a use case is an ellipse.

3) Relationships

With the simple line we can represent relationships between an actor and use
cases.

Above all notation are use in a use case. Both are connect using connecting line
with an optional arrowhead showing the direction of control.

The following diagram indicates that the actor "Customer" uses the
"Withdraw" use case.

Different relationship in use case diagram are defined using include and
exclude relationship.

4) <<Including>> Relationship
 3

Use cases may contain the functionality of another use case as part of their
normal processing. It is assumed that any included use case will be called every
time at that time the basic path will run.

An example of this is to have the execution of the use case <Card

Identification> to be run as part of a use case <Withdraw>.

5) <<Extend>> Relationship

One use case may be used to extend the behaviour of another, this is typically
used in exceptional circumstances.

For example, if before modifying a particular type of customer order, a user

must get approval from some higher authority, then the <Get Approval> use
case may optionally extend the regular <Modify Order> use case.

6) Generalization
 3

A generalization relationship is used to represent inheritance relationship

between model elements of same type.

The more specific model element share the same specification with. the more
general the model element but carries more details in extra

7) System

The scope of a system can be represented by a system (shape), or sometimes

known as a system boundary.

The use cases of the system are placed inside the system shape, while
the actor who interact with the system are put outside the system. The use
cases in the system make up the total requirements of the system.

Rules must be followed while drawing use-case for any system:

1. The name of an actor or a use case must be meaningful and relevant to

the system.
2. Interaction of an actor with the use case must be defined clearly and in
an understandable way.
3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.
 3

Advantages of Use Case Testing

 It helps to understand the requirements of the system.

 It is a sequence of steps that describes the interaction between user and
system.
 It helps to manage the complexity in the transaction, as it focuses on
one task at a time.
 3

Practical 9
AIM: Prepare Activity diagrams of the selected system for
object oriented design.
What is an Activity diagram?

It helps to visualize a certain use case at a more detailed level. It is a

behavioural diagram that illustrates the flow of activities through a system.

It used to depict a flow of events in a software process. They can be used to

examine processes in order to identify their flow and requirements.

Activity diagram in the software design models is used to represent the flow of
control among the different activities of the software.

In the activity diagram, we represent different actions through activities.

These activities take some input from some other activity of the system or
through the input and output units and produce some signal outputs that
control the workflow of the other activities

Activity Diagram Symbols

Symbol Name Use

Start/ Initial Used to represent the starting point

Node or the initial state of an activity

Activity / Used to represent the activities of the

Action State process

Control Used to represent the flow of control

Flow / Edge from one action to the other

Activity Final Used to mark the end of all control

Node flows within the activity
 3

Used to represent a conditional

Decision
branch point with one input and
Node
multiple outputs

Used to represent the merging of

Merge Node flows. It has several inputs, but one
output.

Used to represent a flow that may

Fork branch into two or more parallel
flows

Used to represent two inputs that

Merge
merge into one output

[] Guards useful when defining specific answer

Activity Diagrams with Swimlanes

In activity diagrams, swimlanes – also known as partitions – are used to

represent or group actions carried out by different actors in a single thread.
 3

 Add swimlanes to linear processes. It makes it easy to read.

 Don’t add more than 5 swimlanes.
 Arrange swimlanes in a logical manner.

How to Draw an Activity Diagram

Activity diagrams can be used to model requirements, create a high-level view

of a system’s functionalities, analyse use cases, and for various other purposes.
In each of these cases, here’s how to draw an activity diagram from the
beginning.

Step 1: Figure out the action steps from the use case

Here you need to identify the various activities and actions for your software
process or system is made up of.

Step 2: Identify the actors who are involved

If you already have figured out who the actors are, then it’s easier to discern
each action they are responsible for.

Step 3: Find a flow among the activities

Figure out in which order the actions are processed. Mark down the conditions
that have to be met in order to carry out certain processes, which actions
occur at the same time and whether you need to add any branches in the
diagram. And do you have to complete some actions before you can proceed
to others?

Step 4: Add swimlanes

You have already figured out who is responsible for each action. Now it’s time
to assign them a swimlane and group each action they are responsible for
under them.
 4

Practical 10)
AIM : Design appropriate User Interface based on the
type of project.
❖ What is User Interface (UI) Design?
User Interface (UI) defines the way humans interact with the information
systems.
User Interface (UI) is a series of pages, screens, buttons, forms and other visual
elements that are used to interact with the device. Every app and every
website has a user interface.

❖ Types of User Interface

• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)

❖ Significance of User Interface (UI):

• A good User Interface (UI) focuses on making user’s interactions simple and
efficient.
• User would appreciate a website with intuitive user interface that leads them
towards their task in most engaging way.
• User Interface (UI) design focuses on thinking of a user, what they might
need to do when they visit website and ensure that the interface has elements
that are easy to access and understand.

❖ Advantages of User Interface (UI):

• No need to learn complex commands/languages for working with UI.
• Easiness for non-technical people. A beginner can navigate through a site
with ease if its simple and well informative.
• Usage of blocks and typography makes user experience better.
• Easy setup and ready to start working are awesome. Hiding the complexity of
actions from the user and display only the required information is key to good
interface.

❖ Disadvantages of UI :
• When not properly built, it can be very difficult to work with.
• Takes time to built a Perfect UI.

❖ Example:
 4

As the User Interface can make or break the incoming users, it’s important to
take care of below points when designing a UI:
• Keep the interface simple: Clear and simple interface are best. Avoid
unnecessary elements. Best interfaces are invisible to user.
• Be consistent and use common UI elements: Using common elements, users
feel more comfortable and are able to get things done more quickly.
• Placement of items: To draw attention to most important pieces of
information careful placement of items is necessary. This can improve users
readability and engage them.
• Use of right colour: To direct attention towards something take advantage of
colour, light, shade, contrast and texture. It’s important top make use of good
colour combination as a bad colour combination can easily distract or irritate a
user.

❖ What is Graphical User Interface (GUI) Design?

GUI relies much more heavily on the mouse. A typical example of this type of
interface is any versions of the Windows operating systems.
Advantages:
• Less expert knowledge is required to use it.
• Easier to Navigate and can look through folders quickly in a guess and check
manner.
• The user may switch quickly from one task to another and can interact with
several different applications.
Disadvantages
• Typically decreased options.
• Usually less customizable. Not easy to use one button for tons of different
variations.

Practical 11)
 4

Prepare the test cases to test the functionalities of the

modules.
❖ What is functional testing?
It is a black box type of software testing and QA process that helps to validate
systems and components against functional requirements.
This testing process aims to test the functionality of the application by
providing certain inputs and validating the outputs against functional
requirements.

❖ Why is functional testing required?

1. Functional testing is required to validate the functionalities of the software
2. This test helps to validate that all the requirements that have been
mentioned in the SRS documents have been fulfilled or not
3. This type of testing is more focused on customer requirements whereas
non-functional tests are more focused on customer expectations.
4. This test helps to ensure that the product performs well as it claims

❖ What are the different types of functional tests?

1. Unit test — It is the first phase of the software testing process. The main aim
of this test is to validate whether the small units of the components are
working as expected or not
2. Component test — It is similar to the unit testing method but the only
difference is that it is performed by testers and it tests each object of the
application separately with or without isolation of other software objects
3. Integration test- In this test individual module of the application are
combined and tested as a group to identify the functionality after combining
different modules
4. System test — This test helps to ensure that all the fully integrated software
is working well or not
5. User acceptance test — In this test method, the end users/client test the
product to ensure that it is meeting all requirements and working as expected.
This test helps to gain approval for the release of the product
What are the functional testing test cases and examples?
Situation –
Suppose there is an e-commerce app on which the user logs in with their user
account and password.
The login page has two text fields, one for username and the other for
password. It also has two buttons, i.e.; Login and Cancel.
 4

When action is successful, the login page directs the user to the eCommerce
app home page. The cancel button cancels the login.
Specifications –

1. The user id field requires a minimum of 6 characters, maximum of 10

characters, numbers(0–9), letters(a-z, A-z), special characters (only underscore,
period, hyphen allowed). It cannot be left blank. User id must begin with a
number/character. It cannot include special characters.
2. The password field requires a minimum of 6 characters, a maximum of 8
characters, numbers (0–9), letters (a-z, A-Z), all special characters. It cannot be
blank.

The use-case scenario above can be tested through a variety of functional tests
such as:
1. System tests: This test is performed to ensure that all the components of the
software are working as expected or not in perfect combination.
Example — This test would check the customer journey i.e. Ecommerce
application loading, entering accurate credentials, directing to the home page,
performing tasks, logging out of the system. This test ensures that the
workflow proceeds and completes without any errors.
1. Boundary value tests: This test is performed to check how the system
behaves when data limits are implemented.
Example — The user-id requires a minimum of 6 characters, this test will check
how the system responds when less than 6 characters are entered.
1. Decision-based tests: This tests checks for possible system outcomes when a
particular condition is met.
Example -
• If incorrect credentials are entered, the system should alert the user and
reload the login page.
• If correct credentials are entered, the system should take the user to the
home page.
• If correct credentials are entered but the user wants to cancel login, the
system should not direct the user to the home page UI. Instead, it should
reload the login page