Software

IEEE defines software engineering as:

(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; that
is, the application of engineering principles
to software.
(2) The study of approaches as in the above
statement

Software Application Domains

• System Software
• Real time Software
• Business Software
• Engineering & Scientific Software
• Embedded Software
• Personal Computer Software
• Web Based Software
• Artificial Intelligence Software
 Attributes / Characteristics of
Software
Maintainability
• Software should be written in such a way that it may
evolve to meet the changing needs of customers.
Dependability
• Dependability has a range of features such as:
reliability
security
Safety.
• Dependable-software should not cause physical or
economic damage in event of failure.

Efficiency
• Software should not waste system-resources
such as:
• memory-cycles and
• Processor-cycles.
– Efficiency includes
– response-time
– processing-time and
– Memory-utilization.
Usability
• Software must be usable, without undue
effort, by the user.
• Software should have an appropriate
• user interface and
• Proper documentation

Generic Products Customized Products

Generic products are developed for anonymous The customized products are developed for specific
customers customers.

The specifications are usually developed and controlled The software specifications are developed and controlled
by the Organization who develops the software product. by the Organizations who are buying the software.

The product is designed and developed for a specific

The target is generally the entire world.
customer.

Examples: Operating Systems, Examples: Payroll system, Inventory

compilers, word – processors Systems.
 Software Process
• The software process is the set of activities whose goal is the development
of software.
• There are four main process activities:
1. Software Specification
• The functionality of the software and constraints on its operations must be
defined.
• This answers following questions:
• What the system should do?
• What are its development constraints?
2. Software Development
• Software is designed and programmed to meet the requirements.

3. Software Validation
• Software is checked to ensure that it is what the customer requires.

4. Software Evolution
• Software must evolve to meet the changing customer requirements.
PRESCRIPTIVE PROCESS MODELS
• The Waterfall Model
• Incremental Process Models
• Evolutionary Process
Models(Spiral,prototype,iterative)
• Concurrent Models
SPECIALIZED PROCESS MODELS
• Component-Based Development Model
• The Formal Methods Model
• Aspect-Oriented Software Development Model
 Prescriptive process models
• Prescriptive process models were originally
proposed to bring order to the chaos of
software development. Prescriptive process
models define a prescribed set of process
elements and a predictable process work flow.
“prescriptive” because they prescribe a set of
process elements—framework activities,
software engineering actions, tasks, work
products, quality assurance, and change
control mechanisms for each project.

The Waterfall Model

• The waterfall model, sometimes called the
classic life cycle
• It suggests a systematic, sequential approach
to software development
that begins with customer specification of
requirements and progresses through
planning, modeling, construction, and
deployment.
• It was developed by Royce in 1970.
• This model is also referred as Linear Sequential
Model or Classical Life Cycle Model.
• This model follows a systematic, sequential
approach to software development.
• In this model, the software development activity
is divided into different phases and each phase
consists of series of tasks.
• Each phase must be completed before the next
phase can begin.
• Classical waterfall model divides the life cycle into
the following phases:
Requirement Gathering and analysis
• This is the first phase of waterfall model which
includes a meeting with the customer to understand
his requirements.
• This is the most crucial phase as any
misinterpretations at this stage may rise to project
failure.
• The software definition must be detailed and accurate
with no ambiguities.
• It is very important to understand the customer
requirements and expectations so that the end
product meets the customer requirements.
• Then all this requirements are then well documented
in a requirement specification document.

System Design
• It is the intermediate step between requirement analysis
and coding.
• The requirement specifications from first phase are studied
in this phase and the system design is prepared.
• This system design helps in specifying hardware and system
requirements and helps in defining the overall system
architecture.
• The customer requirements are broken down into logical
modules.
• Also the inter relation between the various logical modules
is established at this stage.
• Algorithms and diagrams are designed to define the scope
and objective of each logical model.
• This phase lays a fundamental for actual programming and
implementation.
Implementation and Unit Testing
• Coding is a step in which design is translated into
machine readable form.
• On receiving system design documents, the work is
divided into modules / units and actual coding is
started.
• The system is first developed in small programs called
units, which are integrated in the next phase.
• Each unit is developed is developed and tested for its
functionality, that is referred to as unit testing.
• If design is done with the sufficient details then coding
can be done efficiently.

Integration and System Testing

• In this stage both individual components and
the integrated components are tested to
ensure that they are error free and meet the
customer requirements.
• During integration testing, the components
are integrated into a complete system and
tested to check if all the modules/units
coordinate with each other, and the system as
whole behaves as per the requirements.
Operation &Maintenance
• This the final phase of the waterfall model, in
which the completed software is handed over to
the customer after performing testing.
• After the software has been deployed on the
client site, it is the duty of the software
development team to undertake maintenance
activities.
Maintenance includes:
• Correcting errors
• If the customer suggests changes or
enhancements

Advantages of waterfall model:

• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase has
specific deliverables and a review process.
• Clearly defined stages.
• In this model phases are processed and completed one at a time. Phases
do not overlap.
• Waterfall model works well for smaller projects where requirements are
very well understood.

Disadvantages of waterfall model:

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to
high risk of changing.
• Once an application is in the testing stage, it is very difficult to go back and
change something.
When to Use waterfall model:
• Requirements are very well known.
• Product definition is stable.
• New version of an existing product.

Incremental Model
• Incremental Model is a process of
software development where
requirements divided into multiple
standalone modules of the software
development cycle. In this model, each
module goes through the requirements,
design, implementation and testing
phases. Every subsequent release of
the module adds function to the
previous release. The process
• The various phases of incremental model are as
follows:
• 1. Requirement analysis: In the first phase of
the incremental model, the product analysis
expertise identifies the requirements. And the
system functional requirements are
understood by the requirement analysis team.
To develop the software under the incremental
model, this phase performs a crucial role.
• 2. Design & Development: In this phase of the
Incremental model of SDLC, the design of the
system functionality and the development
method are finished with success. When
software develops new practicality, the
incremental model uses style and development
phase.
• 3. Testing: In the incremental model, the testing phase
checks the performance of each existing function as
well as additional functionality. In the testing phase,
the various methods are used to test the behavior of
each task.
• 4. Implementation: Implementation phase
enables the coding phase of the development
system. It involves the final coding that design
in the designing and development phase and
tests the functionality in the testing phase.
After completion of this phase, the number of
the product working is enhanced and
upgraded up to the final system product

• When we use the Incremental Model?

• When the requirements are superior.
• A project has a lengthy development
schedule.
• When Software team are not very well
skilled or trained.
• When the customer demands a quick
release of the product.
• You can develop prioritized requirements
first.
Advantage of Incremental Model
Errors are easy to be recognized.
Easier to test and debug
More flexible.
Simple to manage risk because it handled during its
iteration.
The Client gets important functionality early.
Disadvantage of Incremental Model
Need for good planning
Total Cost is high.
Well defined module interfaces are needed

Iterative Model

• In this Model, you can start with some of the

software specifications and develop the first
version of the software. After the first version
if there is a need to change the software, then
a new version of the software is created with
a new iteration. Every release of the Iterative
Model finishes in an exact and fixed period
that is called iteration.
• The Iterative Model allows the accessing
earlier phases, in which the variations made
respectively. The final output of the project
renewed at the end of the Software
Development Life Cycle SDLC) process.
• The various phases of Iterative model are as
follows:
• 1. Requirement gathering & analysis: In this
phase, requirements are gathered from
customers and check by an analyst whether
requirements will fulfil or not. Analyst checks
that need will achieve within budget or not.
After all of this, the software team skips to the
next phase.
• 2. Design: In the design phase, team design
the software by the different diagrams like
Data Flow diagram, activity diagram, class
diagram, state transition diagram, etc.
• 3. Implementation: In the implementation, requirements
are written in the coding language and transformed into
computer programmes which are called Software.
• 4. Testing: After completing the coding phase, software
testing starts using different test methods. There are
many test methods, but the most common are white box,
black box, and grey box test methods.
• 5. Deployment: After completing all the phases, software
is deployed to its work environment.
• 6. Review: In this phase, after the product deployment,
review phase is performed to check the behaviour and
validity of the developed product. And if there are any
error found then the process starts again from the
requirement gathering.
• 7. Maintenance: In the maintenance phase, after
deployment of the software in the working environment
there may be some bugs, some errors or new updates
are required. Maintenance involves debugging and new
addition options.

