Software Engineering, Unit -2

RAGHU ENGINEERING COLLEGE

(Affiliated to JNTU-KAKINADA & Accredited by NBA)
Visakhapatnam-531162
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
II-B.Tech. CSE Semester-I
Regulation: AR 20 SUB: SOFTWARE ENGINEERING

Syllabus for Unit -2

Requirement Analysis and Specification: Requirement Gathering and analysis, requirement

engineering process, requirement elicitation, requirement analysis, software requirement
specification (SRS), prototyping analysis, requirement specification, requirement validation,
formal system specification.

1. What do you mean by requirement engineering?

● The requirements provided by the customer ultimately reflect in the quality of the final
product. The requirements of a system are the descriptions of the features or services that
the system exhibits within the specified constraints. Incorrect, incomplete, and
inconsistent requirements always lead to a faulty system.
● Sometimes, it becomes very difficult, especially in the case when customers are unaware
of computers and have communication problems in articulating the needs, to express
requirements in a formal document. This formal document is called software
requirements specification (SRS) document.
● This document is treated as the basis of development. The requirements collected from
the customer are organized in some systematic manner and presented in the SRS.
● Requirements may change during development. Sometimes, user requirements are
ambiguous and are difficult to convert into system requirements.
● Nonfunctional requirements may also change due to changes in the functional
requirements. Therefore, changes must be managed in a database or document so that
these changes can be incorporated in the final system development.
● Requirements engineering is the process of gathering, analyzing, documenting,
validating, and managing the requirements. The main goal of requirements engineering is
to clearly understand the customer requirements and systematically organize these
requirements in the SRS.
● Requirements engineering process begins once feasibility study and preliminary
investigation are over. It deals with the problem domain of the software that is to be
converted into the solution domain
2. Discuss different types of software requirements

● Software requirements come from the customer. They are used in development to
develop software.

1
 Software Engineering, Unit -2

● A requirement is a detailed, formal description of system functionalities. A requirement

specifies a function that a system or component must able to perform for customer
satisfaction.

Business requirements

● It defines the project goal and the expected business needs and opportunities for the
product. Business needs also describe the product domain and product demand.
● It focuses on data and process analysis, which helps to carry out the further software
development life cycle. The Business analyst is well versed in understanding the
concept of business flow as well as the process being followed in the organization.
User and System Requirements
● User requirements are the high level abstract statements supplied by the customer,
end users. These requirements are the functionalities that the system is expected to
provide within the certain constraints or environment.
● These requirements are translated into system requirements keeping in mind user’s
view. These are generally represented in some natural languages with pictorial
representation or tables to understand the requirements.
● User requirements may be ambiguous or incomplete in description with less product
specification and little/software configurations are stated in the user requirements.
● System requirements are the detailed and technical functionalities written in a
systematic manner that are implemented in the business process to achieve the goal of
user requirements.
● It can also be set of functional and non-functional requirements. System
requirements are often expressed as documents in a structured manner using technical
representations.
● In an ATM machine, user requirements allow users to withdraw and deposit cash. The
requirements consider customer ID, account type, bank name, consortium, PIN,

2
 Software Engineering, Unit -2

communication link, hardware, and software. Also, an ATM will service one
customer at a time.
Functional Requirements
● Requirements, which are related to functional aspect of software fall into this
category. They define functions and functionality within and from the software
system.
● Functional requirements are the behavior or functions that the system must support.
Each function receives some user input, processes it, and provides certain out comes.
● These are the attributes that characterize what the software does to fulfil the needs of
the customer.
Example:
● Search option given to user to search from various invoices.
● User should be able to mail any report to management.
● Users can be divided into groups and groups can be given separate rights.
● Should comply business rules and administrative functions.
● Software is developed keeping downward compatibility intact
Non-functional Requirements
● Non-functional Requirements specify how a system must behave. These are qualities,
standards, constraints upon the system services that are specified with respect to a
product, organization and external environment.
● It specifies quality characteristics of a system. Functional requirements are actions
that must be performed by the system under development.
● Non-functional requirement includes
o Security
o Logging
o Storage
o Configuration
o Performance
o Cost
o Interoperability
o Flexibility

3
 Software Engineering, Unit -2

