Software Requirement Specification 39

Unit 3: Software Requirement Specification

Notes
Structure
3.1 Introduction
3.2 Requirement Engineering
3.2.1 What Is Software Requirement
3.2.2 Types of Requirements
3.2.3 Requirements Engineering Process
3.3 Feasibility Study
3.3.1 Types of Feasibility
3.4 Requirement Elicitation
3.4.1 Elicitation Techniques
3.5 Requirement Analysis
3.5.1 Structured Analysis
3.5.2 Object-oriented Modelling
3.6 Requirements Documentation
3.6.1 Structure of SRS
3.7 Requirements Validation
3.7.1 Requirement Review
3.7.2 Other Requirement Validation Techniques
3.8 Summary
3.9 Check Your Progress
3.10 Questions and Exercises
3.11 Key Terms
3.12 Further Readings

Objectives
After studying this unit, you should be able to:
z Understand the requirement Engineering process
z Learn the concept of Feasibility Study
z Identify the Elicitation Techniques
z Role of Requirements Documentation

3.1 Introduction
In the software development process, requirements phase is the first software
engineering activity, which translates the ideas or views into a requirements document.
This phase is user-dominated phase. Defining and documenting the user requirements
in a concise and unambiguous manner is the first major step to achieve a high quality
product. Requirements phase encompasses a set of tasks, which helps to specify the
impact of the software on the organisation, customers’ needs, and how users will
interact with the developed software. The requirements are the basis of system design.
If requirements are not correct the end product will also contain errors. Note that

Amity Directorate of Distance and Online Education

40 Software Engineering

requirement activity like all other software engineering activities should be adapted to
the needs of the process, the project, the product, and the people involved in the
Notes activity. Also, the requirements should be specified at different levels of detail. This is
because requirements are meant for (such as users, managers, system engineers, and
so on). For example, managers may be interested in knowing how the system is
implemented rather than knowing the detailed features of the system. Similarly, end-
users are interested in knowing whether the specified requirements meet their desired
needs or not.

3.2 Requirement Engineering

Requirements engineering is the process of eliciting, documenting, analyzing,
validating, and managing requirements. Different approaches to requirements
engineering exist, some more complete than others.

3.2.1 What Is Software Requirement

Requirement is a condition or a capability possessed by software or system component
in order to solve a real world problem. The problems can be to automate a part of a
system, to correct shortcomings of an existing system, to control a device, and so on.
IEEE defines requirement as “(1) A condition or capability needed by a user to solve a
problem or achieve an objective. (2) A condition or capability that must be met or
possessed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed documents. (3) A documented representation of
a condition or capability as in (1) or (2)”.
Requirements describe how a system should act, appear, or perform. For this,
when users request for software, they possess an approximation of what the new
system should be capable of doing. Requirements differ from one user to another user
and from one business process to another business process.
Note: Information about requirements is stored in a database, which helps software
development team to understand user requirements and develop software according to
those requirements.

3.2.2 Types of Requirements

Requirements help to understand the behaviour of a system, which is described by
various tasks of the system. For example, some of the tasks of a system are to provide
response to input values, determine the state of data objects, and so on. Note that
requirements are considered prior to the development of the software. The
requirements, which are commonly considered, are classified into three categories,
namely, functional requirements, nonfunctional requirements, and domain
requirements.

Figure 3.1: Types of Requirements

Amity Directorate of Distance and Online Education

Software Requirement Specification 41
(a) Functional Requirements: The functional requirements (also known as
behavioural requirements) describe the functionality or services that software
should provide. For this, functional requirements describe the interaction of software Notes
with its environment and specify the inputs, outputs, external interfaces, and the
functions that should not be included in the software. Also, the services provided by
functional requirements specify the procedure by which the software should react to
particular inputs or behave in particular situations. IEEE defines function
requirements as “a function that a system or component must be able to perform.”
(b) Non-functional Requirements: The non-functional requirements (also known as
quality requirements) relate to system attributes, such as reliability and response
time. Non-functional requirements arise due to user requirements, budget
constraints, organizational policies, and so on. These requirements are not related
directly to any particular function provided by the system.
Non-functional requirements should be accomplished in software to make it perform
efficiently. For example, if an aeroplane is unable to fulfil reliability requirements, it is not
approved for safe operation. Similarly, if a real time control system is ineffective in
accomplishing non-functional requirements, the control functions cannot operate
correctly.

Figure 3.2: Types of Non-functional Requirements

Different types of non-functional requirements are shown in Figure 3.2. The

description of these requirements are listed below:
z Product requirements: These requirements specify how software product
performs. Product requirements comprise of the following:
™ Efficiency requirements: Describe the extent to which software makes optimal
use of resources, the speed with which system executes, and the memory it
consumes for its operation. For example, system should be able to operate at
least three times faster than the existing system.
™ Reliability requirements: Describe the acceptable failure rate of the software.
For example, software should be able to operate even if a hazard occurs.
™ Portability requirements: Describe the ease with which software can be
transferred from one platform to another. For example, it should be easy to port
software to different operating system without the need to redesign the entire
software.

Amity Directorate of Distance and Online Education

42 Software Engineering

™ Usability requirements: Describe the ease with which users are able to operate
the software. For example, software should be able to provide access to
Notes functionality with fewer keystrokes and mouse clicks.
z Organizational requirements: These requirements are derived from the policies
and procedures of an organization. Organizational requirements comprise of the
following:
™ Delivery requirements: Specify when software and its documentation are to be
delivered to the user.
™ Implementation requirements: Describe requirements, such as programming
language and design method.
™ Standards requirements: Describe the process standards to be used during
software development. For example, software should be developed using
standards specified by ISO (International Organization for Standardization) and
IEEE standards.
z External requirements: These requirements include all the requirements that
affect the software or its development process externally. External requirements
comprise of the following:
™ Interoperability requirements: Define the way in which different computer-based
systems interact with each other in one or more organizations.
™ Ethical requirements: Specify the rules and regulations of the software so that
they are acceptable to users.
™ Legislative requirements: Ensure that software operates within the legal
jurisdiction. For example, pirated software should not be sold.

3.2.3 Requirements Engineering Process

The requirements engineering (RE) process is a series of activities that are performed
in requirements phase in order to express requirements in software requirements
specification (SRS) document. This process focuses on understanding the requirement
and its type so that an appropriate technique is determined to carry out the
requirements engineering process.
The new software developed after collecting requirements either replaces the
existing software or enhances its features and functionality. For example, the payment
mode of existing software can be changed from payment through hand-written cheques
to electronic payment of bills.

