RNS FIRST GRADE COLLEGE

(Affiliated to Bangalore University NAAC Accredited with ‘A’ Grade)

Dr. Vishnuvardhan Road, Channasandra, R R Nagar Post, Bengaluru-98.

Software Evolution is a term which refers to the process of developing software initially, then timely
updating it for various reasons, i.e., to add new features or to remove obsolete functionalities etc. The
evolution process includes fundamental activities of change analysis, release planning, system
implementation and releasing a system to customers. 
The cost and impact of these changes are accessed to see how much system is affected by the change
and how much it might cost to implement the change. If the proposed changes are accepted, a new
release of the software system is planned. During release planning, all the proposed changes (fault
repair, adaptation, and new functionality) are considered. 
A design is then made on which changes to implement in the next version of the system. The process of
change implementation is an iteration of the development process where the revisions to the system are
designed, implemented and tested. 
The necessity of Software evolution : Software evaluation is necessary just because of the following
reasons:
a) Change in requirement with time : With the passes of time, the organization’s needs change in its
operational working this can be achieved by frequently changing the tools(software) that they are
using need to change for maximizing the performance.
b) Environment change: As the working environment changes the things(tools) that enable us to work
in that environment also changes proportionally same happens in the software world as the working
environment changes then, the organizations need reintroduction of old software with updated features
and functionality to adapt the new environment.
c) Errors and bugs: As the age of the deployed software within an organization increases their
preciseness decrease and the efficiency to bear the increasing complexity workload also continually
degrades. So, in that case, it becomes necessary to avoid use of obsolete and aged software. All such
obsolete Softwares need to undergo the evolution process in order to become robust as per the
workload complexity of the current environment.  
d) Security risks: Using outdated software within an organization may lead you to at the verge of
various software-based cyberattacks and could expose your confidential data illegally associated with
the software that is in use. So, it becomes necessary to avoid such security breaches through regular
assessment of the security modules are used within the software
e) For having new functionality and features : In order to increase the performance and fast data
processing and other functionalities, an organization need to continuously evaluate the software
throughout its life cycle so that stakeholders & clients of the product could work efficiently.
 
Laws used for Software Evolution: 
 
1. Law of continuing change: 
This law states that any software system that represents some real-world undergoes continuous
change or become progressively less useful in that environment.
2. Law of increasing complexity: 
As an evolving program changes, its structure becomes more complex unless effective efforts are
made to avoid this phenomenon.
3. Law of conservation of organization stability: 
Over the lifetime of a program, the rate of development of that program is approximately constant
and independent of the resource devoted to system development.
4. Law of conservation of familiarity: 
This law states that during the active lifetime of the program, changes made in the successive
release are almost constant.
 

Introduction to Software Engineering

Software is a program or set of programs containing instructions that provide desired functionality.
And Engineering is the process of designing and building something that serves a particular purpose
and finds a cost-effective solution to problems. 
Software engineering is the process of designing, developing, testing, and maintaining software. It is a
systematic and disciplined approach to software development that aims to create high-quality, reliable,
and maintainable software. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and maintenance.
Some key principles of software engineering include:

1. Modularity: Breaking the software into smaller, reusable components that can be developed and
tested independently.
2. Abstraction: Hiding the implementation details of a component and exposing only the necessary
functionality to other parts of the software.
3. Encapsulation: Wrapping up the data and functions of an object into a single unit, and protecting
the internal state of an object from external modifications.
4. Reusability: Creating components that can be used in multiple projects, which can save time and
resources.
5. Maintenance: Regularly updating and improving the software to fix bugs, add new features, and
address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is free of bugs.
7. Design Patterns: Solving recurring problems in software design by providing templates for solving
them.
8. Agile methodologies: Using iterative and incremental development processes that focus on
customer satisfaction, rapid delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating the code changes and deploying
them into the production environment.

The characteristics of software include:

1. It is intangible, meaning it cannot be seen or touched.
2. It is non-perishable, meaning it does not degrade over time.
3. It is easy to replicate, meaning it can be copied and distributed easily.
4. It can be complex, meaning it can have many interrelated parts and features.
5. It can be difficult to understand and modify, especially for large and complex systems.
6. It can be affected by changing requirements, meaning it may need to be updated or modified as the
needs of users change.
7. It can be affected by bugs and other issues, meaning it may need to be tested and debugged to
ensure it works as intended.

