Requirement Engineering

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

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.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development

project. Hence they should be clear, correct, and well-defined.
A complete Software Requirement Specifications should be:

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

Software Requirements: Largely software requirements must be categorized into

two categories:

1. Functional Requirements: Functional requirements define a function that a

system or system element must be qualified to perform and must be
documented in different forms. The functional requirements are describing
the behavior of the system as it correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the
criteria that can be used to decide the operation instead of specific behaviors
of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable
at run time.
 o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.

Requirement Engineering Process

• Requirement Engineering means that requirements for a product are defined,

managed and tested systematically.

• Requirements engineering builds a bridge to design and construction.

• Requirements engineering provides the appropriate mechanism for

understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution

• unambiguously, validating the specification, and managing the requirements

as they are transformed into an operational system.

Requirement Engineering Tasks

Inception

• ̶ Establish a basic understanding of the problem and the nature of the

solution.

• ̶ In project inception, you establish a basic understanding of the problem,

the people who want a solution, the nature of the solution that is desired, and
the effectiveness of preliminary communication and collaboration between
the other stakeholders and the software team.

Elicitation

• ̶ Draw out the requirements from stakeholders.

 • ̶ Number of problems that are encountered as elicitation occurs are
problems of scope, problems of understanding, problems of volatility

Elaboration (Highly structured)

• ̶ Create an analysis model that represents information, functional, and

behavioral aspects of the requirements.

• ̶ Elaboration is driven by the creation and refinement of user scenarios that

describe how the end user (and other actors) will interact with the system.

• ̶ Each user scenario is parsed to extract analysis classes—business domain

entities that are visible to the end user.

• ̶ The attributes of each analysis class are defined, and the services that are
required by each class are identified.

• ̶ The relationships and collaboration between classes are identified, and a

variety of supplementary diagrams are produced.

Negotiation

• ̶ Agree on a deliverable system that is realistic for developers and

customers.

• ̶ The best negotiations strive for a “win-win” result.

• ̶ That is, stakeholders win by getting the system or product that satisfies the
majority of their needs and you (as a member of the software team) win by
working to realistic and achievable budgets and deadlines.

• ̶ activities in negotiation are :

• ̶ Identification of the system or subsystem’s key stakeholders.

 • ̶ Determination of the stakeholders’ “win conditions.”

• ̶ Negotiation of the stakeholders’ win conditions to reconcile them into a

set of win-win conditions for all concerned (including the software team).

Specification

• ̶ Describe the requirements formally or informally.

• ̶ A specification can be a written document, a set of graphical models, a

formal mathematical model, and a collection of usage scenarios, a prototype,
or any combination of these.

Validation

• ̶ Review the requirement specification for errors, ambiguities, omissions,

and conflicts.

• ̶ Requirements validation examines the specification to ensure that all

software requirements havBeen stated unambiguously; that inconsistencies,
omissions, and errors have been detected and Corrected; and that the work
products conform to the standards established for the process, the project,
and the product.

• ̶ The primary requirements validation mechanism is the technical review.

• ̶ The review team that validates requirements includes software engineers,

customers, users, and other stakeholders who examine the specification
looking for errors in content or interpretation, areas where clarification may
be required, missing information, inconsistencies (a major problem when
large products or systems are engineered), conflicting requirements, or
unrealistic (unachievable) requirements.
Requirements management

• ̶ Manage changing requirements.

• ̶ Requirements management is a set of activities that help the project team

identify, control, and track requirements and changes to requirements at any
time as the project process.

• ̶ Many of these activities are identical to the software configuration

management.

Requirement Elicitation

• Requirements elicitation (also called requirements gathering) combines

elements of problem solving, elaboration, negotiation, and specification.

• · In order to encourage a collaborative, team-oriented approach to

requirements gathering, stakeholders work together to identify the problem,
propose elements of the solution, negotiate different approaches and specify
a preliminary set of solution requirements.

Collaborative Requirements Gathering