o Disaster recovery
o Accessibility
3. Explain the requirement engineering process

● Requirement Engineering is the disciplined, process-oriented approach to the

development and management of requirements.
● It is a four step process, which includes –
o Feasibility Study
o Requirement Gathering
o Software Requirement Specification
o Software Requirement Validation
Feasibility Study
● When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software must
perform and which all features are expected from the software.
● Referencing to this information, the analysts does a detailed study about whether the
desired system and its functionality are feasible to develop.
● This feasibility study is focused towards goal of the organization. This study analyses
whether the software product can be practically materialized in terms of
implementation, contribution of project to organization, cost constraints and as per
values and objectives of the organization.
● It explores technical aspects of the project and product such as usability,
maintainability, and productivity and integration ability.
● The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or not the
project should be undertaken.
Requirement Gathering
● If the feasibility report is positive towards undertaking the project, next phase starts
with gathering requirements from the user.
● Analysts and engineers communicate with the client and end-users to know their
ideas on what the software should provide and which features they want the software
to include.
Software Requirement Specification

4
 Software Engineering, Unit -2

● SRS is a document created by system analyst after the requirements are collected
from various stakeholders.
● SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software across
various platforms, maintainability, speed of recovery after crashing, Security, Quality,
Limitations etc.
● The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical language
so that they can be comprehended and useful by the software development team.
● SRS should come up with following features:
o User Requirements are expressed in natural language.
o Technical requirements are expressed in structured language, which is used
inside the organization.
o Design description should be written in Pseudo code.
o Format of Forms and GUI screen prints.
o Conditional and mathematical notations for DFDs etc.
Software requirement validation
● After requirement specifications are developed, the requirements mentioned in this
document are validated.
● User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
● Requirements can be checked against following conditions -
o If they can be practically implemented
o If they are valid and as per functionality and domain of software
o If there are any ambiguities
o If they are complete
o If they can be demonstrated
4. Explain about requirement elicitation
● It is the initial stage in the requirements engineering process for software
development. The problem-understanding phase is used to capture and understand the
problem domain used enough to analyze the problem in the existing system,
opportunities, and constraints in the proposed system.

5
 Software Engineering, Unit -2

● The goal of requirement elicitation is to identify the different parties involved in the
project as source of requirements, gather requirements from different parties, write
requirements in their original form as collected from the parties and integrate these
requirements
● A system Analyst is the person, who interacts with people, understands the business
needs and has knowledge of computing. He studies the requests and represents them
in the specification document.
● He studies the requests and represents them in the specification document. The skills
of the system analyst include programming experience, problem solving,
interpersonal survey, IT expertise and political practical understanding. He acts as a
broker and needs to be a team player.
● He should have good communication and decision-making skills. The main challenge
of requirement elicitation is the identification of the problem scope, Identification of
stakeholders, Understanding of problem, and volatility of requirements.
● The elicitation begins with business context and operational environment to
determine the boundary, scope, and objective of the target system

5. List out requirement elicitation technique

● Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users and others
who have a stake in the software system development.
● There are various ways to discover requirements

6
 Software Engineering, Unit -2

Interview
● Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
o Structured (closed) interviews, where every single information to gather is
decided in advance, they follow pattern and matter of discussion firmly.
o Non-structured (open) interviews, where information to gather is not
decided in advance, more flexible and less biased.
o Oral interviews
o Written interviews
o One-to-one interviews, which are held between two persons across the table.
o Group interviews which are held between groups of participants. They help
to uncover any missing requirement as numerous people are involved.
Survey
● Organization may conduct surveys among various stakeholders by querying about
their expectation and requirements for the upcoming system
Questionnaires:
● A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.
● A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Task Analysis
● Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.
Domain Analysis
● Every software falls into some domain category. The expert people in the domain
can be a great help to analyse general and specific requirements.

Brainstorming

● An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
Prototyping

7
 Software Engineering, Unit -2

● Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product.
● It helps giving better idea of requirements. If there is no software installed at client’s
end for developer’s reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned requirements.
● The prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
Observation
● Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems.
● They observe the workflow at client’s end and how execution problems are dealt.
The team itself draws some conclusions, which aid to form requirements expected
from the software.
6. Write short notes on requirement Analysis
● Requirement analysis is carried out after gathering requirements in the requirement
elicitation phase. Requirement analysis is an activity, which is performed iteratively
during the course of software development.
● Requirement analysis includes various activities, such as classification, organization,
prioritization, negotiation and modelling requirements.
● During Requirement analysis, models are prepared to analyse the requirements.
Requirements analysis is critical to the success of a systems or software project.
● The requirements should be documented, actionable, measurable, testable, traceable,
related to identified business needs or opportunities, and defined to a level of detail
sufficient for system design.
● The following analysis techniques are generally used for the modelling of
requirements:
o Structured Analysis
o Data-oriented analysis
o Object- oriented analysis
o Prototyping
7. Write short notes on Structured analysis
● Structured Analysis (SA) is also referred to as process modelling or data modeling.
Data flow modeling is useful to understand the working process of the system
Structured Design (SD), are methods for analyzing and converting business
requirements into specifications and ultimately, computer programs, hardware
configurations and related manual procedures.
● Structured Analysis uses a graphical tool called data flow diagrams (DFD), which
represent the system behavior. Structured analysis and design techniques are

8
 Software Engineering, Unit -2

fundamental tools of systems analysis, and developed from classical systems analysis
of the 1960s and 1970s.
Data flow Diagram
● A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data
through an information system. It differs from the system flowchart as it shows the
flow of data through processes instead of computer hardware.
● Data flow diagrams were invented by Larry Constantine, developer of structured
design, based on Martin and Estrin's "data flow graph" model of computation.
● It is common practice to draw a System Context Diagram first which shows the
interaction between the system and outside entities. The DFD is designed to show
how a system is divided into smaller portions and to highlight the flow of data
between those parts.
● This context-level Data flow diagram is then "exploded" to show more detail of the
system being modelled.
● Data flow diagrams (DFDs) are one of the three essential perspectives of Structured
Systems Analysis and Design Method (SSADM). DFD are different from flowcharts
a flowchart is a graphical representation of a process.
● Earlier, flowcharts were used for program design. DFDs represent the flow of data
through the system while flowcharts represent the flow of control in a program.
● DFDs do no having branching and iteration of data whereas flowcharts have
conditional and repetitive representation of process.
Process
● A process shows a transformation or manipulation of data flows within the system.
The process is represented by circle. The data flows of the opened process are
connected in the new diagram to the process with the name of the opened process.
● Vertices, and the flows and objects connected to them, are transferred with the flows
that are connected to the decomposed process.
● If a data process has decomposition at a lower level; an asterisk is placed inside the
ellipse. The data process can be opened only if it has a name.

Data flow
● A data flow moves data between processes or between processes and data stores. As
such, it represents a data value at some point within a computation and an
intermediate value within a computation if the flow is internal to the diagram. This
value is not changed.

9
 Software Engineering, Unit -2

● The names of input and output flows can indicate their roles in the computation or
the type of the value they move. Data names are preferably nouns. The name of a
typical piece of data, the data aspect, is written alongside the arrow.
Data store
● A data store stores data passively for later access. A data store responds to requests to
store and access data. It does not generate any operations. A data store allows values
to be accessed in an order different from the order in which they were generated.
● Input flows indicate information or operations that modify the stored data such as
adding or deleting elements or changing values. Output flows indicate information
retrieved from the store; this information can be an entire value or a component of a
value.
Actor
● An actor produces and consumes data, driving the DFD. Actors lie on the boundary
of the diagram; they terminate the flow of data as sources and sinks of data. They are
also known as terminators.
● Data flows between an actor and a diagram are inputs to and outputs of the diagram.
The system interacts with people through the actor.

8. Write short notes on data-oriented analysis

● Data oriented analysis is also referred to as data oriented modeling which aims at
conceptual representation of the business requirements. A data model is the
abstraction of the data structures required by a database rather than the operations on
those data structures.

10
 Software Engineering, Unit -2