Attributes of Software Engineering:-

 Functionality
 Efficiency
 Reliability
 Robustness
 Maintainability 
 Functionality: 
It refers to the degree of performance of the software against its intended purpose. Functionality
refers to the set of features and capabilities that a software program or system provides to its users.
Examples of functionality in software include:
1. Data storage and retrieval
2. Data processing and manipulation
3. User interface and navigation
4. Communication and networking
5. Security and access control
6. Reporting and visualization
7. Automation and scripting
The more functionality a software has, the more powerful and versatile it is, but also the more complex
it can be. It is important to balance the need for functionality with the need for ease of use,
maintainability, and scalability.
Required functions are: 
 

 Reliability: 

Reliability is a characteristic of software that refers to its ability to perform its intended functions
correctly and consistently over time. Reliability is an important aspect of software quality, as it helps
ensure that the software will work correctly and not fail unexpectedly.
Examples of factors that can affect the reliability of software include:
1. Bugs and errors in the code
2. Lack of testing and validation
3. Poorly designed algorithms and data structures
4. Inadequate error handling and recovery
5. Incompatibilities with other software or hardware
To improve the reliability of software, various techniques and methodologies can be used, such
as testing and validation, formal verification, and fault tolerance.
A software is considered reliable when the probability of it failing is low and it is able to recover
from the failure quickly
Required functions are: 
 
 Efficiency: 
Efficiency is a characteristic of software that refers to its ability to use resources such as memory,
processing power, and network bandwidth in an optimal way. High efficiency means that a
software program can perform its intended functions quickly and with minimal use of resources,
while low efficiency means that a software program may be slow or consume excessive
resources.
Examples of factors that can affect the efficiency of software include:
1. Poorly designed algorithms and data structures
2. Inefficient use of memory and processing power
3. High network latency or bandwidth usage
4. Unnecessary processing or computation
5. Unoptimized code
To improve the efficiency of software, various techniques and methodologies can be used, such
as performance analysis, optimization, and profiling.
Efficiency is important in software systems that are resource-constrained, high-performance, and
real-time systems. It is also important in systems that need to handle a large number of users or
transactions simultaneously.
Required functions are: 
 

 
 Usability: 
It refers to the extent to which the software can be used with ease. The amount of effort or
time required to learn how to use the software. 
Required functions are: 
 

 
 Maintainability: 
It refers to the ease with which the modifications can be made in a software system to extend
its functionality, improve its performance, or correct errors. 
Required functions are: 
 
 
 Portability: 
A set of attributes that bears on the ability of software to be transferred from one environment
to another, without or minimum changes. 
Required functions are: 
 

Characteristics of software engineering

 Software is developed or engineered; it is not manufactured in the classical sense:

 Although some similarities exist between software development and hardware
manufacturing, few activities are fundamentally different.
 In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems than software.
 The software doesn’t “wear out.”:
 Hardware components suffer from the growing effects of many other
environmental factors. The hardware begins to wear out.
 Software is not susceptible to the environmental maladies that cause hardware to
wear out.
 When a hardware component wears out, it is replaced by a spare part.
 There are no software spare parts.
 Every software failure indicates an error in design or in the process through which
design was translated into machine-executable code. Therefore, the software
maintenance tasks that accommodate requests for change involve considerably
more complexity than hardware maintenance. software doesn’t wear out. But it
does deteriorate.
 The software continues to be custom-built:
 A software part should be planned and carried out with the goal that it tends to be
reused in various projects.
 In the hardware world, component reuse is a natural part of the engineering
