Course title: Software Engineering

• Course Code:
• Course Instructor: Sitaram Pokhrel
• Semester: V
• Nature of course: Theory +Lab( Case Studies+Projects)
• Marks: 80 (Final Theory)+20 (Internal)+25(Lab)
Unit 1: Software Process and Requirements

• Software Crisis
• Software Characteristics
• Software Quality attributes
• Software process model
• Process iteration
• Process Activities
• Computer-aided software engineering
• Functional and Non functional requirements
Unit 1: Software Process and Requirements

• User Requirements
• System Requirement
• Interface specification
• The software requirements documents
• Feasibility study
• Requirement elicitation and analysis
• Requirements validation and management
1.1 Software Crisis
• Software crisis is a term used in the early days of computing
science for the difficulty of writing useful and efficient computer
programs in the required time.
• The software crisis was due to the rapid increases in computer power
and the complexity of the problems that could now be tackled.
• With the increase in the complexity of the software, many software
problems arose because existing methods were inadequate.
Software Crisis
• The causes of the software crisis were linked to the overall complexity of
hardware and the software development process.
• The crisis manifested itself in several ways:-
1. Projects running over-budget
2. Projects running over-time
3. Software was very inefficient
4. Software was of low quality
5. Software often did not meet requirements
6. Projects were unmanageable and code difficult to maintain
7. Software was never delivered
Software Crisis
• A software crisis is a mismatch between what software can deliver and the capacities
of computer systems, as well as expectations of their users.
• As the complexity of systems grows, so do the needs of users, who expect increasingly
more performance from their software.
• Projects can run into a software crisis where they start to go over budget and take
much longer than expected to develop.
• The programmers working on the software may have to deal with ongoing bug fixes
while learning new aspects of a system, making adjustments for the client, and
addressing other issues that arise.
• Low quality can be a concern, as the programmers may experience increasing pressure
to meet budgets at all costs, even if it means the software won’t be of good quality.
Software and its types
• Software are programs that execute within a computer of any size and
architecture and provide desired output.
• Software are data structures that enable the programs to adequately
manipulate information.
• Everyone uses it directly or indirectly and affects nearly every aspects
of our lives.
• Types includes: Application Software, Driver software, System
software, Utility sofware, etc.
1.2 Software Characteristics
• Software does not wear out.
• Usability of Software.
• Reusability of components.
• Flexibility of software.
• Maintainability of software.
• Portability of software.
• Reliability of Software.
Software Characteristics
Functionality:
• It refers to the degree of performance of the software against its
intended purpose.
• Required functions are: Suitability, Accuracy, Compliance, security,
etc.
Reliability
• A set of attribute that bear on capability of software to maintain its
level of performance under the given condition for a stated period of
time.
• Required functions are: recoverability, fault tolerance, maturity.
Efficiency
• It refers to the ability of the software to use system resources in the
most effective and efficient manner.
• The software should make effective use of storage space and
executive command as per desired timing requirement.
• Required functions are: in time, in resource
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: Understandability, Operability, Learnability.
Maintainability
• t 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: Testability, stability, changeability, operability.
Portability
• A set of attribute that bear on the ability of software to be transferred
from one environment to another, without or minimum changes.
• Required functions are: Adaptability, Installability, Replaceabality
1.3 Software Quality Attributes
• Stable:-It does not crash. It need to be reliable.
• Adequate Features:-Sufficient Characteristics regarding to
requirements and goal.
• Intuitive User Interface:-Need to be easy to understand easy to
understand so that user can figure out how to use the software.
• Straight forwardness and simplicity:-Need to be simple and straight
forward so the it can be traced forward and backward.
• Efficient:-Use no more computer resources than is absolutely
essential so that it cannot affects the performance of machine.
Software Quality Attributes
• Consistent:-Should not contradict itself and need to be easy to test.
• Verifiable:-Needs to be satisfied the user.
• Modifiable:-Should adopt changes.
• Performance, Security, Reliability, maintainability, etc
Software Engineering and its importance
• Software engineering encompasses a process; a collection of methods
(practices) and an array of tools that allow professionals to build high
quality software.
• It is the application of a systematic, disciplined, quantifiable approach
to the development , operation and maintenance of software and the
study of these applications to software.
• It provides automated and semi automated support for the process
and methods.
Importance/Role of Software Engineering
• With the development of technology, requirements are increasing
and is becoming more and more complex. To deal with the increasing
complex nature of software, software engineering plays an important
role.
• Software engineering researches, designs and develops software
systems to meet with client’s requirements.
• Generally, it translates the vague requirements and derives into
precise specifications.
Importance/Role of Software engineering
• It derive model of application and understand the behavior and
performance of the system.
• Provides methods to schedule, manage and operate works or tasks.
• Promote inter-personnel and communication skills and management
skills.
• Generally, it is important because it enable us to build complex
systems in timely manner and with high quality.
Difference between software engineering and
computer science
• Computer Science focuses on understanding, designing, and
developing programs and computers.
• Software Engineering deals with building and
maintaining software systems.
• Software Engineering is with database, mathematics, AI,
programming, etc which are the field of computer science.
Difference between system engineering and
software engineering
• Software is prominent in most modern systems architectures and is
often the primary means for integrating complex system components.
• It can be said that the System Engineers focus more on users and
domains, while Software Engineering focus more on n implementing
quality software.
• Good system engineering is a key factor in enabling good software
engineering.
Difference between system engineering and
software engineering
• System engineering deals with work-processes and tools to handle
software engineering projects and it overlap with both technical and
human centered disciplines i.e. it deals with all aspects of computer
based system development.
• System engineering is to identify the roles of hardware, software,
people, database and other elements involved with that system which
is going to be developed.
• Software engineering is a part of system engineering.
System engineering methods
• Stakeholder Analysis
• Requirements Engineering
• Functional Decomposition
• Design Constraints
• Architectural Design
• Design Criteria
• Design Tradeoffs
• Interface Specification
• Configuration Management
• Systematic Verification and Validation
Software engineering methods
• Model-Driven Development
• UML-SysML
• Use Cases
• Object-Oriented Design
• Iterative Development
• Agile Methods
• Continuous Integration
• Process Modeling
• Process Improvement
• Incremental Verification and Validation
Challenges of software engineering
• The methods used to develop small or medium scale projects are not
suitable when the system is growing to large and complex system.
• Changes to software are unavoidable so developing of complete
software is a challenge.
• Producing high quality software by addressing changing needs.
• Maintenance with acceptable cost.
• Meeting of allocated budget associated with project.
• Meeting of user’s expectations due to unclear ideas.
• Verification and validation challenges.
Challenges of software engineering
• Rapid technology advancement.
• Increasing customer demands.
• Time limitations.
• Limited infrastructure/resources.
• Conflicts with software testing teams.
Professional Software Development
• The economies of ALL developed nations are dependent on software.
• More and more systems are software controlled ( transportation,
medical, telecommunications, military, industrial, entertainment,)
• Software engineering is concerned with theories, methods and tools
for professional software development.
• Expenditure on software represents a significant fraction of GDP in all
developed countries.
• So software development can be adopted professionally in all sectors.
Software engineering ethics
• Ethics is necessary to make software engineering profession beneficial
and respected.
• In accordance with their commitment to the health, safety and welfare
of public software engineer should adhere to the following principles.
• 1. Public-work consistently with public interest.
• 2. Employer-work consistently with employer interest.
• 3. product-ensure their products should meet high standard.
• 4. Management-provides ethical approach to management.
• 5. Colleagues- fair and supportive to their colleagues.
Software Engineering
• Software engineering encompasses a process, the management of
activities, technical methods, and use of tools to develop software
products.
• IEEE definition of software engineering (1) the application of a
systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of
engineering to software. (2) The study of approaches as in (1).