• When to use the Iterative Model?

1. When requirements are defined clearly
and easy to understand.
2. When the software application is large.
3. When there is a requirement of changes
in future.
 • Advantage(Pros) of Iterative Model:
1. Testing and debugging during smaller
iteration is easy.
2. A Parallel development can plan.
3. It is easily acceptable to ever-changing
needs of the project.
4. Risks are identified and resolved during
iteration.
5. Limited time spent on documentation and
extra time on designing.

• Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.
2. More Resources may be required.
3. Design can be changed again and again
because of imperfect requirements.
4. Requirement changes can cause over
budget.
5. Project completion date not confirmed
because of changing requirements.
 Spiral Model
• The spiral model, initially proposed by Boehm,
is an evolutionary software process model that
couples the iterative feature of prototyping
with the controlled and systematic aspects of
the linear sequential model. It implements the
potential for rapid development of new
versions of the software. Using the spiral
model, the software is developed in a series of
incremental releases. During the early
iterations, the additional release may be a
paper model or prototype. During later
iterations, more and more complete versions of
the engineered system are produced.
• Each cycle in the spiral is divided into
four parts:
• Objective setting: Each cycle in the
spiral starts with the identification of
purpose for that cycle, the various
alternatives that are possible for
achieving the targets, and the
constraints that exists.