process.
LIFE CYCLE MODEL

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 transit through its life cycle phases.In other words, a life cycle model
maps the different activities performed on a software product from its inception to retirement.
Different life cycle models may map the basic development activities to phases in different
ways. Thus, no matter which life cycle model is followed, the basic activities are included in all
life cycle models though the activities may be carried out in different orders in different life
cycle models. During any life cycle phase, more than one activity may also be carried out.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software product is being
developed by a team there must be a clear understanding among team members about when and
what to do. Otherwise it would lead to chaos and project failure. This problem can be illustrated
by using an example. Suppose a software development problem is divided into several parts and
the parts are assigned to the team members. From then on, suppose the team members are
allowed the freedom to develop the parts assigned to them in whatever way they like. It is
possible that one member might start writing the code for his part, another might decide to
prepare the test documents first, and some other engineer might begin with the design phase of
the parts assigned to him. This would be one of the perfect recipes for project failure. A software
life cycle model defines entry and exit criteria for every phase. A phase can start only if its
phase-entry criteria have been satisfied. So without software life cycle model the entry and exit
criteria for a phase cannot be recognized. Without software life cycle models it becomes difficult
for software project managers to monitor the progress of the project.

Different Life cycle models.

1. Classical Waterfall
2. Prototype
3. Evolutionary
4. Spiral Model

1. Classical Waterfall Model

The classical waterfall model is the basic software development life cycle model. It is very simple but
idealistic. Earlier this model was very popular but nowadays it is not used. But it is very important
because all the other software development life cycle models are based on the classical waterfall model. 
The classical waterfall model divides the life cycle into a set of phases. This model considers that one
phase can be started after the completion of the previous phase. That is the output of one phase will be the
input to the next phase. Thus the development process can be considered as a sequential flow in the
waterfall. Here the phases do not overlap with each other. The different sequential phases of the classical
waterfall model are shown in the below figure: 
 

Let us now learn about each of these phases in brief detail: 

 
1. Feasibility Study: The main goal of this phase is to determine whether it would be financially and
technically feasible to develop the software. 
The feasibility study involves understanding the problem and then determining the various possible
strategies to solve the problem. These different identified solutions are analyzed based on their
benefits and drawbacks, The best solution is chosen and all the other phases are carried out as per this
solution strategy. 
 
2. Requirements analysis and specification: The aim of the requirement analysis and specification
phase is to understand the exact requirements of the customer and document them properly. This
phase consists of two different activities. 
 Requirement gathering and analysis: Firstly all the requirements regarding the software are
gathered from the customer and then the gathered requirements are analyzed. The goal of the
analysis part is to remove incompleteness (an incomplete requirement is one in which some parts
of the actual requirements have been omitted) and inconsistencies (an inconsistent requirement is
one in which some part of the requirement contradicts some other part).
 Requirement specification: These analyzed requirements are documented in a software
requirement specification (SRS) document. SRS document serves as a contract between the
development team and customers. Any future dispute between the customers and the developers
can be settled by examining the SRS document.
3. Design: The goal of this phase is to convert the requirements acquired in the SRS into a format that
can be coded in a programming language. It includes high-level and detailed design as well as the
overall software architecture. A Software Design Document is used to document all of this effort
(SDD)
 
4. Coding and Unit testing: In the coding phase software design is translated into source code using
any suitable programming language. Thus each designed module is coded. The aim of the unit testing
phase is to check whether each module is working properly or not. 
 
5. Integration and System testing: Integration of different modules are undertaken soon after they have
been coded and unit tested. Integration of various modules is carried out incrementally over a number
of steps. During each integration step, previously planned modules are added to the partially
integrated system and the resultant system is tested. Finally, after all the modules have been
 successfully integrated and tested, the full working system is obtained and system testing is carried
out on this. 
System testing consists of three different kinds of testing activities as described below : 
 Alpha testing: Alpha testing is the system testing performed by the development team.
 Beta testing: Beta testing is the system testing performed by a friendly set of customers.
 Acceptance testing: After the software has been delivered, the customer performed acceptance
testing to determine whether to accept the delivered software or reject it.
6. Maintenance: Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop a full software. There are basically three types
of maintenance : 
 Corrective Maintenance: This type of maintenance is carried out to correct errors that were not
discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of
the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to
work in a new environment such as working on a new computer platform or with a new operating
system.

Advantages of Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very simple, so it can
be considered the basis for other software development life cycle models. Below are some of the major
advantages of this SDLC model: 
 
 This model is very simple and is easy to understand.
 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well-understood milestones.
 Process, actions and results are very well documented.
 This model works well for smaller projects and projects where requirements are well 
understood.
Drawbacks of Classical Waterfall Model
The classical waterfall model suffers from various shortcomings, basically, we can’t use it in real
projects, but we use other software development lifecycle models which are based on the classical
waterfall model. Below are some major drawbacks of this model: 
 
 No feedback path: In the classical waterfall model evolution of software from one phase to another