● Abstraction represents the view of the real physical environment that the user
observes in the business. A data model is independent of hardware and software
constraints that are used to implement the database.
● Without analyzing data models, it is not possible to design database. Data oriented
analysis is performed using entity relationship modeling (ERM).
Entity – relationship Modeling
● In software engineering, an entity–relationship model (ER model) is a data model for
describing the data or information aspects of a business domain or its process
requirements, in an abstract way that lends itself to ultimately being implemented in
a database such as a relational database.
● The main components of ER models are entities (things) and the relationships that
can exist among them.
● Entity–relationship modeling was developed by Peter Chen and published in a 1976
paper However; variants of the idea existed previously, and have been devised
subsequently such as super type and subtype data entities and commonality
relationships.
Entity
● An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. For example, in a school database, students, teachers, classes, and
courses offered can be considered as entities.
● All these entities have some attributes or properties that give them their identity.
● An entity set is a collection of similar types of entities. An entity set may contain
entities with attribute sharing similar values.
● For example, a Students set may contain all the students of a school; likewise a
Teachers set may contain all the teachers of a school from all faculties. Entity sets
need not be disjoint.

Attributes:

● Entities are represented by means of their properties, called 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.

Types of Attributes

● Simple attribute − Simple attributes are atomic values, which cannot be divided
further. For example, a student's phone number is an atomic value of 10 digits.
● Composite attribute − Composite attributes are made of more than one simple

11
 Software Engineering, Unit -2

attribute. For example, a student's complete name may have first_name and
last_name.

● Derived attribute − Derived attributes are the attributes that do not exist in the
physical database, but their values are derived from other attributes present in the
database. For example, average_salary in a department should not be saved directly
in the database, instead it can be derived. For another example, age can be derived
from data_of_birth.

● Single-value attribute − Single-value attributes contain single value. For example −

Social_Security_Number.

● Multi-value attribute − Multi-value attributes may contain more than one values.
For example, a person can have more than one phone number, email_address, etc.

Relationship:

● Relationships are represented by diamond-shaped box. Name of the relationship is

written inside the diamond-box. All the entities (rectangles) participating in a
relationship, are connected to it by a line.

Binary Relationship and Cardinality

● A relationship where two entities are participating is called a binary relationship.

Cardinality is the number of instance of an entity from a relation that can be associated
with the relation.
● One-to-one − when only one instance of an entity is associated with the relationship, it is
marked as '1:1'. The following image reflects that only one instance of each entity should
be associated with the relationship. It depicts one-to-one relationship.

12
 Software Engineering, Unit -2

● One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one instance of
entity on the left and more than one instance of an entity on the right can be associated
with the relationship. It depicts one-to-many relationship.

● Many-to-one − when more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

● Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with the
relationship. It depicts many-to-many relationship.

13
 Software Engineering, Unit -2

Generalization:

● As mentioned above, the process of generalizing entities, where the generalized entities
contain the properties of all the generalized entities is called generalization. In
generalization, a number of entities are brought together into one generalized entity
based on their similar characteristics. For example, pigeon, house sparrow, crow and
dove can all be generalized as Birds.

Specialization:

● Specialization is the opposite of generalization. In specialization, a group of entities is

divided into sub-groups based on their characteristics. Take a group ‘Person’ for
example. A person has name, date of birth, gender, etc. These properties are common in
all persons, human beings. But in a company, persons can be identified as employee,
employer, customer, or vendor, based on what role they play in the company.

● Similarly, in a school database, persons can be specialized as teacher, student, or a staff,

based on what role they play in school as entities.

14
 Software Engineering, Unit -2

9. Write short notes on object oriented analysis.

● Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system's
object model, which comprises of interacting objects.
● In the system analysis or object-oriented analysis phase of software development, the
system requirements are determined, the classes are identified and the relationships
among classes are identified.
● The object-oriented approach has two aspects, object-oriented analysis (OOA) and
object-Oriented design (OOD). OOA using the concept of object modeling technique
(OMT). OOA deals with the engineering requirements and modelling the application in
the problem domain. The most common concepts and the constructs used in OOA are
Objects and Classes:
● Object – Objects are the real world entities that can uniquely be identified and
distinguished from other objects. Each object has certain attributes (state) and operations
(behaviour). Similar objects are grouped together to form a class.
● Classes are formed by identifying the common attributes, common operations and
common relationships in the similar objects. Attributes are the data values of an object.
Operations of the services or functions of an object in a class. An object communicates
to other objects through message passing or signatures.
● In OMT, a class is represented through class diagram, which is indicated by a rectangle
with its three parts: First part for class name, second part for its attributes and third part
for operations. Objects are shown through object diagrams, which are also represented as
class diagrams but with rounded rectangle.
● Association: Association is a relationship between classifiers, which is used to show that
instances of classifiers could be either linked to each other or combined logically or
physically into some aggregation.
● UML specification categorizes association as semantic relationship. Some other UML
sources also categorize association as a structural relationship. Wikipedia states that
15
 Software Engineering, Unit -2

