Unit-2

Software Requirements
Requirement is a condition or capability possessed by the 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.
According to IEEE standard 729, a requirement is defined as follows:
 A condition or capability needed by a user to solve a problem or achieve an objective
 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
 A documented representation of a condition or capability as in 1 and 2.

Requirements describe how a system should act, appear or perform. For this, when users request
for software, they provide an approximation of what the new system should be capable of doing.
Requirements differ from one user to another and from one business process to another.

Guidelines for Expressing Requirements

The purpose of the requirements document is to provide a basis for the mutual understanding
between the users and the designers of the initial definition of the software development life
cycle (SDLC) including the requirements, operating environment and development plan.
The requirements document should include the overview, the proposed methods and
procedures, a summary of improvements, a summary of impacts, security, privacy, internal
control considerations, cost considerations, and alternatives. The requirements section should
state the functions required in the software in quantitative and qualitative terms and how these
functions will satisfy the performance objectives. The requirements document should also
specify the performance requirements such as accuracy, validation, timing, and flexibility.
Inputs, outputs, and data characteristics need to be explained. Finally, the requirements
document needs to describe the operating environment and provide (or make reference to) a
development plan.
There is no standard method to express and document requirements. Requirements can be stated
efficiently by the experience of knowledgeable individuals, observing past requirements, and by
following guidelines. Guidelines act as an efficient method of expressing requirements, which
also provide a basis for software development, system testing, and user satisfaction. The
guidelines that are commonly followed to document requirements are listed below.

 Sentences and paragraphs should be short and written in active voice. Also, proper
grammar, spelling, and punctuation should be used.
  Conjunctions such as ‘and’ and ‘or’ should be avoided as they indicate the combination
of several requirements in one requirement.
 Each requirement should be stated only once so that it does not create redundancy in the
requirements specification document.

Types of Requirements

Requirements help to understand the behavior of a system, which is described by various tasks of
the system. For example, some of the tasks of a system are to provide a 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
as follows:

1. Functional Requirements
2. Non-functional Requirements
3. User Requirements
4. System Requirements
5. User Interface Requirements

1. Functional Requirements

IEEE defines functional requirements as ‘a function that a system or component must be able to
perform.’ These requirements describe the interaction of software with its environment and
specify the inputs, outputs, external interfaces, and the functions that should 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.
To understand functional requirements properly, let us consider the following example of an
online banking system.

 The user of the bank should be able to search the desired services from the available
ones.
 There should be appropriate documents for users to read. This implies that when a user
wants to open an account in the bank, the forms must be available so that the user can
open an account.
 After registration, the user should be provided with a unique acknowledgement number
so that he can later be given an account number.

The above mentioned functional requirements describe the specific services provided by the
online banking system. These requirements indicate user requirements and specify that
functional requirements may be described at different levels of detail in an online banking
system. With the help of these functional requirements, users can easily view, search and
download registration forms and other information about the bank. On the other hand, if
requirements are not stated properly, they are misinterpreted by software engineers and user
requirements are not met.
The functional requirements should be complete and consistent. Completeness implies that all
the user requirements are defined. Consistency implies that all requirements are specified clearly
without any contradictory definition. Generally, it is observed that completeness and consistency
cannot be achieved in large software or in a complex system due to the problems that arise while
defining the functional requirements of these systems. The different needs of stakeholders also
prevent the achievement of completeness and consistency. Due to these reasons, requirements
may not be obvious when they are first specified and may further lead to inconsistencies in the
requirements specification.
2. Non-functional Requirements
The non-functional requirements (also known as quality requirements) are related 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 fulfill 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.
The description of different types of non-functional requirements is listed below.

i. Product requirements: These requirements specify how software product performs.

Product requirements comprise the following.
a. Efficiency requirements: Describe the extent to which the software makes optimal use of
resources, the speed with which the system executes, and the memory it consumes for its
operation. For example, the system should be able to operate at least three times faster
than the existing system.
b. Reliability requirements: Describe the acceptable failure rate of the software. For
example, the software should be able to operate even if a hazard occurs.
c. Portability requirements: Describe the ease with which the software can be transferred
from one platform to another. For example, it should be easy to port the software to a
different operating system without the need to redesign the entire software.
d. Usability requirements: Describe the ease with which users are able to operate the
software. For example, the software should be able to provide access to functionality with
fewer keystrokes and mouse clicks.
ii. Organizational requirements: These requirements are derived from the policies and
procedures of an organization. Organizational requirements comprise the following.
 a. Delivery requirements: Specify when the software and its documentation are to be