phase is like a waterfall. It assumes that no error is ever committed by developers during any phase.
Therefore, it does not incorporate any mechanism for error correction. 
 
 Difficult to accommodate change requests: This model assumes that all the customer requirements
can be completely and correctly defined at the beginning of the project, but actually customers’
requirements keep on changing with time. It is difficult to accommodate any change requests after the
requirements specification phase is complete. 
 
 No overlapping of phases: This model recommends that a new phase can start only after the
completion of the previous phase. But in real projects, this can’t be maintained. To increase efficiency
and reduce cost, phases may overlap. 
 2. Iterative Model 
 In a practical software development project, the classical waterfall model is hard to use. So, the
Iterative waterfall model can be incorporated to overcome the drawback of the waterfall model. It is
almost the same as the classical waterfall model except some changes are made to increase the
efficiency of the software development. 
The iterative waterfall model provides feedback paths from every phase to its preceding phases, which
is the main difference from the classical waterfall model. 
Feedback paths introduced by the iterative waterfall model are shown in the figure below. 
 

3. Prototype Model
Prototyping is defined as the process of developing a working replication of a product or system that
has to be engineered. It offers a small scale facsimile of the end product and is used for obtaining
customer feedback as described below: 
 
 Prototype model is used when the customers do not know the exact project requirements beforehand.
In this model, a prototype of the end product is first developed, tested and refined as per customer
feedback repeatedly till a final acceptable prototype is achieved which forms the basis for developing
the final product.

System is partially implemented before or during the analysis phase thereby giving the customers an
opportunity to see the product early in the life cycle.
Advantages of using Prototype Model :
 This model is flexible in design.
 It is easy to detect errors.
 We can find missing functionality easily.
 There is scope of refinement, it means new requirements can be easily accommodated.
 It can be reused by the developer for more complicated projects in the future.
 It ensures a greater level of customer satisfaction and comfort.
 It is ideal for online system.
 It helps developers and users both understand the system better.
 Integration requirements are very well understood and deployment channels are decided at a
very early stage.
 It can actively involve users in the development phase.
Disadvantages of using Prototype Model :
 This model is costly.
 It has poor documentation because of continuously changing customer requirements.
 There may be too much variation in requirements.
 Customers sometimes demand the actual product to be delivered soon after seeing an early
prototype.
 There may be sub-optimal solutions because of developers in a hurry to build prototypes.
 Customers may not be satisfied or interested in the product after seeing the initial prototype.
 There is certainty in determining the number of iterations.
 There may be incomplete or inadequate problem analysis.
 There may increase the complexity of the system.

There are four types of models available: 

 
A) Rapid Throwaway Prototyping – 
This technique offers a useful method of exploring ideas and getting customer feedback for each of
them. In this method, a developed prototype need not necessarily be a part of the ultimately accepted
prototype. Customer feedback helps in preventing unnecessary design faults and hence, the final
prototype developed is of better quality. 
 
B)Evolutionary Prototyping – 
In this method, the prototype developed initially is incrementally refined on the basis of customer
feedback till it finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a better
approach which saves time as well as effort. This is because developing a prototype from scratch for
every iteration of the process can sometimes be very frustrating for the developers. 
 
C) Incremental Prototyping – In this type of incremental Prototyping, the final expected product is
broken into different small pieces of prototypes and being developed individually. In the end, when all
individual pieces are properly developed, then the different prototypes are collectively merged into a
single final product in their predefined order. It’s a very efficient approach that reduces the complexity
of the development process, where the goal is divided into sub-parts and each sub-part is developed
individually. The time interval between the project’s beginning and final delivery is substantially
reduced because all parts of the system are prototyped and tested simultaneously. Of course, there
might be the possibility that the pieces just do not fit together due to some lack of technique in the
development phase – this can only be fixed by careful and complete plotting of the entire system before
prototyping starts.
D) Extreme Prototyping – This method is mainly used for web development. It is consists of three
sequential independent phases:
1) In this phase a basic prototype with all the existing static pages are presented in the HTML format.
2)  In the 2nd phase, Functional screens are made with a simulated data process using a prototype
services layer.
3) This is the final step where all the services are implemented and associated with the final prototype.

