Software Requirement Specifications

unit 2
• A condition of capability needed by a user to solve a problem or achieve an
objective
• Known Requirements:- Something a stakeholder believes to be
implemented
• Unknown requirements:-Forgotten by the stakeholder because they are
not needed right now or needed only by another stakeholder
• Undreamt requirements:- stakeholder may not be able to think of new
• requirement due to limited knowledge
• A Known, Unknown and Undreamt requirements may functional or non
functional.
• Known Requirements:- Something a stakeholder believes to be implemented
• Unknown requirements:-Forgotten by the stakeholder because they are not
needed right now or needed only by another stakeholder
• Undreamt requirements:- stakeholder may not be able to think of new
requirement due to limited knowledge A Known, Unknown and Undreamt
requirements may functional or non functional.
• Functional requirements: - describe what the software has to do. They are often
called product features. It depends on the type of software, expected users and
the type of system where the software is used.
• Non Functional requirements: - are mostly quality requirements. That stipulate
how well the software does. These define system properties and constraints e.g.
reliability, response time and storage requirements. Constraints are I/O device
capability, system representations, etc.
• User requirements:- Statements in natural language plus diagrams of the services
the system provides and its operational constraints.
• System requirements: - A structured document setting out detailed descriptions
of the system’s functions, services and operational constraints. Defines what
should be implemented so may be part of a contract between client and
contractor
Requirements engineering Process
• The process of finding out, analyzing, documenting and checking
these services and constraints called requirement engineering.
• RE produces one large document, written in a natural language,
contains a description of what the system will do without how it will
do.
• Input to RE is problem statement prepared by the customer and the
output is SRS prepared by the developer.
• The requirements themselves are the descriptions of the system
services and constraints that are generated during the requirements
engineering process.
Requirements engineering processes:-
• The processes used for RE vary widely depending on the application
domain, the people involved and the organization developing the
requirements. However, there are a number of generic activities
common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements documentation
• Requirements review
• Requirement Elicitation: - known as gathering of requirement. Here requirement
are identified with the help of customer and exiting system processes, if they are
available.
• Requirement Analysis: - analysis of requirement stars with Requirement
Elicitation. Requirements are analyzed in order to identify inconstancy, defects
etc.
• Requirement Documentation:- this is the end product of requirement elicitation
and analysis. Documentation is very important as it will be the foundation for the
design of the software. The documentation is known as SRS.
• Requirement Review:-review process is carried out to improve the quality of the
SRS. it may also called verification. It should be a continuous activity that is
incorporated into the elicitation, analysis, documentation.
• The primary output of requirement engineering process is requirement
specification (SRS).
• Elicitation: - It is also called requirement discovery. Requirements are
identified with the help of customer and exiting system processes, if
they are available.
• Requirement Elicitation is most difficult is perhaps most critical most
error prone most communication intensive aspect of software
development.
Various methods of Requirements Elicitation
• Interviews
• After receiving the problem statement from the customer, the first
step is to arrange a meeting with the customer.
• During the meeting or interview, both the parties would like to
understand each other.
• The objective of conducting an interview is to understand the
customer’s expectation from the software.
• Entry level personnel
• Middle level stakeholder
• Managers
• Users of the software (Most important)
• Brainstorming Sessions
• Brainstormy is a group technique that may be used during requirement
elicitation to understand the requirement
• Every idea will be documented in a way that every can see it
• After brainstormy session a detailed report will be prepared and reviewed by the
facilitator
• 3. Facilitated Application specification approach (FAST)
• FAST is similar to brainstormy session and the objective is to bridge the
expectation gap-a difference what the developers think they are suppose to build
and what the customer think they are going to get
• In order to reduce the gap a team oriented approach is developed for
requirement gathering and is called FAST
• 4. Quality function deployment (QFT)
It incorporates the voice of the customer and converts it in to the document.
 Analysis
