Software Development

Processes

1
What is a Software Process?
• Software Process is a coherent set of activities for specifying,
designing, implementing and testing software systems.
• There are many different software processes but all involve:
• Specification – defining what the system should do
• Design and implementation – defining the organization of
the system and implementing the system
• Validation – checking that it does what the customer
wants
• Evolution – changing the system in response to changing
customer needs.
2
Program vs. Software

• Software is more than programs.

• Any program is a subset of software, and it becomes
software only if documentation & operating procedures
manuals are prepared.
• There are three components of the software

3
4
• Program: Program is a combination of source code & object
code.
• Documentation: Documentation consists of different types
of manuals.
• Examples of documentation manuals are: Data Flow
Diagram, Flow Charts, ER diagrams, etc.
• Operating Procedures: Operating Procedures consist of
instructions to set up and use the software system and
instructions on how react to the system failure.
• Example of operating system procedures manuals is:
installation guide, Beginner's guide, reference guide,
system administration guide, etc.
5
6
7
Software Development Life Cycle
(SDLC)
• SDLC represents the process of developing software.
• SDLC framework includes the following steps:

8
9
The stages of SDLC are as follows:
Stage1: Planning and requirement analysis

• Requirement Analysis is the most important and necessary

stage in SDLC.
• The senior members of the team perform it with inputs from
all the stakeholders and domain experts in the industry.
• Planning for the quality assurance requirements and
identifications of the risks associated with the projects is also
done at this stage.

10
The stages of SDLC are as follows:
Stage1: Planning and requirement analysis

• Business analyst and Project organizer set up a meeting with

the client to gather all the data like
• what the customer wants to build,
• who will be the end user,
• what is the objective of the product.
• Before creating a product, a core understanding or
knowledge of the product is very necessary.

11
• For Example, A client wants to have an application which
concerns money transactions.
• In this method, the requirement has to be precise like
• what kind of operations will be done,
• how it will be done,
• in which currency it will be done, etc.
• Once the required function is done, an analysis is complete with
auditing the feasibility of the growth of a product.
• In case of any ambiguity, a signal is set up for further discussion.
• Once the requirement is understood, the SRS (Software
Requirement Specification) document is created.
• The developers should thoroughly follow this document and also
should be reviewed by the customer for future reference.
12
The stages of SDLC are as follows:
Stage2: Defining Requirements

• Once the requirement analysis is done, the next stage is to

certainly represent and document the software
requirements and get them accepted from the project
stakeholders.
• This is accomplished through "SRS"- Software Requirement
Specification document which contains all the product
requirements to be constructed and developed during the
project life cycle.

13
Requirement Engineering
• Requirements engineering (RE) refers to the process of
defining, documenting, and maintaining requirements in the
engineering design process.
• Requirement engineering provides the appropriate
mechanism to understand
• what the customer desires
• analyzing the need and
• assessing feasibility
• validating the specifications and
• managing the requirements as they are transformed into
a working system.
14
• Thus, requirement engineering is the disciplined application
of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its
associated constraints.

15
Requirement Engineering Process
• Feasibility Study
• Requirement Elicitation and Analysis
• Software Requirement Specification
• Software Requirement Validation
• Software Requirement Management

16
17
 Feasibility Study

• The objective behind the feasibility study is to create the

reasons for developing the software that is
• acceptable to users,
• flexible to change and
• conformable to established standards.

18
 Types of Feasibility
• Technical Feasibility –
• Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements
within the time and budget.
• Operational Feasibility –
• Evaluates whether or not your organization is able to
complete this project.
• This includes staffing requirements, organizational
structure, and any applicable legal requirements.
• Economic Feasibility –
• Economic feasibility decides whether the necessary
software can generate financial profits for an
organization. 19
• When the client approaches the organization for getting the
desired product developed, it comes up with rough idea
about
• what all functions the software must perform and
• which all features are expected from the software.
• Referencing to this information, the analysts does a detailed
study about whether the desired system and its functionality
are feasible to develop.
• This feasibility study is focused towards goal of the
organization.

20
• This study analyzes whether the software product can be practically
materialized in terms of
• implementation,
• contribution of project to organization,
• cost constraints and
• as per values and objectives of the organization.
• It explores technical aspects of the project and product such as
• usability,
• maintainability,
• productivity and
• integration ability.
• The output of this phase should be a feasibility study report that
should contain adequate comments and recommendations for
management about whether or not the project should be
undertaken. 21
 Requirement Elicitation and Analysis

• Requirements elicitation is the process of gathering and