30
A Layered Technology
tools

methods

process model

a “quality” focus

31
A Layered Technology
• Process-defines a framework that must be established for effective
delivery of S/W.
• Methods -provide the technical “how to” for building S/W (a broad
array of tasks that include communication, req. analysis, design,
coding, testing and support)
• Tools -provide automated or semi-automated support for the process
and the methods.
• “The bedrock that supports software engineering is a quality focus.”

32
Process
• A process is defined as a series of actions in which one or more inputs
are used to produce one or more outputs.

33
Process-A Generic view
• Process defines a framework for a set of Key Process Areas (KPAs) that
must be established for effective delivery of software engineering
technology.
• This establishes the context in which technical methods are applied,
work products such as models, documents, data, reports, forms, etc.
are produced, milestones are established, quality is ensured, and
change is properly managed.

34
1.4 Process Activities
• Software development is the process of developing software through
successive phases in an orderly way.
• The process not only includes the writing of code but also the
preparation of requirements and objectives, the design of what is to
be coded and confirmation that what is developed has meet
objectives.
• The fundamental and orderly phases of software development are:
Requirement analysis and specifications, Design and specification,
coding and module testing, integration and system testing and
delivery and maintenance.
Process Activities
• i) Requirement analysis and specifications:-After defining the precise
cost and benefits of a software system through feasibility study
analysis, this phase identifies and documents the exact requirements
of the system.
• ii)Design and specification:- the specified requirement [from phase i) ]
are given final design. It can be splitted into two sub phases;
architectural or high level deign (deals with modules and structures)
and detailed design (deals with interactions and data flows).
Process Activities
• iii) Coding and module testing:-in this phase we produce the actual
code for development. Development of prototypes and module test
are done (i.e. unit testing is done at this level)
• iv) integration and system testing:-All modules tested individually are
then integrated to make a complete system and perform test on
whole system.
• V) Delivery and maintenance:- After all the tests are positive (okay),
the system is delivered to the customer and enters the maintenance
phase. Here new changes and enhancements needs to be
implemented.
 1.5 Software Process Model/Framework
