Chapter 02 :- Software Requirements Engineering Marks = 16

2.1 Software Engineering Practices - Definition, Importance, Essence

Definition :- “Practice” is collection of concept, principles, methods and tools

those are consider while planning & developing software.

Importance of practices:-
- Software engineering practices play very important role in development of
software product.
- The most important thing is that customer satisfaction, Software engineering
practices helps in achieving expected goals.
- These practices help in delivering best product & sustain in market long
time.
- Practices help at every stage of the development.
- It is also provide guidelines related to maintenance.

Essence of practice:
Understand the problem (communication and analysis)
- Who has a stake in the solution to the problem?
- What are the unknowns (data, function, behavior)?
- Can the problem be compartmentalized?
- Can the problem be represented graphically?
Plan a solution (planning, modeling and software design)
- Have you seen similar problems like this before?
- Has a similar problem been solved and is the solution reusable?
- Can sub problems be defined and are solutions available for the
Sub problems?
Carry out the plan (construction; code generation)
- Does the solution conform to the plan? Is the source code traceable back to the
design?
- Is each component of the solution correct? Has the design and code been
reviewed?
Examine the results for accuracy (testing and quality assurance)
- Is it possible to test each component of the solution?
- Does the solution produce results that conform to the data, function, and behavior
that are required?
1

2.2 Core Principles of Software Engineering

Page

SVERI’s COE(Polytechnic), Pandharpur

1. The Reason It All Exists
2. Keep It Simple, Stupid!
3. Maintain the Vision
4. What You Produce, Others Will Consume.
5. Be Open to the Future
6. Plan Ahead for Reuse
7. Think!

1. The Reason It All Exists

A software system exists for one reason: To provide value to its users. All
decisions should be made with this in mind. Before specifying a system
requirement, before noting a piece of system functionality, before determining the
hardware platforms or development processes, ask yourself questions such as:
"Does this add real VALUE to the system?" If the answer is "no", don't do it. All
other principles support this one.
2. Keep It Simple, Stupid!
There are many factors to consider in any design effort. All design should be as
simple as possible, but no simpler. This facilitates having a more easily
understood, and easily maintained system.
3. Maintain the Vision
A clear vision is essential to the success of a software project. Without one, a
project almost unfailingly ends up being "of two [or more] minds" about itself.
Compromising the architectural vision of a software system weakens and will
eventually break even the most well designed systems. Having an empowered
Architect who can hold the vision and enforce compliance helps ensure a very
successful software project.
4. What You Produce, Others Will Consume
Seldom is an industrial-strength software system constructed and used in a
vacuum. In some way or other, someone else will use, maintain, document, or
otherwise depend on being able to understand your system. So, always specify,
design, and implement knowing someone else will have to understand what you
are doing. The audience for any product of software development is potentially
large. Making their job easier adds value to the system.
5. Be Open to the Future
A system with a long lifetime has more value. In today's computing environments,
where specifications change on a moment's notice and hardware platforms are
obsolete when just a few months old, software lifetimes are typically measured in
months instead of years. However, true "industrial-strength" software systems must
2

endure far longer. To do this successfully, these systems must be ready to adapt to
Page

these and other changes. Systems that do this successfully are those that have been

SVERI’s COE(Polytechnic), Pandharpur

designed this way from the start. Never design yourself into a corner. Always ask
"what if ", and prepare for all possible answers by creating systems that solve the
general problem, not just the specific one. This could very possibly lead to the
reuse of an entire system.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest
goal to accomplish in developing a software system. The reuse of code and designs
has been proclaimed as a major benefit of using object-oriented technologies.
However, the return on this investment is not automatic. How can you reuse
something that you don't know exists? Planning ahead for reuse reduces the cost
and increases the value of both the reusable components and the systems into
which they are incorporated.
7. Think!
This last Principle is probably the most overlooked. Placing clear, complete
thought before action almost always produces better results. When you think about
something, you are more likely to do it right. You also gain knowledge about how
to do it right again. If you do think about something and still do it wrong, it
becomes valuable experience. A side effect of thinking is learning to recognize
when you don t know something, at which point you can research the answer.
When clear thought has gone into a system, value comes out. Applying the first six
Principles requires intense thought, for which the potential rewards are enormous.

