Software Engineering Unit 2

Software Engineering Specification (SRS)

1. Requirements engineering Process:
Requirements engineering is the process of identifying, eliciting, analysing, specifying,
validating, and managing the needs and expectations of stakeholders for a software system.
The requirement’s engineering process is an iterative process that involves several steps,
including:
Requirements Elicitation: This is the process of gathering information about the needs and
expectations of stakeholders for the software system. This step involves interviews, surveys,
focus groups, and other techniques to gather information from stakeholders.
Requirements Analysis: This step involves analysing the information gathered in the
requirements elicitation step to identify the high-level goals and objectives of the software
system. It also involves identifying any constraints or limitations that may affect the
development of the software system.
Requirements Specification: This step involves documenting the requirements identified in
the analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
Requirements Validation: This step involves checking that the requirements are complete,
consistent, and accurate. It also involves checking that the requirements are testable and that
they meet the needs and expectations of stakeholders.
Requirements Management: This step involves managing the requirements throughout the
software development life cycle, including tracking, and controlling changes, and ensuring
that the requirements are still valid and relevant.
1.1 Tools involved in requirement engineering:
 observation report
 Questionnaire (survey, poll)
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Role playing
 Prototyping
1.2 Requirements Engineering Process consists of the following main steps:
 Requirements elicitation
 Requirements specification
  Requirements verification and validation
 Requirements management
1.2.1 Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of same type, standards, and other stakeholders of the project.
The techniques used for requirements elicitation include interviews, brainstorming, task
analysis, Delphi technique, prototyping, etc.
There are several techniques that can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.
o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
 o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

1.2.2 Requirements specification:

This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation process. The models used at
this stage include ER diagrams, data flow diagrams (DFDs), function decomposition
diagrams (FDDs), data dictionaries, etc.
There are several types of requirements that are commonly specified in this step,
including:
 Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
 Non-Functional Requirements: These describe how well the software system should
do it. They specify the quality attributes of the system, such as performance,
reliability, usability, and security.
 Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.
 Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.
1.2.3 Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly implements a
specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
 The requirements should be consistent with all the other requirements i.e.no two
requirements should conflict with each other.
 The requirements should be complete in every sense.
 The requirements should be practically achievable.
Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
 o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

1.2.4 Requirements Management:

Requirement management is the process of analysing, documenting, tracking, prioritizing,
and agreeing on the requirement and controlling the communication to relevant stakeholders.
This stage takes care of the changing nature of requirements. It should be ensured that the
SRS is as modifiable as possible to incorporate changes in requirements specified by the end
users at later stages too. Being able to modify the software as per requirements in a
systematic and controlled manner is an extremely important part of the requirements
engineering process.

Software Requirements: Largely software requirements must be categorized into two

categories:
1. Functional Requirements: Functional requirements define a function that a system
or system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.
Requirement reviews in Software Development
Requirements are mandatory in terms of software development. Requirements are the basics
that take forward the development procedure. Requirements enhance the existing project to a
different level. The software cannot progress without the participation of user input. User
input like feedback and product review comes as the major requirements in the development
work.
In short, Requirement review is the practice of scanning the software errors to make the
industry user-friendly for all.
Importance of performing requirement review:
 The performance of requirement review helps to radiate the precise and correct data to
the consumers and users.
 It helps to have a quick tour of the Existing project to see whether or not it is going in
the right direction.
 It helps to provide practical instructions and helps make decisions accordingly.
Methods of performing requirement review:
1.Team consultation:
Suggestion matters also matter the way of performance. Teamwork goes hand in hand. When
there are people to offer suggestions, give appropriate guidelines, and supervise in a team.
There is no doubt about the project getting mismanaged. Reaching out to the team/individual
who has better insights into requirement review works the best way.
2.Understanding the user’s requirement:
Recognize the user’s needs and go all out in understanding them. Requirements keep on
changing with time. So, when you have collected a list of things that a user requires in the
current time. There you found a way to go about it. To get exact information on their
requirements, Asking for feedback is Important.
3. Finding measures to software problem:
The occurrence of software problems is predictable. Errors and defects are bound to take
place in software development. In this context, Rather than making a fuss about the
Problems, developers should find solutions to satisfy the requirements. The requirement
review not only meets the expectations of users but also the standard of the entire industry.
Advantages of performing requirement reviews:
 Requirement reviews accord the developers a motive and structure to carry out the