• Risk Assessment and reduction: The

next phase in the cycle is to calculate
these various alternatives based on the
goals and constraints. The focus of
evaluation in this stage is located on
the risk perception for the project.
• Development and validation: The next phase is to
develop strategies that resolve uncertainties and
risks. This process may include activities such as
benchmarking, simulation, and prototyping.
• Planning: Finally, the next step is planned. The
project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is
determined to keep, plans are drawn up for the
next step of the project.
• The development phase depends on the remaining
risks. For example, if performance or user-interface
risks are treated more essential than the program
development risks, the next phase may be an
evolutionary development that includes developing
a more detailed prototype for solving the risks.

• When to use Spiral Model?

• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
• Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
• Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.
 Prototype Model

• The prototype model requires that before carrying

out the development of actual software, a working
prototype of the system should be built. A
prototype is a toy implementation of the system. A
prototype usually turns out to be a very crude
version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and
inefficient performance as compared to actual
software. In many instances, the client only has a
general view of what is expected from the software
product. In such a scenario where there is an
absence of detailed information regarding the input
to the system, the processing needs, and the
output requirement, the prototyping model may be
employed.
 • Steps of Prototype Model
1. Requirement Gathering and Analysis.
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

• Advantage of Prototype Model

1. Reduce the risk of incorrect user
requirement
2. Good where requirement are
changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the
system is made side by side.
 • Disadvantage of Prototype Model
1. An unstable/badly implemented prototype often
becomes the final product.
2. Require extensive customer collaboration
1. Costs customer money
2. Needs committed customer
3. Difficult to finish if customer withdraw
4. May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper
requirement analysis, design, customer evaluation, and
feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a
prototype.
7. It is a time-consuming process.

Concurrent Models
• The concurrent development model, sometimes called
concurrent engineering, allows a software team to
represent iterative and concurrent elements of any of the
process models.
• The concurrent model is often more appropriate for product
engineering projects where different engineering teams are
involved.
• These models provides a schematic representation of one
software engineering activity, within the modeling activity
using a concurrent modeling approach.
• The activity modeling may be in any one of the states noted
at any given time.
• Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an
analogous manner.
• The concurrent development model
• The concurrent development model is called as
concurrent model.
• The communication activity has completed in the first
iteration and exits in the awaiting changes state.
• The modeling activity completed its initial
communication and then go to the
underdevelopment state.
• If the customer specifies the change in the
requirement, then the modeling activity moves from
the under development state into the awaiting
change state.
• The concurrent process model activities moving from
one state to another state.
• Advantages of the concurrent development
modelThis model is applicable to all types of
software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current
state of a project.
• Disadvantages of the concurrent
development modelIt needs better
communication between the team members.
This may not be achieved all the time.
• It requires to remember the status of the
different activities.

AGILE DEVELOPMENT
WHAT IS AGILITY?
• Agile is a software development methodology to build software
incrementally using short iterations of 1 to 4 weeks so that the
development process is aligned with the changing business needs.
• An agile team is a nimble (smart)team able to appropriately
respond to changes.
• Change is what software development is very much about.
• Changes in the software being built, changes to the team
members, changes because of new technology, changes of all
kinds that may have an impact on the product they build or the
project that creates the product.
• Support for changes should be built-in everything we do in
software, something we embrace because it is the heart and soul
of software.
• An agile team recognizes that software is developed by individuals
working in teams and that the skills of these people, their ability to
collaborate is at the core for the success of the project.
 Agile Process
