“SOFTWARE ENGINEERING”

REQUIREMENT ENGINEERING:

SYED AMAN SHAH

BUSHRA KHAN

IT(21-25)

DEPARTMENT OF INFORMATION TECHNOLOGY,

THE ISLAMIA UNIVERSITY OF BAHAWALPUR
REQUIREMENT ENGINEERING:
The process of collecting the software requirement from the client then understand, evaluate
and document it is called as requirement engineering.
Requirement engineering constructs a bridge for design and construction.

CHARACTERISTICS OF A GOOD REQUIREMENT:

● Clear and Unambiguous
1. standard structure
2. has only one possible interpretation
3. Not more than one requirement in one sentence
● Correct A requirement contributes to a real need
● Understandable A reader can easily understand the meaning of the requirement
● Verifiable A requirement can be tested
● Complete
● Consistent
● Traceable

WHY IS GETTING GOOD REQUIREMENTS HARD?

● Stakeholders don’t know what they really want.
● Stakeholders express requirements in their own terms.
● Different stakeholders may have conflicting requirements.
● Organisational and political factors may influence the system requirements.
● The requirements change during the RE process. New stakeholders may emerge and the
business environment change.

REQ ENG TASKS:

Requirement engineering consists of seven different tasks as follows:

INCEPTION:
● Inception is a task where the requirement engineering asks a set of questions to establish a
software process.
● In this task, it understands the problem and evaluates with the proper solution.
● It collaborates with the relationship between the customer and the developer.
● The developer and customer decide the overall scope and the nature of the question.

ELICITAION:
Elicit requirements from all stakeholders.

ELABORATION:
● In this task, the information taken from user during inception and elaboration and are expanded
and refined in elaboration.
● Its main task is developing pure model of software using functions, featurand constraints of a
software.
NEGOTIATION:
● Agree on a deliverable system that is realistic for developers and customers.

SPECIFICATION:
● In this task, the requirement engineer constructs a final work product.
● The work product is in the form of software requirement specification.
● can be any one (or more) of the following:
1. A written document
2. A set of models
3. A formal mathematical
4. A collection of user scenarios (use-cases)
5. A prototype

VALIDATION:
A review mechanism that looks 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 or unrealistic (unachievable) requirements.

● The requirements should be consistent with all the other requirements i.e no two requirements
should conflict with each other.
● The requirements should be complete in every sense.
● The requirements should be practically achievable.

REQUIREMENT MANAGEMENT:

● It is a set of activities that help the project team to identify, control and track the requirements
and changes can be made to the requirements at any time of the ongoing project.
FUNCTIONAL & NON-FUNCTIONAL REQ:

FUNCTIONAL REQUIREMENTS:
● A functional requirement defines a system or its component.
● It describes the functions a software must perform.
● How the system should react to particular inputs.
● How the system should behave in particular situations.

Functional Requirements depend on the type of software, expected users and the type of system
where the software is used.
In functional system requirements, the system services should be described in detail.

FOR EXAMPLE:
1) Authentication of user whenever he/she logs into the system.
2) System shutdown in caseyber attack.

EXAMPLE OF PATIENT MANAGEMENT SYSTEM:

● A user shall be able to search the appointments lists for all clinics.
● The system shall generate each day, a list of patients who are expected to attend
appointments that day.
● Each staff member using the system shall be uniquely identified by his or her 8-digit
employee number.

REQUIREMENTS IMPRECISION:
● Problems arise when requirements are not precisely stated.
● Ambiguous requirements may be interpreted in different ways by developers and users.

Consider the term ‘Search’ in requirement 1:

● User intention – search for a patient name across all appointments in all clinics;
● Developer interpretation – search for a patient name in an individual clinic. User chooses
clinic then search.

REQUIREMENTS COMPLETENESS AND CONSISTENCY:

In principle, requirements should be both complete and consistent.
Complete:
They should include descriptions of all facilities required.
Consistent:
There should be no conflicts or contradictions in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and consistent requirements document.

NON-FUNCTIONAL REQUIREMENTS:
● A non-functional requirement defines the quality attribute of a software system.
● These define system properties and constraints e.g. reliability, security, response time and
storage requirements.
● Non-functional requirements may be more critical than functional requirements. If these are
not met, the system may be useless.
● Any Requirement That Specifies How The System Performs A Certain Function.

FOR EXAMPLE:
1. The processing of each request should be done within 10 seconds.
2. The site should load in 3 seconds when the number of simultaneous users are > 10000.

NON-FUNCTIONAL REQUIREMENTS IMPLEMENTATION

● Non-functional requirements may affect the overall architecture of a system rather than the
individual components.
For example, to ensure that performance requirements are met, you may have to
organize the system to minimize communications between components.
● A single non-functional requirement, such as a security requirement, may generate a number
of related functional requirements that define system services that are required. It may also
generate requirements that restrict existing requirements.

NON-FUNCTIONAL CLASSIFICATIONS

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 OF PATIENT MANAGEMENT SYSTEM:

PRODUCT REQUIREMENT:
The Mental Health Care shall be available to all clinics during normal working hours
(Mon–Fri, 08:30–17:30). Downtime within normal working hours shall not exceed five seconds in
any one day.
ORGANIZATIONAL REQUIREMENT:
Users of the MHC-PMS system shall authenticate themselves using their health authority
identity card.
EXTERNAL REQUIREMENT:
The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
DOMAIN REQUIREMENT:
● Domain requirements are the requirements which are characteristic of a particular category
or domain of projects.
● Domain requirements can be functional or nonfunctional.
● If domain requirements are not satisfied, the system may be unworkable.
● The system’s operational domain imposes requirements on the system.
For example, a train control system has to take into account the braking characteristics in
different weather conditions.
● Domain requirements be new functional requirements, constraints on existing requirements
or define specific computations.