project further.
 Group collaboration is the highlight. Group work saves time.
 Therefore, the developers can utilize the saved time in rechecking and reconfirming
the processing work to take it ahead.
Disadvantages of performing requirement reviews:
  Lack of attention acts as a hindrance. When a team does not listen to each other in a
meeting room because of disagreement on matters, it emerges as a sign of
unprofessional and uncoordinated work.
 At times, the Review cannot be accurate. So, If you fail in assembling the precise
information, it can be an obstacle for the developers and the industry.

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.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.
Aim of feasibility study:
 The overall objective of the organization is covered and contributed by the system or
not.
 The implementation of the system be done using current technology or not.
 Can the system be integrated with the other system which are already exist
Feasibility Study Process:
The below steps are carried out during entire feasibility analysis.
1. Information assessment
2. Information collection
3. Report writing
4. General information
Importance of Feasibility Study
 It prevents you from committing, investing your resources and capital for an
impractical project.
 It might discover new ideas that might completely change the scope of your software.
 Improves the confidence of the team to concentrate on their project.
 Validate the need for the software.
  Estimates the risk involved in developing the software and analysed if they can be
minimized.
Benefits of Feasibility Study
 It increases the focus of the software development team.
 The software developer team may come across new opportunities.
 Confirms the developer team whether to accept the software project or not.
 Helps in evaluating the success rate of the software.

Cost Benefit Analysis:

In developing cost estimates for a system, we need to consider some of cost elements. Some
elements among them are hardware, personnel, facility, operating and supply cost. The
following are the cost factors:
1. Hardware cost
Hardware cost includes actual purchase and peripherals (external devices) that are
connected to computer. For example, printer, disk drive etc. Actually, finding actual
cost of hardware is generally more difficult especially, when system is shared by
various users so as to compared to a system which dedicated stand alone . In some
case, best way is to treat it as operating cost.
2. Personnel costs
Personnel costs includes EDP staff salaries and benefits as well as pay for those who
are involved in process of development of system. Cost occurred during development
of system which are onetime costs and are also called development cost. Once system
is installed, cost of operating and maintaining system becomes recurring cost that one
has to pay very frequently based on requirement.
3. Facility cost
Facility cost is amount of money that is spent in preparation of a site that is physical
where application or computer will be in operation. This includes wiring, flooring,
lighting and air conditioning. These costs are treated as one- time costs and are
included into overall cost estimate of candidate system.
4. Operating costs
These includes all costs associated with day-to-day(everyday) operation of system and
amount depends on number of shifts, nature of applications. There are various ways
of covering operating costs. One approach is to treat operating costs as an overhead.
Another approach is to charge money from each authorized user for amount of
processing they require from system.
5. Supply Cost:
 Supply cost are variable costs that increase with increased use of paper, disks and like.
They should be estimated and included in overall cost of system.
Cost benefit Analysis based on Cost:
1. Direct/Tangible cost: A tangible cost is a quantifiable cost related to an
identifiable source or asset. Tangible costs can be directly connected to a material
item used in production or to conduct business operations. A tangible cost is the
money paid to a new employee to replace an old one.
Tangible costs represent expenses that are clearly tied to the item generating the
expense. Some examples of tangible costs include:
 Paying employee wages
 Inventory
 Computer systems
 Assets such as equipment, land, or a new factory
 Renting or leasing equipment
2. Indirect / Intangible Cost: An intangible cost consists of a subjective value placed
on a circumstance or event to quantify its impact. Although intangible costs are more
difficult to quantify, they have a real, identifiable source.
Intangible costs can include:
 A fall in employee morale
 Damage to a company's reputation or brand
 Customer dissatisfaction
 Loss of intellectual capital following employee layoffs
Cost benefit Analysis based on Benefits:
1. Tangible Benefits: Tangible benefits are all those benefits that are quantifiable and
measurable. Simply put, they are project benefits that can be assigned a monetary
value, the number of labour hours, or other specific metrics.
Therefore, the defining factor is whether a benefit includes measurable objective
evidence.
some practical examples of tangible benefits of a project:
 Increased turnover;
 Savings in resource costs;
 Savings in hardware costs;
 Increased productivity;
 Improved quality,
  Reduced production costs,
 Reduced error rate,
 An improved customer service,
 Increased customer retention rate.

2. Intangible Benefits: An intangible benefit is a benefit that cannot be calculated in