• Any agile software process is characterized in a manner that
addresses a number of key assumptions about the majority of
software projects:
• 1. It is difficult to predict in advance which software
requirements will persist and which will change. It is equally
difficult to predict how customer priorities will change as the
project proceeds.
• 2. For many types of software, design and construction are
interleaved. That is, both activities should be performed in
tandem so that design models are proven as they are created. It is
difficult to predict how much design is necessary before
construction is used to prove the design.
• 3. Analysis, design, construction, and testing are not as
predictable

Agility Principles
1. Our highest priority is to satisfy the customer through early
and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness
change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with
a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity—the art of maximizing the amount of work not done—is
essential.
11. The best architectures, requirements, and designs emerge from self–
organizing teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

Human Factors
• Agile development focuses on the talents and skills of individuals,
molding the process to specific people and teams.” The key point
in this statement is that the process molds to the needs of the
people and team
• Competence. In an agile development context, “competence”
encompasses innate talent, specific software-related skills, and
overall knowledge of the process that the team has chosen to
apply. Skill and knowledge of process can and should be taught to
all people who serve as agile team members.
• Common focus. Although members of the agile team may
perform different tasks and bring different skills to the project, all
should be focused on one goal—to deliver a working software
increment to the customer within the time promised.
• To achieve this goal, the team will also focus on continual
adaptations (small and large) that will make the process fit the
needs of the team.
• Collaboration. Software engineering (regardless of process) is
about assessing, analyzing, and using information that is
communicated to the software team; creating information that
will help all stakeholders understand the work of the team; and
building information (computer software and relevant databases)
that provides business value for the customer. To accomplish these
tasks, team members must collaborate—with one another and all
other stakeholders.
• Decision-making ability. Any good software team (including agile
teams) must be allowed the freedom to control its own destiny.
This implies that the team is given autonomy—decision-making
authority for both technical and project issues.
• Fuzzy problem-solving ability. Software managers must recognize
that the agile team will continually have to deal with ambiguity
and will continually be buffeted by change.
• Mutual trust and respect. The agile team must become what
DeMarco and Lister call a “jelled” team. A jelled team exhibits the
trust and respect that are necessary to make them “so strongly
knit that the whole is greater than the sum of the parts.”

• 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.
 • 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
• Agile Testing Methods:
• Scrum
• Crystal
• Dynamic Software Development
Method(DSDM)
• Feature Driven Development(FDD)
• Lean Software Development
• eXtreme Programming(XP)

• 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:
• Scrum Master: The scrum can set up the master
team, arrange the meeting and remove obstacles
for the process
• Product owner: The product owner makes the
product backlog, prioritizes the delay and is
responsible for the distribution of functionality on
each repetition.
• Scrum Team: The team manages its work and
organizes the work to complete the sprint or cycle.
• SCRUM is an agile development method
which concentrates specifically on how to
manage tasks within a team-based
development environment. Basically, Scrum is
derived from activity that occurs during a
rugby match. Scrum believes in empowering
the development team and advocates working
in small teams (say- 7 to 9 members). Agile
and Scrum consist of three roles, and their
responsibilities are explained as follows:
 • Crystal Methodologies
• Crystal Methodology is based on three concepts
1. Chartering: Various activities involved in this phase
are creating a development team, performing a
preliminary feasibility analysis, developing an initial
plan and fine-tuning the development methodology
2. Cyclic delivery: The main development phase
consists of two or more delivery cycles, during which
the
1. Team updates and refines the release plan
2. Implements a subset of the requirements through one or
more program test integrate iterations
3. Integrated product is delivered to real users
4. Review of the project plan and adopted development
methodology
3. Wrap Up: The activities performed in this phase are
deployment into the user environment, post-
deployment reviews and reflections are performed.

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.
• XP is a lightweight, efficient, low-risk, flexible,
predictable, scientific, and fun way to develop a
software.
• eXtreme Programming (XP) was conceived and
developed to address the specific needs of
software development by small teams in the face
of vague and changing requirements.
• Why is it called “Extreme?”
• Extreme Programming takes the effective principles
and practices to extreme levels.
• Code reviews are effective as the code is reviewed all
the time.
• Testing is effective as there is continuous regression
and testing.
• Design is effective as everybody needs to do
refactoring daily.
• Integration testing is important as integrate and test
several times a day.
• Short iterations are effective as the planning game for
release planning and iteration planning.

• Extreme Programming is one of the Agile