• Requirement analysis phase analyze, refine and scrutinize requirements to make
consistent & unambiguous requirements.
• Draw the context diagram :-The context diagram is a simple model that defines
the boundaries and interface of the proposed system.
• Development of prototype:-Prototype helps the client to visualize the proposed
system and increase the requirement. Prototype may help the parties to take
final decision.
• Model the requirement:-This process usually consists of various graphical
representations of function, data entities, external entities and their relationship
between them. It graphical view may help to find incorrect, inconsistent, missing
requirements. Such models include data flow diagram, entity relationship
diagram, data dictionary, state transition diagram.
• 4. Finalize the requirement:- After modeling the requirement inconsistencies and
ambiguities have been identified and corrected. Flow of data among various
modules has been analyzed. Now Finalize and analyzes requirements and next
step is to document these requirements in prescribed format.
1. Draw the context diagram
• The context diagram is a simple model that defines the boundaries and interface of the proposed
system.
2. Development of prototype
• Prototype helps the client to visualize the proposed system and increase the understanding
of requirement. Prototype may help the parties to take final decision.
3. Model the requirement
• This process usually consists of various graphical representations of function, data entities,
external entities and their relationship between them. It graphical view may help to find
incorrect, inconsistent, missing requirements. Such models include data flow diagram,
entity relationship diagram, data dictionary, state transition diagram.
4. Finalize the requirement
• After modeling the requirement inconsistencies and ambiguities have been identified and
Corrected. Flow of data among various modules has been analyzed. Now Finalize and analyzes
requirements and next step is to document these requirements in prescribed format.
• Documentation:-This is the way of representing requirements in a consistent format SRS serves
many purpose depending upon who is writing it.
• Feasibility Study: - It is the process of evaluation or analysis of the potential impact
of a propose project or program.
• Feasibility study is carried out based on many purposes to analyze whether software
product will be right in terms of development, implantation, contribution of project to
the organization etc.
• Five common factors (TEFOS)
• Technical feasibility: -
• Economic feasibility:-
• Legal feasibility: -
• Operational feasibility: -
• Schedule feasibility: -
• Aim of feasibility study :-The overall objective of the organization are 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
• Technical Feasibility – In Technical Feasibility current resources both hardware software along with required
technology are analyzed/assessed to develop project. This technical feasibility study gives report whether
there exists correct required resources and technologies which will be used for project development.
• Operational Feasibility – In Operational Feasibility degree of providing service to requirements is analyzed
along with how much easy product will be to operate and maintenance after deployment.
• Economic Feasibility –In Economic Feasibility study cost and benefit of the project is analyzed. Means under
this feasibility study a detail analysis is carried out what will be cost of the project for development which
includes all required cost for final development like hardware and software resource required, design and
development cost and operational cost and so on. After that it is analyzed whether project will be beneficial in
terms of finance for organization or not.
• Legal Feasibility – In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing
barriers of legal implementation of project, data protection acts or social media laws, project certificate,
license, copyright etc.
• Schedule Feasibility – In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed
project which includes how many times teams will take to complete final project which has a great impact on
the organization as purpose of project may fail if it can’t be completed on time.
• Feasibility Study Process :
• Information assessment
• Information collection
• Report writing
• General information
• Need of Feasibility Study :
Feasibility study is so important stage of software engineering process as
after completion of feasibility study it gives a conclusion of whether to go
ahead with proposed project as it is practically feasible or to stop proposed
project here as it is not right/feasible to develop or to think/analyze about
proposed project again.
• Feasibility study helps in identifying risk factors involved in developing and
deploying system and planning for risk analysis also narrows the business
alternatives and enhance success rate analyzing different parameters
associated with proposed project development
Information modelling
• An information model in software engineering is a representation of
concepts and the relationships, constraints, rules, and operations to
specify data semantics for a chosen domain of discourse.
• Typically it specifies relations between kinds of things, but may also include
relations with individual things.
• It can provide a sharable, stable, and organized structure of information
requirements or knowledge for the domain context.
• Information model is usually an abstract, formal representation of entity
types that may include their properties, relationships and the operations
that can be performed on them.
• The entity types in the model may be kinds of real-world objects, such as
devices in a network, or occurrences, or they may themselves be abstract,
such as for the entities used in a billing system.
• Typically, they are used to model a constrained domain that can be
described by a closed set of entity types, properties, relationships and
operations.
Objectives of Analysis Modelling:
• It must establish a way of creating software design.
• It must describe the requirements of the customer.
• It must define a set of requirements that can be validated, once the software is built.
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 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 :
• All names should be unique. This makes it easier to refer to elements in the DFD.
• 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.
• 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.
• Do not become bogged down with details. Defer error conditions and error
handling until the end of the analysis
• 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. In fact, 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.
• 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. Then the system is
decomposed and described as a DFD with multiple bubbles. Parts of the
system represented by each of these bubbles are then decomposed and
documented as more and more detailed DFDs. This process may be repeated
at as many levels as necessary until the program at hand is well understood.
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 sub processes.
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.
Entity Relationship Diagram
• ER-modeling is a data modeling method used in software engineering to produce
a conceptual data model of an information system. Diagrams created using this
ER-modeling method are called Entity-Relationship Diagrams or ER diagrams or
ERDs.
• Purpose of ERD
• The database analyst gains a better understanding of the data to be contained in
the database through the step of constructing the ERD.
• The ERD serves as a documentation tool.
• 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 ER Diagram
• Entity, Attributes, Relationship.
• Entity:-An entity can be a real-world object, either animate or inanimate,
that can be merely identifiable. An entity is denoted as a rectangle in an ER
diagram. For example, in a school database, students, teachers, classes, and
courses offered can be treated as entities. All these entities have some
attributes or properties that give them their identity.
• Attributes
• Entities are denoted utilizing their properties, known as attributes. All
attributes have values. For example, a student entity may have name, class,
and age as attributes.
• There exists a domain or range of values that can be assigned to attributes.
For example, a student's name cannot be a numeric value. It has to be
alphabetic. A student's age cannot be negative, etc.
• There are four types of Attributes:
• Key attribute
• Composite attribute
• Single-valued attribute
• Multi-valued attribute
• Derived attribute
• Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among the
entity set.
• There are mainly three types of keys:
• Super key: A set of attributes that collectively identifies an entity in the entity set.
• Candidate key: A minimal super key is known as a candidate key. An entity set may have more
than one candidate key.
• Primary key: A primary key is one of the candidate keys chosen by the database designer to
uniquely identify the entity set.
• Composite attribute: An attribute that is a combination of other attributes is called a composite
attribute. For example, In student entity, the student address is a composite attribute as an
address is composed of other characteristics such as pin code, state, country.
•
• Single-valued attribute: Single-valued attribute contain a single value.
• Multi-valued Attribute: If an attribute can have more than one value, it is known as a
multi-valued attribute. Multi-valued attributes are depicted by the double ellipse.
• Derived attribute: Derived attributes are the attribute that does not exist in the physical
database, but their values are derived from other attributes present in the database.
• Relationships:-The association among entities is known as relationship. Relationships are
represented by the diamond-shaped box.
 Decision Table
