Requirements Engineering

Requirement Engineering is the process of establishing the services that the customer
requires from a system and the constraints under which it operates and is developed.
It is the process of defining, documenting, and maintaining requirements in the
engineering design process.
The requirements themselves are the descriptions of the system services and
constraints that are generated during the requirements engineering process.
o User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
• Written for customers.
o System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
• Defines what should be implemented so may be part of a contract between
client and contractor.
• Whom do you think these are written for?
Problems with NL
Types of requirements

1. Business Requirements: Business requirements specify the software’s business demand. The
business requirement identifies why the software is required, who will be the end-users of the
software, how the software will benefit its end users. The business requirement does specify the
technicality of the software i.e. how it should be implemented it focuses only on what software
must do for them.
2. Users Requirements: The user requirements specify the need and expectations of the end-users
of the software. Although the user’s requirement is sometimes incorporated with the business
requirements. But sometimes requirements of software with more complex functionality or more
complex user interface must be documented separately.
3. Software Requirements:
Software requirements include functional, non-functional and domain requirements.
Functional Requirements

These are the requirements that the end user specifically demands as basic facilities that
the system should offer. It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what function a system is
likely to perform.
These are represented or stated in the form of input to be given to the system, the
operation performed and the output 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.

4
Non-functional requirements

These are basically the quality constraints that the system must satisfy according to
the project contract. Nonfunctional requirements, not related to the system
functionality, rather define how the system should perform. The priority or extent to
which these factors are implemented varies from one project to other. They
basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
 NFRs

• Reliability means making systems work correctly and meet the requirements of the
user.
• Scalability means having strategies for keeping performance good, even when load
increases.
• Portability: The system must be able to run on different platforms with minimal
changes.
• Reliability: The system must be reliable Usability: The system must be easy to use and
understand.
• Compatibility: The system must be compatible with other systems.
• Flexibility: How easily the software can be modified to adapt to different
environments, configurations, and user expectations.
• Maintainability: how easily faults in the software system can be found and fixed.
• Reusability: It is the extent to which a portion of the software system can be converted
for use in another system.
• Flexibility: How easily the software can be modified to adapt to different
environments, configurations, and user expectations.
Domain requirements

o The domain requirement describes area/group for which the software is to be

developed. Domain requirements: Domain requirements are the requirements which
are characteristic of a particular category or domain of projects. Domain
requirements can be functional or nonfunctional. Such as for college, office, military,
hospital, students, teachers, patients etc.
o For instance, in an academic software that maintains records of a school or college,
the functionality of being able to access the list of faculty and list of students of each
grade is a domain requirement. These requirements are therefore identified from that
domain model and are not user specific.

7
Differences
Metrics for specifying nonfunctional
requirements

Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure (MTTF)
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure (MTTR)
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

9
The Requirement Document
 Requirement Discovery, Interviews, Scenarios, Use Cases and
Ethnography

 Requirement discovery is a type of informal document that is written before

development of SRS, it consists of overall requirements that are described by the
client. In gathering these requirements we have to interact with the stakeholders,
client, users etc.
 Interviews: This can be done by formal or informal interactions with the client or
the environment in which the system is to be deployed. Our main goal is to interpret
the user requirements, it is our choice how we do it, either by interviewing or by
analyzing the environment ourselves. In close interview first we think about some
questions and queries, that are to be answered by the client while in open interview
scope of discussion is not fixed, it is more generalized and effective.
Requirement Discovery, Interviews, Scenarios, Use Cases and
Ethnography

 Scenario: It is a scene that illustrates some interaction with a proposed system. It is

a tool used during requirements analysis to describe a specific use of a proposed
system. Scenarios capture the system, as viewed from outside, e.g., by a user, using
specific examples. These are tools for requirement analysis.
 Use Cases: For the description of all possible interactions with the system, we
practice use cases which are scenario based technique in UML to identify the actors
involved in an interaction. Use cases are tools foe modeling requirements.
 Ethnography: The method of requirement discovery in which the software engineer
interacts, observe and understand the environment personally is called ethnography.
This method is not that effective for the addition of new feature since the non-
existing features cannot be observed.
Tasks/Steps
Tasks/Steps of Requirement Engineering
Tasks/Steps of Requirement Engineering
Tasks/Steps of Requirement Engineering
Tasks/Steps of Requirement Engineering

Steps of Requirement engineering process

Requirement Engineering Process Diagram
Requirements Change Management:

It is a process “of managing changing requirements during the requirements

engineering process and system development.” Having a requirements change
management system and process in place is crucial since it ensures that changes are
made systematically, changes are documented for, and the requirements change
management document is updated. It also includes ensuring that the subsequent
changes are communicated to stakeholders thus avoiding miscommunication.