• The goal is to identify the problem, propose elements of the solution,

negotiate different approaches, and specify a preliminary set of solution
requirements in an atmosphere that is conducive to the accomplishment of
the goal.

• Meetings are conducted and attended by both software engineers and other
stakeholders.

• Rules for preparation and participation are established.

 • An agenda is suggested that is formal enough to cover all important points
but informal enough to encourage the free flow of ideas.

• A “facilitator” (can be a customer, a developer, or an outsider) controls the

meeting.

• A “definition mechanism” (can be work sheets, flip charts, or wall stickers

or an electronic bulletin board, chat room, or virtual forum) is used.

Quality Function Deployment

• Quality function deployment (QFD) is a quality management technique that

translates the needs of the customer into technical requirements for software.
QFD “concentrates on maximizing customer satisfaction from the software
engineering process”.

• QFD identifies three types of requirements normal requirements, expected

requirements, exciting requirements

Usage Scenarios

• As requirements are gathered, an overall vision of system functions and

features begins to materialize.

• Users can create a set of scenarios that identify a thread of usage for the
system to be constructed.

• The scenarios, often called use cases.

Elicitation Work Products

• The work products produced as a consequence of requirements elicitation

will vary depending on the
 • size of the system or product to be built. For most systems, the work
products include

• · A statement of need and feasibility.

• · A bounded statement of scope for the system or product.

• · A list of customers, users, and other stakeholders who participated in

requirements elicitation.

• · A description of the system’s technical environment.

• · A list of requirements (preferably organized by function) and the domain

constraints that apply to each.

• · A set of usage scenarios that provide insight into the use of the system or
product under different

• operating conditions.

• · Any prototypes developed to better define requirements.

System Requirement Specification

• · It contains a complete information description, a detailed functional

description, a representation of

• system behaviour, an indication of performance requirements and design

constraints, appropriate

• validation criteria, and other information pertinent to requirements.

• · Software requirement specification (SRS) is a document that completely

describes what the proposed
 • software should do without describing how software will do it.

• · The basic goal of the requirement phase is to produce the SRS, Which
describes the complete behaviour

• of the proposed software.

• · SRS is also helping the clients to understand their own needs.

Characteristics of an SRS

• Software requirements specification should be accurate, complete, efficient,

and of high quality, so that it

• does not affect the entire project plan. An SRS is said to be of high quality
when the developer and user easily

• understand the prepared document. Other characteristics of SRS are

discussed below.

Correct

• SRS is correct when all user requirements are stated in the requirements
document.

• The stated requirements should be according to the desired system.

• This implies that each requirement is examined to ensure that it (SRS)

represents user requirements.

• Note that there is no specified tool or procedure to assure the correctness of

SRS. Correctness

• ensures that all specified requirements are performed correctly.

Unambiguous

• SRS is unambiguous when every stated requirement has only one

interpretation.

• This implies that each requirement is uniquely interpreted.

• In case there is a term used with multiple meanings, the requirements

document should specify the meanings in the SRS so that it is clear and easy
to understand.

Complete

• SRS is complete when the requirements clearly define what the software is
required to do.

• This includes all the requirements related to performance, design and

functionality

Rankedd for importance/stability

• All requirements are not equally important, hence each requirement is

identified to make differences among other requirements.

• For this, it is essential to clearly identify each requirement. Stability implies

the probability of changes in the requirement in future.

Modifiable

• The requirements of the user can change, hence requirements document

should be created in such a

• manner that those changes can be modified easily, consistently maintaining

the structure and style of the SRS.
Traceable

• SRS is traceable when the source of each requirement is clear and facilitates
the reference of each requirement in future.

• For this, forward tracing and backward tracing are used.

• Forward tracing implies that each requirement should be traceable to design

and code elements.

• Backward tracing implies defining each requirement explicitly referencing

its source.

Verifiable

• SRS is verifiable when the specified requirements can be verified with a

cost-effective process to check whether the final software meets those
requirements.