Spiral model 
Spiral model is one of the most important Software Development Life Cycle models, which provides
support for Risk Handling. In its diagrammatic representation, it looks like a spiral with many loops.
The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of
the spiral is called a Phase of the software development process. The exact number of phases needed
to develop the product can be varied by the project manager depending upon the project risks. As the
project manager dynamically determines the number of phases, so the project manager has an important
role to develop a product using the spiral model. 
The Spiral Model is a software development life cycle (SDLC) model that provides a systematic and
iterative approach to software development. It is based on the idea of a spiral, with each iteration of the
spiral representing a complete software development cycle, from requirements gathering and analysis
to design, implementation, testing, and maintenance.
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through multiple
iterations of the software development process. It consists of the following phases:
1. Planning: The first phase of the Spiral Model is the planning phase, where the scope of the project
is determined and a plan is created for the next iteration of the spiral.

2. Risk Analysis: In the risk analysis phase, the risks associated with the project are identified and
evaluated.
3. Engineering: In the engineering phase, the software is developed based on the requirements
gathered in the previous iteration.
4. Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
5. Planning: The next iteration of the spiral begins with a new planning phase, based on the results of
the evaluation.
6. The Spiral Model is often used for complex and large software development projects, as it allows
for a more flexible and adaptable approach to software development. It is also well-suited to
projects with significant uncertainty or high levels of risk.
The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the
angular dimension represents the progress made so far in the current phase. 
Diagram

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure.
1. Objectives determination and identify alternative solutions: Requirements are gathered from
the customers and the objectives are identified, elaborated, and analyzed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution are
identified and the risks are resolved using the best possible strategy. At the end of this quadrant,
the Prototype is built for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.
Risk Handling in Spiral Model: A risk is any adverse situation that might affect the successful
completion of a software project. The most important feature of the spiral model is handling these
unknown risks after the project has started. Such risk resolutions are easier done by developing a
prototype. The spiral model supports coping up with risks by providing the scope to build a prototype
at every phase of the software development. 

The Prototyping Model also supports risk handling, but the risks must be identified completely before
the start of the development work of the project. But in real life project risk may occur after the
development work starts, in that case, we cannot use the Prototyping Model. In each phase of the Spiral
Model, the features of the product dated and analyzed, and the risks at that point in time are identified
and are resolved through prototyping. Thus, this model is much more flexible compared to other SDLC
models. 

Advantages of Spiral Model: 

1. Risk Handling:  Spiral Model is the best development model to follow due to the risk analysis and
risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the early phase of the
software development and thus, they habituated with the system by using it before completion of
the total product.
5. Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental
approach to software development, allowing for flexibility and adaptability in response to changing
requirements or unexpected events.
6. Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk management,
which helps to minimize the impact of uncertainty and risk on the software development process.
7. Improved Communication: The Spiral Model provides for regular evaluations and reviews, which
can improve communication between the customer and the development team.
8. Improved Quality: The Spiral Model allows for multiple iterations of the software development
process, which can result in improved software quality and reliability
Disadvantages of Spiral Model: 
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced experts, it is going to be a failure to
develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start of the project, so
time estimation is very difficult.
5. Complexity: The Spiral Model can be complex, as it involves multiple iterations of the software
development process.
6. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple evaluations and
reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a significant
investment in planning, risk analysis, and evaluations.