defining the requirements for a software system.
• The goal of requirements elicitation is to ensure that the
software development process is based on a clear and
comprehensive understanding of the customer needs and
requirements.
• Requirements elicitation involves the
• identification
• collection
• analysis and
• refinement of the requirements for a software system. 22
• It is a critical part of the software development life cycle and
is typically performed at the beginning of the project.
• Requirements elicitation involves stakeholders from different
areas of the organization, including
• business owners,
• end-users, and
• technical experts.
• The output of the requirements elicitation process is a set of
clear, concise, and well-defined requirements that serve as
the basis for the design and development of the software
system.
23
• This is also known as the gathering of requirements.
• The requirements are analyzed to identify inconsistencies,
defects, omission, etc.
• Requirements elicitation is perhaps the
• most difficult,
• most error-prone and
• most communication intensive software development.
• It can be successful only through an effective customer-
developer partnership.
• It is needed to know what the users really need.

24
 Problems of Elicitation and Analysis

• Getting all, and only, the right people involved.

• Stakeholders often don't know what they want.
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system
requirements.

25
26
 Requirements elicitation Methods

• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case Approach

27
• The success of an elicitation technique used depends on the
maturity of the
• analyst,
• developers,
• users, and
• the customer involved.

28
 Interviews
• Objective of conducting an interview is to understand the customer’s
expectations from the software.
• It is impossible to interview every stakeholder hence representatives
from groups are selected based on their expertise and credibility.
• Interviews maybe be open-ended or structured.
• In open-ended interviews
• there is no pre-set agenda.
• Context free questions may be asked to understand the problem.
• In structured interview,
• agenda of fairly open questions is prepared.
• Sometimes a proper questionnaire is designed for the interview.
29
 Brainstorming Sessions
• It is a group technique
• It is intended to generate lots of new ideas hence providing a
platform to share views
• A highly trained facilitator is required to handle group bias
and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.

30
 Facilitated Application Specification
Technique
• It’s objective is to bridge the expectation gap – difference between
• what the developers think they are supposed to build and
• what customers think they are going to get.
• A team oriented approach is developed for requirements gathering.
• Each attendee is asked to make a list of objects that are-
• Part of the environment that surrounds the system
• Produced by the system
• Used by the system
• Each participant prepares his/her list, different lists are then
combined, redundant entries are eliminated, team is divided into
smaller sub-teams to develop mini-specifications and finally a draft of
specifications is written down using all the inputs from the meeting. 31
 Quality Function Deployment

• In this technique customer satisfaction is of prime concern,

hence it emphasizes on the requirements which are valuable
to the customer.
• 3 types of requirements are identified –
• Normal requirements –
• In this the objective and goals of the proposed software
are discussed with the customer.
• Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc

32
• Expected requirements –
• These requirements are so obvious that the customer
need not explicitly state them.
• Example – protection from unauthorized access.
• Exciting requirements –
• It includes features that are beyond customer’s
expectations and prove to be very satisfying when
present.
• Example – when unauthorized access is detected, it
should backup and shutdown all processes.

33
• The major steps involved in this procedure are –
• Identify all the stakeholders, eg. Users, developers,
customers etc
• List out all requirements from customer.
• A value indicating degree of importance is assigned to
each requirement.
• In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off

34
 Use Case Approach

• This technique combines text and pictures to provide a

better understanding of the requirements.
• The use cases describe the ‘what’, of a system and not
‘how’. Hence, they only give a functional view of the system.
• The components of the use case design includes three major
things – Actor, Use cases, use case diagram.

35
 Actor

• It is the external agent that lies outside the system but

interacts with it in some way.
• An actor maybe a person, machine etc.
• It is represented as a stick figure.
• Actors can be primary actors or secondary actors.
• Primary actors – It requires assistance from the system to
achieve a goal.
• Secondary actor – It is an actor from which the system
needs assistance.

36
 Use cases
• They describe the sequence of interactions between actors
and the system.
• They capture who(actors) do what(interaction) with the
system.
• A complete set of use cases specifies all possible ways to use
the system.

37
 Use case diagram
• Use case diagram –
• A use case diagram graphically represents what happens
when an actor interacts with a system.
• It captures the functional aspect of the system.
• A stick figure is used to represent an actor.
• An oval is used to represent a use case.
• A line is used to represent a relationship between an actor
and a use case.

38
 Requirement Elicitation Process

• Requirement elicitation process can be depicted using the

following diagram:

39
• Requirements gathering –
• The analyst discuss with the client and end users and
know their expectations from the software.
• Organizing Requirements –
• The analyst prioritize and arrange the requirements in
order of importance, urgency and convenience.
• Negotiation & discussion –
• If requirements are ambiguous or there are some conflicts
in requirements of various stakeholders, if they are, it is
then negotiated and discussed with stakeholders.
• Requirements may then be prioritized and reasonably
compromised.
40
• Documentation –
• All formal & informal, functional and non-functional
requirements are documented and made available for
next phase processing.

41
 Software Requirements Characteristics