• A process framework establishes the foundation for a complete software
process by identifying a small number of framework activities that are
applicable to all software projects, regardless of  size or complexity.
• It also includes a set of umbrella activities that are applicable across the
entire software process.
• The framework activities are applicable to all projects and all application
domains, and they are a template for every process model.

38
 Generic Process Framework
• Communication:- involves heavy communication with the customer (and
other stakeholders) and encompasses requirements gathering.
• Planning:- Describes the technical tasks to be conducted, the risks that are
likely, resources that will be required, the work products to be produced and
a work schedule.
• Modeling:- encompasses the creation of models that allow the developer
and customer to better understand S/W requirements and the design that
will achieve those requirements.
• Construction:- combines code generation and the testing required
uncovering errors in the code.
• Deployment:- deliver the product to the customer who evaluates the
delivered product and provides feedback.
39
Umbrella Activities
• S/W project tracking and control: allows the team to assess progress
against the project plan and take necessary action to maintain
schedule.
• Risk Management: Assesses the risks that may affect the outcome of
the project or the quality.
• Software quality assurance: defines and conducts the activities
required to ensure software quality.
• Formal Technical Review: uncover and remove errors before they
propagate to the next action.

40
Umbrella Activities
• Measurement: defines and collects process, project, and product
measures that assist the team in delivering S/W that meets
customers’ needs.
• Software configuration management: Manages the effect of change
throughout the S/W process
• Reusability management: defines criteria for work product reuse.
• Work product preparation and production: encompasses the
activities required to create work products such as models,
documents, etc.

41
 Process Model
• A process model is a description of the sequence of activities carried out
in an SE project, and the relative order of these activities.
• It provides a fixed generic framework that can be tailored to a specific
project.
• A software process model is an abstract representation of a process that
presents a description of a process from some particular perspective.
• There are hundreds of different process models but most are minor
variations on a small number of basic models.

42
Process Model
• Waterfall Model
• Incremental Model
• Evolutionary Model
• Iterative Development
• The Unified Process
• Agile Process

43
Waterfall Model

44
 Waterfall Model
• first Process Model and it is also referred to as a linear-sequential life
cycle model.  
• very simple to understand and use. 
• each phase must be completed fully before the next phase can begin.
• basically used for the for the project which is small and there are no
uncertain requirements. 
• At the end of each phase, a review takes place to determine if the project
is on the right path and whether or not to continue or discard the project.
• In this model the testing starts only after the development is complete.
• In waterfall model  phases do not overlap.
45
Advantages
• 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.
• 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.

46
 Disadvantages
• Once an application is in the testing stage, it is very difficult to go back
and change something that was not well-thought out in the concept
stage.
• 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.