2.3 Communication Practices

Principle 1. Listen Carefully.

Try to focus on the speaker’s words, rather than formulating your response to those
words. Ask for clarification if something is unclear, but avoid constant
interruptions. Never become contentious in your words or actions (e.g., rolling
your eyes or shaking your head) as a person is talking.
Principle 2. Prepare before you communicate.
Spend the time to understand the Problem before you meet with others. If
necessary, do some research to understand business domain. If you have
responsibility for conducting a meeting, prepare an agenda in advance of the
meeting.
Principle 3. Someone should facilitate the activity.
Every communication meeting should have a leader (a facilitator) to keep the
conversation moving in a productive direction, to mediate any conflict that does
occur, and to ensure that other principles are followed.
3

Principle 4. Face-to-face communication is best.

Page

SVERI’s COE(Polytechnic), Pandharpur

Face to face communication is always makes sense. It usually works better when
some other representation of the relevant information is present. For example, a
participant may create a drawing document that serves as a focus for discussion.
Principle 5. Take notes and document decisions.
Things have a way of falling into the cracks. Someone participating in the
communication should serve as a “recorder” and write down all important points
and decisions.
Principle 6. Strive for collaboration.
Collaboration occurs when the collective knowledge of members of the team is
used to describe product or system functions or features. Each small collaboration
serves to build trust among team members and creates a common goal for the team.
Principle 7. Stay focused; modularize your discussion.
The more people involved in any communication, the more likely that discussion
will bounce from one topic to the next. The facilitator should keep the
conversations modular; leaving one topic only after it has been resolved.
Principle 8. If something is unclear, draw a picture:
Verbal communication goes only so far. A sketch or drawing can often provide
clarity when words fail to do the job.
Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree
to something, move on. (c) If a feature or function is unclear and cannot be
clarified at the moment, move on.
Communication, like any software engineering activity, takes time. Rather than
iterating endlessly, the people who participate should recognize that many topics
require discussion and that “moving on” is sometimes the best way to
achieve communication agility.
Principle 10. Negotiation is not a contest or a game.
It works best when both parties win. There are many instances in which you and
other stakeholders must negotiate functions and features, priorities, and delivery
dates. If the team has collaborated well, all parties have a common goal. Still,
negotiation will demand compromise from all parties.

2.4 Planning Practices

Principle 1. Understand the scope of the project.
It’s impossible to use a road map if you don’t know where you’re going. Scope
provides the software team with a destination.
Principle 2. Involve stakeholders in the planning activity.
Stakeholders define priorities and establish project constraints. To accommodate
these realities, software engineers must often negotiate order of delivery, time
4

lines, and other project-related issues.

Page

Principle 3. Recognize that planning is iterative.

SVERI’s COE(Polytechnic), Pandharpur

 A project plan is never engraved in stone. As work begins, it is very likely that
things will change. As a consequence, the plan must be adjusted to accommodate
these changes. In addition, iterative, incremental process models dictate re-
planning after the delivery of each software increment based on feedback received
from users.
Principle 4. Estimate based on what you know.
The intent of estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work to be done. If
information is vague or unreliable, estimates will be equally unreliable.
Principle 5. Consider risk as you define the plan.
If you have identified risks that have high impact and high probability, contingency
planning is necessary. In addition, the project plan (including the schedule) should
be adjusted to accommodate the likelihood that one or more of these risks will
occur.
Principle 6. Be realistic.
People don’t work 100 percent of every day. Noise always enters into any human
communication. Omissions and ambiguity are facts of life. Change will occur.
Even the best software engineers make mistakes. These and other realities should
be considered as a project plan is established.
Principle 7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a project plan is
developed. A “high-granularity” plan provides significant work task detail that is
planned over relatively short time increments (so that tracking and control occur
frequently). A “low-granularity” plan provides broader work tasks that are planned
over longer time periods. In general granularity moves from high to low as the
project time line moves away from the current date. Over the next few weeks or
months, the project can be planned in significant detail. Activities that won’t occur
for many months do not require high granularity (too much can change).
Principle 8. Define how you intend to ensure quality.
The plan should identify how the software team intends to ensure quality. If
technical reviews are to be conducted, they should be scheduled. If pair
programming is to be used during construction, it should be explicitly defined
within the plan.
Principle 9. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change. You should
identify how changes are to be accommodated as software engineering work
proceeds. For example, can the customer request a change at any time? If a change
is requested, is the team obliged to implement it immediately? How is the impact
5