Figure 3.3: Requirements Engineering Process

Amity Directorate of Distance and Online Education
Software Requirement Specification 43
In Figure 3.3, a requirements engineering process is shown, which comprises of
various steps. These steps include feasibility study, requirements elicitation,
requirements analysis, requirements specification, requirements validation, and Notes
requirements management.
Requirements engineering process begins with a feasibility study of the
requirements. Then, requirements elicitation is performed, which focuses on gathering
user requirements. After the requirements are gathered, analysis is performed, which
further leads to requirements specification. The output of this is stored in the form of
software requirements specification document. Next, the requirements are checked for
their completeness and correctness in requirements validation. Lastly, to understand
and control changes to system requirements, requirements management is performed.

3.3 Feasibility Study

Feasibility is defined as the practical extent to which a project can be performed
successfully. To evaluate feasibility, a feasibility study is performed, which determines
whether the solution considered to accomplish the requirements is practically workable
in the software or not. For this, it considers information, such as resource availability,
cost estimates for software development, benefits of software to organization after it is
developed, and cost to be incurred on its maintenance. The objective of feasibility study
is to establish the reasons for developing software that is acceptable to users,
adaptable to change, and conformable to established standards. Various other
objectives of feasibility study are listed below:
z Analyze whether the software will meet organizational requirements or not.
z Determine whether the software can be implemented using current technology and
within the specified budget and schedule or not.
z Determine whether the software can be integrated with other existing software or
not.

3.3.1 Types of Feasibility

Various types of feasibility that are commonly considered include technical feasibility,
operational feasibility, and economic feasibility.
(a) Technical Feasibility: Technical feasibility assesses the current resources (such
as hardware and software) and technology, which are required to accomplish user
requirements in the software within the allocated time and budget. For this, software
development team ascertains whether the current resources and technology can be
upgraded or added in the software to accomplish specified user requirements.
Technical feasibility performs the tasks listed below:
™ Analyzes the technical skills and capabilities of software development team
members.
™ Determines whether the relevant technology is stable and established or not.
™ Ascertains that the technology chosen for software development has large
number of users so that they can be consulted when problems arise or
improvements are required.
(b) Operational Feasibility: Operational feasibility assesses the extent to which the
required software performs series of steps to solve business problems and user
requirements. This feasibility is dependent on human resources (software
development team) and involves visualizing whether or not the software will operate
after it is developed and be operated once it is installed. In addition, operational
feasibility performs the tasks listed below:
™ Determines whether the problems proposed in user requirements are of high
priority or not.
™ Determines whether the solution suggested by software development team is
acceptable or not.

Amity Directorate of Distance and Online Education

44 Software Engineering

™ Analyzes whether users will adapt to new software or not.

™ Determines whether the organization is satisfied by the alternative solutions
Notes proposed by software development team or not.
(c) Economic Feasibility: Economic feasibility determines whether the required
software is capable of generating financial gains for an organization or not. It
involves the cost incurred on software development team, estimated cost of
hardware and software, cost of performing feasibility study, and so on. For this, it is
essential to consider expenses made on purchases (such as hardware purchase)
and activities required to carry out software development. In addition, it is necessary
to consider the benefits that can be achieved by developing the software.
Software is said to be economically feasible if it focuses on the issues listed below:
™ Cost incurred on software development produces long-term gains for an
organization.
™ Cost required to conduct full software investigation (such as requirements
elicitation and requirements analysis).
™ Cost of hardware, software, development team, and training.
Note: As economic feasibility assesses cost and benefits of the software, cost-
benefit analysis is performed for it. Economic feasibility uses several methods to
perform cost-benefit analysis, such as payback analysis, return on investment (ROI),
and present value analysis.

3.4 Requirement Elicitation

Requirements elicitation (also known as requirements capture or requirements
acquisition) is a process of collecting information about software requirements from
different individuals, such as users and other stakeholders. Stakeholders are individuals
who are affected by the system, directly or indirectly. These include project managers,
marketing people, consultants, software engineers, maintenance engineers, and user.
Various issues may arise during requirements elicitation and may cause difficulty in
understanding the software requirements. Some of the problems are listed below:
z Problems of scope: This problem arises when the boundary of software (that is,
scope) is not defined properly. Due to this, it becomes difficult to identify objectives
as well as functions and features to be accomplished in software.
z Problems of understanding: This problem arises when users are not certain
about their requirements and thus are unable to express what they require in
software and which requirements are feasible. This problem also arises when users
have no or little knowledge of the problem domain and are unable to understand the
limitations of computing environment of software.
z Problems of volatility: This problem arises when requirements change over time.
Requirements elicitation uses elicitation techniques, which facilitate a software
engineer to understand user requirements and software requirements needed to
develop the proposed software.

3.4.1 Elicitation Techniques

Various elicitation techniques are used to identify the problem, determine its solution,
and identify different approaches for the solution. These techniques also help the
stakeholders to clearly express their requirements by stating all the important
information. The commonly followed elicitation techniques are listed below:
z Interviews: These are conventional ways for eliciting requirements, which help
software engineer, users, and software development team to understand the
problem and suggest solution for the problem. For this, the software engineer
interviews the users with a series of questions. When an interview is conducted,
rules are established for users and other stakeholders. In addition, an agenda is

Amity Directorate of Distance and Online Education

Software Requirement Specification 45
prepared before conducting interviews, which includes the important points (related
to software) to be discussed among users and other stakeholders.
Notes
An effective interview should have the characteristics listed below:
™ Individuals involved in interviews should be able to accept new ideas. Also, they
should focus on listening to the views of stakeholders related to requirements
and avoid biased views.
™ Interviews should be conducted in defined context to requirements rather than
in general terms. For this, users should start with a question or a requirements
proposal.
z Scenarios: These are descriptions of a sequence of events, which help to
determine possible future outcome before the software is developed or
implemented. Scenarios are used to test whether the software will accomplish user
requirements or not. Also, scenarios help to provide a framework for questions to
software engineer about users’ tasks.
These questions are asked from users about future conditions (what-if) and
procedure (how) in which they think tasks can be completed. Generally, a scenario
comprises of the information listed below:
™ Description of what users expect when scenario starts.
™ Description of how to handle the situation when software is not operating
correctly.
™ Description of the state of software when scenario ends.
™ Prototypes: Prototypes help to clarify unclear requirements. Like scenarios,
prototypes also help users to understand the information they need to provide
to software development team.
z Quality function deployment (QFD): This deployment translates user
requirements into technical requirements for the software. For this, QFD facilitates
development team to understand what is valuable to users so that quality can be
maintained throughout the software development. QFD identifies some of the
common user requirements, which are listed below:
™ General requirements: These requirements describe the system objectives,
which are determined by various requirements elicitation techniques. Examples
of general requirements are graphical displays requested by users, specific
software functions, and so on.
™ Expected requirements: These requirements are implicit to software, as users
consider them to be fundamental requirements, which will be accomplished in
the software and hence do not express them. Examples of expected
requirements are ease of software installation, ease of software and user
interaction, and so on.
™ Unexpected requirements: These requirements specify the requirements that
are beyond user expectations. These requirements are not requested by the
user but if development team adds them to the software, users are satisfied to
have the software with the additional features. An example of unexpected
requirements is to have word processing software with additional capabilities,
such as page layout capabilities along with the earlier features.

