Ch.

4 Requirement Determination and Specifications

G H Raisoni Institute of
Business Management, Jalgaon
Department of Computer Application

Master of Computer Application (MCA)

Academic Year: 2023-24
Third Semester

Course Code: BCA-CC-10

Course Name: Software Engineering

Prepared By: Prof. Manisha Rajput

1
 Ch.4 Requirement Determination and Specifications

Requirements engineering (RE) refers to the process of

defining, documenting, and maintaining requirements in the
engineering design process. Requirement engineering provides
the appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility, negotiating
a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are
transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's
intended behavior and its associated constraints.
Requirement Engineering Process
It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons
for developing the software that is acceptable to users, flexible
to change and conformable to established standards.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility evaluates the
current technologies, which are needed to accomplish
customer requirements within the time and budget.
2
 Ch.4 Requirement Determination and Specifications

2. Operational Feasibility - Operational feasibility assesses

the range in which the required software performs a series
of levels to solve business problems and customer
requirements.
3. 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. Here,
requirements are identified with the help of customers and
existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The
requirements are analyzed to identify inconsistencies, defects,
omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
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
 Ch.4 Requirement Determination and Specifications

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), function decomposition diagrams (FDDs),
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

4
 Ch.4 Requirement Determination and Specifications

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 check against the following
conditions -
o If they can practically implement
o If they are correct and as per the functionality and specially
of software
o If there are any ambiguities
o If they are full
o If they can describe
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.

5
 Ch.4 Requirement Determination and Specifications

5. Software Requirement Management:

Requirement management is the process of managing changing
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.
Fundamental Challenges/Problems in Requirement:
Requirements is the first step of the Requirement
Engineering process. It helps the analyst to gain knowledge
about the problem domain which in turn is used to produce a
formal specification of the software. There are a number of
issues and challenges encountered during this process.
Some of them are as follows:
1. Understanding large and complex system requirements is
difficult: The word ‘large’ represents 2 aspects:
 (i) Large constraints in terms of security, etc. due to a

large number of users.

 (ii) a Large number of functions to be implemented.

2. Undefined system boundaries: There might be no defined

set of implementation requirements. The customer may go on
to include several unrelated and unnecessary functions
besides the important ones, resulting in an extremely large
implementation cost that may exceed the decided budget.

6
 Ch.4 Requirement Determination and Specifications

3. Customers/Stakeholders are not clear about their

needs: Sometimes, the customers themselves may be unsure
about the exhaustive list of functionalities they wish to see in
the software. This might happen when they have a very basic
idea about their needs but haven’t planned much about the
implementation part.
4. Conflicting requirements are there: There is a possibility
that two different stakeholders of the project express
demands which contradict each other’s implementation.
Also, a single stakeholder might also sometimes express two
incompatible requirements.
5. Changing requirements is another issue: In the case of
successive interviews or reviews from the customer, there is
a possibility that the customer expresses a change in the
initial set of specified requirements. While it is easy to
accommodate some of the requirements, it is often difficult
to deal with such changing requirements.

6. Partitioning the system suitably to reduce

complexity: The projects can sometimes be broken down
into small modules or functionalities which are then handled
by separate teams. Often, more complex and large projects
require more partitioning. It needs to be ensured that the
partitions are non-overlapping and independent of each
other.
7. Cross-checking the listed requirements before starting
the implementation part : is very important. Also, there
should be forward as well as backward traceability. For eg,
all the entity names should be the same everywhere, i.e.,
there shouldn’t be a case where ‘STUDENT’ and

7
 Ch.4 Requirement Determination and Specifications

‘STUDENTS’ are used at separate places to refer to the same

entity.
8. Identifying critical requirements: Identifying the set of
requirements that have to be implemented at any cost is very
important. The requirements should be prioritized so that
crucial ones can be implemented first with the highest
priority.
9. Resolving the “to be determined” part of the
requirements: The TBD set of requirements include those
requirements which are yet to be resolved in the future. The
number of such requirements should be kept as low as
possible.
10. Proper documentation, proper meeting time, and
budget constraints –
Ensuring proper documentation is an inherent challenge,
especially in the case of changing requirements. The time
and budget constraints too need to be handled carefully and
systematically.

Types of Requirement:
A software requirement can be of following types:
 Functional requirements

 Non-functional requirements

Functional Requirements: These are the requirements

that the end user specifically demands as basic facilities that the
system should offer. All these functionalities need to be
necessarily incorporated into the system as a part of the
contract. These are represented or stated in the form of input to
be given to the system, the operation performed and the output
8
 Ch.4 Requirement Determination and Specifications

expected. They are basically the requirements stated by the user