47
When to use
• This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

48
 Incremental Models
• the whole requirement is divided into various builds so multiple
development cycles take place here, making the life cycle a “multi-
waterfall” cycle. 
• Cycles are divided up into smaller, more easily managed modules and
each module passes through the requirements, design, implementation
and testing phases.
• A working version of software is produced during the first module, so you
have working software early on during the software life cycle.
• Each subsequent release of the module adds function to the previous
release and the process continues till the complete system is achieved.

49
Incremental Models

50
Advantages
• Generates working software quickly and early during the software life
cycle.
• This model is more flexible – less costly to change scope and
requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled
during it’d iteration.

51
Disadvantages
• Needs good planning and design.
• Needs a clear and complete definition of the whole system before it
can be broken down and built incrementally.
• Total cost is higher than waterfall.

52
When to use
• This model can be used when the requirements of the complete
system are clearly defined and understood.
• Major requirements must be defined; however, some details can
evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.

53
 Evolutionary Model
• Evolves an initial implementation with user feedback → multiple versions until
the final version.
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

54
 Evolutionary Model
• Two fundamental types:
• Exploratory Development:
• Explores the requirement and delivers a final system.
• Starts with something that is understood and evolves by adding new features proposed by
customers.
• Throwaway prototyping:
• Understands the requirement and develop a better requirement definition.
• Experimenting with poorly understood requirement.
• Usually develops User Interface (UI) with minor or no functionality.

55
Evolutionary Model: Advantages
• Customer involvement in the process:
• More likely to meet the user requirement.
• Early and frequent testing:
• More likely to identify problems.
• Lower risk.
• Suitable for small to medium sized system.

56
 Evolutionary Model: Problems
• The process is intangible:
• No regular, well-defined deliverables.
• The process is unpredictable:
• Hard to manage, e.g., scheduling, workforce allocation, etc.
• Systems are poorly structured:
• Continual, unpredictable change tends to corrupt the software structure.
• Can cause major problems during software evolution.
• Systems may not even converge to a final version.
• No strategy to gauge or solve this problem.

57
Iterative Development
• An iterative life cycle model does not attempt to start with a full
specification of requirements.
• Instead, development begins by specifying and implementing just part
of the software, which can then be reviewed in order to identify
further requirements.
• This process is then repeated, producing a new version of the
software for each cycle of the model.

58
Iterative Development

59
Iterative Development
• In iterative model we are building and improving the product step by
step. Hence we can track the defects at early stages. This avoids the
downward flow of the defects.
• In iterative model we can get the reliable user feedback. When
presenting sketches and blueprints of the product to users for their
feedback, we are effectively asking them to imagine how the product
will work.
• In iterative model less time is spent on documenting and more time is
given for designing.

60
Disadvantages of Iterative model
• Each phase of an iteration is rigid with no overlaps
• Costly system architecture or design issues may arise because not all
requirements are gathered up front for the entire lifecycle

61
When to use iterative model
• Requirements of the complete system are clearly defined and
understood.
• When the project is big.
• Major requirements must be defined; however, some details can
evolve with time.

62
 Spiral Model
• Formalize the Evolutionary Model and avoid the management shortcomings.

63
 Spiral Model
• Process is represented as a spiral rather than as a sequence of activities
with backtracking.
• Each loop = One Iteration = A process phase.
• Each Loop passes through 4 quadrants (90°):
• Objective Setting.
• Risk Assessment and Reduction.
• Development and Validation.
• Planning.
• As loops move away from center → Time and Cost increase.

64
 Spiral Model
• Risk Driven:
• Explicitly identify risks for each iteration.
• Address the highest perceived risk.
• Does not prescribe a fix process:
• Project Manager chooses the appropriate activity for each iteration base on
progress and perceived risk.
• Flexible:
• May resemble other process model depends on needs.

