Ch.

4 Requirement Engineering
 Content:
 4.1 Introduction
 4.2 Requirement Elicitation
 4.3 Requirement Elaboration
 4.4 Requirement Gathering
 4.5 Feasibility Study
 4.6 Fact Finding Techniques
 4.7 SRS Format

4.1 Introduction:
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.
Requirements engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software
system.
 Tools involved in requirement engineering:
1. observation report
2. Questionnaire ( survey , poll )
3. Use cases
4. User stories
5. Requirement workshop
 6. Mind mapping
7. Role playing
8. Prototyping

4.2 Requirements Elicitation:

It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of same type, standards and other stakeholders of the
project. The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the requirements
understood. Instead, it widens the domain knowledge of the analyst and thus helps in
providing input to the next stage.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the
requirements engineering process and it is critical to the success of the software
development project. The goal of this step is to understand the problem that the software
system is intended to solve, and the needs and expectations of the stakeholders who will
use the system.

There are several techniques that can be used to elicit requirements, including:

 Interviews: These are one-on-one conversations with stakeholders to gather

information about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
It’s important to document, organize and prioritize the requirements obtained from all
these techniques to ensure that they are complete, consistent and accurate.

4.3 Requirement Elaboration:

 This is the third phase of the requirements analysis process.
 This phase is the result of the inception and elicitation phase.
 In the elaboration process, it takes the requirements that have been stated and
gathered in the first two phases and refines them.
 Expansion and looking into it further are done as well.
 The main task in this phase is to indulge in modeling activities and develop a prototype
that elaborates on the features and constraints using the necessary tools and functions.

4.4 Requirement Gathering:

 Requirements gathering are the process of understanding what you are trying to build
and why you are building it.
 Requirements gathering are often regarded as a part of developing software
applications or of cyber-physical systems like aircraft, spacecraft, and automobiles
(where specifications cover both software and hardware).
 Step Requirements Gathering Process
 The requirements gathering process consists of six steps.
 The full six steps are as follows:
Note: It is important to note that while these steps are typically initiated in the order listed,
there is a great deal of overlap and iteration among them. It may, therefore, be better to think
of them as subprocesses rather than steps as we look at each one individually.
 Identify the Relevant Stakeholders:
Find qualified representatives from each relevant stakeholder group. Depending on your project,
these may include:

 Customers stakeholders
 Decision-makers
 Users
 System administrators
 Other impacted customer departments
 Internal stakeholders
 Executives
 Engineering
 Marketing
 Sales
 Customer support (including on-site maintenance teams, if applicable)
 Key suppliers
 Distributers and other partners

 Establish Project Goals and Objectives:

 What are you trying to achieve with this new product or project? What are the
overall outcomes your customers want from the product? What are your company’s
business goals? What are the actionable, measurable objectives you need to achieve
to realize those goals and outcomes?
 Write them down. State them clearly, and get all your stakeholders to sign-off on
them.
 Your goals and objectives will act as a framework for your decision-making.
 Each requirement you write should help satisfy a project objective and accomplish a
goal.
 If it doesn’t, you should either discard it or made it a candidate for a future release.
 Elicit Requirements From Your Stakeholders:
 Elicitation can be performed in several ways.
 Time-tested techniques include surveys, questionnaires, and interviews.
 Interviews and follow-up meetings will be prevalent during later iterations.

 Document the Requirements:

 As soon as requirements begin to emerge from your elicitation process, start documenting
them.
 Write them down and collect them in whatever format your organization has agreed upon.
 Most important is that the requirements documentation…
 Can be easily navigated and understood by your team
 Is available for review by all stakeholders
 Provides a facility for traceability to other documentation.

 Confirm the Requirements:

 Review the requirements with all stakeholders.
 Make sure the requirements clearly capture what was intended and that all parties have a
common understanding of each of them.
 If you find any ambiguity in a requirement, revise it.

 Prioritize the Requirements:

 Most engineering development programs run into unexpected challenges along the way.
 Unanticipated obstacles are encountered. Schedules slip. Priorities change.
 It’s important to be able to adapt to those challenges and changes.
 That’s why it is crucial to prioritize your requirements based on how each will impact your
goals and objectives for your release.

4.5 Feasibility Study:

 Feasibility study is carried out whenever there is a complex problem or opportunity.

 It is in fact a preliminary investigation which emphasizes the “ Look before you leap”
approach to any important project.
  A feasibility study is undertaken to determine the possibility or probability of either
improving the existing system or developing a completely new system.

 Need for Feasibility study:

 Answer the question whether a new system is to be installed or not?
 Determine the potential of the existing system
 Improve the existing system
 Know what should be embedded in the new system.
 Define the problems and objectives involved in a project.
 Avoid costly repairs at a later stage when the system is implemented.
 Avoid crash implementation of new system.

 To conduct a detailed feasibility study, firstly an expert committee called “Steering

Committee” is appointed.
 This committee generally consists of systems analyst, representatives from the departments
which are likely to benefit from the project and a chairman who is generally a key person in
the organization.
 There are Three methods are as follows:
1. Technical feasibility
2. Economic feasibility and
3. Operational feasibility

1. Technical feasibility:

 The technical feasibility should ask questions related to:

1. Adequacy of available technology
2. Adequacy of hardware
3. Availability of computer
4. Operating time and support facilities etc.
2. Economic feasibility:

 Firstly identify the alternatives.

 Determines costs and expected saving of each of the alternatives.
  The cost must include both one-time costs and recurring costs.
 One-time costs includes:
 Feasibility study cost
 The costs for converting from present system to new system
 Construction or remodeling of computer room / facilities.
 Cost involved in software packages.
 Recurring costs may include:
 Rental or purchase of equipment's
 Salaries of personnel
 Supplies.
 Equipment Maintenance.

