OBJECTIVE 1

IDENTIFY THE REQUREMENT FROM PROBLEM

STATEMENT
1.1 PROBLEM STATEMENT
The stock maintenance system must take care of sales information of the company and must
analyze the potential of the trade. It maintains the number of items that are added or removed.
The sales person initiates this Use case. The sales person is allowed to update information
and view the database.

1.2 INTRODUCTION:
Stock maintenance is an interface between the customer and the salesperson. It aims at
improving the efficiency in maintaining the stocks.

1.3 PURPOSE
The entire process of Stock maintenance is done in a manual manner considering the fact that
the number of customers for purchase is increasing every year, a maintenance system is
essential to meet the demand. So this system uses several programming and database
techniques to elucidate the work involved in this process.

1.4 SCOPE
The System provides an interface to the customer where they can fill in orders for the item
needed.

The sales person is concerned with the issue of items and can use this system.

Provide a communication platform between the customer and the sales person

1.5 DEFINITIONS,ACRONYMS AND THE ABBREVIATIONS

Market Data provider: One who analyze the product and distribute the news.
Customer: One who takes order of product
Salesperson: One who maintains the stock details.

1.6 OVERVIEW
SRS includes two sections overall description and specific requirements Overall Description
will describe major role of the system components and inter-Connections Specific
Requirements will describe roles &functions of the actors.
1.7 References
Standard book of Rajib Mall

Software Engg. Subject teacher- Mrs. Deepti Pandey

Our technical adviser- Mr. Krishana Kumar Yadav

 OBJECTIVE 2

To the object of SDLC document requirements.

2.1 Software Development Life Cycle (SDLC)

Software development life cycle (SDLC) is a structured process that is used to design,
develop, and test good-quality software. SDLC, or software development life cycle, is a
methodology that defines the entire procedure of software development step-by-step.

Fig.2.1 Software Development Life Cycle (SDLC)

The goal of the SDLC life cycle model is to deliver high-quality, maintainable software that
meets the user’s requirements. SDLC in software engineering models outlines the plan for
each stage so that each stage of the software development model can perform its task
efficiently to deliver the software at a low cost within a given time frame that meets users’
requirements.

2.2 Software Development Models – SDLC Models

SDLC Models or Software Development Life Cycle (SDLC) models are frameworks that
guide the development process of software applications from initiation to deployment.
Various SDLC models in software engineering exist, each with its approach to the phases of
development. During the software development phase, various software development life
cycle models are specified and designed. To guarantee success at each stage of the software
development process, each process model adheres to a set of phases specific to its kind.

Fig.2.2: SDLC Models – Software Development Models

2.3 Waterfall SDLC Models:

The Waterfall model follows a linear and sequential approach to software development. Each
phase in the development process must be completed before moving on to the next one,
resembling the downward flow of a waterfall. The model is highly structured, making it easy
to understand and use.

Fig2.3 Waterfall SDLC Models

Phases of Waterfall SDLC Models:
Requirements: The first phase involves gathering requirements from stakeholders and
analyzing them to understand the scope and objectives of the project.
Design: Once the requirements are understood, the design phase begins. This involves
creating a detailed design document that outlines the software architecture, user interface, and
system components.
Development: The Development phase includes implementation involves coding the
software based on the design specifications. This phase also includes unit testing to ensure
that each component of the software is working as expected.
Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.
Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing
any issues that arise after the software has been deployed and ensuring that it continues to
meet the requirements over time
Advantages of the Waterfall SDLC Models:
Simplicity: The linear and sequential nature of the Waterfall models makes it easy to
understand and implement.
Clear Documentation: Each phase has its own set of documentation, making it easier to
track progress and manage the project.
Stable Requirements: Well-suited for projects with stable and well-defined requirements at
the beginning.
Predictability: Due to its structured nature, the Waterfall model allows for better
predictability in terms of timelines and deliverables.
Disadvantages of the Waterfall SDLC Models:
Rigidity: The model is highly inflexible once a phase is completed, making it challenging to
accommodate changes.
Late Testing: Testing is performed after the implementation phase, so defects might not be
discovered until late in the process.
Limited Client Involvement: Clients are involved mainly in the initial phase, and significant
changes cannot be easily accommodated later in the development process.
No Prototyping: The models lack the provision for creating prototypes, which could be a
disadvantage in projects where user feedback is crucial.
 OBJECTIVE 3
Estimation of Project Metrics
Project Duration: Estimate the total time required for development, testing, and deployment
of the stock management system. Break it down into phases such as planning, design,
development, testing, and deployment.
Resource Allocation: Determine the number of developers, testers, designers, and other team
members required for the project based on its scope and complexity.
Budget: Estimate the total cost of the project, including salaries, infrastructure costs,
software licenses, and any other expenses.
Scope: Clearly define the features and functionalities of the stock management system to
ensure that the project stays on track and within budget.
Risk Assessment: Identify potential risks that could impact the project timeline, budget, or
quality, and develop mitigation strategies to address them.
Quality Assurance Metrics: Define metrics for measuring the quality of the stock
management system, such as code coverage, defect density, and customer satisfaction.
Performance Metrics: Determine performance benchmarks for the system, such as response
time, throughput, and scalability.
User Adoption: Estimate the expected adoption rate of the stock management system among
users, and plan for user training and support accordingly.
Maintenance: Estimate the ongoing maintenance effort required to support and update the
stock management system after deployment.
Success Criteria: Define criteria for measuring the success of the project, such as meeting
project deadlines, staying within budget, and achieving the desired level of functionality and
performance.
 OBJECTIVE 4
Modeling UML Use Case Diagrams and Capturing Use Case Scenarios

4.1 Use Case Diagram

Its purpose is to present a graphical overview of the functionality provided by a
system in terms of actors and their goals.
The main purpose of a use case diagram is to show what system functions are
performed for which actors.

4.2 Diagram Building Block

Use cases
A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.

Use case
Actor
An actor is a person, organization or external system that plays a role in one or more
interactions with the system.

Actor

System boundary boxes (optional)

A rectangle is drawn around the use case called the system boundary box to indicate
scope of the system.
Fig.4.1 SMS Use Diagram
 Objective 5

E-R modeling from the project Statement.

5.1 Introduction of ER Model

The Entity Relational Model is a model for identifying entities to be represented in the
database and representation of how those entities are related. The ER data model specifies
enterprise schema that represents the overall logical structure of a database graphically.

5.2 Why Use ER Diagrams In DBMS?

ER diagrams are used to represent the E-R model in a database, which makes them easy to
convert into relations (tables).

ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.

ER diagrams require no technical knowledge and no hardware support.

These diagrams are very easy to understand and easy to create even for a naive user.

It gives a standard solution for visualizing the data logically.

5.3 Symbols Used in ER Model

Entity Symbol Name Description

Strong entity These shapes are independent

from other entities, and are
often called parent entities,
since they will often have
weak entities that depend on
them. They will also have a
primary key, distinguishing
 each occurrence of the entity.

Weak entity Weak entities depend on

some other entity type. They
don't have primary keys, and
have no meaning in the
diagram without their parent
entity.

Associative entity Associative entities relate the

instances of several entity
types. They also contain
attributes specific to the
relationship between those
entity instances.

Attribute Symbol Name Description

Attribute Attributes are characteristics

of an entity, a many-to-many
relationship, or a one-to-one
relationship.

Multivalued attribute Multivalued attributes are

those that are can take on
more than one value.

Derived attribute Derived attributes are

attributes whose value can be
calculated from related
attribute values.
Relationship Relationships are
associations between or
among entities.
 OBJECTIVE 6
Identifying Domain Classes from the Problem Statements