65
Rational Unified Process
• The RUP identifies four discrete development phases in the software
process that are not equated with process activities. The phases in
the RUP are more closely related to business rather than technical
concerns.
• The phases in the RUP are: Inception, Elaboration, construction and
Transistion.
Rational Unified Process
1. Inception. The goal of the inception phase is to establish a business case for the
system, identify all external entities, i.e. people and systems that will interact
with the system and define these interactions. Then this information is used to
assess the contribution that the system makes to the business.
2. Elaboration. The goals of the elaboration phase are to develop an understanding
of the problem domain, establish an architectural framework for the system,
develop the project plan and identify key project risks.
3. Construction. The construction phase is essentially concerned with system
design, programming and testing.
4. Transition. The final phase of the RUP is concerned with moving the system from
the development community to the user community and making it work in a real
environment.
The V-model of development

Requir ements System System Detailed

specification specification design design

System Sub-system Module and

Acceptance
integration integ ration unit code
test plan
test plan test plan and test

Acceptance System Sub-system

Service
test integ ration test integ ration test

SoftwareEngineering_SRP 68
The V-model of development
• The V-model represents a software process model that may be
considered an extension of the waterfall model.
• The V-model demonstrates the relationships between each phase of
the development life cycle and its associated phase of testing.
• The horizontal and vertical axes represent time and level of
abstraction respectively.
• Similarly to waterfall model the process steps follow each other in a
sequential order but V-model allows the parallel execution of
activities.
Agile Development
• Agile is an iterative approach to project management and software
development that helps teams deliver value to their customers faster
and with fewer headaches.
• Requirements, plans, and results are evaluated continuously so teams
have a natural mechanism for responding to change quickly.
• Development is done through the collaborative effort of self-
organizing and cross-functional teams and their customer(s)/end
user(s).
Agile Methodology
• Agile methodology is a practice that promotes continuous iteration of
development and testing throughout the software development
lifecycle of the project (Both development and testing activities are
concurrent.)
• It emphasizes on four core values:
1. Individual and team interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Difference than other model
• Customer collaboration over contract negotiation i.e. agile principles
require customers to be involved in all phases of the project.
• The Waterfall approach or Traditional methodologies only
allow customers to negotiate before and after the project this used to
result in wastage of both time and resources.
Agile Principles in agile manifesto
• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout
the project.
• Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
Agile Principles in agile manifesto
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing
teams.
• At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
Agile Development Techniques
• While there are a number of different methodologies available, some
of the common ones used are as mentioned below:
• Scrum Methodology
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Lean Software Development
• Kanban
• Crystal
• Dynamic Systems Development Method (DSDM)
Plan Driven and agile development
• Plan-driven software development is a more formal specific approach
to creating an application. Plans are typically generated by the
following: Project broken down into stages/tasks. Each task broken
into its composite activities. Each individual task estimated (perhaps
using metrics)
• Agile approaches to software development consider design and
implementation to be the central activities in the software process.
They incorporate other activities, such as requirements elicitation and
testing, into design and implementation.
Plan Driven Vs. Agile Development
Plan Driven Vs. Agile Development
Most projects include elements of plan-driven and agile processes.
Deciding the balance depends on Technical, human, organizational
issues:
• Is it important to have a very detailed specification and design before
moving to implementation? If so, software engineer probably needs
to use a plan-driven approach.
• Is an incremental delivery strategy, where software engineer delivers
the software to customers and get rapid feedback from them,
realistic? If so, consider using agile methods.
Plan Driven Vs. Agile Development
• How large is the system that is being developed? Agile methods are most
effective when the system can be developed with a small co-located team
who can communicate informally. This may not be possible for large
systems that require larger development teams so a plan-driven approach
may have to be used.
• What type of system is being developed? Plan-driven approaches may be
required for systems that require a lot of analysis before implementation
(e.g. real-time system with complex timing requirements).
• What is the expected system lifetime? Long-lifetime systems may require
more design documentation to communicate the original intentions of the
system developers to the support team.
Plan Driven Vs. Agile Development
• What technologies are available to support system development?
Agile methods rely on good tools to keep track of an evolving design
• How is the development team organized? If the development team is
distributed or if part of the development is being outsourced, then
software engineer may need to develop design documents to
communicate across the development teams.
• Are there cultural or organizational issues that may affect the system
development? Traditional engineering organizations have a culture of
plan-based development, as this is the norm/standard in engineering.
Plan Driven Vs. Agile Development
• How good are the designers and programmers in the development
team? It is sometimes argued that agile methods require higher skill
levels than plan-based approaches in which programmers simply
translate a detailed design into code.
• Is the system subject to external regulation? If a system has to be
approved by an external regulator then software engineer will
probably be required to produce detailed documentation as part of
the system safety case.
1.6 Process Iteration
• Changes are usually unavoidable in all large software projects.
• The system requirements change as organization continuously
responds to the changing environment and conditions.
• Management priorities may change.
• Due to the quick progress in technologies, designs and
implementation will change.
• This means that the process activities are regularly repeated as the
system is reworked in response to change requirements.
Process Iteration
• The following two process models have been designed to support
process iteration:
1. Incremental delivery. The software specification, design and
implementation are broken down into a series of increments that
are each developed in turn.
2. Spiral development. The development of the system spirals
outwards from an initial outline through to the final developed
system.
Assignment 1
• What software development project does waterfall model
recommended for?
• What software development project does waterfall model not
recommended for?
• Explain the reason for software developed by an evolutionary
development are often more difficult to maintain.
• How does RUP support the iterative software process?
• What do you mean by agile? List out the agility principles.
• Differentiate between plan-driven and agile development models.

