Requirement analysis

REQUIREMENT ANALYSIS
After carrying out the feasibility study,
the next major step of the requirement
process is requirement analysis.
Requirement analysis is the process of
understudying the application domain of
the system to be developed, what
services the system should provide, the
required performance of the system and
the hardware limitation of the system.

Types of Requirement
2 types:
Functional Requirement
Non-Functional Requirement

Functional Requirement
Functional requirements: These are
statements of services the system
should provide, how the system
should react to particular inputs,
and how it generates output. In
other words, this type of
requirement entails specifying in
clear terms, how the system should
function.

Function Requirement Cont’d
Functional System Requirement
differs from General System
Requirement in that it addresses
specific specifications and
functionalities. It suggests certain
and peculiar facilities to be
provided for proper functioning of
the system.

Functional Requirement Cont’d
By General Requirement we mean, what is
obtainable (as requirement) of that
application/system from similar works of
life/fields/domain– DOMAIN REQUIREMENT e.g.
tailoring/assuming the design of a particular
banking application by utilizing the general
requirement of a typical banking application
system. By specific system requirement (functional
requirement) however, we refer to what is
obtainable as requirement from that organisation,
institution or environment for that system to
function in such an organisation, institution or
environment, and not generally what is obtainable
from the domain.

Take for instance, the AVERS System was
designed such that:
 In the Security Interface Column
(Username/Password), it is expected that
the user specify TYPE (i.e. Staff OR
Student). This may not be obtainable from
other similar software in other higher
institution of learning. The design may be
a way of ensuring flexible filtering of
student and staff access and data.

Consider the uploading section/column in
which the SEMESTER Column/Drop Down
Box only have 1st Semester OR 2nd Semester
for the lecturer uploading to select from and
NOT both. This again you may not find as
design requirement and constraint in other
university’s result platform. This is
INSTITUTIONAL; it may perhaps have been
so designed to control laziness of lecturers in
uploading at the right semester (uploading to
time before the semester runs out, else no
opportunity again for that session)

Non-Functional Requirement
This defines the constraints to the
operation of the system. They are
regarded as constraint in the
sense that, they have indirect
influence on the full
implementation of the requirement
and design of the proposed
system.

Non-Functional Requirement Cont’d
To put this in simpler term, we mean that
aside Functional Requirement which is
where you specify how the system will
function and probably the little limitations it
has, Non-Functional Requirements imply
looking into other areas of the requirement
which ordinarily are not part of the stated
functional requirement but which if not
considered can hinder the effective
operation or survival or acceptance of the
system.

Simply put, their non-inclusion may be a
threat to the full acceptance and survival of
the system.
Take for instance, in designing a standalone
or intranet-web-based app for NACOSS,
restriction of access or security will not be
part of the main functional requirement so
as to promote the image and integrity of
NACOSSAAUA. However, the absence of
security checks as part of the requirement
for the design of the app, may end up been
a threat to the eventual survival of the app.

Hope you are following? –
FUNCTIONAL REQUIREMENT: A must set
of requirements,
NON-FUNCTIONAL REQUIREMENT: not
compulsory but necessary set of
requirements.
If we don’t attach/append security to the
design of NACOSSAAUA app, the objective
will still be achieve (Functional), but not
including some specifications (Non-
Functional) can also give way to hackers OR
data infiltration.

We have three (3) divisions :
i. Product Requirement
ii.Organizational Requirement
iii.External Requirement

Product requirements:
These requirements specify the constrain to the
behavior or normal functioning of the software. In
this, we have
*Performance requirements: Which specify how
fast the system must execute and how much
memory it requires.
*Reliability requirements: This sets out the
acceptable failure rate of the system/software.
*Security requirements: As the name suggests, this
spelt out the security details of the system/software.
*Usability requirements: This stipulates procedures
for the system usage. This includes documentation,
data repository, manual, Help Facilities etc.

Organizational requirements:
These requirements are broad
system requirements derived from
policies and procedures in the
customer’s and developer’s
organization. This implies the design
and deployment of a software are tied
to the available policies that govern
the institution that used to them.

For instance, if a company’s policy or
tradition is such that they prefer DOS-
based application that Windows-
based, then any graphical application
developed may not be accepted. For
some, it may be the choice of
Operating System to deployed on; in
which the builder/developer has to
verify and ensure the system under
construction meets the requirement of
running on such platform.

We have:
*Operational process requirements: This
simply defines how the system will be
used. That is, the operation of the system
in line with the organizational policy. For
instance, you may have designed the
system such that all junior officers are
GRANTED ROLES, whereas the policy of
the organization does not allow junior staff
to have access to any modules in the
system except for manual data collation.

*Development process requirements: In
this, the programming language, the
development environment or process
standards to be used are specified.
Again, there has to be harmonization
between the intended language (e.g.
Java) or development environment
(e.g. Eclipse) or process standard (e.g.
Functional Modules) that the developer
wants to use and that the organization
is accustomed to OR preferred.

This non-functional (non-essential you
may call it), then becomes essential and
necessary to be sorted out before
concluding on the requirement issues.
*Environmental requirements. This
stipulates the operating environment of
the system/software to be developed.

External requirements
As the name sounds, this has to do with
external policies that automatically and
indirectly affect the requirement designs of a
system/software.
We have:
*Regulatory requirements: This stipulates
what must be done for the system to be
approved for use; usually by a regulator. E.g.
Central bank – all banking applications are
subject to particular design specification –
common modules and interfaces.

*Legislative requirements: This
guides the operating jurisdiction of
the system. They must be followed
to ensure that the system operates
within the law.
*Ethical requirements: This ensures
that the system is designed such
that it will be acceptable both to its
users and the general public.

ANALYZING REQUIREMENT
In analyzing a requirement, the
following activities are undertaken:
Domain understudy
Requirement collection
Classification
Conflict resolution
Prioritization
Requirements validation

REQUIREMENT ANALYSIS CONT’D
Domain understudy: This involves having
the understudy of the system to be developed.
So the understudy of the system will not be
limited only to the case study, but rather, the
developer/analyst will gather knowledge about
of minor and mega forms of the system, local
and international attributes/features of the
system. e.g. design of a supermarket software
– it will involve not only studying local
supermarket structure, but the international
ones as well.

Requirement collection: This involves
having interaction with the system’s
stakeholders to know/gather/collect/discover
their requirements.
Classification: Certainly, stakeholders/users
requirements about the system
development/design will vary. It is the job of
the developer/analyst to now arrange these
requirements into their various categories.

 Conflict Resolution: Because there are many stakeholders in a
system, it is certain that, there will be some level of agreement
and disagreement in requirement for system development/design.
Hence, it is the duty of the developer/analyst to harmonize/resolve
this conflict in requirement.
 Prioritization: After conflicts in requirement have been resolved,
a clearer picture of the requirement classification is now seen.
From here, a scale of preference can now be drawn based on the
level of importance of the requirements. It will still involve
interaction with stakeholders.
 Requirement Validation: In turn, the classified and prioritized
requirements are checked to know/discover if they are complete,
consistent and in accordance with the stakeholders’
request/requirement.

Requirement analysis

More Related Content

What's hot (20)

Similar to Requirement analysis (20)

More from Bro Shola Ajayi (14)

Recently uploaded (20)

Requirement analysis