• Gathering software requirements is the foundation of the
entire software development process.
• Hence they must be clear, correct and well-defined.
• A complete Software Requirement Specifications must be:

42
• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source
43
 Types of software requirements

• Broadly software requirements should be categorized in two

categories:
• Functional Requirements
• Non-Functional Requirements

44
• Functional Requirements
• Requirements, which are related to functional aspect of
software fall into this category.
• They define functions and functionality within and from
the software system.
• Examples -
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate
rights.
• Should fulfil business rules and administrative functions.

45
• Non-Functional Requirements
• Requirements, which are not related to functional aspect
of software, fall into this category.
• They are implicit or expected characteristics of software,
which users make assumption of.
• Non-functional requirements include -
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility 46
• Requirements are categorized logically as
• Must Have : Software cannot be said operational without
them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with
these requirements.
• Wish list : These requirements do not map to any
objectives of software.
• While developing software, ‘Must have’ must be
implemented, ‘Should have’ is a matter of negotiation with
stakeholders, whereas ‘could have’ and ‘wish list’ can be kept
for software updates.
47
• User Interface requirements
• UI is an important part of any software or hardware or
hybrid system.
• A software is widely accepted if it is -
• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

48
• User acceptance majorly depends upon how user can use the
software.
• UI is the only way for users to perceive the system.
• A well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface.
• Otherwise the functionalities of software system can not be used in
convenient way.
• A system is said be good if it provides means to use it efficiently.
• User interface requirements are -

49
• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings.
50
 Software Requirement Specification
• Software requirement specification is a kind of document
which is created by a software analyst after the
requirements collected from the various sources - the
requirement received by the customer written in ordinary
language.
• It is the job of the analyst to write the requirement in
technical language so that they can be understood and
beneficial by the development team.

51
• The production of the requirements stage of the software
development process is Software Requirements
Specifications (SRS) (also called a requirements document).
• This report lays a foundation for software engineering
activities and is constructing when entire requirements are
elicited and analyzed.
• SRS is a formal report, which acts as a representation of
software that enables the customers to review whether it
(SRS) is according to their requirements.
• Also, it comprises user requirements for a system as well as
detailed specifications of the system requirements.

52
• The SRS is a specification for a specific software product,
program, or set of applications that perform particular
functions in a specific environment.
• It serves several goals depending on who is writing it.
• First, the SRS could be written by the client of a system.
• Second, the SRS could be written by a developer of the
system.
• The two methods create entirely various situations and
establish different purposes for the document altogether.
• The first case, SRS, is used to define the needs and
expectation of the users.
• The second case, SRS, is written for various purposes and
serves as a contract document between customer and
developer. 53
 Characteristics of good SRS
• Concise:
• The SRS report should be concise and at the same time,
unambiguous, consistent, and complete.
• Verbose and irrelevant descriptions decrease readability
and also increase error possibilities.

54
• Structured:
• It should be well-structured.
• A well-structured document is simple to understand and
modify.
• In practice, the SRS document undergoes several revisions
to cope up with the user requirements.
• Often, user requirements evolve over a period of time.
• Therefore, to make the modifications to the SRS
document easy, it is vital to make the report well-
structured.

55
• Black-box view:
• It should only define what the system should do and
refrain from stating how to do these.
• This means that the SRS document should define the
external behavior of the system and not discuss the
implementation issues.
• The SRS report should view the system to be developed as
a black box and should define the externally visible
behavior of the system.
• For this reason, the SRS report is also known as the black-
box specification of a system.

56
• Conceptual integrity:
• It should show conceptual integrity so that the reader can
merely understand it.
• Response to undesired events:
• It should characterize acceptable responses to unwanted
events.
• These are called system response to exceptional
conditions.

57
• Verifiable:
• All requirements of the system, as documented in the SRS
document, should be correct.
• This means that it should be possible to decide whether
or not requirements have been met in an implementation.

58
 Software Requirement Validation
• After requirement specifications developed, the
requirements discussed in this document are validated.
• The user might demand illegal, impossible solution or
experts may misinterpret the needs.
• Requirements can be the check against the following
conditions -
• If they can practically implement
• If they are correct and as per the functionality
• If there are any ambiguities
• If they are full
• If they can describe
59
 Requirements Validation Techniques

• Requirements reviews/inspections:
• systematic manual analysis of the requirements.
• Prototyping:
• Using an executable model of the system to check
requirements.
• Test-case generation:
• Developing tests for requirements to check testability.
• Automated consistency analysis:
• checking for the consistency of structured requirements
descriptions.
60
 Software Requirement Management
• Requirement management is the process of managing
changes during the requirements engineering process and
system development.
• New requirements emerge during the process as business
needs a change, and a better understanding of the system is
developed.
• The priority of requirements from different viewpoints
changes during development process.
• The business and technical environment of the system
changes during the development.
61
Next: Software Design

62