84
1.7 Computer-aided software
engineering (CASE)
• Computer-aided software engineering (CASE) is the domain
of software tools used to design and implement applications.
• CASE tools are similar to and were partly inspired by computer-
aided design (CAD) tools used for designing hardware products.
• CASE tools are set of software application programs, which are used to
automate SDLC activities.
• CASE tools are used by software project managers, analysts and
engineers to develop software system.
• There are number of CASE tools available to simplify various stages of
Software Development Life Cycle.
CASE Tools
Computer-aided software engineering
• Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.
• Lower Case Tools - Lower CASE tools are used in implementation, testing
and maintenance.
• Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.
• Examples of CASE tools include diagram tools, documentation tools, process
modeling tools, analysis and design tools, system software tools, project
management tools, design tools, prototyping tools, configuration manage
tools, programming tools, Web development tools, testing tools,
maintenance tools, etc.
Software Requirements
• “Any project’s requirements need to be well thought out, balanced
and clearly understood by all involved, but perhaps of most
importance is that they are not dropped or compromised halfway
through the project.”
Software Requirements
• It is a field within software engineering that deals with establishing
the needs of stakeholders that are to be solved by software.
• The IEEE defines a requirement as:
1. A condition or capability needed by a user to solve a problem or
achieve an objective.
2. A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed document.
• A documented representation of a condition or capability as in 1 or 2.
1.8 Functional Requirements
• A functional requirement describes what a software system should do
• functional requirements are the main things that the user expects
from the software
• Ex: if the application is a banking application that application should
be able to create a new account, update the account, delete an
account, etc.
1.8 Non-functional Requirements
• non-functional requirements place constraints on how the system will
do so
• The non-functional requirement elaborates a performance
characteristic of the system.
• Typically non-functional requirements fall into areas such as:
Accessibility, Capacity, Disaster recovery, Efficiency, Effectiveness,
Extensibility, Fault tolerance, Maintainability, Privacy, Portability,
Quality, Reliability, Scalability, etc.
Activity 1
• Suppose you are building a Library Management system software for
your college. Point out the functional and non functional
requirements necessary for the system.
1.9 Requirements engineering process
• It is the process of eliciting (finding, drawing, extracting),
documenting, analyzing, validating and monitoring requirements.
• Different approaches to it exists but whatever we follow, the necessity
is that we have to collect complete, precise and detailed specification
of the system and users.
• It produces one large document, written in natural language and
contains a description of what a system will do but does not describe
how it will do.
Requirement Engineering Process
• Requirement engineering provides the appropriate mechanism for
understanding the customer’s needs, analyzing needs, accessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification and managing the
requirements.
• The processes used for RE vary widely depending on the application
domain, the people involved and the organization developing the
requirements.
Requirement Engineering Process

Fig: Requirement Engineering Process