• The requirements are verified with the help of reviews. Note that
unambiguity is essential for verifiability.

Consistent

• SRS is consistent when the subsets of individual requirements defined do

not conflict with each other.

• For example, there can be a case when different requirements can use
different terms to refer to the same object.

• There can be logical or temporal conflicts between the specified

requirements and some requirements whose logical or temporal
characteristics are not satisfied.
 • For instance, a requirement states that an event 'a' is to occur before another
event 'b'. But then another set of requirements states (directly or indirectly
by transitivity) that event 'b' should occur before event 'a'.

Functional and Non-Functional Requirements

Functional requirements

• These describe the functionality of a system -- how a system should react to

a particular set of inputs and what should be the corresponding output.

• Given a problem statement, the functional requirements could be identified

by focusing on the following

points:

• ̶ Identify the high level functional requirements simply from the conceptual
understanding of the problem. For example, a Library Management System,
apart from anything else, should be able to issue and return books.

• ̶ Identify the cases where an end user gets some meaningful work done by
using the system. For example, in a digital library a user might use the
"Search Book" functionality to obtain information about the books of his
interest.

• ̶ If we consider the system as a black box, there would be some inputs to it,
and some output in return. This black box defines the functionalities of the
system. For example, to search for a book, user gives title of the book as
input and get the book details and location as the output.

• ̶ Any high level requirement identified could have different sub-

requirements. For example, "Issue Book" module could behave differently
 for different class of users, or for a particular user who ha issuedd the book
thrice consecutively.

Non-Functional requirements

• They are not directly related what functionalities are expected from the
system.

• However, NFRs could typically define how the system should behave under
certain situations.

• For example, a NFR could say that the system should work with 128MB
RAM.

Product requirements

• Requirements which specify that the delivered product must behave in a

particular way e.g. execution speed, reliability, etc.

Organisational requirements

• Requirements which are a consequence of organisational policies and

procedures e.g. process standards used, implementation requirements, etc.

External requirements

• Requirements which arise from factors which are external to the system and
its development process

• e.g. interoperability requirements, legislative requirements, etc.

• Example:

• Functional Requirements for Hotel Management System

• 1. Reservation/Booking

• [Link] system shall record reservations.

• [Link] system shall record the customer’s first name.

• [Link] system shall record the customer’s last name.

• [Link] system shall record the number of occupants.

• [Link] system shall record the room number.

• [Link] system shall display the default room rate.

• [Link] system shall record the customer’s phone number.

• [Link] system shall display whether or not the room is guaranteed.

• [Link] system shall generate a unique confirmation number for each

reservation.

• 1.10. The system shall record the expected check-in date and time.

• 1.11. The system shall record the expected checkout date and time.

• 1.12. The system shall check-in customers.

• 1.13. The system shall allow reservations to be modified without having to

reenter all the

• customer information.

• 1.14. The system shall checkout customers.

• 1.15. The system shall charge the customer for an extra night if they
checkout after 11:00 a.m.
• 1.16. The system shall mark guaranteed rooms as “must pay” after 6:00 pm
on the check-in

• date.

• 1.17. The system shall record customer feedback.

• 2. Food

• [Link] system shall track all meals purchased in the hotel (restaurant and
room service).

• [Link] system shall record payment and payment type for meals.

• [Link] system shall bill the current room if payment is not made at time of
service.

• [Link] system shall accept reservations for the restaurant and room service.

• Management

• [Link] system shall display the hotel occupancy for a specified period of
time (days; including

• past, present, and future dates).

• [Link] system shall display projected occupancy for a period of time

(days).

• [Link] system shall display room revenue for a specified period of time
(days).

• [Link] system shall display food revenue for a specified period of time
(days).
 • [Link] system shall display an exception report, showing where default
room and food prices

• have been overridden.

• [Link] system shall allow for the addition of information, regarding rooms,
rates, menu items,

• prices, and user profiles.

• [Link] system shall allow for the deletion of information, regarding rooms,
rates, menu items,

• prices, and user profiles.