dollars or is difficult to quantify or measure. Intangible benefits are marked by their
non-physicality and their distinctness from other benefits. Some characteristics of
intangible benefits are:
 Intangible benefits can change over time.
 Intangible benefits are very difficult to predict.
 Intangible benefits are not monetary, and so are not included in a budget or financial
statement.
 Intangible benefits are not material, meaning that they are usually not physical
property.

Data Flow Diagrams:

 A Data Flow Diagram (DFD) is a traditional visual representation of the information
flows within a system
 It shows how data enters and leaves the system, what changes the information, and
where data is stored.
 The objective of a DFD is to show the scope and boundaries of a system as a whole. It
may be used as a communication tool between a system analyst and any person who
plays a part in the order that acts as a starting point for redesigning a system. The
DFD is also called as a data flow graph or bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in
a DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only one is taken. This implies
an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:

Rules for Data Flow Diagram

 Data cannot flow between two entities. –
Data flow must be from entity to a process or a process to an entity. There can be
multiple data flows between one entity and a process.
 Data cannot flow between two data stores
Data flow must be from data store to a process or a process to a data store. Data flow
can occur from one data store to many processes.
 Data cannot flow directly from an entity to data store –
Data Flow from entity must be processed by a process before going to data store and
vice versa.

 Two data flows cannot cross each other.

 All the process in the system must be linked to minimum one data store or any other
process.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction.
Infact, DFDs may be partitioned into levels that represent increasing information flow
and functional detail.
0-level DFD
 It is also known as fundamental system model, or context diagram represents the
entire software requirement as a single bubble with input and output data denoted by
incoming and outgoing arrows.

1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple

bubbles/processes. In this level, we highlight the main objectives of the
system and breakdown the high-level process of 0-level DFD into
subprocesses.
2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning.
DFD for Library Management System
Level 0 DFD –

Level 1 DFD
Difference between Flowchart and Data Flow Diagram:
Sr. Flowchart
no.
1 The main objective is to represent the
flow of control in the program.
2 It has only a single type of arrow is
used to show the control flow in the
flow chart.
3 It is the view of the system at a lower
level.
4 Three symbols represent a Flowchart.
Data Flow Diagram
The main objective is to represent the
processes and data flow between them.
It defines the flow and process of data
input, data output, and storing data.
It is the view of the system at a high level.
Five symbols represent a DFD

5 It deals with the physical aspect of the
action.
6 It shows how to make the system
function.
7 It is not very suitable for a complex
system.
8 Flowchart types are System flowchart,
Data flowchart,
Document flowchart, and Program
flowchart.
It deals with the logical aspect of the
action.
It defines the functionality of the system.
It is used for complex systems.
DFD types are Logical DFD and Physical
DFD.

Entity-Relationship Diagrams
ER-modelling is a data modelling method used in software engineering to produce a
conceptual data model of an information system. Diagrams created using this ER-modelling
method are called Entity-Relationship Diagrams or ER diagrams or ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.
Components of an ER Diagrams
1. Entities:
An entity can be either a living or non-living component.
It showcases an entity as a rectangle in an ER diagram.
For example, in a student study course, both the student and the course are entities.

 Weak Entity:
An entity that makes reliance over another entity is called a weak entity.
You showcase the weak entity as a double rectangle in ER Diagram.
In the example below, school is a strong entity because it has a primary key
attribute - school number. Unlike school, the classroom is a weak entity because it
does not have any primary key and the room number here acts only as a
discriminator.

2. Attributes:
An attribute exhibits the properties of an entity.
You can illustrate an attribute with an oval shape in an ER diagram.
 Key Attribute:
Key attribute uniquely identifies an entity from an entity set.
It underlines the text of a key attribute.
For example: For a student entity, the roll number can uniquely identify a
student from a set of students.

 Composite Attribute:
An attribute that is composed of several other attributes is known as a
composite attribute.
An oval showcases the composite attribute, and the composite attribute oval is
further connected with other ovals.

 Multivalued Attribute:
Some attributes can possess over one value, those attributes are called
multivalued attributes.
The double oval shape is used to represent a multivalued attribute.

 Derived Attribute:
An attribute that can be derived from other attributes of the entity is known as
a derived attribute.
In the ER diagram, the dashed oval represents the derived attribute.
3. Relationships:
The diamond shape showcases a relationship in the ER diagram.
It depicts the relationship between two entities.
In the example below, both the student and the course are entities, and study is the
relationship between them.

 One-to-One Relationships:
When a single element of an entity is associated with a single element of
another entity, it is called a one-to-one relationship.
For example, a student has only one identification card and an identification
card is given to one person.

 One-to-Many Relationships:
When a single element of an entity is associated with more than one element
of another entity, it is called a one-to-many relationship
For example, a customer can place many orders, but an order cannot be placed
by many customers.

 Many-to-One Relationships:
When more than one element of an entity is related to a single element of
another entity, then it is called a many-to-one relationship.
For example, students must opt for a single course, but a course can have
many students.
  Many-to-Many Relationships:
When more than one element of an entity is associated with more than one
element of another entity, this is called a many-to-many relationship
For example, you can assign an employee to many projects and a project can
have many employees.

Advantages
1. SIMPLE: It is simple to draw an ER diagram when we know entities and
relationships.
2. EFFECTIVE: It is an effective communication tool.
3. EASY TO UNDERSTAND: The design of ER is very logical and hence they are
easy to design and understand. They show database capabilities like how tables, keys
and columns are used to find a solution to the given question.
4. INTEGRATED: The ER Model can be easily integrated with relational model.
5. USEFUL IN DECISION MAKING: Since some of the entities in the database are
analysed by an ER-Diagram, so by drawing an ER-Diagram we come to know what
kind of attributes and relationship exist between them.
6. EASY CONVERTION: It can be easily converted to other type of models.
7. DATABASE TROUBLESHOOTING: ER diagrams are used to analyze existing
databases to find and resolve the key issues in logic or deployment. Drawing the
diagram should reveal where it is going wrong.
Disadvantages
LOSS OF INFORMATION: While drawing an ER Model some of the information can
be hidden or lost.
LIMITED RELATIONSHIP: ER model can represent limited relationships as
compared to other models and It is not possible to indicate primary keys and foreign keys
when they’re expected.
NO REPRESENTATION FOR DATA MANIPULATION: It is not possible to
represent data manipulation (commands like insert(), delete(),alter(),update()) in ER
model.
 NO INDUSTRY STANDARD: There is no industry standard for notations of an ER
diagram.
DATA INCONSISTENCY: Due to improper Normalization some data inconsistency
may occur so, while creating an ER diagram at least it should be in third normal form.
MISSING CARDINALITIES: Missing relationship cardinalities, so everything looks
like a one-to-one relationship. One-to-one relationships are actually
Decision Table
A decision table is a brief visual representation for specifying which actions to perform
depending on given conditions. The information represented in decision tables can also be
represented as decision trees or in a programming language using if-then-else and switch-case
statements.
Importance of Decision Table:
 Decision tables are very much helpful in test design techniques.
 It helps testers to search the effects of combinations of different inputs and other
software states that must correctly implement business rules.
 It provides a regular way of starting complex business rules, that is helpful for
developers as well as for testers.
 It assists in the development process with the developer to do a better job. Testing
with all combinations might be impractical.
 A decision table is basically an outstanding technique used in both testing and
requirements management.
 It is a structured exercise to prepare requirements when dealing with complex
business rules.
 It is also used in model complicated logic.
Advantage of Decision Table:
1. Any complex business flow can be easily converted into test scenarios & test cases
using this technique.
2. Decision tables work iteratively which means the table created at the first iteration is
used as input tables for the next tables. The iteration is done only if the initial table is
not satisfactory.
3. Simple to understand and everyone can use this method to design the test scenarios &
test cases.
4. It provides complete coverage of test cases which helps to reduce the rework on
writing test scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition
values. This is known as its completeness property.