association is instance level relationship and that associations can only be shown on class
diagrams. Not sure where they got that information from but it is not based on UML
specification. Association could be used on different types of UML structure diagrams:

10. Explain briefly about object oriented analysis method.

● OOA in the OMT approach starts with problem statement of the real world situation
expressed by the customer. Based on the problem statement, following three kinds of
modeling are performed to produce the object-oriented analysis model
Object modelling
● Object modelling develops the static structure of the software system in terms of
objects. It identifies the objects, the classes into which the objects can be grouped
into and the relationships between the objects.
● It also identifies the main attributes and operations that characterize each class.
● The process of object modelling can be visualized in the following steps:
o Identify objects and group into classes
o Identify the relationships among classes
o Create user object model diagram
o Define user object attributes
o Define the operations that should be performed on the classes
o Review glossary
Dynamic Modelling:
● After the static behaviour of the system is analysed, its behaviour with respect to time
and external changes needs to be examined. This is the purpose of dynamic
modelling.
● Dynamic Modelling can be defined as “a way of describing how an individual object
responds to events, either internal events triggered by other objects, or external
events triggered by the outside world”.
● The process of dynamic modelling can be visualized in the following steps:
16
 Software Engineering, Unit -2

o Identify states of each object

o Identify events and analyze the applicability of actions
o Construct dynamic model diagram, comprising of state transition diagrams
o Express each state in terms of object attributes
o Validate the state–transition diagrams drawn
Functional Modelling:
● Functional Modelling is the final component of object-oriented analysis. The
functional model shows the processes that are performed within an object and how
the data changes as it moves between methods.
● It specifies the meaning of the operations of object modelling and the actions of
dynamic modelling. The functional model corresponds to the data flow diagram of
traditional structured analysis.
● The process of functional modelling can be visualized in the following steps:
o Identify all the inputs and outputs
o Construct data flow diagrams showing functional dependencies
o State the purpose of each function
o Identify constraints
o Specify optimization criteria
11. Explain about Prototyping Analysis
● Traditional Approaches, such as process-oriented, data-oriented, object oriented
approaches, work well if all the requirements are known in advance and less user
interaction is required for long term projects. Prototyping takes different approach for
elicitation, analysis, and validation of the requirements.
● This approach is more suitable where requirements are not know in advance, rapid
delivery of the product is required, and the customer involvement is necessary in
software development. Prototyping is an iterative approach that begins with the
partial development of executable model of the system.
● It is then demonstrated to the customer for the collection of feedback. The model is
evaluated and modified for the final system development. Prototype can be
developed either using automated tools, such as Visual basics, PHP (Hyper Text
pre-processor), 4GL (Forth Generation Language), or paper sketching.
● Prototyping have several benefits. The requirements are understood early and
misunderstanding or conflicts are resolved through customer feedback during
prototype development.
● The final prototype may be considered as the basis for writing the SRS document.
There are two types of approaches widely used for elicitation, analysis, and
requirement validation:

17
 Software Engineering, Unit -2

▪ Throwaway Prototyping

▪ Evolutionary Prototyping