• Decision tables are used in various engineering fields to represent complex logical
relationships. This testing is a very effective tool in testing the software and its
requirements management. The output may be dependent on many input conditions and
decision tables give a tabular view of various combinations of input conditions and these
conditions are in the form of True(T) and False(F). Also, it provides a set of conditions and
its corresponding actions required in the testing.
• Condition Stubs : The conditions are listed in this first upper left part
of the decision table that is used to determine a particular action or
set of actions.
• Action Stubs : All the possible actions are given in the first lower left
portion (i.e, below condition stub) of the decision table.
• Condition Entries : In the condition entry, the values are inputted in
the upper right portion of the decision table. In the condition entries
part of the table, there are multiple rows and columns which are
known as Rule.
• Action Entries : In the action entry, every entry has some associated
action or set of actions in the lower right portion of the decision table
and these values are called outputs.
• Types of Decision Tables :
• The decision tables are categorized into two types and these are given below:
• Limited Entry : In the limited entry decision tables, the condition entries are restricted to
binary values.
• Extended Entry : In the extended entry decision table, the condition entries have more
than two values. The decision tables use multiple conditions where a condition may have
many possibilities instead of only ‘true’ and ‘false’ are known as extended entry decision
tables.
• Applicability of Decision Tables :
• The order of rule evaluation has no effect on the resulting action.
• The decision tables can be applied easily at the unit level only.
• Once a rule is satisfied and the action selected, n another rule needs to be examined.
• The restrictions do not eliminate many applications
Software requirement specification
• Requirements specification is a complete description of the behavior
of a system to be developed. It includes a set of use cases that
describe all the interactions the users will have with the software. Use
cases are also known as functional requirements. In addition to use
cases, the SRS also contains non-functional (or supplementary)
requirements. Nonfunctional requirements are requirements which
impose constraints on the design or implementation (such as
performance engineering requirements, quality standards, or design
constraints).
Need for Software Requirement Specification (SRS)
• The problem is that the client usually does not understand software
or the software development process, and the developer often does
not understand the client's problem and application area
• This causes a communication gap between the parties involved in the
development project. A basic purpose of software requirements
specification is to bridge this communication gap.
• Characteristics of good SRS document:- Some of the identified desirable qualities
of the SRS documents are the following-
• Concise- The SRS document should be concise and at the same time
unambiguous, consistent, and complete. An SRS is unambiguous if and only if
every requirement stated has one and only one interpretation.
• Structured- The SRS document should be well-structured. A well-structured
document is easy to understand and modify. In practice, the SRS document
undergoes several revisions to cope with the customer requirements.
• Black-box view- It should only specify what the system should do and refrain
from stating how to do. This means that the SRS document should specify the
external behavior of the system and not discuss the implementation issues.
• Conceptual integrity- The SRS document should exhibit conceptual integrity so
that the
reader can easily understand the contents.
• Verifiable- All requirements of the system as documented in the SRs document
should be verifiable. This means that it should be possible to determine whether
or not requirements have been met in an implementation.
Requirements Validation
• Requirement Validation is used for checking the document:-
• Completeness & consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements
Software Quality
• The degree to which a system, component, or process meets specified
requirements.
• The degree to which a system, component or process meets customer or user
needs or expectations.
• Software Quality attribute
Software Quality Model
• Product Operation
• Factors which are related to the operation of a product are combined. The factors
are:
• Correctness
• Efficiency
• Integrity
• Reliability
• Usability
• These five factors are related to operational performance, convenience, ease of
usage and its correctness. These factors play a very significant role in building
customer’s satisfaction.
• Product Revision
• The factors which are required for testing & maintenance are combined and are
given below:
• Maintainability
• Flexibility
• Testability
• These factors pertain to the testing & maintainability of software. They give us
idea about ease of maintenance, flexibility and testing effort. Hence, they are
combined under the umbrella of product revision.
• Product Transition
• We may have to transfer a product from one platform to an other platform or
from one technology to another technology. The factors related to such a transfer
are combined and given below:
• Portability
• Reusability
• Interoperability
• Software Quality Assurance
• It is a planned and systematic pattern of all actions necessary to
provide adequate confidence that the time or product conforms to
established technical requirements.”
• Purpose of SQAP is to specify all the works products that need to be
produced during the project, activities that need to performed for
checking the quality of each of the work product
• It is interested in the quality of not only the final product but also an
intermediate product.
• Verification:-is the process of determine whether or not product of a
given phase of software development full fill the specification
established during the previous phase.
• Validation:-is the process of evaluating software at the end of software
development to ensure compliance with the software requirement. testing is
common method of validation Software V&V is a system engineering process
employing rigorous methodologies for evaluating the correctness and quality of
the software product throughout the software life cycle.
International National Organization (ISO)
• An international set of standards for quality management. It is applicable to a range of
organizations from manufacturing to service industries. ISO 9001 applicable to
organizations which design, develop and maintain products. ISO 9001 is a generic model
of the quality process that must be instantiated for each organization using the standard.
• Quality standards and procedures should be documented in an organizational quality
manual. An external body may certify that an organization’s quality manual conforms to
ISO 9000 standards. Some customers require suppliers to be ISO 9000 certified although
the need for flexibility here is increasingly recognized.
• Process of getting ISO 9000 Certification
• Application
• Pre-assessment
• Document review and adequacy of audit
• Compliance audit
• Registration
• Continued surveillance
The Capability Maturity Model (CMM)
• When it is applied to an existing organization's software development processes, it allows an
effective approach toward improving them. Eventually it became clear that the model could be
applied to other processes. This gave rise to a more general concept that is applied to business
processes and to developing people
• The Capability Maturity Model involves the following aspects:
• Maturity Levels: a 5-level process maturity continuum - where the uppermost (5th) level is a
notional ideal state where processes would be systematically managed by a combination of
process optimization and continuous process improvement.
• Key Process Areas: a Key Process Area (KPA) identifies a cluster of related activities that, when
performed together, achieve a set of goals considered important.
• Goals: the goals of a key process area summarize the states that must exist for that key process
area to have been implemented in an effective and lasting way. The extent to which the goals
have been accomplished is an indicator of how much capability the organization has established
at that maturity level. The goals signify the scope, boundaries, and intent of each key process
area.
• Common Features: common features include practices that implement and institutionalize a key
process area.
There are five types of common features:
• commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis,
and Verifying Implementation
Difference between ISO and SEI-CMM
ISO9000 CMM

ISO certification is awarded by an international SEI CMM assessment is purely for Internal use
standard body and can be quoted as an official
document
Deals primarily for manufacturing industry and CMM was developed specially for Software industry
provisioning of services and therefore addresses software issues
It aims at level 3 of CMM Goes beyond Quality Assurance and lead to TQM
Has Customer Focus as primary aim and follows Provide a list of Key Process Areas to proceed from
procedural controls lower CMM level to higher level to provide gradual
Quality improvements