3.5 Requirement Analysis

Definition of a system, hardware, or software requirements. (2) the process of studying
and refining system, hardware, or software requirements”. Requirements analysis helps
to understand, interpret, classify, and organize the software requirements in order to
assess the feasibility, completeness, and consistency of the requirements. Various
other tasks performed using requirements analysis are listed below:
z Detect and resolve conflicts that arise due to unclear and unstated requirements.

Amity Directorate of Distance and Online Education

46 Software Engineering

z Determine operational characteristics of software and how it interacts with its

environment.
Notes z Understand the problem for which software is to be developed.
z Develop analysis model to analyze the requirements in the software.
Software engineers perform analysis modelling and create analysis model to
provide information of ‘what’ software should do instead of ‘how’ to fulfil the
requirements in software. This model emphasizes on information, such as the functions
that software should perform, behaviour it should exhibit, and constraints that are
applied on the software.
This model also determines the relationship of one component with other
components. The clear and complete requirements specified in analysis model help
software development team to develop software according to those requirements. An
analysis model is created to help the development team to assess the quality of
software when it is developed. An analysis model helps to define a set of requirements
that can be validated when the software is developed.
Let us consider an example of constructing a study room, where user knows the
dimensions of the room, the location of doors and windows, and the available wall
space. Before constructing the study room, user provides information about flooring,
wallpaper, and so on to the constructor. This information helps the constructor to
analyze the requirements and prepare an analysis model that describes the
requirements. This model also describes what needs to be done to accomplish those
requirements. Similarly, an analysis model created for software facilitates software
development team to understand what is required in software and then develop it.

Figure 3.4 Analysis Model as Connector

In Figure 3.4, analysis model connects system description and design model.
System description provides information about the entire functionality of system, which
is achieved by implementing software, hardware, and data. In addition, analysis model
specifies the software design, in the form of design model, which provides information
about software’s architecture, user interface, and component level structure. The
guidelines followed while creating an analysis model are listed below:
z The model should concentrate on requirements that are present within the problem
with detailed information about the problem domain. However, an analysis model
should not describe the procedure to accomplish requirements in the system.
z Every element of analysis model should help in understanding the software
requirements. This model should also describe the information domain, function and
behaviour of the system.
z The analysis model should be useful to all stakeholders because every stakeholder
uses this model in their own manner. For example, business stakeholders use this
model to validate requirements whereas software designers view this model as a
basis for design.

Amity Directorate of Distance and Online Education

Software Requirement Specification 47
z The analysis model should be as simple as possible. For this, additional diagrams
that depict no new or unnecessary information should be avoided. Also,
abbreviations and acronyms should be used instead of complete notations. Notes
The choice of representation is made according to requirements to avoid
inconsistencies and ambiguity. Due to this, analysis model comprises of structured
analysis, object-oriented modelling, and other approaches. Each of these describes a
different manner to represent the functional and behavioural information. Structured
analysis expresses this information through data flow diagrams, whereas object-
oriented modelling specifies the functional and behavioural information using objects.
Other approaches include ER modelling and several requirements specification
languages and processors.

Figure 3.5 Analysis Model

3.5.1 Structured Analysis

Structured analysis is a top-down approach, which focuses on refining the problem with
the help of functions performed in the problem domain and data produced by these
functions.
The basic principles of this approach are:
z To facilitate software engineer in order to determine the information received during
analysis and to organize the information to avoid complexity of the problem.
z To provide a graphical representation to develop new software or enhance the
existing software.
Generally, structured analysis is represented using data flow diagram.
(a) Data Flow Diagram (DFD): IEEE defines data flow diagram (also known as bubble
chart or work flow diagram) as “a diagram that depicts data sources, data sinks,
data storage, and processes performed on data as nodes, and logical flow of data
as links between the nodes”. DFD allows software development team to depict flow
of data from one or more processes to another. In addition, DFD accomplishes the
objectives listed below:
™ Represents system data in hierarchical manner and with required level of detail.
™ Depicts processes according to defined user requirements and software scope.
DFD depicts the flow of data within a system and considers a system that
transforms inputs into the required outputs. When there is complexity in a system,
data needs to be transformed by using various steps to produce an output. These

Amity Directorate of Distance and Online Education

48 Software Engineering

steps are required to refine the information. The objective of DFD is to provide an
overview of the transformations that occur to the input data within the system in
Notes order to produce an output.
DFD should not be confused with a flowchart. A DFD represents the flow of data
whereas flowchart depicts the flow of control. Also, a DFD does not depict the
information about the procedure to be used for accomplishing the task. Hence,
while making DFD, procedural details about the processes should not be shown.
DFD helps a software designer to describe the transformations taking place in the
path of data from input to output DFD comprises of four basic notations (symbols),
which help to depict information in a system. These notations are listed in Table 3.2.
Table 3.2: DFD Notations

While creating a DFD, certain guidelines are followed to depict the data flow of
system requirements effectively. These guidelines help to create DFD in an
understandable manner. The commonly followed guidelines for creating DFD are
listed below:
™ DFD notations should be given meaningful names. For example, verb should be
used for naming a process whereas nouns should be used for naming external
entity, data store, and data flow.
™ Abbreviations should be avoided in DFD notations.
™ Each process should be numbered uniquely but the numbering should be
consistent.
™ DFD should be created in an organized manner so that it is easily
understandable.
™ Unnecessary notations should be avoided in DFD in order to avoid complexity.
™ DFD should be logically consistent. For this, processes without any input or
output and any input without output should be avoided.
™ There should be no loops in DFD.
™ DFD should be refined until each process performs a simple function so that it
can be easily represented as a program component.
™ DFD should be organized in a series of levels so that each level provides more
detail than the previous level.
™ The name of a process should be carried to the next level of DFD.
™ Each DFD should not have more than six processes and related data stores.
™ The data store should be depicted at the context level where it first describes an
interface between two or more processes. Then, the data store should be
depicted again in the next level of DFD that describes the related processes.