When we begin it?
• Begin with feasibility(possibility, practicality) study activity which
leads to feasibility study report.
• Feasibility study may lead to the decision that whether the project
need to continue or not.
• If the feasibility study suggests that the project should be developed,
then requirement analysis begin.
Activities in Requirement Engineering Process
• Feasibility study
• Requirement elicitation and analysis
• Requirement Validation
• Requirement documentation
• Requirement Management
1.10 Feasibility study
• It is a short focused study that checks if the system contributes to
organizational objectives, the system can be engineered using current
technology, within time and budget and the system can be integrated
with other systems that are used.
• It aim is to determine what are the current trends and problems and
how will the proposed system help, is new technology and skills are
necessary, what facilities must it supported.
Types of Feasibility study
• Technical feasibility- is it possible to solve the problem using existing
technology?
• Economic feasibility- do the benefits exceed the cost of solving the
problem?
• Operational feasibility- can the system be implemented in the user’s
environment perhaps many constrains such as ethics, union
agreement, government regulations, legal and political issues, etc?
• Organizational feasibility- is the system logical with the organization’s
strategic objectives?
Requirement Elicitation and analysis
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the
application domain, the services that the system should provide and
the system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc. ( i.e. stakeholders)
Problems: Requirement Elicitation and analysis

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system
requirements.
• The requirements change during the analysis process. New
stakeholders may emerge and the business environment change.
1.11 Requirements elicitation and analysis:
Process activities
• Requirements discovery-Interacting with stakeholders to discover
their requirements. Domain requirements are also discovered at this
stage.
• Requirements classification and organization-Groups related
requirements and organizes them into coherent clusters.
• Prioritization and negotiation-Prioritizing requirements and resolving
requirements conflicts.
• Requirements documentation-Requirements are documented and
input into the next round.
Requirement Gathering methods
• Interview
• Questionnaire
• Survey
• Case study
• Internet research
• etc.
1.12 Requirement Validation
• Concerned with demonstrating that the requirements define the
system that the customer really wants.
• Requirements error costs are high so validation is very important
(Fixing a requirements error after delivery may cost up to 100 times
the cost of fixing an implementation error).
Requirements checking for Validity

• Validity->Does the system provide the functions which best support

the customer’s needs?
• Consistency->Are there any requirements conflicts?
• Completeness->Are all functions required by the customer included?
• Realism=>Can the requirements be implemented given available
budget and technology?
• Verifiability->Can the requirements be checked?
Requirement documentation
• SRS document-output of requirement analysis.
• SRS contains functional and non functional requirements only.
• It does not offer design suggestions, possible solutions to technology
or business issues or any other information other than what the
development team understands the customer system requirements.
Requirement Documentation
• SRS document
1.13 Requirements management
• It is the process of managing changing requirements during the
requirements engineering process and system development.
• Requirements management involves communication between the
project team members and stakeholders, and adjustment to
requirements changes throughout the course of the project.
• To prevent one class of requirements from overriding another,
constant communication among members of the development team
is critical.
Requirement Management
• The activities in requirement management are:
• Recognizing the need for change in the requirements
• Establishing a relationship amongst stakeholders and involving them in the
requirements engineering process
• Identifying and tracking requirements attributes.
• Requirements management enables the development team to
identify, control, and track requirements and changes that occur as
the software development process progresses. 
1.14 User requirements
• User requirements, often referred to as user needs, describe what
the user does with the system, such as what activities that users must
be able to perform. 
• User requirements are generally documented in a User
Requirements Document (URD) using narrative text.
1.15 System Requirements
• System requirements are the required specifications a device must
have in order to use certain hardware or software.
• For example, a computer may require a specific I/O port to work with
a peripheral device.
• A smartphone may need a specific operating system to run a
particular app.
1.16 Interface Specification
• A user interface specification (UI specification) is a document that
captures the details of the software user interface into a written
document.
• The specification covers all possible actions that an end user may
perform and all visual, auditory and other interaction elements.
• Interface specifications provide the standardized mechanism in which
subsystems can effectively communicate with each other and enable
them to operate as independent modules that, when collectively
implemented, support the entire CM technical reference model.
Model Questions: Assignment 1 continue
• What do you mean by computer-aided software engineering? Explain
at least one case tool used in different phases of life cycle.
• Differentiate between functional and non functional requirements
with a common example. (except Library management system)
• Explain requirement engineering process in detail.
• Explain SRS document with its importance in software development.