and cost of the change assessed?

Page

SVERI’s COE(Polytechnic), Pandharpur

Principle 10. Track the plan frequently and make adjustments as required.
Software projects fall behind schedule one day at a time. Therefore, it makes sense
to track progress on a daily basis, looking for problem areas and situations in
which scheduled work does not conform to actual work conducted. When slippage
is encountered, the plan is adjusted accordingly.

2.5 Modeling Practices

• Models are useful for better understanding of actual entity to be built or

design.
• There are two classes of models are created:-
• 1) Analysis model
• 2) Design model
• Analysis Model: – Represent the customer requirement, which includes
algorithmic specifications of program or process. Analysis model includes
three different domains
• a) Information domain
• b) Functional domain
• c) Behavioral domain

• Analysis Modeling principles:-

• 1) The information domain of problem must be clearly represented: –
Analysis model uses “data flow diagram “to show information domain
which includes following detail input flow into system, output flow in
system, data collection by data store to collect data in system.
• 2)The function of software must be defined clearly:-function are process
those transform input flow to output flow so specification must be clearly
defined.
• 3)Behavior of system must be defined clearly:-Analysis model uses state
transition diagram to represent the behavior of system clearly.
• 4) The clear hierarchy among information function and behavior must
be shown: – information, function and behavior of system must be
represented by using proper hierarchy which leads to easy design.
• 5)Analysis should be clear enough to convert it into design model: – it
analysis of requirement is clear and simple then it will be easy for design.
6
Page

SVERI’s COE(Polytechnic), Pandharpur

 Design Modeling Principles :-
• 1. Design must be traceable to analysis Model
analysis model describe the information domain of the problem, User
visible functions, System behavior, and the set of analysis classes that
package business object with the methods that service them
The design model translate this information Into an Architecture: A set of
subsystems that implement major function and set of component level
design
• 2.Always consider architecture
S/W architecture is the skeleton of the To be built. Only after the
architecture is built the component level issue should be considered
• 3. Focus on the design of data It is as important as a Design
Data design is an essential element of the architectural design
• 4. Interfaces (both user and internal) must be designed
Well designed interfaces makes integration easier And assist the tester in
validating component functions.
• 5. User interface design should be tuned to the needs of the end user
“ Ease of use”
• 6. Component level design should be exhibit functional independence.
The functionality that is delivered by a component should be cohesive: It
should focus on one and only one function.
• 7. Components should be loosely coupled to one another and to the
external environment.
Complaints should be kept as low as possible. As the level of coupling
increases, error Propagation also increases and the overall maintainability of
the software decreases
• 8. Design representation (models) should be easily understood
The design models should be developed iteratively with each situation of
the designer should strive for greater simplicity

2.6 Construction Practices

 Construction activity included coding & testing activity

1.Coding :
 Coding activity is related to programming language.
 Design details are implemented using appropriate programming language.
 It include Preparation, Actual coding, Validation phases.
7
Page

SVERI’s COE(Polytechnic), Pandharpur

 1.Preparation principle
 These are the principles are followed before starting the coding
A. Understand the exact problem to which you are trying.
B. Understand the basic design principles.
C. Select appropriate programming language.
D. Select the programming environment that will be suitable for writing
the code
E. Create set of unittests that will be applied once the component you code
is completed