delivered to the user.
b. Implementation requirements: Describe requirements such as programming language
and design method.
c. Standards requirements: Describe the process standards to be used during software
development. For example, the software should be developed using standards specified
by the ISO and IEEE standards.
iii. External requirements: These requirements include all the requirements that affect the
software or its development process externally. External requirements comprise the
following.
a. Interoperability requirements: Define the way in which different computer based
systems will interact with each other in one or more organizations.
b. Ethical requirements: Specify the rules and regulations of the software so that they are
acceptable to users.
c. Legislative requirements: Ensure that the software operates within the legal jurisdiction.
For example, pirated software should not be sold.

Non-functional requirements are difficult to verify. Hence, it is essential to write non-functional

requirements quantitatively, so that they can be tested. For this, non-functional requirements
metrics are used. These metrics are listed in Table.
Metrics for Non-functional Requirements

Features Measures
  Processed transaction/ second
Speed
 User/event response time
 Screen refresh rate

 Amount of memory (KB)

Size
 Number of RAM chips.

 Training time
Ease of use
 Number of help windows

 Mean time to failure (MTTF)

Reliability
 Portability of unavailability
 Rate of failure occurrence

 Time to restart after failure

Robustness
 Percentage of events causing failure
 Probability of data corruption on failure

 Percentage of target-dependent statements

Portability
 Number of target systems

3. User Requirements

User requirements are statements in natural language along with

corresponding diagrams (tables, forms, intuitive diagrams) detailing the services provided by
the system and operational constraints it must comply with. Additionally, it’s worth noting that
user requirements primarily focus on the user’s needs. Thus, these user requirements cater to the
customer.

Essentially, it entails the requirement that the user wants or ability to perform a functionality or
action with the system. So, it outlines the activities a user can perform with the system. User
requirements entail both functional and non-functional requirements that are understandable even
by users without technical knowledge.

User requirements are set by client and confirmed before system development.
– For example, in a system for a bank the user may require a function to calculate interest over a
set time period.
These requirements don’t contain details of the system design and don’t use technical
expressions or formal notations. Also, these user requirements are documented in a text as “User
Requirements Document” using narrative text.

4. System Requirements

On the other hand, system requirements consist of a structured document that details
the system’s functions, services and operational constraints. It’s mainly written and serves as
a tool for the developers of the system to build and implement the system design. It contains the
functionality that’s needed by the system in order to fulfill the user requirements. A system
requirement is a more technical requirement, often relating to hardware or software required for
a system to function.

– System requirements may be something like - "The system must run on a server with IIS
– System requirements may also include validation requirements such as "File upload is limited
to .xls format
System requirements are more commonly used by developers throughout the development life
cycle. The client will usually have less interest in these lower level requirements.
Along with that, it outlines both the functional and non-functional requirements the system
should fulfill. Hence, it consists of all things the system must contain to construct or develop it.
They’re often described as the expanded version of user requirements that engineers use at the
beginning of a system’s design. Hence, the system requirements serve as a blueprint for the
developer to follow defining the parts of a system that are to be implemented, so it acts as a
contract between the client and contractor.
These requirements can be written in natural language, and also possesses more structured forms
and graphical notations. However, as it’s primarily written for developers it possesses a detailed
description of the project services. It uses natural language and is documented as a System
Requirement Specification (SRS).
5. User Interface Requirements
UI is an important part of any software or hardware or hybrid system. Software is widely
accepted if it is -
 easy to operate
 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface
User acceptance majorly depends upon how user can use the software. UI is the only way for
users to perceive the system. A well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface. Otherwise the functionalities of
software system cannot be used in convenient way. A system is said be good if it provides means
to use it efficiently. User interface requirements are briefly mentioned below -
 Content presentation
 Easy Navigation
 Simple interface
 Responsive
 Consistent UI elements
 Feedback mechanism
 Default settings
 Purposeful layout
 Strategical use of color and texture.
 Provide help information
 User centric approach
 Group based view settings.