Feasibility Study 
Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or
system product in terms of how much beneficial product development will be for the organization in a
practical point of view. Feasibility study is one of stage among important four stages of Software
Project Management Process. Feasibility study is carried out based on many purposes to analyze
whether software product will be right in terms of development, implantation, contribution of project to
the organization etc.
Types of Feasibility Study : 
The feasibility study mainly concentrates on below five mentioned areas. Among these Economic
Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less
considered feasibility analysis. 
1. Technical Feasibility
In Technical Feasibility current resources both hardware software along with required technology
are analyzed/assessed to develop project. This technical feasibility study gives report whether there
exists correct required resources and technologies which will be used for project development.
Along with this, feasibility study also analyzes technical skills and capabilities of technical team,
existing technology can be used or not, maintenance and up-gradation is easy or not for chosen
technology etc. 
2. Operational Feasibility
In Operational Feasibility degree of providing service to requirements is analyzed along with how
much easy product will be to operate and maintenance after deployment. Along with this other
operational scopes are determining usability of product
3. Economic Feasibility
In Economic Feasibility study cost and benefit of the project is analyzed. Means under this
feasibility study a detail analysis is carried out what will be cost of the project for development
which includes all required cost for final development like hardware and software resource
required, design and development cost and operational cost and so on. After that it is analyzed
whether project will be beneficial in terms of finance for organization or not.  
4. Legal Feasibility – 
In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing
barriers of legal implementation of project, data protection acts or social media laws, project
certificate, license, copyright etc. Overall it can be said that Legal Feasibility Study is study to
know if proposed project conform legal and ethical requirements.  
5. Schedule Feasibility – 
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which
includes how many times teams will take to complete final project which has a great impact on the
organization as purpose of project may fail if it can’t be completed on time. 
 
Aim of feasibility study:
 The overall objective of the organization are covered and contributed by the system or not.
 The implementation of the system be done using current technology or not.
 can the system be integrated with the other system which are already exist

Steps in Feasibility study

1.  Information assessment
2. Information collection
3. Report writing
4. General information

Requirements analysis is very critical process that enables the success of a system or software project
to be assessed. Requirements are generally split into two types: Functional and Non-functional
requirements.
Functional Requirements: These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be necessarily incorporated into
the system as a part of the contract. These are represented or stated in the form of input to be given to
the system, the operation performed and the output expected. They are basically the requirements stated
by the user which one can see directly in the final product, unlike the non-functional requirements.
Functional Requirements of a system should include the following things:

 Details of operations conducted in every screen

 Data handling logic should be entered into the system
 It should have descriptions of system reports or other outputs
 Complete information about the workflows performed by the system
 It should clearly define who will be allowed to create/modify/delete the data in the system
 How the system will fulfill applicable regulatory and compliance needs should be captured in the
functional document

Non-functional requirements: These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these factors are implemented varies
from one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
Following are the differences between Functional and Non Functional Requirement

Functional Requirements Non Functional Requirements

A functional requirement defines a system or A non-functional requirement defines the quality

its component. attribute of a software system.

It specifies “What should the software system It places constraints on “How should the software
do?” system fulfill the functional requirements?”

Non-functional requirement is specified by

technical peoples e.g. Architect, Technical
Functional requirement is specified by User. leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

 Functional Requirements Non Functional Requirements

Helps you verify the functionality of the Helps you to verify the performance of the
software. software.

Functional Testing like System, Integration, Non-Functional Testing like Performance, Stress,
End to End, API testing, etc are done. Usability, Security testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example Example
1) Authentication of user whenever he/she logs 1) Emails should be sent with a latency of no
into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be done
3) A Verification email is sent to user within 10 seconds
whenever he/she registers for the first time on 3) The site should load in 3 seconds when the
some software system. number of simultaneous users are > 10000

Requirement Gathering and Analysis

Requirements gathering is the process of identifying your project's exact requirements from start to finish.
This process occurs during the project initiation phase, but you'll continue to manage your project
requirements throughout the project timeline.

The following are some of the well-known requirements gathering techniques −

Brainstorming
Brainstorming is used in requirement gathering to get as many ideas as possible from group of people.
Generally used to identify possible solutions to problems, and clarify details of opportunities.
Document Analysis
Reviewing the documentation of an existing system can help when creating AS–IS process document, as
well as driving gap analysis for scoping of migration projects.
Interview
Interviews of stakeholders and users are critical to creating the great software. Without understanding the
goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have
to recognize the perspective of each interviewee, so that, we can properly weigh and address their inputs.
Listening is the skill that helps a great analyst to get more value from an interview than an average
analyst.
Observation
By observing users, an analyst can identify a process flow, steps, pain points and opportunities for
improvement. Observations can be passive or active (asking questions while observing). Passive
observation is better for getting feedback on a prototype (to refine requirements), where active
observation is more effective at getting an understanding of an existing business process. Either approach
can be used.
Survey/Questionnaire
When collecting information from many people – too many to interview with budget and time constraints
– a survey or questionnaire can be used. The survey can force users to select from choices, rate something
(“Agree Strongly, agree…”), or have open ended questions allowing free-form responses. Survey design
is hard – questions can bias the respondents.
Requirement Analysis

Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity
reviews all requirements and may provide a graphical view of the entire system. After the completion of
the analysis, it is expected that the understandability of the project may improve significantly. 

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries and
interfaces of the proposed systems with the external world. It identifies the entities outside the proposed
system that interact with the system. The context diagram of student result management system is given
below:
(ii) Development of a Prototype (optional): One effective way to find out what the customer wants is to
construct a prototype, we can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure about some of the elements, a
prototype may help both the parties to take a final decision.

