Name: Ankur Pathak

Email: ankurpathak.ap@gmail.com
Mobile: 7385500660
Application ID: 113114
Seat Number: 00162
Subject: Software Engineering
1. Explain the good criteria of a good Software Requirement Specification
(SRS)
Characteristics of an SRS Software requirements specification should be unambiguous,
accurate, complete, efficient, and of high quality, so that it does not affect the entire
project plan. An SRS is said to be of high quality when the developer and user easily
understand the prepared document. Other characteristics of SRS are explained below.
Unambiguous
SRS is unambiguous when every stated requirement has only one interpretation
This implies that each requirement is uniquely interpreted
In case there is a term used with multiple meanings, the requirements
document should specify the meanings in the SRS so that it is clear and easy to
understand Complete
SRS is complete when the requirements clearly define what the software is required to
do
This includes all the requirements related to performance, design and
functionality Correct
SRS is correct when all user requirements are stated in the requirements document
The stated requirements should be according to the desired system
This implies that each requirement is examined to ensure that it (SRS) represents user
requirements
Note that there is no specified tool or procedure to assure the correctness of SRS.
Correctness ensures that all specified requirements are performed correctly.
Ranked for importance/stability
All requirements are not equally important, hence each requirement is identified to
make differences among other requirements
For this, it is essential to clearly identify each requirement. Stability implies the
probability of changes in the requirement in future.
Modifiable
The requirements of the user can change, hence requirements document should be
created in such a manner that those changes can be modified easily, consistently
maintaining the structure and style of the SRS
Traceable
SRS is traceable when the source of each requirement is clear and facilitates the
reference of each requirement in future
For this, forward tracing and backward tracing are used
Forward tracing implies that each requirement should be traceable to design and code
elements
Backward tracing implies defining each requirement explicitly referencing
its source Consistent
SRS is consistent when the subsets of individual requirements defined do not conflict
with each other. For example, there can be a case when different requirements can
use different terms to refer to the same object
There can be logical or temporal conflicts between the specified requirements and
some requirements whose logical or temporal characteristics are not satisfied
Verifiable
SRS is verifiable when the specified requirements can be verified with a cost-effective
process to check whether the final software meets those requirements
The requirements are verified with the help of reviews. Note that unambiguity is
essential for verifiability.
2. Explain all phases of Waterfall Model.
Software development is a process that involves the creation and maintenance
of frameworks, applications and other software elements. This process
comprises of activities such as: requirements analysis, defining specifications,
designing, constructing, and testing maintenance of the software product.
There is a wide range of software designing models available to hand -pick in
accordance with the objectives, needs and constraints of the project. In this
article, we will be discussing the Waterfall Model, with in-depth focus on logical
progression of this development life cycle.

The Waterfall Model, also known as the Linear-Sequential Life-cycle Model, is

one of the first process models introduced for software development. As the
name implies, this model's process of downward mechanism is similar to that of
a waterfall. The whole process is divided into sequential stages, and it is
imperative to complete each phase successfully in order to move onto the next
one. According to the International Software Testing Qualifications Board, the
Waterfall Model consists of 6 phases:
1. Requirements Analysis
In this phase, all requirements of the project are analysed and
documented in a specification document and a feasibility analysis is done
to check if these requirements are valid. It is essential to consider any
limitations and constraints (e.g. time, budget constraints) which can
affect the development process. After thorough analysis, a Requirements
Understanding Documents (RUD) is created.
2. System Design
In this phase, the system design is prepared which specifies hardware and
system requirements, such as data layers, programming languages,
network infrastructure, user interface etc. It helps define the overall
system architecture, which is further divided into:
a) High-level design phase
This is the first stage of system design and architecture. It includes a list
and functionality of modules, correlation between these modules,
architecture diagrams, and database tables. This phase ends with the
creation of a High-level Design document.
b) Low-level design phase
This involves designing actual software components. The High-level
Design created in the previous phase is disintegrated into separate
modules. The Low-level Design document describes each module (pseudo-
code), which enables the programmer to code directly from the document.
It also contains interface details, error-message listings, dependency
issues, inputs and outputs for each module. 3. Implementation
As the name implies, in this phase the source code is written as per
requirements. The physical design specifications are turned into a working
code. The system is developed in small programs called units, after which
these units are integrated. Sometimes, functionality of each unit is tested
before integration, which is called Unit Testing.
4. Testing
The code is then handed over to the testing team. Testers check the
program for all possible defects, by running test cases either manually or
by automation. The client is involved in the testing phase as well, in order
to ensure all requirements are met. All Flaws and bugs detected during
this phase are fixed to ensure Quality Assurance.
5. Deployment
In this phase, the software is deployed into a live environment (client's
server) in order to test its performance. Once the software is deployed, it
becomes available to end-users. Sometimes, this phase also includes
training of real-time users to communicate benefits of the system.
6. Maintenance
After the deployment phase, the next step is to provide support and maintenance for
the software, making sure it runs smoothly. If the client and users come across
errors/defects/bugs during use, fixing them is the main purpose of this stage.
When to use the Waterfall Model?
This model is appropriate for projects with defined goals and requirements.
Projects that demand frequent modifications should not be carried out following
this approach, as this model lacks flexibility. However, if the project has strict
deadlines, the Waterfall Model enables completion of the project, adhering to
time constraints, provided that enough resources are available.
Advantages
The requirements, phases and activities are well-defined. Therefore, it is easy for
the project managers to plan, schedule, make use of resources and define goals.
Each phase has a deliverable, thus making the whole process simple and easy to
understand.
It is the go-to approach for small projects.
The whole process is well-documented and well-scripted.
Each phase is separate and completed within a given time-frame; there is less
need for reworking. Disadvantages
This model is rigid; it is not possible to make modifications in the
requirements once the process begins. Hence, there is no room for
reflection and revision.
This model is not favourable for big projects which involve frequent
requirement changes. After developers and clients agree on the
requirements early in the cycle, and there is no room for feedback during
the development process.
It involves a high amount of risk and uncertainty.
Testing starts after completion of the development phase; this may lead
to late detection of bugs and design issues in the development life-cycle.
Conclusion
The Waterfall Model is one of the first models introduced in software devel
opment, and it has gained popularity because it clearly defines each step,
with logical flow of information. It enables developers to know about the
requirements in early stages, which guide them throughout the
development process. But it is not without constraints; there is no room
for frequent changes which increases inflexibility of the model. These
shortcomings have given room to alternative approaches and models,
such as the Agile Development Model.
Selection of the right model is mainly dependent on variables like
availability of resources and specifications of the project. The Waterfall
Model remains one of the most popular software development models to-
date, mostly for small-scale projects, regardless of its shortcomings.