Software Engineering

Notes
UNIT-2
 Software Requirements

The software requirements are description of features and functionalities of the

target system. Requirements convey the expectations of users from the software
product. The requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.

Requirement Engineering
The process to gather the software requirements from client, analyze, and
document them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated

and descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four-step process, which includes –

• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
Let us see the process briefly -

Feasibility study
When the client approaches the organization for getting the desired product
developed, it comes up with a 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 do 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 analyses
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. It explores technical aspects of the

2
project and product such as usability, maintainability, productivity, and
integration ability.

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.

Requirement Gathering
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.

Software Requirement Specification (SRS)

SRS is a document created by system analyst after the requirements are
collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing,
Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the
responsibility of the system analyst to document the requirements in technical
language so that they can be comprehended and used by the software
development team.

SRS should come up with the following features:

• User Requirements are expressed in natural language.

• Technical requirements are expressed in structured language, which is

used inside the organization.

• Design description should be written in Pseudo code.

• Format of Forms and GUI screen prints.

• Conditional and mathematical notations for DFDs etc.

3
Characteristics of good SRS

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:
a. All essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external interfaces.
b. Definition of their responses of the software to all realizable classes
of input data in all available categories of situations.
c. Full labels and references to all figures, tables, and diagrams in the
SRS and definitions of all terms and units of measure.
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible
conflict in the SRS:
➢ The specified characteristics of real-world objects may conflict. For
example,
• The format of an output report may be described in one requirement
as tabular but in another as textual.
• One condition may state that all lights shall be green while another
states that all lights shall be blue.
4
➢ There may be a reasonable or temporal conflict between the two specified
actions. For example,
• One requirement may determine that the program will add two inputs,
and another may determine that the program will multiply them.
• One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.
➢ 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 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:

• Backward Traceability: This depends upon each requirement
explicitly referencing its source in earlier documents.
• 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
5
 the complete set of requirements that may be concerned by those
modifications.
9. Design Independence: There should be an option to select from
multiple design alternatives for the final system. More specifically, the
SRS should not contain any implementation details.
10.Testability: An SRS should be written in such a method that it is simple
to generate test cases and test plans from the report.
11.Understandable by the customer: An end user may be an expert in
his/her explicit domain but might not be trained in computer science.
Hence, the purpose of formal notations and symbols should be avoided
too as much extent as possible. The language should be kept simple and
clear.
12.The right level of abstraction: If the SRS is written for the
requirements stage, the details should be explained explicitly. Whereas,
for a feasibility study, fewer analysis can be used. Hence, the level of
abstraction modifies according to the objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

1. Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions decrease readability and also increase error possibilities.
2. Structured: It should be well-structured. A well-structured document is
simple to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the user requirements. Often,
user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report
well-structured.
3. Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS document
should define the external behaviour of the system and not discuss the
implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible
behaviour of the system. For this reason, the SRS report is also known as
the black-box specification of a system.
4. Conceptual integrity: It should show conceptual integrity so that the
reader can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.

6
 5. Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to
decide whether or not requirements have been met in an implementation.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts
may interpret the requirements inaccurately. This results in huge increase in cost if
not nipped in the bud. Requirements can be checked against following
conditions-

• If they can be practically implemented

• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

In the requirements validation process, we perform a different type of test to check

the requirements mentioned in the Software Requirements Specification (SRS),
these checks include:
• Completeness checks
• Consistency checks
• Validity checks
• Realism checks
• Ambiguity checks
• Variability

Requirement Validation Techniques

There are several techniques that are used either individually or in conjunction with
other techniques to check entire or part of the system:

1. Test Case Generation

The requirement mentioned in the SRS document should be testable, the
conducted tests reveal the error present in the requirement. It is generally
believed that if the test is difficult or impossible to design, this usually means
that the requirement will be difficult to implement and it should be
reconsidered.

2. Prototyping
In this validation technique the prototype of the system is presented before
the end-user or customer, they experiment with the presented model and
check if it meets their need. This type of model is mostly used to collect
feedback about the requirement of the user.

7
 3. Requirements Reviews
In this approach, the SRS is carefully reviewed by a group of people including
people from both the contractor organizations and the client side, the
reviewer systematically analyses the document to check errors and
ambiguity.

4. Automated Consistency Analysis

This approach is used for the automatic detection of an error, such as non-
determinism, missing cases, a type error, and circular definitions, in
requirements specifications. First, the requirement is structured in formal
notation then the CASE tool is used to check the in-consistency of the
system, The report of all inconsistencies is identified, and corrective actions
are taken.

5. Walk-through
A walkthrough does not have a formally defined procedure and does not
require a differentiated role assignment.
• Checking early whether the idea is feasible or not.
• Obtaining the opinions and suggestions of other people.
• Checking the approval of others and reaching an agreement.

6. Simulation
Simulating system behaviour in order to verify requirements is known as
simulation. This method works especially well for complicated systems when
it is possible to replicate real-world settings and make sure the criteria fulfil
the desired goals.

7. Checklists for Validation

It employs pre-made checklists to methodically confirm that every
prerequisite satisfies predetermined standards. Aspects like completeness,
clarity and viability can all be covered by checklists.

Importance of Requirements Validation Techniques

1. Accuracy and Clarity

It makes sure that the requirements are precise, unambiguous and clear. This
helps to avoid miscommunications and misunderstandings that may result in
mistakes and more effort in subsequent phases of the project.