software development methodologies. It
provides values and principles to guide the
team behavior. The team is expected to
self-organize. Extreme Programming
provides specific core practices where −
• Each practice is simple and self-complete.
• Combination of practices produces more
complex and emergent behavior.
 EXTREME PROGRAMMING (XP)
• Extreme Programming (XP), the most widely used
approach to agile software development, emphasizes
business results first and takes an incremental,
get-something-started approach to building the
product, using continual testing and revision.
• XP Values
• Beck defines a set of 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.

Other Agile Process Models

• 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)
 Agile Modeling (AM)
• Agile Modeling (AM) is a practice-based methodology for effective
modeling and documentation of software-based systems.
• Agile Modeling (AM) is a collection of values, principles, and practices for
modeling software that can be applied on a software development
project in an effective and light-weight manner.
• Agile models are more effective than traditional models because they are
just barely good, they don’t have to be perfect.
• Agile modeling adopts all of the values that are consistent with the agile
policy.
• The agile modeling philosophy recognizes that an agile team must have
the courage to make decisions that may cause it to reject a design and
refactor (restructuring the existing code).
• The team must also have the humility to recognize that technologists do
not have all the answers and that business experts and other
stakeholders should be respected and embraced.

Agile Modeling suggests a wide array of “core” and “supplementary” modeling principles,
those that make AM unique are :

Model with a purpose

A developer who uses AM should have a specific goal in mind before creating the model.
Once the goal for the model is identified, the type of notation to be used and level of detail
required will be more clear

Use multiple models

There are many different models and notations that can be used to describe software.
Only a small subset is essential for most projects.
AM suggests that to provide needed insight, each model should present a different aspect of
the system and only those models that provide value to their intended audience should be
used.

Travel light
As software engineering work proceeds, keep only those models that will provide long-term
value and throw the remaining models.
Every work product that is kept must be maintained as changes occur.
This represents work that slows the team down.
Every time you decide to keep a model you trade-off agility for the convenience of having that
information available to your team in an abstract manner
Content is more important than representation
Modeling should impart information to its intended audience.
A syntactically perfect model that imparts little useful content
is not as valuable as a model with flawed notation that
nevertheless provides valuable content for its audience.

Know the models and the tools you use to create them
Understand the strengths and weaknesses of each model and
the tools that are used to create it.

Adapt locally
The modeling approach should be adapted to the needs of the
agile team

Agile Unified Process (AUP)

• The Agile Unified Process (AUP) adopts a “serial
in the large” and “iterative in the small”
philosophy for building computer-based systems.
• By adopting the classic UP phased
activities—inception, elaboration, construction,
and transition—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.

Modeling: 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. Like the generic process activity 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 co-ordinates a process

infrastructure that includes standards, tools, and other support technology available to
the team.

REQUIREMENTS ENGINEERING
• Requirements analysis, also called requirements engineering, is
the process of determining user expectations for a new or
modified product. Requirements engineering is a major software
engineering action that begins during the communication activity
and continues into the modeling activity.
• It must be adapted to the needs of the process, the project, the
product, and the people doing the work. Requirements
engineering builds a bridge to design and construction.

• Requirements engineering provides the appropriate mechanism

for understanding what the customer wants, analyzing need,
assessing feasibility, negotiating a reasonable solution, specifying
the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an
operational system.
• It encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and
management.
• Inception : It establish a basic understanding of the problem, the people
who want a solution, the nature of the solution that is desired, and the
effectiveness of preliminary communication and collaboration between
the other stakeholders and the software team.
• Elicitation: In this stage, proper information is extracted to prepare to
document the requirements. It certainly seems simple enough—ask the
customer, the users, and others what the objectives for the system or
product are, what is to be accomplished, how the system or product fits
into the needs of the business, and finally, how the system or product is to
be used on a dayto-day basis.
• Problems of scope. The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may confuse,
rather than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely
sure of what is needed, have a poor understanding of the capabilities and
limitations of their computing environment, don’t have a full
understanding of the problem domain, have trouble communicating needs
to the system engineer, omit information that is believed to be “obvious,”
specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or un
testable.
• Problems of volatility. The requirements change over time.

• Elaboration: The information obtained from the customer during

inception and elicitation is expanded and refined during elaboration. This
task focuses on developing a refined requirements model that identifies
various aspects of software function, behavior, and information.
Elaboration is driven by the creation and refinement of user scenarios that
describe how the end user (and other actors) will interact with the
system.

• Negotiation: To negotiate the requirements of a system to be developed,