2.Actual coding principles

 These are the principles to be followed while writing the coding

A. Use suitable data structures those are fit for coding.
B. Keep minimum nested condition
C. Keep minimum nested loop.
D. The variable names should be meaningful & as per standards.
E. E. Code must be self-documented, i.e. provide help comments for all the
steps

3.Validation principles

 These are the principles to be followed after complimenting the first coding
pass
A. Conduct the unit test. Test whether the module is producing exact
output.
B. Refactor the code if necessary.
 ( program reorganizing its internal structure without altering its external
behavior ).
C. Conduct a code walkthrough when appropriate.

Testing PRINCIPLES

 Testing is carried out for the purpose

A. To check whether the flow of coding is correct.
B. To check out the errors of the program
C. To check whether the program is giving the expected output as per
8

input specification.
Page

SVERI’s COE(Polytechnic), Pandharpur

 1. Test must be conducted to validate customer’s requirement.
 The basic aim of testing is to find the defects from the developed modules.
 These defects are considered from customer’s point of view. I.e. what
customer wants exactly as output?
 Hence testing must validate customer’s requirements.

2. Tests should be well planed before starting testing work

 Testing plan can be started as soon as analysis module is completed.
 Detailed definition of test case can be started as soon as design module
reaches to final stage.
 Hence all the test can planed before starting actual coding.

3. Testing should begin “in the small” and progress towards testing “in the
large”
 Testing should start from individual units and finally go towards testing of
complete system as whole.
 Software is always divided in to small size and independent components
called as modules.
 As modules are small in size they are easy to understand, easy to test, easy
to debug and easy to modify.
 These modules are called as units. Hence software testing always starts from
unit testing.
 These units are then integrated i.e. combined as per design specification.
 And finally system is tested as a whole.

4. Accept that “testing of every combination of paths is not possible”

 Each software modules as unit contains to many conditions and nested
conditions.
 Hence it is not possible to check out coming results satisfying every
combination of inputs.
 E.g. it is not possible to check every if- else combination of systems.
9
Page

SVERI’s COE(Polytechnic), Pandharpur

Software Deployment

 The software is delivered to the customers who evaluates the delivered

product and provides feedback based on the evaluation.
 The deployment phase includes 3 actions namely
• 1. Delivery 2. Support 3. Feedback
 1. The delivery cycle provides the customer and the end user with an
operational software increment that provides usable functions and features.
 2. The support cycle provides documentation, human assistance for all
functions and features introduced during all deployment cycles to date.
 3. Each feedback cycle provides the software team with useful inputs. The
feedback can help in modifications to the functions, features and even the
approach for the next increments.

Principle of Software Deployment

• 1. Manage customer’s expectations.
 It always happens that customer wants more than he has started earlier as his
requirements. It may be the case that customer gets disappointed, even after
getting all his requirements satisfied. Hence at time of delivery developer
must have skills to manage customer‘s expectations.
• 2. Assembled and test complete delivery package.
 It is not the case that the deliverable package is only software‘. The
customer must get all supporting and essential help from developer‘s side.
• 3.Record-keeping mechanism must be established for customer support.
 Customer support is important factor in deployment phase. If proper support
is not provided, customer will not be satisfied. Hence support should be well
planned and with record-keeping mechanism.
• 4. Provide essential instructions, documentations and manual.
 Many times, developer thinks ―when project is successful deliverable part
is only working program. But realty is that working program is just part of
software product. Actual project delivery includes all documentations, help
files and guidance for handling the software by user.
• 5. Don’t deliver any defective or buggy software to the customer.
 In incremental type of software, software organizations may deliver some
defective software to the customer by giving assurance that the defects will
be removed in next increment.
10
Page

SVERI’s COE(Polytechnic), Pandharpur

 Requirement Engineering

• Characteristics of Requirements:
1. Requirement should be unambiguous –
 if requirement contents ambiguity then it is difficult to fulfill the
requirement correctly.
2. requirement should be testable –
 Tester should be able to easily test the requirement, whether they are