Interface Specification
A user interface specification (UI specification) is a document that captures the details of
the software user interface into a written document. The specification covers all possible actions
that an end user may perform and all visual, auditory and other interaction elements.
The UI specification is the main source of implementation information for how the software
should work. Beyond implementation, a UI specification should consider usability, localization,
and demo limits. A UI specification may also be incorporated by those within the organization
responsible for marketing, graphic design, and software testing. As future designers might
continue or build on top of existing work, a UI specification should consider forward
compatibility constraints in order to assist the implementation team.
The UI specification can be regarded as the document that bridges the gap between the product
management functions and implementation. One of the main purposes of a UI specification is to
process the product requirements into a more detailed format. The level of detail and document
type varies depending on the needs and design practices of the organizations. The small scale
prototypes might require only modest documentation with high-level details.
In general, the goal of requirement specifications is to describe what a product is capable of,
whereas the UI specification details how these requirements are implemented in practice.
The Process of creating UI Specification
Before UI specification is created, a lot of work is done already for defining the application and
desired functionality. Usually there are requirements for the software which are basis for the use
case creation and use case prioritizing. UI specification is only as good as the process by which it
has been created, so let’s consider the steps in the process:
i. Use case definition
Use cases are then used as basis for drafting the UI concept (which can contain for example main
views of the software, some textual explanations about the views and logical flows), these are
short stories that explain how the end user starts and completes a specific task, but not about how
to implement it.
The purpose of writing use cases is to enhance the UI designer understanding of the features that
the product must have and of the actions that take place when the user interacts with the product.
ii. Design draft creation
The UI design draft is done on the basis of the use case analysis. The purpose of the UI design
draft is to show the design proposed, and to explain how the user interface enables the user to
complete the main use cases, without going into details.
It should be as visual as possible and all the material created must be in such a format that it can
be used in the final UI specification.
iii. Writing the user interface specification
The UI specification is then written to describe the UI concept. The UI specification can be seen
as an extension of the design draft that provides a complete description that contains all details,
exceptions, error cases, notifications, and so forth. The amount of detail provided depends on the
needs and characteristics of the development organization (scope of the product, culture of the
organization, and development methodology used, among others). Usually, the UI concept and
specifications are reviewed by the stakeholders to ensure that all necessary details are in place.
Structure of UI Specification
Example structure of the UI specification may contain, but not limited to, the following items:

i. Change history
ii. Open issues
iii. Logical flow
iv. Display descriptions
v. Error and exception cases
i. Change history
Having an informative change history helps the reader to see what, when and why something
was changed. A UI specification quite often changes during implementation.
ii. Open issues
Possible open issues. While there are unclear or open issues, those can be visible.
iii. Logical flow
The logical flow can be used to give high-level view of how different screens in the user
interface relate to each other to support a task. Flow can reveal for example number of required
steps to perform a certain task.
iv. Display descriptions
The display description contains the screen contents and information about available functions.
The screen contents may be wireframes, screen-shots of a prototype, or UI mock-ups.
A picture of the user interface state will provide a quick overview. Wireframes are recommended
over high resolution graphics. Caution should be taken in providing too polished a picture as
details might change and time and resources have to be allocated to redraw pictures.
In addition to a picture of the display, access points should be listed and the fields and controls
on the screen should be described. The following table gives a list of the bare minimum you
should be describing:

Element Description Comment

if the element has no label, number it and

Label Label on the screen
refer to it by number

its type (input, drop-down, calendar), what

Description Describe the element
it does, etc.

Default what the field defaults to if no May not be applicable for every type of
value value is provided screen

v. Error and exception cases

Indicates how to display information regarding any network issues or other events that require
error indications to user.
Software Requirements Specifications (SRS)

The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the system
requirements.

The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who
is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various situations and
establish different purposes for the document altogether. The first case, SRS, is used to define the
needs and expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all
terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in it conflict. There are three types of possible conflicts in the SRS:

(i) The specified characteristics of real-world objects may conflict. For example,

(a) The format of an output report may be described in one requirement as tabular but in another
as textual.

(b) One condition may state that all lights shall be green while another states that all lights shall
be blue.