it is necessary to identify conflicts and to resolve those conflicts. You have
to reconcile these conflicts through a process of negotiation. Customers,
users, and other stakeholders are asked to rank requirements and then
discuss conflicts in priority. Using an iterative approach that prioritizes
requirements, assesses their cost and risk, and addresses internal conflicts,
requirements are eliminated, combined, and/or modified so that each
party achieves some measure of satisfaction.
Specification:
• The term specification means different things to different people. A specification
can be a written document, a set of graphical models, a formal mathematical model,
a collection of usage scenarios, a prototype, or any combination of these.

Validation:
• The work products produced as a consequence of requirements engineering are
assessed for quality during a validation step. Requirements validation examines the
specification to ensure that all software requirements have been stated
unambiguously; that inconsistencies, omissions, and errors have been detected and
corrected; and that the work products conform to the standards established for the
process, the project, and the product.
• The primary requirements validation mechanism is the technical review.
• The review team that validates requirements includes software engineers,
customers, users, and other stakeholders who examine the specification looking for
errors in content or interpretation, areas where clarification may be required,
missing information, inconsistencies, conflicting requirements, or unrealistic
requirements.

Requirements management:
• Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system. Requirements management
is a set of activities that help the project team identify, control, and track
requirements and changes to requirements at any time as the project proceeds.
Many of these activities are identical to the software configuration management
(SCM) techniques.

Requirements 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.

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, something that looks
and preferably acts as part of the system they say they want.

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.

(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
 What is a Functional Requirement

• A Functional Requirement (FR) is a description of

the service that the software must offer. It describes a
software system or its component.

• A function is nothing but inputs to the software system,

its behavior, and outputs. It can be a calculation, data
manipulation, business process, user interaction, or
any other specific functionality which defines what
function a system is likely to perform.

• Functional Requirements in Software Engineering are

also called Functional Specification.

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
 Types of Functional Requirements
Here are the most common functional
requirement types:
•Transaction Handling
•Business Rules
•Certification Requirements
•Reporting Requirements
•Administrative functions
•Authorization levels
•Audit Tracking
•External Interfaces
•Historical Data management
•Legal and Regulatory Requirements

Non-functional Requirements in Software Engineering

Non-functional requirements in software engineering refer to the

characteristics of a software system that are not related to specific functionality
or behavior. They describe how the system should perform, rather than what it
should do. Examples of non-functional requirements include:
1.Performance: This includes requirements related to the speed, scalability, and
responsiveness of the system. For example, a requirement that the system
should be able to handle a certain number of concurrent users or process a
certain amount of data within a specific time frame.
2.Security: This includes requirements related to the protection of the system and
its data from unauthorized access, as well as the ability to detect and recover
from security breaches.
3.Usability: This includes requirements related to the ease of use and
understandability of the system for the end-users.
4.Reliability: This includes requirements related to the system’s ability to function
correctly and consistently under normal and abnormal conditions.
5.Maintainability: This includes requirements related to the ease of maintaining
the system, including testing, debugging, and modifying the system.
6.Portability: This includes requirements related to the ability of the system to be
easily transferred to different hardware or software environments.
7.Compliance: This includes requirements related to adherence to laws,
regulations, industry standards, or company policies.
 Non-Functional Requirements are the constraints or the
requirements imposed on the system. They specify the quality
attribute of the software. Non-Functional Requirements deal with
issues like scalability, maintainability, performance, portability,
security, reliability, and many more. Non-Functional Requirements
address vital issues of quality for software systems. If NFRs not
addressed properly, the results can include:
•Users, clients, and developers are unsatisfied.
•Inconsistent software.
•Time and cost overrun to fix the software which was prepared
without keeping NFRs in mind.

Non Functional vs. Functional Requirements

Parameters Functional Requirement Non-Functional Requirement

What it is Verb Attributes

Requirement It is mandatory It is non-mandatory

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

End result Product feature Product properties

Capturing Easy to capture Hard to capture

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

Area of focus Focus on user requirement Concentrates on the user’s expectation.

Documentation Describe what the product does Describes how the product works

Functional Testing like System, Non-Functional Testing like Performance,

Type of Testing
Integration, End to End, API testing, etc. Stress, Usability, Security testing, etc.

Test Execution is done before

Test Execution After the functional testing
non-functional testing.

Product Info Product Features Product Properties

1. what are the difference between
system software and application
software?
2.Write short notes on a) iterative model
b)incremental model
3. Explain briefly about Agile Model
4. Which model can analyse the risk
factor of a product and How?