Unit-II

 Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing the
need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a proposed system's intended
behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

Requirements elicitation is perhaps the most difficult, most error-prone and most communication
intensive software development. It can be successful only through an effective customer-
developer partnership. It is needed to know what the users really need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed below –
• Knowledge of the overall area where the systems is applied.
• The details of the precise customer problem where the system are going to be applied must
be understood.
• Interaction of system with external requirements.
• Detailed investigation of user needs.
• Define the constraints for system development.

Requirements elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.

1. Interviews: Objective of conducting an interview is to understand the customer’s expectations

from the software. It is impossible to interview every stakeholder hence representatives
from groups are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

2. Brainstorming Sessions:
• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share views
A highly trained facilitator is required to handle group bias and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of requirements and their priority
if possible.

3. Facilitated Application Specification Technique: It’s objective is to bridge the expectation

gap – difference between what the developers think they are supposed to build and what
customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a
draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment: In this technique customer satisfaction is of prime concern,
hence it emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements – In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
 Expected requirements – These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
 Exciting requirements - –
It includes features that are beyond customer’s expectations and prove to be very satisfying
when present. Example – when unauthorized access is detected, it should backup and
shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off

5. Use Case Approach: This technique combines text and pictures to provide a better
understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system. The components of the use case design includes
three major things – Actor, Use cases, use case diagram.
1. Actor – It is the external agent that lies outside the system but interacts with it in some way.
An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be
primary actors or secondary actors.
• Primary actors – It requires assistance from the system to achieve a goal.
• Secondary actor – It is an actor from which the system needs assistance.
2. Use cases – They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.

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

 Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine,
and scrutinize the gathered requirements to make consistent and unambiguous requirements.
This activity reviews all requirements and may provide a graphical view of the entire system.
After the completion of the analysis, it is expected that the understandability of the project may
improve significantly. Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important than others.

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the
boundaries and interfaces of the proposed systems with the external world. It identifies the
entities outside the proposed system that interact with the system. The context diagram of
student result management system is given below:

(ii) Development of a Prototype (optional): One effective way to find out what the
customer wants is to construct a prototype, something that looks and preferably acts as part of
the system they say they want.

We can use their feedback to modify the prototype until the customer is satisfied continuously.
Hence, the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure about some of the
elements, a prototype may help both the parties to take a final decision.
Some projects are developed for the general market. In such cases, the prototype should be
shown to some representative sample of the population of potential purchasers. Even though a
person who tries out a prototype may not buy the final system, but their feedback may allow us
to make the product more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical
representations of the functions, data entities, external entities, and the relationships between
them. The graphical view may help to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been identified
and corrected. The flow of data amongst various modules has been analyzed. Elicitation and
analyze activities have provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a prescribed format.

 Engineering requirements document:- An engineering requirements document (ERD) is

a statement describing the goal and purpose of a new component. Unlike a product
requirements document (PRD), which tells engineers what they need to build, an ERD
specifies why a part is being built and how its design fuels its purpose. By following the
engineering requirements outlined in an ERD, engineers can ensure that the part they build
will satisfy customer needs. Using an ERD also helps streamline production in various ways:

1. ERDs use defined and consistent communication to promote collaboration,

reduce miscommunication, and keep everyone on the same page.
2. ERDs help break down large projects into smaller tasks, making them easier to
delegate or outsource.
3. ERDs can be checked against PRDs to ensure all design intentions are correctly
implemented and all product goals are achieved.

A well-written ERD allows engineers and manufacturers to answer critical questions about part
design and purpose without going back and forth. This results in a faster, more efficient building
process that saves you time and money. Here’s everything you need to know to write a clear and
effective engineering requirements document.

Requirements needed before developing software:- 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.

Requirement reviews:-In short, Requirement review is the practice of scanning the software
errors to make the industry user-friendly for all.