2. User Satisfaction
It confirms that the requirements meet the wants and expectations of the
users, which helps to increase user happiness. This aids in providing a
product that satisfies consumer needs and improves user experience as a
whole.

8
 3. Early Issue Identification
It makes it easier to find problems, ambiguities or conflicts in the
requirements early on. It is more economical to address these issues early in
the development phase rather than later, when the project is far along.

4. Prevents the Scope Creep

It ensures that the established requirements are well stated and recorded,
which helps to prevent scope creep. By establishing defined parameters for
the project’s scope, requirements validation helps to lower the possibility of
uncontrollably changing course.

5. Improving Quality
It enhances the software product’s overall quality. By detecting and resolving
possible quality problems early in the development life cycle, requirements
validation contributes to the creation of a more durable and dependable final
product.

Advantages of Requirements Validation Techniques

• Improved quality of the final product: By identifying and addressing

requirements early on in the development process, using validation
techniques can improve the overall quality of the final product.
• Reduced development time and cost: By identifying and addressing
requirements early on in the development process, using validation
techniques can reduce the likelihood of costly rework later on.
• Increased user involvement: Involving users in the validation process can
lead to increased user buy-in and engagement in the project.
• Improved communication: Using validation techniques can improve
communication between stakeholders and developers, by providing a clear
and visual representation of the software requirements.
• Easy testing and validation: A prototype can be easily tested and
validated, allowing stakeholders to see how the final product will work and
identify any issues early on in the development process.
• Increased alignment with business goals: Using validation techniques
can help to ensure that the requirements align with the overall business goals
and objectives of the organization.
• Traceability: This technique can help to ensure that the requirements are
being met and that any changes are tracked and managed.
• Agile methodologies: Agile methodologies provide an iterative approach to
validate requirements by delivering small chunks of functionality and getting
feedback from the customer.

9
Disadvantages of Requirements Validation Techniques
• Increased time and cost: Using validation techniques can be time-
consuming and costly, especially when involving multiple stakeholders.
• Risk of conflicting requirements: Using validation techniques can lead to
conflicting requirements, which can make it difficult to prioritize and
implement the requirements.
• Risk of changing requirements: Requirements may change over time and
it can be difficult to keep up with the changes and ensure that the project is
aligned with the updated requirements.
• Misinterpretation and miscommunication: Misinterpretation and
miscommunication can occur when trying to understand the requirements.
• Dependence on the tool: The team should be well-trained on the tool and
its features to avoid dependency on the tool and not on the requirement.
• Limited validation: The validation techniques can only check the
requirement that is captured and may not identify the requirement that is
missed
• Limited to functional requirements: Some validation techniques are
limited to functional requirements and may not validate non-functional
requirements.

Requirement Elicitation Process

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, it is then
negotiated and discussed with the 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 and informal, functional and non-functional

requirements are documented and made available for next phase
processing.
10
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an
intended software system by communicating with client, end users, system
users, and others who have a stake in the software system development.

There are various ways to discover requirements. Some of them are explained
below:

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

➢ Surveys
• Organization may conduct surveys among various stakeholders by
querying about their expectation and requirements from the upcoming
system.

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

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

➢ Domain Analysis
11
• Every software falls into some domain category. The expert people in the
domain can be a great help to analyze general and specific requirements.

➢ Brainstorming
• An informal debate is held among various stakeholders and all their inputs
are recorded for further requirements analysis.

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

➢ Observation
• Team of experts visit the client’s organization or workplace. They observe
the actual working of the existing installed systems. They observe the
workflow at the client’s end and how execution problems are dealt. The
team itself draws some conclusions which aid to form requirements
expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software
development project. Hence, they must be clear, correct, and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

12
Software Requirements
We should try to understand what sort of requirements may arise in the
requirement elicitation phase and what kinds of requirement are expected from
the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements
Requirements, which are related to functional aspect of software fall into this
category.

They define functions and functionality within and from the software system.

EXAMPLES -

• Search option given to user to search from various invoices.

• User should be able to mail any report to management.

• Users can be divided into groups and groups can be given separate rights.

• Should comply business rules and administrative functions.

• Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into
this category. They are implicit or expected characteristics of software, which
users make assumption of.

Non-functional requirements include -

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility
Requirements are categorized logically as:

• Must Have: Software cannot be said operational without them.

• Should have: Enhancing the functionality of software.

• Could have: Software can still properly function with these requirements.

• Wish list: These requirements do not map to any objectives of software.

13
While developing software, ‘Must have’ must be implemented, ‘Should have’ is a
matter of debate with stakeholders and negation, whereas ‘Could have’ and
‘Wish list’ can be kept for software updates.

User Interface requirements

User Interface (UI) is an important part of any software or hardware or hybrid
system. A 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 can not be used in
convenient way. A system is said to 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 colour and texture.
• Provide help information
• User centric approach
• Group based view settings.

Software System Analyst

System analyst in an IT organization is a person, who analyses the requirement of
proposed system and ensures that requirements are conceived and documented
properly and accurately. Role of an analyst starts during Software Analysis Phase

14
of SDLC. It is the responsibility of analyst to make sure that the developed
software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analysing and understanding requirements of intended software.

• Understanding how the project will contribute to the organizational

objectives.

• Identify sources of requirement.

• Validation of requirement.

• Develop and implement requirement management plan.

• Documentation of business, technical, process, and product requirements.

• Coordination with clients to prioritize requirements and remove ambiguity.

• Finalizing acceptance criteria with client and other stakeholders.

15