Throwaway Prototyping:
● It is also called close-ended prototyping. Throwaway or Rapid Prototyping refers to
the creation of a model that will eventually be discarded rather than becoming part of
the final delivered software.
● After preliminary requirements gathering is accomplished, a simple working model
of the system is constructed to visually show the users what their requirements may
look like when they are implemented into a finished system. It is also a Rapid
Prototyping.
● Rapid Prototyping involved creating a working model of various parts of the system
at a very early stage, after a relatively short investigation. The method used in
building it is usually quite informal, the most important factor being the speed with
which the model is provided.
● The model then becomes the starting point from which users can re-examine their
expectations and clarify their requirements. When this has been achieved, the
prototype model is 'thrown away', and the system is formally developed based on the
identified requirements.
● The objective of throw-away prototyping is to ensure that the system requirements
are validated and that they are clearly understood.
● The throw-away prototype is NOT considered part of the final system. It is simply
there to aid understanding and reduce the risk of poorly defined requirements. The
full system is being developed alongside the prototypes and incorporates the changes
needed.
● The advantage of this approach is the speed with which the prototype is put together.
It also focuses the user on only one aspect of the system so keeping their feedback
precise.
● One disadvantage with throw-away prototyping is that developers may be
pressurized by the users to deliver it as a final system! Another issue is that all the
man-hours of putting together the throw away prototypes are lost unlike the
evolutionary approach. But the benefits may outweigh the disadvantages. Which
approach to use (evolutionary or throw-away) will depend on the nature of the
system being developed?

18
 Software Engineering, Unit -2

Evolutionary Prototyping:
● Evolutionary prototyping (also known as breadboard prototyping) is quite different
from Throwaway Prototyping. The main goal when using Evolutionary Prototyping
is to build a very robust prototype in a structured manner and constantly refine it. The
reason for this is that the Evolutionary prototype, when built, forms the heart of the
new system, and the improvements and further requirements will be built.
● The objective of this approach is to first find out the core element of the software to
be developed, which is the most important part of the software. Then, the next layer
is found out. This process is continued until the final product is compete.
● Like the throw away model after development of each part of the product, it is send
to the customer for verification after the customer says ok, then the next step is
continued. If the customer has suggested any changes than the changes are carried
out and again the product is send to the customer for verification again.
● This process is continues until a positive comment comes from the customer side.
● Unlike the throw away protocol, where after the idea or design is accepted by the
customer, the design is not used in the final design of the software. But in
evolutionary approach as it is an incremental one, the design in each step is stored for
the future reference to know what are things implemented in previous steps.
● The best part of this approach is that if any fault found out in next stages, which is
rare as verification is done in each step before going to next step, the source of the
fault can be easily found out and the correction is done to make the final product
error free and user acceptable standard but this is missing in case of the throw away
protocol.

19
 Software Engineering, Unit -2

12. Write short notes on requirement specification

● Requirements specification in systems engineering and software engineering is the

direct result of a requirements analysis and can refer to SRS.
● Software requirement specification (SRS) is a document that completely describes
what the proposed software should do without describing how software will do it.
● The basic goal of the requirement phase is to produce the SRS, Which describes the
complete behaviour of the proposed software. SRS is also helping the clients to
understand their own needs.
Advantages
● Software SRS establishes the basic for agreement between the client and the supplier
on what the software product will do.
1. A SRS provides a reference for validation of the final product.
2. A high-quality SRS is a prerequisite to high-quality software.
3. A high-quality SRS reduces the development cost.
Characteristics of SRS
● Software requirements specification should be accurate, complete, efficient, and of
high quality, so that it does not affect the entire project plan. An SRS is said to be of
high quality when the developer and user easily understand the prepared document.
Other characteristics of SRS are discussed below.
1. Correct: SRS is correct when all user requirements are stated in the requirements
document. The stated requirements should be according to the desired system.
This implies that each requirement is examined to ensure that it (SRS) represents
user requirements. Note that there is no specified tool or procedure to assure the
correctness of SRS. Correctness ensures that all specified requirements are
performed correctly.
2. Unambiguous: SRS is unambiguous when every stated requirement has only one
interpretation. This implies that each requirement is uniquely interpreted. In case
there is a term used with multiple meanings, the requirements document should
specify the meanings in the SRS so that it is clear and easy to understand.
3. Complete: SRS is complete when the requirements clearly define what the
software is required to do. This includes all the requirements related to
performance, design and functionality.

20
 Software Engineering, Unit -2

4. Ranked for importance/stability: All requirements are not equally important,