Amity Directorate of Distance and Online Education

Software Requirement Specification 49
There are various levels of DFD, which provide detail about the input, processes,
and output of a system. Note that the level of detail of process increases with
increase in level(s). However, these levels do not describe the systems’ internal Notes
structure or behaviour.
These levels are listed below:
™ Level 0 DFD (also known as context diagram): Shows an overall view of the
system.
™ Level 1 DFD: Elaborates level 0 DFD and splits the process into a detailed
form.
™ Level 2 DFD: Elaborates level 1 DFD and displays the process(s) in a more
detailed form.
™ Level 3 DFD: Elaborates level 2 DFD and displays the process(s) in a detailed
form.
(b) Data Dictionary: Although data flow diagrams contain meaningful names of
notations, they do not provide complete information about the structure of data
flows. For this, data dictionary is used, which is a repository that stores description
of data objects to be used by the software. Data dictionary stores an organized
collection of information about data and their relationships, data flows, data types,
data stores, processes, and so on. In addition, a data dictionary helps users to
understand the data types and processes defined along with their uses. It also
facilitates the validation of data by avoiding duplication of entries and provides
online access to definitions to the users.
Data dictionary comprises of the source of data, which are data objects and entities.
In addition, it comprises of the elements listed below:
™ Name: Provides information about the primary name of the data store, external
entity, and data flow.
™ Alias: Describes different names of data objects and entities used.
™ Where-used/how-used: Lists all the processes that use data objects and entities
and how they are used in the system. For this, it describes the inputs to the
process, output from the process, and the data store.
™ Content description: Provides information about the content with the help of
data dictionary notations (such as ‘=’, ‘+’, and ‘* *’).
™ Supplementary information: Provides information about data types, values used
in variables, and limitations of these values.

3.5.2 Object-oriented Modelling

Now a days object-oriented approach is used to describe system requirements using
prototypes. This approach is performed using object-oriented modelling (also known as
object-oriented analysis), which analyzes the problem domain and then partitions the
problem with the help of objects. An object is an entity that represents a concept and
performs a well-defined task in the problem domain. For this, an object contains
information of the state and provides services to entities, which are outside the
object(s). The state of an object changes when it provides services to other entities.
The object-oriented modelling defines a system as a set of objects, which interact
with each other by the services they provide. In addition, objects interact with users
through their services so that they can avail the required services in the system.
To understand object-oriented analysis, it is important to understand the various
concepts used in object-oriented environment. Some of the commonly used these
concepts are listed in Table 3.3.

Amity Directorate of Distance and Online Education

50 Software Engineering
Table 3.3 Object-Oriented Concepts

Notes

Generally, it is considered that object-oriented systems are easier to develop and

maintain. Also, it is considered that the transition from object-oriented analysis to object-
oriented design can be done easily. This is because object-oriented analysis is resilient
to changes as objects are more stable than functions that are used in structured
analysis. Note that object oriented analysis comprises a number of steps, which
includes identifying objects, identifying structures, identifying attributes, identifying
associations, and defining services.

Figure 3.6: Steps in Object-oriented Analysis

(a) Identifying Objects: While performing analysis, an object encapsulates the
attributes on which it provides the services. Note that an object represents entities
in a problem domain. The identification of the objects starts by viewing the problem
space and its description. Then, a summary of the problem space is gathered to
consider the ‘nouns’. Nouns indicate the entities used in problem space and which

Amity Directorate of Distance and Online Education

Software Requirement Specification 51
will further be modelled as objects. Some examples of nouns that can be modelled
as objects are structures, events, roles, and locations.
(b) Identifying Structures: Structures depict the hierarchies that exist between the
Notes
objects. Object modelling applies the concept of generalization and specialization to
define hierarchies and to represent the relationships between the objects. As
mentioned earlier, superclass is a collection of classes, which can further be refined
into one or more subclasses. Note that a subclass can have its own attributes and
services apart from the attributes and services inherited from its superclass. To
understand generalization and specialization, consider an example of class ‘car’.
Here, ‘car’ is a superclass, which has attributes, such as wheels, doors, and
windows. There may be one or more subclasses of a superclass. For instance,
superclass ‘car’ has subclasses ‘Mercedes’ and ‘Toyota’, which have the inherited
attributes along with their own attributes, such as comfort, locking system, and so
on.
It is essential to consider the objects that can be identified as generalization so that
the classification of structure can be identified. In addition, the objects in the
problem domain should be determined to check whether they can be classified into
specialization or not. Note that the specialization should be meaningful for the
problem domain.
(c) Identifying Attributes: Attributes add details about an object and store the data for
the object. For example, the class ‘book’ has attributes, such as author name,
ISBN, and publication house. The data about these attributes is stored in the form
of values and are hidden from outside the objects. However, these attributes are
accessed and manipulated by the service functions used for that object. The
attributes to be considered about an object depend on the problem and the
requirement for that attribute. For example, while modelling the student admission
system, attributes, such as age and qualification are required for the object
‘student’. On the other hand, while modelling for hospital management system, the
attribute ‘qualification’ is unnecessary and requires other attributes of class
‘student’, such as gender, height, and weight. In short, it can be said that while
using an object, only the attributes that are relevant and required by the problem
domain should be considered.
(d) Identifying Associations: Associations describe the relationship between the
instances of several classes. For example, an instance of class ‘University’ is
related to an instance of class ‘person’ by ‘educates’ relationship. Note that there is
no relationship between the class ‘University’ and class ‘person’, however only the
instance(s) of class ‘person’ (that is, student) is related to class ‘University’. This is
similar to entity relationship modelling, where one instance can be related by 1:1,
1:M, and M:M relationships. An association may have its own attributes, which may
or may not be present in other objects. Depending on the requirement, the
attributes of the association can be ‘forced’ to belong to one or more objects without
losing the information. However, this should not be done unless the attribute itself
belongs to that object.
(e) Defining Services: As mentioned earlier, an object performs some services. These
services are carried out when an object receives a message for it. Services are a
medium to change the state of an object or carry out a process. These services
describe the tasks and processes provided by a system. It is important to consider
the ‘occur’ services in order to create, destroy, and maintain the instances of an
object. To identify the services, the system states are defined and then the external
events and the required responses are described. For this, the services provided by
objects should be considered.

3.6 Requirements Documentation

The output of requirements phase of software development process is the software
requirement specification document (also known as requirements document). This
document lays a foundation for software engineering activities and is created when