System but their feedback may allow us to make the product more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have limitations
and would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical representations of the
functions, data entities, external entities, and the relationships between them. The graphical view may
help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data
Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better understanding of
the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of
data amongst various modules has been analyzed. Elicitation and analyze activities have provided better
insight into the system. Now we finalize the analyzed requirements, and the next step is to document
these requirements in a prescribed format.

Requirement Specification

Software Requirement Specification: Is complete specification and description of requirements of

software that needs to be fulfilled for successful development of software system. These
requirements can be functional as well as non-functional depending upon type of requirement.
The interaction between different customers and contractor is done because its necessary to fully
understand needs of customers.  Depending upon information gathered after interaction, SRS is
developed which describes requirements of software that may include changes and modifications
that is needed to be done to increase quality of product and to satisfy customer’s demand.
In order to form a good SRS here you will see some points which can be used and should be
considered to form a structure of good SRS. These are as follows :
1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices 

1. Introduction
 (i) Purpose of this Document – At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.
 (ii) Scope of this document – In this, overall working and main objective of document
and what value it will provide to customer is described and explained. It also includes a
description of development cost and time required.
 (iii) Overview – In this, description of product is explained. It’s simply summary or
overall review of product.
2. General description : In this, general functions of product which includes objective of user, a
user characteristic, features, benefits, about why its importance is mentioned. It also describes
features of user community.
3. Functional Requirements : In this, possible outcome of software system which includes
effects due to operation of program is fully explained. All functional requirements which may
include calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements: In this, software interfaces which mean how software program
communicates with each other or users either in form of any language, code, or message are
fully described or explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements: In this, how a software system performs desired functions
under specific condition is explained. It also explains required time, required memory,
maximum error rate, etc.
6. Design Constraints: In this, constraints which simply means limitation or restriction are
specified and explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.
7. Non-Functional Attributes: In this, non-functional attributes are explained that are required
by software system for better performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget: In this, initial version and budget of project plan are
explained which include overall time duration required and overall cost required for
development of project.
9. Appendices: In this, additional information like references from where information is
gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and
explained.
 Uses of SRS document:
1. Development team require it for developing product according to the need.
2. Test plans are generated by testing group based on the describe external behavior.
3. Maintenance and support staff need it to understand what the software product is supposed to
do.
4. Project manager base their plans and estimates of schedule, effort and resources on it.
5. Customer rely on it to know that product they can expect.
6. As a contract between developer and customer.
7. In documentation purpose.
 

The meaning of Agile is swift or versatile."Agile process model" refers to a software

development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in
advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically
lasts from one to four weeks. The division of the entire project into smaller parts helps to
minimize the project risk and to reduce the overall project delivery time requirements. Each
iteration involves a team working through a full software development life cycle including
planning, requirements analysis, design, coding, and testing before a working product is
demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
 4. Testing/ Quality assurance

5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should explain
business opportunities and plan the time and effort needed to build the project. Based on this information,
you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to show the work of
new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins. Designers and
developers start working on their project, which aims to deploy a working product. The product will
undergo various stages of improvement, so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for
the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback
about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

eXtreme Programming(XP)

This type of methodology is used when customers are constantly changing demands or requirements, or
when they are not sure about the system's performance.

Extreme Programming (XP), the most widely used approach to agile software development. Although
early work on the ideas and methods associated with XP occurred during the late 1980s. Five values that
establish a foundation for all work performed as part of XP—communication, simplicity, feedback,
courage, and respect. Each of these values is used as a driver for specific XP activities, actions, and tasks.
In order to achieve effective communication between software engineers and other stakeholders (e.g., to
establish required features and functions for the software), XP emphasizes close, yet informal (verbal)
collaboration between customers and developers.To achieve simplicity, XP restricts developers to
design only for immediate needs, rather than consider future needs. The intent is to create a
simple design that can be easily implemented in code). If the design must be improved, it can
be refactored at a later time.