hence each requirement is identified to make differences among other
requirements. For this, it is essential to clearly identify each requirement.
Stability implies the probability of changes in the requirement in future.
5. Modifiable: The requirements of the user can change, hence requirements
document should be created in such a manner that those changes can be modified
easily, consistently maintaining the structure and style of the SRS.
6. Traceable: SRS is traceable when the source of each requirement is clear and
facilitates the reference of each requirement in future. For this, forward tracing
and backward tracing are used. Forward tracing implies that each requirement
should be traceable to design and code elements. Backward tracing implies
defining each requirement explicitly referencing its source.
7. Verifiable: SRS is verifiable when the specified requirements can be verified
with a cost-effective process to check whether the final software meets those
requirements. The requirements are verified with the help of reviews. Note that
unambiguity is essential for verifiability.
8. Consistent: SRS is consistent when the subsets of individual requirements
defined do not conflict with each other. For example, there can be a case when
different requirements can use different terms to refer to the same object.

13. What are Petri nets Explain?

Ans:- A Petri Net is a graphical and mathematical modeling tool used to describe and study
information processing systems of various types.
Petri Nets originate from the dissertation of Carl Adam Petri to the faculty of Mathematics and
Physics at the Technical
University of Darmstadt, West Germany in 1962.
As a mathematical tool, it can be used to set up algebraic equations, state equations, and other
mathematical models governing systems.
Due to the nature of the tool, it also lends itself rather handily to the modeling of logical
systems, including those that may occur in computer science or communication systems.

● A petri net is drawn as a directed, weighted, bipartite graph.

● A bipartite graph is a graph with
two distinct sets of nodes such that there are no edges between nodes of the same set.
● In the case of petri nets, these two sets are defined as places and transitions.
● Typically, places are represented
as circles and transitions as either bars or boxes.
● The edges between nodes are defined as arcs.

21
 Software Engineering, Unit -2

-----

A petri net has states, designated as markings. Each marking corresponds to an assignment of
some non- negative integer k to each place p.
This corresponds to the place being 'marked' with k tokens, which are represented on the graph
typically as smaller black circles within each place.
Normally, there is no limit to the number of tokens which may mark a given place.

An arc, either from a place to a transition or from a transition to a place, has some weight k.
An arc with weight k is functionally the same as there being k arcs of weight 1.
A place with an arc from itself to a transition is an input place, and a place with
an arc from a transition to itself is an output place.

22
 Software Engineering, Unit -2

Formally, a Petri Net is defined as a 5-Tuple in the form: PN=(P,T,F,W,M0) Where:

● P = {p1...pn} is a finite set of places.
T = {t1...tn} is a finite set of transitions.
F ⊆ (P x T) ○ (T x P) is a finite set of arcs. W : F → {1,2,3…} is a weight function.
M0 : P → {0,1,2…} is some initial marking.
P ∩ T = {}
P ○ T ≠ {}
A Petri Net structure with no initial marking may be defined as N=(P,T,F,W).
Likewise, given a structure N with no initial marking, a Petri Net may be defined as PN =
(N,M0).
● Given this formalization, there is a firing rule, which has three parts.
1. A transition t is enabled if each input place p of t is marked with at least w((p,t)) tokens
(where w((p,t)) is the weight of the arc from p to t).
2. An enabled transition t
may or may not fire.
3. The firing of an enabled transition t removes w((p,t)) tokens from each input place p of
t and adds w((t,p')) tokens to each output place p' of t.

A transition does not need to have both input and output.

● A transition with no input places is referred to as a source transition and a transition
with no output places is called a sink transition. A source transition is always enabled.
● A tuple (p,t) is called a self- loop if p is both an input place and output place of t. A
petri net which contains no self loops is called pure.
● A petri net whose arcs all have weight of 1 is called ordinary.

23
 Software Engineering, Unit -2

Important Questions
1. Explain about requirement engineering.
2. Explain about software requirements
3. Explain about requirements engineering process
4. Explain briefly about requirement elicitation
5. List out the requirement elicitation technique
6. Write short notes of requirement analysis.
7. Write short notes on data-oriented analysis.
8. Write short notes on object oriented analysis.
9. Explain about prototyping analysis
10. Short notes on requirement specification
11. Explain components of SRS
12. What are Petri Nets.Explain in Detail

24