Amity Directorate of Distance and Online Education

52 Software Engineering

entire requirements are elicited and analyzed. Software requirement specification (SRS)
is a formal document, which acts as a representation of software that enables the users
Notes to review whether it (SRS) is according to their requirements or not. In addition, the
requirements document includes user requirement for a system as well as detailed
specification of the system requirement.
IEEE defines software requirement specification as “a document that clearly and
precisely describes each of the essential requirements (functions, performance, design
constraints, and quality attributes) of the software and the external interfaces. Each
requirement is defined in such a way that its achievement can be objectively verified by
a prescribed method, for example, inspection, demonstration, analysis, or test.” Note
that requirement specification can be in the form of a written document, a mathematical
model, a collection of graphical models, a prototype, and so on.
Essentially, what passes from requirement analysis activity to the specification
activity is the knowledge acquired about the system. The need for maintaining
requirements document is that the modelling activity essentially focuses on the problem
structure and not its structural behaviour. While in SRS, performance constraints,
design constraints, standard compliance recovery are clearly specified in the
requirements document. This information helps in properly developed design of a
system. Various other purposes served by SRS are listed below:
z Feedback: Provides a feedback, which ensures to the user that the organization
which develops the software) understands the issues or problems to be solved and
the software behaviour necessary to address those problems.
z Decompose problem into components: Organises the information and divides
the problem into its component parts in an orderly manner.
z Validation: Uses validation strategies, applied to the requirements to acknowledge
that requirements are stated properly.
z Input to design: Contains sufficient detail in the functional system requirements to
devise a design solution.
z Basis for agreement between user and organization: Provides a complete
description of the functions to be performed by the system. In addition, it helps the
users to determine whether the specified requirements are accomplished or not.
z Reduce the development effort: Enables developers to consider user
requirements before the designing of the system commences. As a result, ‘rework’
and inconsistencies in the later stages can be reduced.
z Estimating costs and schedules: Determines the requirements of the system and
thus enable the developer to have a ‘rough’ estimate of the total cost and the
schedule of the project.
Requirements document is used by various individuals in the organization As
shown in Figure 3.7, system customers needs SRS to specify and verify whether
requirements meet the desired needs or not. In addition, SRS enables the managers to
plan for the system development processes. System engineers need requirements
document to understand what system is to be developed. These engineers also require
this document to develop validation test for the required system. Lastly, requirements
document is required by system maintenance engineers to use the requirement and the
relationship between its parts.
Requirements document has diverse users, therefore along with communicating the
requirements to the users it also has to define the requirements in precise detail for
developers and testers. In addition it should also include information about possible
changes in the system, which can help system designers to avoid restricted decisions
on design. SRS also helps maintenance engineers to adapt the system to new
requirements.

Amity Directorate of Distance and Online Education

Software Requirement Specification 53

Notes

Figure 3.7 SRS Users

Characteristics of Software Requirements Specification: Software requirement

specification should be accurate, complete, efficient, and of high-quality, so that it does
not affects the entire project plan. A SRS is said to be of high quality when the
developer and user easily understand the prepared document. Other characteristics of
SRS are listed below:
z 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.
z 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.
z 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.
z 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.
z Modifiable: The requirements of the user can change, hence, requirements
document should be created in such a manner where those changes can be
modified easily, consistently maintaining the structure and style of the SRS.
z Traceable: SRS is traceable when the source of each requirement is clear and it
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.
z 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 or not. The requirements are verified with the help of reviews. Note
that unambiguity is essential for verifiability.

Amity Directorate of Distance and Online Education

54 Software Engineering

z Consistent: SRS is consistent when the subset of individual requirements defined

does not conflict with each other. For example, there can be a case when different
Notes requirements can use different terms to refer to the same object. There can be
logical or temporal conflicts between the specified requirements and some
requirements whose logical or temporal characteristics are not satisfied. For
instance, a requirement states that an event ‘a’ is to occur before another event ‘b’.
But then another set of requirements states (directly or indirectly by transitivity) that
event ‘b’ should occur before event ‘a’.

3.6.1 Structure of SRS

The requirements document is devised in a manner that is easier to write, review and
maintain. It is organized into independent sections and each section is organized into
modules or units. Note that the level of detail to be included in the SRS depends on the
type of the system to be developed and the process model chosen for its development.
For example, if a system is to be developed by an external contractor, then critical
system specifications need to be precise and very detail. Similarly, when flexibility is
required in the requirements and where an in-house development takes place,
requirements documents can be much less detailed.
Since the requirements document serves as a foundation for subsequent software
development phases, it is important to develop the document in the prescribed manner.
For this, certain guidelines are followed while preparing SRS. These guidelines are
listed below:
z Functionality should be separate from implementation.
z Analysis model should be developed according to the desired behaviour of a
system. This should include data and functional response of a system to various
inputs given to it.
z Cognitive model (express a system as perceived by the users) should be developed
instead of developing a design or implementation model.
z The content and structure of the specification should be flexible enough to
accommodate changes.
z Specification should be robust. That is, it should be tolerant towards
incompleteness and complexity.
The information to be included in SRS depends on a number of factors. For
example, the type of software being developed and the approach used in its
development. Suppose, if software is developed using iterative development process,
the requirements document will be less detailed as compared to the software being
developed for critical systems. This is because specifications need to be very detailed
and accurate in these systems. A number of standards have been suggested to develop
requirements document. However, the most widely used standard is by IEEE, which
acts as a general framework. This general framework can be customised and adapted
to meet the needs of a particular organization.
Each SRS fits a certain pattern, thus it is essential to standardize the structure of
the requirements document to make it easier to understand. For this IEEE standard is
used for SRS to organize requirements for different projects, which provides different
ways of structuring SRS. Note that in all requirements documents, the first two sections
are same.

3.7 Requirements Validation

The development of software starts, once the requirements document is ‘ready’. One of
the objectives of this document is to check whether the delivered software system is
acceptable or not. For this, it is necessary to ensure that the requirements specification
contains no errors and that it specifies the user’s requirements correctly. Also, errors
present in the SRS will adversely affect the cost if they are detected later in the
development process or when the software is delivered to the user. Hence, it is
Amity Directorate of Distance and Online Education
Software Requirement Specification 55
desirable to detect errors in the requirements before the design and development of the
software begin. To check all the issues related to requirements, requirements validation
is performed. Notes
In validation phase, the work products produced as a consequence of requirements
engineering are examined for consistency, omissions, and ambiguity. The basic
objective is to ensure that the SRS reflects the actual requirements accurately and
clearly. Other objectives of the requirements document are listed below:
z Certify that the SRS contains an acceptable description of the system to be
implemented.
z Ensure that the actual requirements of the system are reflected in SRS.
z Check requirements document for completeness, accuracy, consistency,
requirement conflict, conformance to standards, and technical errors.
Requirements validation is similar to requirements analysis as both these processes
review the gathered requirements. Requirements validation studies the ‘final draft’ of the
requirements document, while, requirements analysis studies the ‘raw requirements’
from the system stakeholders (users). Requirements validation and requirements
analysis can be summarized as follows:
z Requirements validation: Have we got the requirements right?
z Requirements analysis: Have we got the right requirements?