implemented successfully or not?
3. requirement should be clear –
 It should not be contained any unnecessary information. If there is a
necessary information then it becomes difficult to achieve the appropriate
fulfillment of the requirement.
4. Requirement should be understandable –
 Means when anyone read it then it should be understood by the person.
5. Requirement should be feasible(realistic)-
 Should be completed within given time and budget
6. Requirement should be consistent –
 It is important that all inputs must be processes similarly.

 Requirements engineering is a software engineering action that begins

during the communication activity and continues into the modeling activity.

Types of requirements

11
Page

SVERI’s COE(Polytechnic), Pandharpur

 • Functional Requirements:
 These are the requirements that the end user specifically demands as basic
facilities that the system should offer.
 All these functionalities need to be necessarily incorporated into the system
as a part of the contract. These are represented or stated in the form of input
to be given to the system, the operation performed and the output expected.
They are basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.
 For example, in a hospital management system, a doctor should be able to
retrieve the information of his patients.

Functional requirements should include :

 Describe of data to be entered into the system
 Description of operations performed by each screen
 Description of workflow performed by the system
 Description of system reports or other outputs
 Person who can enter the data into the system
 The system its application regulatory requirements.

Non-functional requirements: These are basically the quality constraints

that the system must satisfy according to the project contract. The priority or
extent to which these factors are implemented varies from one project to
other.
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility

 Non functional requirements are classified into three parts

1. Product requirements
2. Organizational requirements
3. External requirements
12
Page

SVERI’s COE(Polytechnic), Pandharpur

1. Product requirements - Requirements which specify that the delivery product
must be behave in a particular way e.g. execution speed, reliability etc
2.Organisational requirements - Requirements which are consequences of
organizational policy and procedures, e.g. Process standard used implementation
requirements etc.
3. External requirements - Requirement which arise from factors which are
external to the system and its development process, e.g. legislative require

Domain requirements:
 Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.
 The basic functions that a system of a specific domain must necessarily
exhibit come under this category.
 For instance, in an academic software that maintains records of a school or
college, the functionality of being able to access the list of faculty and list of
students of each grade is a domain requirement.
 These requirements are therefore identified from that domain model and are
not user specific

Requirements Engineering

 Requirements Engineering uses following 7 functions for Requirement

gathering
 1. Inception
 2. Elicitation
 3. Elaboration
 4. Negotiation
 5. Specification
 6. Validation
 7. Requirements management

1. Inception: - Inception means beginning. It is usually said that requirement

engineering is a―communication intensive activity. The customer and developer
13

meet and they the overall scope and nature of the problem statements. By having
proper inception phase the developer will have clear idea about the system and as
Page

SVERI’s COE(Polytechnic), Pandharpur

a result of that better understanding of a system can be achieved. Once the system
is clear to the developer they can implement a system with better efficiency.
2. Elicitation: - Elicitation task will help the customer to define the actual
requirement of a system. To know the objectives of the system or the project to be
developed is a critical job. This phase will help people to determine the goal of a
system and clear idea about the system can be achieved.
3. Elaboration: - The information obtained from the customer during inception
and elicitation is expanded and refined during elaboration. This requirement
engineering activity focuses on developing a refined technical model of software
functions, features and constraints.
4. Negotiation: - This phase will involve the negotiation between what user actual
expects from the system and what is actual feasible for the developer to build.
Often it is seen that user always expect lot of things from the system for lesser cost.
But based on the other aspect and feasibility of a system the customer and
developer can negotiate on the few key aspect of the system and then they can
proceed towards the implementation of a system
5. Specification: - A specification can be a re-written document, a set of
graphical
models, a formal mathematical model, a collection of usage scenario, a prototype,
or any combinations of these. The specification is the final work product produced
by the requirement engineers. It serves as the foundation for subsequent software
engineering activities. It describes the function and performance of a computer
based system and the constraints that will govern its development.
6. Validation: - The work products produced as a consequence of requirements
engineering are assessed for quality during a validation step. Requirements
validation examines the specification to ensure that all software requirements have
been stated unambiguously; that inconsistencies, omissions and errors have been
detected and corrected, and that the work products conform to the standards
established for the process, the project, and the product.
• During requirement validation process different types of checks should be
carried out on the requirements
1. Validation checks - the function proposed by the stakeholder should be
aligned with what the system needs to perform.
2. Consistency check - requirements in the document shouldn't conflict or with
different description of same function.
3. Completeness check - the document should include all the requirements and
the constrains.
14