which one can see directly in the final product, unlike the non-
functional requirements. For example, in a hospital
management system, a doctor should be able to retrieve the
information of his patients. Each high-level functional
requirement may involve several interactions or dialogues
between the system and the outside world. In order to
accurately describe the functional requirements, all scenarios
must be enumerated. There are many ways of expressing
functional requirements e.g., natural language, a structured or
formatted language with no rigorous syntax and formal
specification language with proper syntax.
Non-functional requirements: These are basically the quality
constraints that the system must satisfy according to the project
contract. The priority or extent to which these factors are
implemented varies from one project to other. They are also
called non-behavioral requirements. They basically deal with
issues like:
 Portability

 Security

 Maintainability

 Reliability

 Scalability

 Performance

 Reusability

 Flexibility

What is SRS?
A software requirements specification (SRS) is a description
of a software system to be developed. It lays out functional and

9
 Ch.4 Requirement Determination and Specifications

non-functional requirements and may include a set of use cases

that describe user interactions that the software must provide.

Why SRS?
In order to fully understand one’s project, it is very important
that they come up with an SRS listing out their requirements,
how are they going to meet them and how will they complete
the project. It helps the team to save upon their time as they are
able to comprehend how are going to go about the project.
Doing this also enables the team to find out about the
limitations and risks early on.
The following is a sample SRS that I wrote for one of my
projects.
SRS’s characteristics include:
 Correct

 Unambiguous

 Complete

10
 Ch.4 Requirement Determination and Specifications
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable

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. Consistency: The SRS is consistent if, and only if, no subset

of individual requirements described in its conflict. There are
three types of possible conflict in the SRS:
The specified characteristics of real-world objects may
conflicts. For example,
(a) The format of an output report may be described in one
requirement as t 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.

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
11
 Ch.4 Requirement Determination and Specifications
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.

6. Modifiability: SRS should be made as modifiable as possible

and should be capable of quickly obtaining 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.

Requirements Analysis:
Requirement analysis is significant and essential activity after
elicitation. We analyze, refine, and scrutinize the gathered
requirements to make consistent and unambiguous requirements.
This activity reviews all requirements and may provide a
graphical view of the entire system. After the completion of the
analysis, it is expected that the understandability of the project
12
 Ch.4 Requirement Determination and Specifications

may improve significantly. Here, we may also use the

interaction with the customer to clarify points of confusion and
to understand which requirements are more important than
others.
The various steps of requirement analysis are shown in fig:

i) Draw the context diagram: The context diagram is a

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

13
 Ch.4 Requirement Determination and Specifications

ii) Development of a Prototype (optional): One effective

way to find out what the customer wants is to construct a
prototype, something that looks and preferably acts as part
of the system they say they want.

iii) Model the requirements: This process usually consists of

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

iv) Finalise the requirements: After modeling the

requirements, we will have a better understanding of the
system behavior. The inconsistencies and ambiguities have
been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analysis
activities have provided better insight into the system. Now
14
 Ch.4 Requirement Determination and Specifications
we finalize the analyzed requirements, and the next step is
to document these requirements in a prescribed format.

Fact Finding Techniques

 To study any system the analyst needs to do collect facts and

all relevant information. the facts when expressed in
quantitative form are termed as data. The success of any
project depends upon the accuracy of available data.
 Accurate information can be collected with help of certain
methods/ techniques.
 These specific methods for finding information of the system
are termed as fact finding techniques. Interview,
Questionnaire, Record View and Observations are the
different fact finding techniques used by the analyst. The
analyst may use more than one technique for investigation

 Interview
 This method is used to collect the information from groups or
individuals. Analyst selects the people who are related with
the system for the interview.
 In this method the analyst sits face to face with the people and
records their responses.
 The interviewer must plan in advance the type of questions he/
she is going to ask and should be ready to answer any type of
question. He should also choose a suitable place and time
which will be comfortable for the respondent.

 Questionnaire
It is the technique used to extract information from number of
people. This method can be adopted and used only by an
skillful analyst. The Questionnaire consists of series of
15
 Ch.4 Requirement Determination and Specifications
questions framed together in logical manner. The
questions are simplee, clear and to the point. This method is
very useful for attaining information from people who are
concerned with the usage of the system and who are living in
different countries

 RecordView
The information related to the system is published in the sources
like newspapers, magazines, journals, documents etc. This
record review helps the analyst to get valuable information
about the system and the organization.

 Observation
In this method the analyst himself visits the organization and
observes and understand the flow of documents, working of
the existing system, the users of the system etc. For this
method to be adopted it takes an analyst to perform this job as
he knows which points should be noticed and highlighted. In
analyst may observe the unwanted things as well and simply
cause delay in the development of the new system.

16