Figure 3.8: Requirements Validation

In Figure 3.8, various inputs, such as requirements document, organizational

knowledge, and organizational standards are shown. The requirements document
should be formulated and organized according to the standards of the organization. The
organizational knowledge is used to estimate the realism of the requirements of the
system. The organizational standards are the specified standards followed by the
organization according to which the system is to be developed.
The lists of problems indicate the problems encountered in the requirements
document of
z the requirement validation process. The agreed action is a list that displays the
actions to
z be performed to resolve the problems depicted in the problem list.

3.7.1 Requirement Review

Requirements validation determines whether the requirements are substantial to design
the system or not. Various problems are encountered during requirements validation.
These problems are listed below:
z Unclear stated requirements.
z Conflicting requirements are not detected during requirements analysis.
z Errors in the requirements elicitation and analysis.
z Lack of conformance to quality standards.
To avoid the problems stated above, a requirement review is conducted, which
consists of a review team that performs a systematic analysis of the requirements. The
Amity Directorate of Distance and Online Education
56 Software Engineering

review team consists of software engineers, users, and other stakeholders who
examine the specification to ensure that the problems associated with consistency,
Notes omissions and errors detected and corrected. In addition, the review team checks
whether the work products produced during requirements phase conform to standards
specified for the process, project and the product or not.
In review meeting, each participant goes over the requirements before the meeting
starts and marks the items, which are dubious or they feel need for further clarification.
Checklists are often used for identifying such items. Checklists ensure that no source of
errors whether major or minor are overlooked by the reviewers. A ‘good’ checklist
consists of the following:
z Is the initial state of the system defined?
z Does a conflict between one requirement and the other exist?
z Are all requirements specified at the appropriate level of abstraction?
z Is the requirement necessary or does it represent an add-on feature that may not be
essentially implemented?
z Is the requirement bounded and have a clear defined meaning?
z Is each requirement feasible in the technical environment where the product or
system is to be used?
z Is testing possible, once requirement is implemented?
z Are requirements associated with performance, behaviour, and operational
characteristics clearly stated?
z Are requirement pattern used to simplify the requirements model?
z Are the requirements consistent with overall objective specified for the
system/product?
z Have all hardware resources been defined?
z Is provision for possible future modifications specified?
z Are functions included as desired by the user (and stakeholder)?
z Can the requirements be implemented in the available budget and technology?
z Are the resources of requirements or any system model (created) stated clearly?
The checklists ensure that the requirements reflect users needs and that
requirements provide ‘groundwork’ for design. Using checklist, the participants specify
the list of potential errors they have uncovered. Lastly, the requirement analyst either
agrees to the presence of errors or clarifies that no errors exist.

3.7.2 Other Requirement Validation Techniques

A number of other requirement validation techniques are used either individually or in
conjunction with other techniques to check the entire system or parts of the system. The
selection of the validation technique depends on the appropriateness and the size of the
system to be developed. Some of these techniques are listed below:
z Test case generation: The requirements specified in the SRS document should be
testable. The test in the validation process can reveal problems in the requirement.
In some cases test becomes difficult to design, which implies that requirement is
difficult to implement and requires improvement.
z Automated consistency analysis: If the requirements are expressed in the form
of structured or formal notation, then computer aided software engineering (CASE)
tools can be used to check the consistency of the system. A requirements database
is created using a CASE tool that checks the entire requirements in the database
using rules of method or notation. The report of all inconsistencies is identified and
managed.

Amity Directorate of Distance and Online Education

Software Requirement Specification 57
z Prototyping: Prototyping is normally used for validating and eliciting new
requirements of the system. This helps to interpret assumptions and provide an
appropriate feedback about the requirements to the user. For example, if users Notes
have approved a prototype, which consists of graphical user interface, then the user
interface can be considered validated.

3.8 Summary
A requirement is defined as (1) a condition or capability needed by a user to solve a
problem or achieve an objective. (2) A condition or capability that must be met or
possessed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed documents. (3) A documented representation of
a condition or capability as in (1) or (2). Guidelines act as an efficient method of
expressing requirements, which also provide a basis for software development, system
testing, and user satisfaction. Various requirements considered before starting software
development are generally classified into three categories, namely, functional
requirements, non-functional requirements, and domain requirements. The functional
requirements, also known as behavioural requirements, describe the functionality or
services that software should provide. For this, functional requirements describe the
interaction of software with its environment and specify the inputs, outputs, external
interfaces and sometimes, the functions that should not be included in the software.
The non-functional requirements, also known as quality requirements, relate to
system attributes, such as reliability and response time. Different types of non-functional
requirements. Domain requirements are derived from the application domain of a
system, instead from the needs of the users. These requirements may be new
functional requirements or specify a method to perform some particular computations.
The requirements engineering process is a series of activities that are performed in
requirements phase in order to express requirements in software requirements
specification (SRS) document. This process focuses on understanding the requirement
and its type so that an appropriate technique is determined to carry out the
requirements engineering process. Various steps of requirements engineering process
include feasibility study, requirements elicitation, requirements analysis, requirements
specification, requirements validation, and requirements management. Feasibility refers
to the evaluation of the software process, design, procedure, or plan in order to
determine whether they can be successfully accomplished in the software in the allotted
time or not. To evaluate feasibility, a feasibility study is performed, which determines
whether the solution considered to accomplish the requirements is practically workable
in the software or not. The commonly considered types of feasibility include technical
feasibility, operational feasibility, and economic feasibility. Technical feasibility assesses
the current resources (such as hardware and software) and technology, which are
required to accomplish user requirements in the software within the allocated time and
budget. Operational feasibility assesses the extent to which the required software
performs series of steps to solve business problems and user requirements. Economic
feasibility determines whether the required software is capable of generating economic
benefits for an organization or not.

3.9 Check Your Progress

Multiple Choice Questions
1. Which of the following is included in the software requirements specification?
(a) Error handling.
(b) Data description.
(c) Functional description.
(d) Performance description.
2. _____________ is the process of developing a software specification.
(a) Software Engineering.
Amity Directorate of Distance and Online Education
58 Software Engineering