3. Operational or Behavioral Feasibility:

 Will the system be used, if it is implemented?
 Will there be resistance from users?
 This is necessary because “equipment’s do not cry but people do cry”.
 The existing personnel normally worry about job security, loss of peer group, changes in job
context and so on, whenever new systems are proposed.
 If their voices are not heard at this stage, the problem will be magnified at the
implementation state and appear as direct or indirect resistance to new system.

 4.6 Fact Finding / Gathering Techniques:

 Information gathering in large and complex organization is not an easy task. It has to be
gathered in an organized way so that
 No system details are left out
 Right problems are identified
 Repetitive work is avoided
 Wrong or incomplete details are not collected.
 To this end, a proper search strategy must be decided first. Search strategy includes
selecting information sources and search method.
 It also includes modeling methods to make sense out of information so collected. Here we
try to get an overall idea about the search methods or fact gathering/ finding techniques
which are commonly used. They are:
  Interviewing
 Questionnaires
 Record Inception
 Observation
 These techniques are used in system analysis, design or even during implementation stage.

 Interviewing:
 This technique is used to collect information from individuals or from groups.
 It is an art better learned from practice than from books.
 It is an invaluable technique to gather qualitative information, opinions, policies,
suggestions, underlying problems etc.
 However there are certain points to be remembered in conducting interviews:
 Put yourself in other man’s place and pose your questions. Cultivate the ability to
appreciate his point of view.
 Be sure you really understand instead of jumping to conclusions.
 Maintain a neutral attitude, show genuine interest so that the other person can come
out with his problems, thought and ideas.
 Let him do the most talking ! Listen ! Listening is an art.
 Ask specifics.
 Notice what he does not say.
 Do not allow your mind to wander. It is usually reflected in your face. If the interviewer
leaves the core subject , bring him back to the track tactfully.
 Don’t show you are in hurry!
 Be prepared for disagreement.
 Distinguish between fact and opinion.
 Always be polite ! Don’t be over polite!
 General rules for conducting an interview:
 Obtain prior permission
 Prepare oneself as regards to objective and methods.
 Put the interviewee at ease.
 Explain in advance about the subject of the interview.
 Avoid arguments involving too many people at the same time.
 Do not try to cover too much ground in one interview
 Questionnaires:
 Questionnaires may be used as a supplement to interviews.
 More people can be reached and answers can be corroborated (confirm).
 The questionnaires can have open ended questions like – What are the major and minor
problems in the existing system?
 A closed ended questionnaire will have fixed responses like – What is the average value of
invoice in your department?
 It can be considered as a structured interview form.
 Since the cost involved in developing and distributing is very high, the following points
must be kept in mind while designing questionnaires:
1. The objective of the questionnaire must be clear.
2. The structure must be useful for the study.
3. Question must be easily and unambiguously understood.
 In addition the respondents should be carefully selected.
 The responses received must be analyzed scientifically and without any bias.
 Questionnaires are useful for:
1. Gathering numerical data
2. Getting relatively simple opinion from a large number of people.
3. Obtaining collective opinion etc.
 Questionnaires are also useful to get feedback in a post implementation audit.

 Record review:
 Believe in record than in people! Thus a good analyst always gets facts from documents.
 An existing system can be better understood by examining existing documents, forms and
files.
 This record review can take place at the beginning of the system study or later in the study
for comparing actual operations with what the records indicate.
 Records may include:
 Written policy manuals.
 Rules and regulations.
 Standard operating procedures used in the organization.
 Forms and documents.
  The following questions may be useful in analysis of form:
 Who uses these forms?
 Do they include all the necessary information?
 How readable and easy to follow is the form? Etc

 Observation:
 An analyst must always keep his mental antenna alert!
 Observation can bring in missed facts, new ways to improve the existing procedures,
duplicate work done inadvertently etc.
 Operation can bring in what other fact finding methods cannot! But this task is delicate
because people do not like to be observed when they work.
 Observation can look for:
 Operational inefficiencies
 Alternate routes and procedures
 Interruptions in the normal flow of work
 The usage of files and documents.
 Informal communication channels etc.

 4.7 SRS Format:

 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.
 Software Requirement Specification (SRS) Format as the name suggests, is a complete
specification and description of requirements of the software that need to be fulfilled for the
successful development of the software system. These requirements can be functional as
well as non-functional depending upon the type of requirement. The interaction between
different customers and contractors is done because it is necessary to fully understand the
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.
 SRS contains:
 Introduction:
 Purpose of this Document – At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.
 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.
 Overview – In this, description of product is explained. It’s simply summary or overall
review of product.
 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.
 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. Functional requirements specify the expected
behavior of the system-which outputs should be produced from the given inputs. They
describe the relationship between the input and output of the system. For each functional
requirement, detailed description all the data inputs and their source, the units of measure,
and the range of valid inputs must be specified.
 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 and
explained. Examples can be shared memory, data streams, etc.
 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. The
performance requirements 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. Dynamic requirements specify constraints on the execution
behaviour of the system.
 Design Constraints:
 In this, constraints which simply means limitation or restriction are specified and explained
for design team. Examples may include use of a particular algorithm, hardware and
software limitations, etc. There are a number of factors in the client’s environment that may
restrict the choices of a designer leading to design constraints 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.
 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.
 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.
 Appendices
 In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.
 Uses of SRS document
 Development team require it for developing product according to the need.
  Test plans are generated by testing group based on the describe external behaviour.
 Maintenance and support staff need it to understand what the software product is supposed
to do.
 Project manager base their plans and estimates of schedule, effort and resources on it.
 Customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 In documentation purpose.

 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 its
conflict. There are three types of possible conflict in the SRS:
(1). 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 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.
(2). 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.
(3). 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.

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

============================================================================