4. Realism check- Ensure all the requirements can actually be implemented

using knowledge of existing Technology, the budget, schedule, etc
Page

SVERI’s COE(Polytechnic), Pandharpur

 5. Verifiability - Requirements should be written so that they can be tested.
This means you should able to write the set of test which demonstrate that
system meets the specified requirements.
6. Requirement review - The system developer start reading the requirement in
the document Investigate into great detail to check for errors, inconsistency,
conflicts, and any ambiguity

7. Requirements management:-Requirement management begins with

identification. Each requirement is assigned a unique identifier. Once
requirement have been identified, traceability tables are developed.

Developing Use cases

• Use case is a term used in the system analysis to determine clarify and
integrate all the system requirement.
• It describe how user interact with the system to achieve certain goals.
15

• Use case consists of three basic elements as Actor, system and Goal
• Use case diagram consists of following three main components
Page

1. Use case 2. Actor 3. System Boundary

SVERI’s COE(Polytechnic), Pandharpur

 1. Use case - Use case of use case diagram represent various business activities
performed in the system.
To identify use case of a system one should list all discrete business
activities of the system in the problem statement.
It is represented as elliptical shape with use case name

2. Actor - An actor is any entity or real world object which perform different
function in the given system.
Actor in use case diagram interact with use case of use case diagram.
various roles in the system describe as actors of system in use case diagram.

3. System boundary - define the scope of the system for limits of the system.
System boundary is represented by solid line rectangular box
Use cases are drawn within the system boundary whereas actor is outside of
the system boundary.

• Relationship in Use case diagram

1. Include - When the use case is represented as making use of functionality of

another use case diagram, this relationship between use cases is called as in
include relationship.
• An include relationship is denoted by dotted Arrow with arrow head
pointing towards derived use case.
• Stereotype <<include>> is labeled on arrow.

2. Extend - relationship between two use cases in which child use case adds
new features to existing functionality of parent use case is called extend
relationship.
An extend relationship is denoted by dotted Arrow with arrow head pointing
towards parent use case.
Stereotype <<extend>> is labeled on arrow.
E.g. here percentage helps to decide class of student.

3. Generalization – It is Parent child relationship.

The child use case is an underlying process of system but it enhance parent
16

use case.
It is represented by Arrow with triangular arrow head pointing towards
Page

parent use case.

SVERI’s COE(Polytechnic), Pandharpur

SRS (Software Requirements Specifications) :

A software requirements specification (SRS) is a complete description of the

behavior of the system to be developed.
It includes a set of use cases describe all of the interactions that the users will have
with the software. In addition to use cases, the SRS contains functional
requirements and nonfunctional requirements.
Functional requirements define the internal workings of the software: that is, the
calculations, technical details, data manipulation and processing, and other specific
functionality that shows how the use cases are to be satisfied.
Non-functional requirements impose constraints on the design or implementation
(such as performance requirements, quality standards, or design constraints).
The purpose of SRS document is providing a detailed overview of software
product, its parameters and goals.
SRS document describes the project's target audience and its user interface,
hardware and software requirements. It defines how client, team and audience see
the product and its functionality.

Need/importance of SRS documents:

1. Establish the basis for agreement between the customers and the
suppliers on what the software product is to do. The complete description of
the functions to be performed by the software specified in the SRS will
assist the potential users to determine if the software specified meets their
needs or how the software must be modified to meet their needs. Reduce the
development effort.
The preparation of the SRS forces the various concerned groups in the
customer's organization to consider rigorously all of the requirements before
design begins and reduces later redesign, recoding, and retesting. Careful
review of the requirements in the SRS can reveal omissions,
misunderstandings, and inconsistencies early i/p the development cycle
when these problems are easier to correct.