Software Requirement Specifications:

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 analysed.
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.
Characteristics of good SRS:

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the
SRS. S2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions
of al
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in
another as textual.
(b) One condition may state that all lights shall be green while another states that all lights
shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified actions. For
example,
(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that "A
and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use different terms
for that object. For example, a program's request for user input may be called a "prompt" in
one requirement and a "cue" in another. The use of standard terminology and descriptions
promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
requirement.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if
it facilitates the referencing of each condition in future development or enhancement
documentation.
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal notations
and symbols should be avoided too as much extent as possible. The language should be kept
simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the
details should be explained explicitly. Whereas, for a feasibility study, fewer analysis can be
used. Hence, the level of abstraction modifies according to the objective of the SRS.
Properties of a good SRS document
The essential properties of a good SRS document are the following:
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.
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.
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.
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.
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 requirements have been met
in an implementation.
The goals of an SRS
Some of the goals an SRS should achieve are to:
 Provide feedback to the customer, ensuring that the IT company understands the
issues the software system should solve and how to address those issues.
 Help to break a problem down into smaller components just by writing down the
requirements.
 Speed up the testing and validation processes.
 Facilitate reviews.
Importance of SRS:
1. The users and the client get a brief idea about the software while in the initial stages.
 The purposes and the intentions as well as the expected results are properly defined. It
2.
hence lays the outline for software design.
3. The desired goals are defined thereby easing off the efforts of the developers in terms
of time and cost.
4. It forms a basis for the agreement between the client and the developer.
5. It becomes easier while transferring and using the solution elsewhere or with new
customers as the basis of functioning of the software is mentioned.
6. It acts as a material for reference at a later stage.
7. It acts as the basis for reviews.
Advantages of good SRS Document
1. An SRS establishes the basis for agreement between the customer and the supplier on
what the software product will perform.
2. An SRS provides a reference for validation of the final product/software.
3. A high-quality SRS is a prerequisite to high-quality product/software.
4. A high-quality SRS reduces the development cost.
SRS Table of Contents:
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
4.1 System Feature 1
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models

Software Quality Assurance:

Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the set of
activities which ensure processes, procedures as well as standards are suitable for the project and
implemented correctly.
Software Quality Assurance is a process which works parallel to development of software. It focuses
on improving the process of development of software so that problems can be prevented before they
become a major issue.
Software quality assurance focuses on:
 software’s portability

 software’s usability

 software’s reusability

 software’s correctness

 software’s maintainability

 software’s error control

Software Quality Assurance has:

1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
 5. Measurement and reporting mechanism
Verification:
Verification is the process of checking that a software achieves its goal without any bugs. It is the
process to ensure whether the product that is developed is right or not. It verifies whether the
developed product fulfils the requirements that we have.
Verification is Static Testing.
Activities involved in verification:
1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking
Validation:
Validation is the process of checking whether the software product is up to the mark or in other words
product has high level requirements. It is the process of checking the validation of product i.e. it
checks what we are developing is the right product. it is validation of actual and expected product.
Validation is the Dynamic Testing.

Activities involved in validation:

1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing

Verification vs Validation

Verification Validation

Definition It is a process of checking if a It is a process of ensuring that the product

product is developed as per the meets the needs and expectations of
 specifications. stakeholders.

It tests the requirements,

What it tests It tests the usability, functionalities, and
architecture, design, and code
or checks for reliability of the product.
of the software product.

It emphasizes executing the code to test the

Coding It does not require executing
usability and functionality of the end
requirement the code.
product.

A few activities involved in

The commonly-used validation activities in
verification testing are
Activities software testing are usability testing,
requirements verification,
include performance testing, system testing, security
design verification, and code
testing, and functionality testing.
verification.

Types of A few verification methods are A few widely-used validation methods are
testing inspection, code review, desk- black box testing, white box testing,
methods checking, and walkthroughs. integration testing, and acceptance testing.

Teams or The quality assurance (QA) The software testing team along with the QA
persons team would be engaged in the team would be engaged in the validation
involved verification process. process.

It targets internal aspects such

as requirements, design, It targets the product that is ready to be
Target of test
software architecture, database, deployed.
and code.

ISO 9000 Certification in Software Engineering

The International standards organization (ISO) is a standard which serves as a for contract
between independent parties. It specifies guidelines for development of quality system.
Standard of ISO addresses to both aspects i.e. operational and organizational aspects which
includes responsibilities, reporting etc. An ISO 9000 standard contains set of guidelines of
production process without considering product itself.
Why ISO Certification required by Software Industry?
There are several reasons why software industry must get an ISO certification. Some of
reasons are as follows:
 This certification has become a standards for international bidding.

 It helps in designing high-quality repeatable software products.

 Its emphasis needs for proper documentation.
 It facilitates development of optimal processes and totally quality measurements.
Features of ISO 9001 Requirements:
  Document control –
All documents concerned with the development of a software product should be
properly managed and controlled.
 Planning –
Proper plans should be prepared and monitored.
 Review –
For effectiveness and correctness all important documents across all phases should be
independently checked and reviewed .
 Testing –
The product should be tested against specification.
 Organizational Aspects –
Various organizational aspects should be addressed e.g., management reporting of the
quality team.
Advantages of ISO 9000 Certification
Some of the advantages of the ISO 9000 certification process are following :
 Business ISO-9000 certification forces a corporation to specialize in “how they are
doing business”. Each procedure and work instruction must be documented and thus
becomes a springboard for continuous improvement.
 Employees morale is increased as they’re asked to require control of their processes
and document their work processes
 Better products and services result from continuous improvement process.
 Increased employee participation, involvement, awareness and systematic employee
training are reduced problems.
Shortcomings of ISO 9000 Certification:
Some of the shortcomings of the ISO 9000 certification process are following:
 ISO 9000 does not give any guideline for defining an appropriate process and does
not give guarantee for high quality process.
 ISO 9000 certification process have no international accreditation agency exist
Software Engineering Institute Capability Maturity Model (SEICMM):
1. The Capability Maturity Model (CMM) is a procedure used to develop and refine an
organization's software development process.
2. The model defines a five-level evolutionary stage of increasingly organized and
consistently more mature processes.
3. CMM was developed and is promoted by the Software Engineering Institute (SEI), a
research and development centre promote by the U.S. Department of Defence (DOD).
4. Capability Maturity Model is used as a benchmark to measure the maturity of an
organization's software process
Methods of SEICMM
Capability Evaluation: Capability evaluation provides a way to assess the software process
capability of an organization. The results of capability evaluation indicate the likely
contractor performance if the contractor is awarded a work. Therefore, the results of the
software process capability assessment can be used to select a contractor.
Software Process Assessment: Software process assessment is used by an organization to
improve its process capability. Thus, this type of evaluation is for purely internal use.
SEI CMM categorized software development industries into the following five maturity
levels. The various levels of SEI CMM have been designed so that it is easy for an
organization to build its quality system starting from scratch slowly.

Level 1: Initial:
Ad hoc activities characterize a software development organization at this level. Very few or
no processes are described and followed. Since software production processes are not limited,
different engineers follow their process and as a result, development efforts become chaotic.
Therefore, it is also called a chaotic level.
Level 2: Repeatable:
At this level, the fundamental project management practices like tracking cost and schedule
are established. Size and cost estimation methods, like function point analysis, COCOMO,
etc. are used.
Level 3: Defined:
At this level, the methods for both management and development activities are defined and
documented. There is a common organization-wide understanding of operations, roles, and
responsibilities. The ways through defined, the process and product qualities are not
measured. ISO 9000 goals at achieving this level.
Level 4: Managed
At this level, the focus is on software metrics. Two kinds of metrics are composed.
Product metrics measure the features of the product being developed, such as its size,
reliability, time complexity, understandability, etc.
Process metrics follow the effectiveness of the process being used, such as average defect
correction time, productivity, the average number of defects found per hour inspection, the
average number of failures detected during testing per LOC, etc. The software process and
product quality are measured, and quantitative quality requirements for the product are met.
Various tools like Pareto charts, fishbone diagrams, etc. are used to measure the product and
process quality. The process metrics are used to analyze if a project performed satisfactorily.
Thus, the outcome of process measurements is used to calculate project performance rather
than improve the process.
Level 5: Optimizing
At this phase, process and product metrics are collected. Process and product measurement
data are evaluated for continuous process improvement.
Difference between ISO9000 and SEI-CMM:
ISO 9000 SEICMM
1 ISO 9000 is a set of international SEI (Software Engineering Institute),
standards on quality management and Capability Maturity Model (CMM)
quality assurance developed to help specifies an increasing series of levels
companies effectively document the of a software development organization.
quality system elements needed to an
efficient quality system.
2 Focus is customer supplier relationship, Focus on the software supplier to
attempting to reduce customer’s risk in improve its interval processes to achieve
choosing a supplier. a higher quality product for the benefit of
the customer.
3 It is created for hard goods It is created for software industry.
manufacturing industries.
4 ISO9000 is recognized and accepted in SEICMM is used in USA, less widely
most of the countries. elsewhere.
5 It specifies concepts, principles and CMM provides detailed and specific
safeguards that should be in place. definition of what is required for given
levels.
6 This establishes one acceptance level. It assesses on 5 levels.

7 Its certification is valid for three years. It has no limit on certification.

8 It focuses on inwardly processes. It focusses outwardly.

9 It has no level. It has 5 levels:
(a). Initial
(b). Repeatable
(c). Defined
(d). Managed
 (e). Optimized
10 It is basically an audit. It is basically an appraisal.

11 It is open to multi sector. It is open to IT/ITES.

12 Follow set of standards to make It emphasizes a process of continuous

success repeatable. improvement.