(ii) There may be a reasonable or temporal conflict between the two specified actions. For
example,
(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and
B" co-occurs.

(iii) Two or more requirements may define the same real-world object but use different terms for
that object. For example, a program's request for user input may be called a "prompt" in one
requirement's and a "cue" in another. The use of standard terminology and descriptions promotes
consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method
used with multiple definitions, the requirements report should determine the implications in the
SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed and
cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The requirements
are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique name or
reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be
able to ascertain the complete set of requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple design alternatives
for the final system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. Hence, the purpose of formal notations and
symbols should be avoided too as much extent as possible. The language should be kept simple
and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas, for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.

Structure of SRS

In order to form a good SRS, there are some points which can be used and should be
considered to form a structure of good SRS. These are as follows:
1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests, is complete
specification and description of requirements of software that needs to be fulfilled for
successful development of software system. These requirements can be functional as well as
non-functional depending upon type of requirement. The interaction between different
customers and contractor is done because it’s necessary to fully understand needs of customers.

Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be done
to increase quality of product and to satisfy customer’s demand.
1. Introduction :
(i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s purpose of document
is explained and described.
(ii) Scope of this document –
In this, overall working and main objective of document and what value it will provide
to customer is described and explained. It also includes a description of development
cost and time required.
(iii) Overview –
In this, description of product is explained. It’s simply summary or overall review of
product.
2. General description :
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also
describes features of user community.
3. Functional Requirements :
In this, possible outcome of software system which includes effects due to operation of
program is fully explained. All functional requirements which may include calculations,
data processing, etc. are placed in a ranked order.
4. Interface Requirements :
 In this, software interfaces which mean how software program communicates with each
other or users either in form of any language, code, or message are fully described or
explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements :
In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.
6. Design Constraints :
In this, constraints which simply mean limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.
7. Non-Functional Attributes :
In this, non-functional attributes are explained that are required by software system for
better performance. An example may include Security, Portability, Reliability,
Reusability, Application compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget :
In this, initial version and budget of project plan are explained which include overall
time duration required and overall cost required for development of project.
9. Appendices :
In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and
explained.

Components of SRS

Completeness of specifications is difficult to achieve and even more difficult to verify. Having
guidelines about what different things an SRS should specify will help in completely specifying
the requirements. Here we describe some of the system properties that an SRS should specify.
The basic issues an SRS must address are:

i. Functionality
ii. Performance
iii. Design constraints imposed on an implementation
iv. External interfaces

i. Functional Requirements

Functional requirements specify what output should be produced from the given inputs. So they
basically describe the connectivity between the input and output of the system. For each
functional requirement:
  A detailed description of all the data inputs and their sources, the units of measure, and
the range of valid inputs be specified:
 All the operations to be performed on the input data to obtain the output should be
specified. For example, if there is a formula for computing the output, it should be
specified.
 Care must be taken not to specify any algorithms that are not parts of the system but that
may be needed to implement the system. These decisions should be left for the designer.
 It must clearly state what the system should do if system behaves abnormally when any
invalid input is given or due to some error during computation. Specifically, it should
specify the behavior of the system for invalid inputs and invalid outputs.
 Furthermore, behavior for situations where the input is valid but the normal operation
cannot be performed should also be specified. An example of this situation is an airline
reservation system, where a reservation cannot be made even for valid passengers if the
airplane is fully booked.

ii. Performance Requirements

This part of an SRS specifies the performance constraints on the software system. All the
requirements relating to the performance characteristics of the system must be clearly specified.
There are two types of performance requirements: static and dynamic.

Static requirements are those that do not impose constraint on the execution characteristics of the
system. These include requirements like the number of terminals to be supported, the number of
simultaneous users to be supported, and the number of files that the system has to process and
their sizes. These are also called capacity requirements of the system.

Dynamic requirements specify constraints on the execution behavior of the system. These
typically include response time and throughput constraints on the system. Response time is the
expected time for the completion of an operation under specified circumstances. Throughput is
the expected number of operations that can be performed in a unit time. For example, the SRS
may specify the number of transactions that must be processed per unit time, or what the
response time for a particular command should be. Acceptable ranges of the different
performance parameters should be specified, as well as acceptable performance for both normal
and peak workload conditions.

iii. Design Constraints

There are a number of factors in the client's environment that may restrict the choices of a
designer. Such factors include standards that must be followed, resource limits, operating
environment, reliability and security requirements, and policies that may have an impact on the
design of the system. An SRS should identify and specify all such constraints.
  Standards Compliance: This specifies the requirements for the standards the system must
follow. The standards may include the report format and accounting procedures. There
may be audit tracing requirements, which require certain kinds of changes, or operations
that must be recorded in an audit file.
 Hardware Limitations: The software may have to operate on some existing or
predetermined hardware, thus imposing restrictions on the design. Hardware limitations
can include the type of machines to be used, operating system available on the system,
languages supported, and limits on primary and secondary storage.
 Reliability and Fault Tolerance: Fault tolerance requirements can place a major
constraint on how the system is to be designed. Fault tolerance requirements often make
the system more complex and expensive. Requirements about system behavior in the face
of certain kinds of faults are specified.
 Security: Security requirements are particularly significant in defense systems and many
database systems. Security requirements place restrictions on the use of certain
commands, control access to data, provide different kinds of access requirements for
different people, require the use of passwords and cryptography techniques, and maintain
a log of activities in the system. Given the current security needs even of common
systems, they may also require proper assessment of security threats, proper
programming techniques, and use of tools to detect flaws like buffer overflow.

iv. External Interface Requirements

All the interactions of the software with people, hardware, and other software should be clearly
specified. For the user interface, the characteristics of each user interface of the software product
should be specified. User interface is becoming increasingly important and must be given proper
attention. A preliminary user manual should be created with all user commands, screen formats,
an explanation of how the system will appear to the user, and feedback and error messages. Like
other specifications, these requirements should be precise and verifiable. So, a statement like
"the system should be user friendly" should be avoided and statements like "commands should
be no longer than six characters" or "command names should reflect the function they perform"
used.

For hardware interface requirements, the SRS should specify the logical characteristics of each
interface between the software product and the hardware components. If the software is to
execute on existing hardware or on predetermined hardware, all the characteristics of the
hardware, including memory restrictions, should be specified. In addition, the current use and
load characteristics of the hardware should be given.

The interface requirement should specify the interface with other software the system will use or
that will use the system. This includes the interface with the operating system and other
applications. The message content and format of each interface should be specified.
Requirement Engineering Process
Requirement Engineering refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the
appropriate mechanism to understand what the customer desires, analyzing the need, and
assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed into a working system.
Thus, requirement engineering is the disciplined application of proven principles, methods, tools,
and notation to describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a five-step process, which includes -

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

1. Feasibility Study:
When the client approaches the organization for getting the desired product developed, it comes
up with rough idea about what all functions the software must perform and which all features are
expected from the software.
Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes whether
the software product can be practically materialized in terms of implementation, contribution of
project to organization, cost constraints and as per values and objectives of the organization.
The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.
Types of Feasibility:
i. Technical Feasibility - Technical feasibility evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.
ii. Operational Feasibility - Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer
requirements.
iii. Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. If the feasibility report is positive towards
undertaking the project, next phase starts with gathering requirements from the user. Analysts
and engineers communicate with the client and end-users to know their ideas on what the
software should provide and which features they want the software to include. The requirements
are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in
terms of relationships and also resolve conflicts if any.
Requirement elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and end users and know
their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the requirements in
order of importance, urgency and convenience.
  Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
 Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Requirement Elicitation Techniques

There are various ways to discover requirements:

i. Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:
 Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.

ii. Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
iii. Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to
all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
iv. Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.
v. Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a great
help to analyze general and specific requirements.
vi. Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
vii. Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input
for requirement gathering.
viii. Observation
Team of experts visits the client’s organization or workplace. They observe the actual working of
the existing installed systems. They observe the workflow at client’s end and how execution
problems are dealt. The team itself draws some conclusions which aid to form requirements
expected from the software.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want.
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst

after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), data
dictionaries, etc.
 o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a software
system, or any combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about
all data items defined in DFDs. At the requirements stage, the data dictionary should at
least define customer data items, to ensure that the customer and developers use the same
definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the checked against the following conditions -

o If they can be practically implemented

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are complete
o If they can be demonstrated

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:

Requirement management is the process of analyzing, documenting, tracking, prioritizing and
agreeing on the requirement and controlling the communication to relevant stakeholders. This
stage takes care of the changing nature of requirements during the requirements engineering
process and system development. New requirements emerge during the process as business
needs a change, and a better understanding of the system is developed. The priority of
requirements from different viewpoints changes during development process. The business and
technical environment of the system changes during the development. It should be ensured that
the SRS is as modifiable as possible so as to incorporate changes in requirements specified by
the end users at later stages too. Being able to modify the software as per requirements in a
systematic and controlled manner is an extremely important part of the requirements engineering
process.