• [Link] system shall allow for the modification of information, regarding

rooms, rates, menu

• items, prices, and user profiles.

• [Link] system shall allow managers to assign user passwords.

Non-Functional Requirements for Hotel Management System

• 1 The load time for user interface screens shall take no longer than two
seconds.

• 2 The log in information shall be verified within five seconds.

• 3 Queries shall return results within five seconds.

• 4 The Hotel Management System shall be a stand-alone system running in a

Windows environment.

• 5 The system shall be developed using Java platform.

 • 6 There shall be consistency in variable names within the system.

• 7 The graphical user interface shall have a consistent look and feel.

• 8 Specify the factors required to establish the required reliability of the

software system at time of

• delivery.

• 9 The system shall be available during normal hotel operating hours.

• 10 Customer Service Representatives and Managers will be able to log in to

the Hotel Management System.

• Customer Service Representatives will have access to the

Reservation/Booking and Food subsystems.

• Managers will have access to the Management subsystem as well as the

Reservation/Booking and Food

• subsystems.

• 11 Access to the various subsystems will be protected by a user log in screen

that requires a user name and

• password.

• Feasibility Study

• Feasibility study establishes the basic business requirements and constraints

associated with the application to be built and then assesses whether the
application is a viable candidate for the process.

Types of Feasibility Study

• Technical feasibility

• In technical feasibility analysis, alternatives for hardware, software and

general design approach are

• determined to be available, appropriate, and functional.

• The technical issues raised during the feasibility study are:

• a) Does the necessary technology exist?

• b) Does the proposed equipment have the technical capacity to hold the data
required to use the new system?

• c) Will the proposed system and components provide adequate responses to

enquires, regardless of the number of location of users?

• d) Can the system be expanded, if developed?

• e) Are there technical guarantees of accuracy, reliability, ease of access and

data security?

• Operational feasibility

• Operational feasibility study tests the operational scope of the software to

be developed. The proposed software must have high operational feasibility.
The usability will be high.

• Operational feasibility is dependent on human resources available for the

project and involves projectin whetherr the system will be used if it is
developed and implemented.

• Operational feasibility is a measure of how well a proposed system solves

the problems, and takes
• advantage of the opportunities identified during scope definition and how it
satisfies the requirements

• identified in the requirements analysis phase of system development.

• The essential questions that help in testing the operational feasibility of a

system include the following:

• a) Does current mode of operation provide adequate throughput and

response time?

• b) Does current mode provide end users and managers with timely,
pertinent, accurate and useful formatted information?

• c) Does current mode of operation provide cost-effective information

services to the business?

• d) Could there be a reduction in cost and or an increase in benefits?

• e) Does current mode of operation offer effective controls to protect against

fraud and to guarantee accuracy and security of data and information?

• f) Does current mode of operation make maximum use of available

resources, including people, time, and flow of forms?

• g) Does current mode of operation provide reliable services

• h) Are the services flexible and expandable?

• i) Are the current work practices and procedures adequate to support the new
system?

• j) If the system is developed, will it be used?

• k) Manpower problems, Labour objections, Manager resistance,
Organizational conflicts and policies, Government regulations

• l) Does management support the project?

• m) Are the users not happy with current business practices?

• n) Will it reduce the time (operation) considerably?

• o) Have the users been involved in the planning and development of the
project?

• p) Will the proposed system really benefit the organization?

• Economic feasibility

• The economic feasibility study evaluate the cost of the software

development against the ultimate income or benefits gets from the developed
system.

• There must be scopes for profit after the successful Completion of the
project.

• Possible questions raised in economic analysis are:

• a) Is the system cost effective?

• b) Do benefits outweigh costs?

• c) The cost of doing full system study

• d) The cost of business employee time

• e) Estimated cost of hardware

• f) Estimated cost of software/software development

• g) Is the project possible, given the resource constraints?

• h) What are the savings that will result from the system?

• i) Cost of employees' time for study.

• j) Cost of packaged software/software development.