Feedback is derived from three sources: the implemented software itself, the customer, and
other software team members. By designing and implementing an effective testing strategy
the software provides the agile team with feedback. XP makes use of the unit test as its
primary testing tactic. As each class is developed, the team develops a unit test to exercise
each operation according to its specified functionality.

An agile XP team must have the discipline (courage) to design for today, recognizing that
future requirements may change dramatically, thereby demanding substantial rework of the
design and implemented code

By following each of these values, the agile team inculcates respect among it members,
between other stakeholders and team members, and indirectly, for the software itself. As they
achieve successful delivery of software increments, the team develops growing respect for the
XP process

Other Agile Process Model

 Adaptive Software Development (ASD)

 Scrum

 Dynamic Systems Development Method (DSDM)

 Crystal

 Feature Drive Development (FDD)

 Lean Software Development (LSD)

 Agile Modeling (AM)

 Agile Unified Process (AUP

Adaptive Software Development

Adaptive Software Development is a method to build complex software and system. ASD
focuses on human collaboration and self-organization. ASD “life cycle” incorporates three
phases namely: 

 Speculation
 Collaboration
  Learning
 These are explained as following below. 


 Adaptive Software Development

 1.Speculation: 
During this phase project is initiated and planning is conducted. The project plan uses
project initiation information like project requirements, user needs, customer mission
statement, etc, to define set of release cycles that the project wants. 
 2. Collaboration: 
It is the difficult part of ASD as it needs the workers to be motivated. It collaborates
communication and teamwork but emphasizes individualism as individual creativity
plays a major role in creative thinking. People working together must trust each others  
 Criticize without animosity,
 Assist without resentment,
 Work as hard as possible,
 Possession of skill set,
 Communicate problems to find effective solution.

3. Learning: 

The workers may have a overestimate of their own understanding of the technology which
may not lead to the desired result. Learning helps the workers to increase their level of
understanding over the project. 
Learning process is of 3 ways: 

1. Focus groups
2. Technical reviews
3. Project postmortem

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in team-based
development conditions.

There are three roles in it, and their responsibilities are:

 o Scrum Master: The scrum can set up the master team, arrange the meeting and remove obstacles
for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay and is
responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the sprint or cycle.

Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development team,
performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:

A. Team updates the release plan.

B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-deployment.

Dynamic Software Development Method (DSDM):

DSDM is a rapid application development strategy for software development and gives an agile project
distribution structure. The essential features of DSDM are that users must be actively connected, and
teams have been given the right to make decisions. The techniques used in DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

Feature Driven Development (FDD):

This method focuses on "Designing and Building" features. In contrast to other smart methods, FDD
describes the small steps of the work that should be obtained separately per function.
Lean Software Development:

Lean software development methodology follows the principle "just in time production." The lean
method indicates the increasing speed of software development and reducing costs. Lean development
can be summarized in seven phases.

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers allotted
to another project, maintenance of the finished project can become a difficulty.b

Agile Modeling(AM)

Agile Modeling (AM) is a practice-based methodology for effective modeling

and documentation

Agile Unified Process

AUP provides a serial overlay that enables a team to visualize the overall process flow for a software
project. However, within each of the activities, the team iterates to achieve agility and to deliver
meaningful software increments to end users as rapidly as possible. Each AUP iteration addresses the
following activities
 Modelling. UML representations of the business and problem domains are created.
 Implementation. Models are translated into source code.
 Testing. Like XP, the team designs and executes a series of tests to uncover errors and ensure that
the source code meets its requirements.
 Deployment: deployment in this context focuses on the delivery of a software increment and the
acquisition of feedback from end users.
 Configuration and project management. In the context of AUP, configuration management
addresses change management, risk management, and the control of any persistent work products
that are produced by the team. Project management tracks and controls the progress of the team
and coordinates team activities.
 Environment management. Environment management coordinates a process infrastructure that
includes standards, tools, and other support technology available to the team.