REQUIREMENTS

ANALYSIS
INTRODUCTION

A requirement is a singular
documented need of what a
particular product or service
should be or perform.
It is a statement that identifies a
necessary attribute, capability,
characteristic, or quality of a
system in order for it to have
value and utility to a user.
 The requirements development phase may have
been preceded by a feasibility study, or a
conceptual analysis phase of the project.
The requirements phase may be broken down into:
requirements elicitation (gathering, understanding,
reviewing, and articulating the needs of the
stakeholders)
analysis (checking for consistency and completeness),
specification (documenting the requirements) and
validation (making sure the specified requirements are
correct).
 Requirements can be the following parts:
Functional Requirements:
specifies something that the delivered system must be
able to do
describe the functionality that the system is to execute;
for example, formatting some text or modulating a signal.
Non-functional requirements,
specifies something about the system itself, and how well
it performs its functions.
Sometimes called as a 'performance requirements' or
'quality of service requirements.'
Examples of such requirements include usability,
availability, reliability, supportability, testability,
maintainability, and (if defined in a way that's verifiably
measurable and unambiguous) ease-of-use.
 Requirements Analysis
Requirements analysis encompasses
those tasks that go into determining the
needs or conditions to meet for a new or
altered product.
Requirements analysis is critical to the
success of a development project.
Requirements must be actionable,
measurable, testable, related to identified
business needs or opportunities, and
defined to a level of detail sufficient for
system design.
 It helps the software engineers to identify
the exact problem behind the development
of the software and to find the exact
requirements for developing the software
or the system.
It also helps us to understand , interpret,
classify and organize the software
requirements in order to assess the
completeness, correctness, and
consistency of the software.
 Requirements analysis
issues
Stakeholder issue
Users do not understand what they want or users
don't have a clear idea of their requirements
Users will not commit to a set of written requirements
Users insist on new requirements after the cost and
schedule have been fixed
Communication with users is slow
Users often do not participate in reviews or are
incapable of doing so
Users are technically unsophisticated
Users do not understand the development process
Users do not know about present technology
* This may lead to the situation where user
requirements keep changing even when system or
product development has been started.
 Engineer/developer issues
Technical personnel and end users may have
different vocabularies. Consequently, they may
wrongly believe they are in perfect agreement
until the finished product is supplied.
Engineers and developers may try to make the
requirements fit an existing system or model,
rather than develop a system specific to the
needs of the client.
Analysis may often be carried out by engineers or
programmers, rather than personnel with the
people skills and the domain knowledge to
understand a client's needs properly.