2. Provide a basis for estimating costs and schedules. The description of the
product to be developed as given in the SRS is a realistic basis for estimating
project costs and can be used to obtain approval for bids or price estimates.
17

3. Provide a baseline for validation and verification. Organizations can

develop their validation and Verification plans much more productively
Page

SVERI’s COE(Polytechnic), Pandharpur

 from a good SRS. As a part of the development contract, the SRS provides a
baseline against which compliance can be measured.

4. Facilitate transfer. The SRS makes it easier to transfer the software product
to new users or new machines. Customers thus find it easier to transfer the
software to other parts of their organization, and suppliers find it easier to
transfer it to new customers.
5. Serve as a basis for enhancement. Because the-SRS discusses the product
but not the project that developed it, the SRS serves as a basis for later
enhancement of the finished product.
The SRS may need to be altered, but it does provide a foundation for
continued production evaluation.

Characteristics of an SRS

• Characteristics of an SRS Software requirements specification should be :

1. Unambiguous : A SRS does not contain any confusion in each specified

requirement has single interpretation.
This state that every requirement is individually interpreted.
If one term has number of meaning then its meaning must be specified in
SRS so that it will be non confusing and simple to understand.

2. Correct : SRS is correct when all requirements of user are described in the
requirement document.
List of requirements must be matched with desired system.
Remember that there is no specific tool or process to ensure the correctness
of SRS.
Correctness give Assurance that all state requirements are worked as
expected

3. Complete : This contain each and every requirement associated to the

performers design and functionality.

4. Ranked for importance/stability : Each and every requirement has not same
importance, so every requirement is recognized to make differentiation
between requirements.
18

Stability refers to the probability of further modifications in the requirement

Page

SVERI’s COE(Polytechnic), Pandharpur

 5. Modifiable : The requirement given by the user are changeable, So
requirement document must be generated in such a way that those
modifications can be included easily in SRS.
6. Traceable : Forward tracing and backward tracing methods are used for this
purpose.
Forward tracing state that every requirements must be referencing to design
and code of components.
Backward tracing state that every requirement explicitly addressing its
source.
7. Verifiable : SRS is stable when the stated requirement can be tested with
cost effective procedure to verify whether the final software fulfill those
requirement. The requirement are tested through reviews.

Format of SRS

• It includes following section with various of subsections in it:

1. Introduction : It contain brief information of SRS.
Purpose : This section specifies the main purpose of SRS document with
intended user for whom SRS is constructed.
Scope : It shows limitations of the software so as to understand the
boundary of the software
Definition acronyms and Abbreviations : to avoid ambiguity.
References : it contains all list of documents which are referred by this
document.

2. The overall description

Product perspective : It state the benefit of our product over other existing
product
Product function : The functionality of the software product summarizes in
this section
User characteristics : To use any system it is mandatory that user of the
system should have some basic knowledge i.e. at least the educational
qualification or basic knowledge.
Constraints : It includes limitations of the component used in the system
Assumptions and dependencies : Factor on which SRS is depending.
19

Priority of requirement
Page

SVERI’s COE(Polytechnic), Pandharpur

 3. Specific requirements
Interfaces: This contain various types of interfaces like Hardware/software
interface, System interface, user interface and communication interface
Database: To store the required and generated data
Performance : Required speed, task completion time, response time and
throughput of the system
Software system attribute : means reliability security maintainability

4. Change management process : Due to additional user requirement

changes in the system are occurred.
As the system makes any changes according to user requirement, SRS
document should be changed accordingly.
5. Document approval: The SRS document should be accepted by both the
parties including customer for whom the system is developing and the
developer who developed the system.
The document approval section include the approval date time and sign of
both the parties.
6. Supporting information : It include guidelines about how to use the
SRS, index of SRS and references etc.

20
Page

SVERI’s COE(Polytechnic), Pandharpur