(b) Requirements Engineering.

(c) Systematic Engineering.
Notes
(d) Computer Engineering.
3. The constraints on the services or functions offered by the system and include
timing constraints, constraints on the development process and standards are
called as _______.
(a) functional requirements.
(b) non-functional requirements.
(c) system requirements.
(d) software requirements.
4. The activity that takes the unstructured collection of requirements groups related
requirements and organizes them into coherent is stated as _________.
(a) requirements classification and organization.
(b) requirements discovery.
(c) requirements prioritization.
(d) requirements documentation.
5. The requirement which change because of changes of the environment in which the
organization is operating is termed as ____________.
(a) compatibility requirements.
(b) consequential requirements.
(c) mutable requirements
(d) emergent requirements.
6. The requirements which results from the change in the organization process and
generate a new kind of system is termed as _________.
(a) mutable requirements.
(b) consequential requirements.
(c) emergent requirements.
(d) compatibility requirements.
7. Which of the following is not a diagram studied in Requirement Analysis?
(a) Use Cases
(b) Entity Relationship Diagram
(c) State Transition Diagram
(d) Activity Diagram
8. The requirements that result from requirements analysis are typically expressed
from one of three perspectives or views. What is that perspective or view?
(a) Developer
(b) User
(c) Non-Functional
(d) Physical
9. The SRS document is also known as _____________ specification.
(a) black-box
(b) white-box
(c) grey-box
10. Which of the following is included in SRS?
(a) Cost
Amity Directorate of Distance and Online Education
Software Requirement Specification 59
(b) Design Constraints
(c) Staffing
Notes
(d) Delivery Schedule

3.10 Questions and Exercises

1. “It is easy for software engineers to develop software according to user
requirements even if they are incomplete as software engineers can consider the
user requirements of earlier developed software”. Do you agree with this
statement? Why or why not? Give reasons in support of your answer.
2. What is requirements management? Describe its process.
3. Consider a student admission system for XYZ University, which is to be automated.
For this system, create the following:
(a) Make DFDs of 2–3 levels. (b) Draw ER diagram
4. Prototyping is advantageous to understand the problem and user requirements. Do
you think it is always advantageous to perform prototyping? Are there any
disadvantages of this approach?
5. HEP university decides to design software for its library information system, which
should allow only the authorised person to insert, delete, upgrade, and select
records related to books in the system. Also, the system should maintain
information related to the issue and return of books to members. For this system,
create the following:
(a) Develop the software requirements specification.
(b) Design DFDs of 2–3 levels.
(c) Identify various modules and their operation.
(d) Design ER diagram depicting the library information system.
6. Describe the principal requirements engineering activities and their relationships.
7. What is requirements validation and the role of requirements reviews?
8. Describe the role of requirements management in support of other requirements
engineering processes.

3.11 Key Terms

z Functional Requirements: The functional requirements (also known as
behavioural requirements) describe the functionality or services that software
should provide.
z Non-functional Requirements: The non-functional requirements (also known as
quality requirements) relate to system attributes, such as reliability and response
time.
z Product requirements: These requirements specify how software product
performs.
z Organizational requirements: These requirements are derived from the policies
and procedures of an organization.
z External requirements: These requirements include all the requirements that
affect the software or its development process externally.
z Ethical requirements: Specify the rules and regulations of the software so that
they are acceptable to users
z Legislative requirements: Ensure that software operates within the legal
jurisdiction.

Amity Directorate of Distance and Online Education

60 Software Engineering

Check Your Progress: Answers

1. (b) Data description
Notes
2. (b) Requirements Engineering.
3. (d) software requirements
4. (a) requirements classification and organization.
5. (c) mutable requirements
6. (b) consequential requirements
7. (d) Activity Diagram
8. (d) Physical
9. (a) black-box
10. (b) Design Constraints

3.12 Further Readings

z Jibitesh Mishra, Software Engineering, Pearson Education, 2011
z Rajib Mall, Fundamentals Of Software Engineering, PHI Learning Pvt. , 2009
z K. K. Aggarwal, Yogesh Singh, Software Engineering, New Age International, 2006
z Ajeet Pandey, Neeraj Kumar Goyal, Early Software Reliability Prediction: A Fuzzy
Logic Approach, Springer Science & Business Media, 2013

Amity Directorate of Distance and Online Education

Software Requirement Specification 61

CASE STUDY: STUDENT ADMISSION AND EXAMINATION SYSTEM

Notes

A
BC University wants to automate its admission and examination system for the two
years course of masters in business administration (MBA). The main objective of
developing this software is to help the university to manage the database of
students efficiently. This software will maintain the electronic record related to personal
and academic data of each student.
1. Problem Statement
The problem statement provides an outline of the system from user’s perspective. ABC
University offers IV-semester MBA programme. This statement has three modules,
namely, registration module, examination module, and result generation module.
z Registration module: To be a part of the university, an applicant must be registered,
for which the applicant should pay the required registration fee. This fee can be paid
through demand draft or cheque drawn from a nationalized bank. After successful
registration an enrolment number is allotted to each student, which makes the student
eligible to appear in the examination.
z Examination module: The examination of the MBA programme comprises of
assignments, theory papers, practical papers, and a project.
¾ Assignments: Each subject has an associated assignment, which is compulsory
and should be submitted by the student before a specified date. Each
assignment carries 20 marks where student obtaining 40% or more (>= 8 marks)
is said to have passed.
¾ Theory papers: The theory papers can be core or elective. Core papers are
mandatory papers, while in elective papers, students have a choice to select two
out of three papers. Note that in first three semesters there are four core papers
and three elective papers out of which two papers are to be chosen. Also, the
student is required to prepare a project in the IVth semester. Each theory paper
carries 50 marks where student obtaining 40% or more (>= 20 marks) is said to
have passed.
¾ Practical papers: The practical papers are mandatory and every semester has
three of them. Each practical paper carries 30 marks where student obtaining
40% or more (>= 12 marks) is said to have passed.
¾ Project: Students need to submit a project in the IVth semester. This project
carries 100 marks where student obtaining 50% or more (>= 50 marks) is said to
have passed. Also, students are required to appear for a viva-voce session,
which will be related to the project.
z Result generation module: The result is declared on the university’s website. This
website contains mark sheets of the students who have appeared in the examination
of the said semester (for which registration fee has been paid). Note that to view the
result student can use enrolment number as password.
2. Data Flow Diagrams
The data flow diagrams of various levels are shown as follows:

Figure 1: Level 0 DFD

Amity Directorate of Distance and Online Education

62 Software Engineering

Notes

Figure 2: Level 1 DFD of Student Admission and Examination System

Figure 3: Level 2 DFD of Registration

Figure 4: Level 2 DFD of Marks Information System

Amity Directorate of Distance and Online Education

Software Requirement Specification 63

Notes

Figure 5: Level 2 DFD of Examination

Figure 6: Level 3 DFD Registration

3. Entity Relationship Diagram
The ER diagram of student admission and examination system is shown in Figure 3.15.

Figure 7: ER Diagram of Student Management System

Amity Directorate of Distance and Online Education

64 Software Engineering
4. Software Requirements Specification Document
The SRS document describes the overall requirements of ABC University to automate the
Notes proposed system. This document follows IEEE guidelines for requirements specification
document with some variations.
1. Introduction
This section specifies the overall requirements of the software. The final software will have
features according to this document and assumptions for any additional features should be
made by individuals involved in developing/ testing/ implementing/ using this product.
(a) Purpose: The requirements specification document determines the capability of the
software to be developed. In addition, it specifies constraints required by the system.
(b) Scope: The final software when developed will help the university in registering
students and conducting examination. In addition, this will manage the record of the
subjects offered in different semesters, the students’ choice of elective papers and the
marks obtained by them in different subjects in various semesters.
(c) Definitions, acronyms, and abbreviations
Following abbreviations are used in the entire specification document.
MBA: Master in business administration
DB: Database
DBMS: Database management system
RAM: Random access memory
MB: Megabyte
(d) References: University website: Provides information about the course, result, and
other information.
(e) Overview: The SRS document provides description about the system requirements,
interfaces, features, and functionalities.
2. Overall description
The proposed system will maintain information about the students who are enrolled in the
MBA programme. In addition, it will manage the record of the subjects taken by the
students in different semesters, choice of elective paper and marks obtained by the
students in different semesters. In the Ist, IInd, and IIIrd semesters, students have to
appear in six theory subjects and three practical papers. It is mandatory to submit a project
report in IVth semester, which is followed by viva-voce for the same.
(a) Product perspective
The application will be Windows-based and an independent software application.
(i) System interface
None
(ii) Interface
The application will have a menu screen, which will have the following options:
™ Login screen: Enter the user name, password, and role (student, administrator,
and coordinator). Note that role is defined to know the information about the
individual(s) accessing the software. This is essential to prevent the students
from modifying the result in the database. Hence, the students will have access
to the information about whether they have been successfully registered or not
and can view the subjectwise result of each semester or year.
™ Subject screen: Enter information regarding the subjects offered in different
semesters. In addition, the subject screen displays the information about the
assignments, subjects (that is, core or elective), and the project.
™ Examination screen: Enter information about the registered students who seek to
take examination.
™ Student screen: Enter information about the student enrolled for MBA in different
semesters.
™ Marks screen: Enter information about the marks of assignments, theory papers,
and practical papers. In addition, marks screen displays the information of the
subjects successfully completed. Marks of the student will be displayed in the

Amity Directorate of Distance and Online Education

Software Requirement Specification 65
form of printable mark-sheet, which includes total marks and percentage of the
student.
(iii) Hardware interface Notes
Screen resolutions with minimum of 800 × 600 pixels should be used. It should also
support output devices like printer.
(iv) Software interface
The software interfaces that will be used for the proposed system are listed below:
™ Windows-based operating system (such as, Windows 95/98/XP/NT).
™ Oracle 8i as the database management system (DBMS) to store files and other
related information.
™ Crystal reports 8 to generate and view reports.
™ Visual Basic 6.0 as a front-end tool for coding and designing the software.
™ Internet Explorer 5.5 or higher to view results of the examination on the Internet.
(v) Communication interface
None
(vi) Memory constraints: Intel Pentium III processor or higher with a minimum of 128 MB
RAM and 600 MB of hard disk space will be required so that software performs its
functions in an optimum manner.
(vii) Operations: The software release will not include automated and maintenance of
database. The university is responsible for manually deleting old/outdated data and
managing backup and recovery of data.
(viii) Site adaptations requirements: The terminals at the user’s end will have to support
the interfaces (both hardware and software) as mentioned above.
(b) Product functions
The system will allow access only to authorized users like student, administrator and
coordinator depending upon the role. Some of the functions that will be performed by
the software are listed below:
™ Login facility for authorized users.
™ Perform modification (by administrator only), such as adding or deleting the
marks obtained by the students.
™ Provide a printable version of the mark-sheet (result) of the students.
™ Use of ‘clear’ function to delete the existing information in the database.
(c) User characteristics
None.
(d) Constraints
As Oracle 8i is a powerful database, it can store a large number of records.
™ The university should have a security policy to maintain information related
tomarks, which are to be modified by administrator.
(e) Assumptions and dependencies
The subjects taken by the students in the semester will not change.
™ The number of semesters and elective subjects offered by the university will not
change.
(f) Apportioning of requirements
Not required.
3. Specific requirements
This section provides the information required by the developers to develop the system.
(a) External interface
This contains complete description of inputs and outputs from the software system.
(b) Functions
None.

Amity Directorate of Distance and Online Education

66 Software Engineering
(c) Performance requirements
None.
Notes (d) Logical database requirements
™ The information that will be stored in the database is listed below:
™ Student detail: Stores information about student’s enrolment number, student
name, the year of enrolment, and fees details according to the semester.
™ Subject choice detail: Stores information about subject name, code, and
semester. In addition, it stores information about enrolment number, semester,
and the subject chosen by the student.
™ Marks detail: Stores information about student’s enrolment number and the
subject-wise marks secured by the student.
™ User account detail: Stores information about user name, password, and role.
(e) Design constraints
None.
(f) Software system attributes
(i) Security: The application will be password protected and hence, will require users
to enter their login ID (user name) and password.
(ii) Maintainability: The application will be designed in a manner that it is easy to
modify the software system later, when required and to incorporate new
requirements in the individual modules, such as subject information, marks
information, and user accounts.
(iii) Portability: The application will be easily portable on any Windows-based system
that has Oracle 8i installed on it.
4. Change management process
In case the university desires to modify the criteria to select the elective papers or
change the number of practical papers in each semester, then the changes will be
updated and reflected in SRS document accordingly.
5. Document approvals
When the requirements are gathered according to the user, SRS is then finally
reviewed, approved, and signed by the developer and user (university). This SRS
serves as a contract for software development activities.
6. Supporting information
None

Amity Directorate of Distance and Online Education