UNIT-II SE [KCS-601]
Unit-II
Software Requirement Specifications (SRS): Requirement Engineering Process:
Elicitation, Analysis, Documentation, Review and Management of User Needs,
Feasibility Study, Information Modelling, Data Flow Diagrams, Entity
Relationship Diagrams, Decision Tables, SRS Document, IEEE Standards for SRS.
Software Quality Assurance (SQA): Verification and Validation, SQA Plans,
Software Quality Frameworks, ISO 9000 Models, SEI-CMM
__________________________________________________________________
Software Requirement & Specifications : Requirement Engineering
Requirements describe What not How
Produces one large document written in natural language contains a description of
what the system will do without describing how it will do it.
Crucial process steps
Quality of product → Process that creates it
Without well written document
-- Developers do not know what to build
-- Customers do not know what to expect
-- What to validate
Requirement Engineering is the disciplined application of proven principles,
methods, tools, and notations to describe a proposed system’s intended behavior
and its associated constraints.
SRS may act as a contract between developer and customer.
State of practice
Requirements are difficult to uncover
• Requirements change
1 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
• Over reliance on CASE Tools
• Tight project Schedule
• Communication barriers
• Market driven software development
• Lack of resources
Example
A University wish to develop a software system for the student result management
of its M.Tech. Programme. A problem statement is to be prepared for the software
development company. The problem statement may give an overview of the
existing system and broad expectations
from the new software system.
Stakeholder: Anyone who should have some direct or indirect influence on the
system requirements.
--- User
--- Affected persons
Functional requirements describe what the software has to do. They are often
called product features. Non Functional requirements are mostly quality
requirements. That stipulate how well the software does, what it has to do.
Feasibility Study
Technical feasibility
• Is it technically feasible to provide direct communication connectivity
through space from one location of globe to another location?
• Is it technically feasible to design a programming language using
“Sanskrit”?
Feasibility depends upon non technical Issues like:
• Are the project’s cost and schedule assumption realistic?
• Does the business model realistic?
2 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
• Is there any market for the product?
Purpose of feasibility study “evaluation or analysis of the potential impact of a
proposed project or program.”
Focus of feasibility studies
• Is the product concept viable?
• Will it be possible to develop a product that matches the project’s vision
statement?
• What are the current estimated cost and schedule for the project?
Following topics study from Chapter-3 (software requirements
Analysis and specification) Book Software engineering by KK
Agarwal & Yogesh Singh
"Elicitation, Analysis, Documentation, Review and Management of User Needs,
Feasibility Study, Information Modelling, "
Data Flow Diagrams
A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system. A neat and clear DFD can depict the right
amount of the system requirement graphically. It can be manual, automated, or a
combination of both.
It shows how data enters and leaves the system, what changes the information, and
where data is stored.
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:
3 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Circle: A circle (bubble) shows a process that transforms data inputs into data
outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data
store.
Data Store: A set of parallel lines shows a place for the collection of data items. A
data store indicates that the data is stored which can be used at a later stage or by
the other processes in a different order. The data store can have an element or
group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.
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. Levels in DFD are numbered 0, 1, 2 or beyond. Here,
we will see primarily three levels in the data flow diagram, which are: 0-level
DFD, 1-level DFD, and 2-level DFD.
Level-0 DFD
4 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
The Level-0 DFD, also called context diagram of the result management system is
shown in fig. As the bubbles are decomposed into less and less abstract bubbles,
the corresponding data flow may also be needed to be decomposed.
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.
Examples
5 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
6 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Decision Table
A Decision Table is a table that shows the relationship between inputs and rules,
cases, and test conditions. It's a very useful tool for both complicated software
testing and requirements management. The decision table allows testers to examine
all conceivable combinations of requirements for testing and to immediately
discover any circumstances that were overlooked. True(T) and False(F) values are
used to signify the criteria.
how a decision table is created for the login function in which we can log in by
using email and password. Both the email and the password are the conditions, and
the expected result is action.
7 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
In the table, there are four conditions or test cases to test the login function. In the
first condition if both email and password are correct, then the user should be
directed to account's Homepage.
In the second condition if the email is correct, but the password is incorrect then
the function should display Incorrect Password. In the third condition if the email
is incorrect, but the password is correct, then it should display Incorrect Email.
Now, in fourth and last condition both email and password are incorrect then the
function should display Incorrect Email.
What is SRS?
A software requirements specification (SRS) is a document that describes what the
software will do and how it will be expected to perform.
It also describes the functionality the product needs to fulfill all stakeholders
(business, users) needs.
Writing an SRS document is important. But it isn’t always easy to do.
We can follow five steps to write an effective SRS document.
We can follow five steps to write an effective SRS document.
1. Define the Purpose With an Outline (Or Use an SRS Template)
2. Define your Product’s Purpose
3. Describe What You Will Build
4. Detail Your Specific Requirements
5. Deliver for Approval
Organisation of SRS [IEEE – std.. 830-1993].
1. Introduction
Purpose, Scope, Definitions, Acronyms and abbreviation , references,
overview
2. The Overall Description
Interfaces( System, HW, SW, communication), Memory Constraints,
operations
3. Specific Requirements
4. Change Management Process
5. Document Approvals
8 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
6. Supporting Information
9 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
10 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
11 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
12 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Example " Student Result Management system See from
Chapter -3 ( Software Engineering by KK Agarwal)
Software quality assurance
What is quality?
Quality defines to any measurable characteristics such as correctness,
maintainability, portability, testability, usability, reliability, efficiency, integrity,
reusability, and interoperability.
What is SQA?
Software quality assurance is a planned and systematic plan of all actions
necessary to provide adequate confidence that an item or product conforms to
establish technical requirements.
A set of activities designed to calculate the process by which the products are
developed or manufactured.
The Software Quality Assurance (SQA) process compromises of the verification
and validation process of the software code. In general, guaranteeing that the
software conforms to its specification while meeting the customer needs.
Let us compare and contrast the verification and validation process.
Verification and validation begin by reviewing the requirements and covering the
design and analysis of the code up to the product testing. For this reason,
verification demands to check that the program meets specified requirements.
While, on the other hand, validation requires examining that the software product
meets the client expectation as well as a formal proof of program correctness
(IEEE, 1990).
Validation testing is executed by the testing team to test the
application. Verification is done before the validation testing. After verification
testing, validation testing takes place.
For this reason, let us display their differences in a table view:
13 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
The modern view of a quality associated with a software product several
quality methods follows as
• Portability:
• Usability:
• Reusability:
• Function ability:
• Correctness:
• Maintainability:
The modern view of a quality associated with a software product several
quality methods such as the following:
Portability:
A software device is said to be portable, if it can be freely made to work in
various operating system environments, in multiple machines, with other
software products, etc.
Usability:
A software product has better usability if various categories of users can easily
invoke the functions of the product.
Reusability:
A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.
Correctness:
A software product is correct if various requirements as specified in the SRS
document have been correctly implemented.
14 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Maintainability:
A software product is maintainable if bugs can be easily corrected as and when
they show up, new tasks can be easily added to the product, and the
functionalities of the product can be easily modified, etc.
Software Quality Framework is a model for software quality by connecting and
integrating the different views of software quality. This framework connects
the customer view with the developer view of software quality and it treats
software as a product.
The software product view describes the characteristics of a product that bear
on its ability to satisfy stated and implied needs.
This is a framework that describes all the different concepts relating to quality
in a common way measured by qualitative scale that can be understood and
interpreted in a common way.
Therefore the most influential factor for the developers is the customer
perception.
This framework connects the developer with the customer to derive a common
interpretation for quality.
Developers View:
Users View:
Product View:
Developers View:
For example the customer understands or describes the quality of operation
as meeting the requirement while the developers use different factors to
describe the software quality. The developer view of quality in the software
is influenced by many factors.
This model stresses on 3 primary ones:
The code:
It is measured by its correctness and reliability.
The data:
It is measured by the application integrity.
Maintainability:
It has different measures the simplest is the mean time to change.
Users View:
For example, a teacher may write a spreadsheet to track students 'test scores.
In these end-user programming situations, the program is a means to an end
that could be used to accomplish a goal.
In contradiction to end-user programming, professional programming has
the goal of producing software for others to use.
Product View:
15 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
The product view describes quality as correlated to inherent characteristics
of the product.
Product quality is defined as the set of characteristics and features of a
product that gives contribution to its ability to fulfill given requirements.
Product quality can be measured by the value-based view which sees the
quality as dependent on the amount a customer is willing to pay for it.
According the users, a high-quality product is one that satisfies their
expectations and preferences while meeting their requirement.
Satisfaction of end users of the product represents craft to learn, use,
upgrade the product and when asked to participate in rating the product, a
positive rating is given.
Benefits
By using SQA the quality of SW will be high If the SW is high quality software
then it saves our time and Cost Ease of use Security
What is ISO?
ISO (International Standards Organization) is a group or consortium of 63
countries established to plan and fosters standardization.
ISO declared its 9000 series of standards in 1987. It serves as a reference for
the contract between independent parties.
The ISO 9000 standard determines the guidelines for maintaining a quality
system.
The ISO standard mainly addresses operational methods and organizational
methods such as responsibilities, reporting, etc.
ISO 9000 defines a set of guidelines for the production process and is not
directly concerned about the product itself.
Types of ISO 9000 Quality Standards
ISO 9001:
This standard applies to the organizations engaged in design,
development, production, and servicing of goods. This is the standard that
applies to most software development organizations.
ISO 9002:
This standard applies to those organizations which do not design products
but are only involved in the production.
16 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Examples of these category industries contain steel and car manufacturing
industries that buy the product and plants designs from external sources and
are engaged in only manufacturing those products.
Therefore, ISO 9002 does not apply to software development organizations.
ISO 9003:
This standard applies to organizations that are involved only in the
installation and testing of the products.
For example, Gas companies.
How to get ISO 9000 Certification?
An organization determines to obtain ISO 9000 certification applies to ISO
registrar office for registration. The process consists of the following stages:
Application:
Once an organization decided to go for ISO certification, it applies to
the registrar for registration.
Pre-Assessment:
During this stage, the registrar makes a rough assessment of the
organization.
Document review and Adequacy of Audit:
During this stage, the registrar reviews the document submitted by the
organization and suggest an improvement.
Compliance Audit:
During this stage, the registrar checks whether the organization has
compiled the suggestion made by it during the review or not.
Registration:
17 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
The Registrar awards the ISO certification after the successful
completion of all the phases.
Continued Inspection:
The registrar continued to monitor the organization time by time.
What is (SEICMM)?
The Capability Maturity Model (CMM) is a procedure used to develop and
refine an organization's software development process. The model defines a
five-level evolutionary stage of increasingly organized and consistently
more mature processes.
CMM was developed and is promoted by the Software Engineering Institute
(SEI), a research and development center promote by the U.S. Department
of Defense (DOD).
Capability Maturity Model is used as a benchmark to measure the maturity
of an organization's software process.
Methods of SEICMM
There are two 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.
18 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
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
19 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
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.
Level 5: Optimizing
At this phase, process and product metrics are collected.Process and product
measurement data are evaluated for continuous process improvement.
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.
Key Process Areas (KPA) of a software organization Except for SEI CMM
level 1, each maturity level is featured by several Key Process Areas (KPAs)
that contains the areas an organization should focus on improving its
software process to the next level.
The focus of each level and the corresponding key process areas are shown
in the fig.
SEI CMM provides a series of key areas on which to focus to take an
organization from one level of maturity to the next.
Thus, it provides a method for gradual quality improvement over various
stages.
20 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
UNIT-II SE [KCS-601]
Each step has been carefully designed such that one step enhances the
capability already built up.
21 Software Engineering [KCS-601] : Department of Computer Science & Engineering, DVSIET, Meerut