Requirement review performed:-Software in the current time is so Advanced that the act of
requirement review holds greater importance in software development. The pursuance of
requirement reviews helps to have a clear peek into the space of the software industry. The
requirement reviews call attention to the only chance of finding quality reviews. So keeping in
mind that there are problems and solutions to everything, a requirement review needs a good
performance.

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 in Software Engineering :
It is a study to evaluate feasibility of proposed project or system. Feasibility study is one of stage
among important four stages of Software Project Management Process. As name suggests
feasibility study is the feasibility analysis or it is a measure of the software product in terms of
how much beneficial product development will be for the organization in a practical point of
view. 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.

Types of Feasibility Study : The feasibility study mainly concentrates on below five mentioned
areas. Among these Economic Feasibility Study is most important part of the feasibility analysis
and Legal Feasibility Study is less considered feasibility analysis.

1. 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. Along with this, feasibility study also analyzes
technical skills and capabilities of technical team, existing technology can be used or not,
maintenance and up-gradation is easy or not for chosen technology etc.

2. 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. Along with this other operational scopes are determining
usability of product, Determining suggested solution by software development team is
acceptable or not etc.

3. 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.

4. 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. Overall it can be said that Legal
Feasibility Study is study to know if proposed project conform legal and ethical
requirements.

5. 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 : The below steps are carried out during entire feasibility analysis.

1. Information assessment
2. Information collection
3. Report writing
4. General information
Need of Feasibility Study : Feasibility study is so important stage of Software Project
Management 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.
Along with this 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.

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.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown
in fig:

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.

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. It is essential to preserve the number of inputs and outputs
between levels, this concept is called leveling by DeMacro. Thus, if bubble "A" has two inputs
x1 and x2 and one output y, then the expanded DFD, that represents "A" should have exactly two
external inputs and one external output as shown in fig:

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.
Entity-Relationship Diagrams
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.

1. 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.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with
attribute sharing similar values. For example, a Student set may contain all the students of a
school; likewise, a Teacher set may include all the teachers of a school from all faculties.

2. 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:

 1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an
entity among the entity set. For example, the roll_number of a student makes him identifiable
among students.

There are mainly three types of keys:

1) Super key: A set of attributes that collectively identifies an entity in the entity set.
2) Candidate key: A minimal super key is known as a candidate key. An entity set may
have more than one candidate key.
3) Primary key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.
2. 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.

3. Single-valued attribute: Single-valued attribute contain a single value. For example,

Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a
multivalued attribute. Multi-valued attributes are depicted by the double ellipse. For example, a
person can have more than one phone number, email-address, etc.

5. 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. For example,
age can be derived from date_of_birth. In the ER diagram, Derived attributes are depicted by
the dashed ellipse.

3. Relationships
The association among entities is known as relationship. Relationships are represented by the
diamond-shaped box. For example, an employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls are called relationships.
Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a relationship
too can have attributes. These attributes are called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the degree of the relationship.
The three most common relationships in E-R models are:
Unary (degree1)
Binary (degree2)
Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is a relationship
between the instances of one entity type. For example, one person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two entity types. For
example, the Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig,

the relationships "may have" provide the association of three entities, i.e., TEACHER,
STUDENT, and SUBJECT. All three entities are many-to-many participants. There may be one
or many participants in a ternary relationship.
In general, "n" entities can be related by the same relationship and is known as nary relationship.
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the
number of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of
entity set B and vice versa. Let us assume that each student has only one student ID, and each
student ID is assigned to only one person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one
instances of another entity then it is called one to many relationships. For example, a client can
place many orders; a order cannot be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than one
entity from entity set A. For example - many students can study in a single college, but a student
cannot study in many colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B
and vice-versa. For example, the student can be assigned to many projects, and a project can be
assigned to many students.

Using Sets, it can be represented as:

Decision Table in Software Testing

The decision table is a software testing technique which is used for testing the system behavior
for different input combinations. This is a systematic approach where the different input
combinations and their corresponding system behavior are captured in a tabular form.
This table helps you deal with different combination inputs with their associated outputs. Also,
it is known as the cause-effect table because of an associated logical diagramming technique
called cause-effect graphing that is basically used to derive the decision table.
Importance of Decision Table
A decision table is an outstanding technique used for testing and requirements management.
Some of the reasons why the decision table is important include:

Decision tables are very much helpful in test design technique.

It helps testers to search the effects of combinations of different inputs and other software states
that implement business rules.
It provides a regular way of stating complex business rules which benefits the developers as well
as the testers.
It assists in the development process with the developer to do a better job. Testing with all
combination might be impractical.
It the most preferable choice for 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.
Advantages of Decision Table in Software Testing
There are different advantages of using the decision table in software testing such as:
Any complex business flow can be easily converted into the test scenarios & test cases using
this technique.
Decision tables work iteratively. Therefore, the table created at the first iteration is used as the
input table for the next tables. The iteration is done only if the initial table is not satisfactory.
Simple to understand and everyone can use this method to design the test scenarios & test cases.
It provides complete coverage of test cases which help to reduce the rework on writing test
scenarios & test cases.
These tables guarantee that we consider every possible combination of condition values. This is
known as its completeness property.
Way to use Decision Table: Example
A Decision Table is a tabular representation of inputs versus rules, cases or test conditions. Let’s
take an example and see how to create a decision table for a login screen:

The condition states that if the user provides the correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.
In the above example,
T – Correct username/password
F – Wrong username/password
E – Error message is displayed
H – Home screen is displayed
Now let’s understand the interpretation of the above cases:
Case 1 – Username and password both were wrong. The user is shown an error message. Case
2 – Username was correct, but the password was wrong. The user is shown an error message.
Case 3 – Username was wrong, but the password was correct. The user is shown an error
message.
Case 4 – Username and password both were correct, and the user is navigated to the homepage.
So, this was an example of building a decision table in software testing. with this we have come
to the end of this article.

Software Requirements Specifications (SRS)

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the system
requirements.
The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who
is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various situations and
establish different purposes for the document altogether. The first case, SRS, is used to define
the needs and expectation of the users. The second case, SRS, is written for various purposes
and serves as a contract document between customer and developer.

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.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.
Skip Ad
2. 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.
Note: It is essential to specify the responses to both valid and invalid values.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of
all terms and units of measure.
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's 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
particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.
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
costeffective 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.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.
The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to
be able to ascertain the complete set of requirements that may be concerned by those
modifications.

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 or not requirements have been
met in an implementation.

Software requirements specification and IEEE standards

The heart of the SRS consists of descriptions of both functional and nonfunctional requirements.
The IEEE standard provides several suggestions of how to organize functional requirements: by
mode, user class, object, feature, stimulus, functional hierarchy or combinations of these criteria.
There is no single organizational approach that's best; use whatever makes sense for your
project. I have used the IEEE SRS template numerous times. While most of it makes sense, I
found a few quirks of IEEE standards that led me to create a modified version of the template.
Organizations and project teams should tailor and customize such templates to best suit the
nature and scale of their projects.

Concepts were include in an SRS

While standards might change for requirements documentation over time, they remain vital to
projects, as they ensure software is developed as intended. If your team develops software
features on a whim, it can dig itself a deep hole on a project. Documentation helps keep agendas
aligned, which makes it well worth the extra effort.
Senior Technology Editor Stephen Bigelow explained the goals and benefits of an SRS. When
it comes to enterprise software development, an SRS should detail compliance, security,
performance, database and customer needs to eliminate guesswork for developers.
But what should the SRS specifically include? Bigelow provided some recommendations for
how to structure an SRS to make it as comprehensive as possible.
Evaluate your standards
IEEE standards result from the collaboration of dozens of practitioners worldwide. They're
meant to reflect the best of what is known about how to address a specific software engineering
domain. However, companies don't have to follow IEEE standards, as no outside agency
enforces a universal standard. Some organizations might mandate that their project teams or
subcontractors follow certain standards but not others.
Generally, view IEEE standards for SRS documentation as a representation of the collective
knowledge of many smart people who have worked on software projects over the last several
decades. I recommend that you start with existing materials, like the IEEE standards, rather than
create your own SRS model from scratch.