Ch.3.Requirements Analysis.

-By Pooja Bahirat.

 Introduction….
• Understanding the user requirements is base for development of
any software.
• This chapter focuses on understanding:
1. Different types of requirements.
2. Main requirements engineering activities.
3. Requirements managements.
• All Software development models begins the development
process by gathering the requirements.

IEEE defines a requirement as :

“ A condition or capability needed by a user to solve a problem or
achieve an objective”.
• Requirements engineering refers to various tools and techniques
used for identifying the requirements.
 • Requirements engineering consists of activities like
inception, elaboration, negotiation, specification,
validation and management.
• These activities can be conducted parallelly as per the need
of the project.
• Software Requirements can be of two types:
1. Functional requirements : It specifies how the system
should process particular input in order to provide certain
service. It specifies the behavior and features of the
system.
2. Non-functional requirements: It specifies the constraints
imposed on a system Constraints can be regarding quality,
security, performance of the system.
 Requirements Elicitation.
• Requirements elicitation is nothing but gathering the
requirements of the proposed system.
• Stakeholders together gives problem specification and
features expected from the proposed solution . Which can
be faced during activities are:
1. Problem of scope : When boundary of the system is not
clearly defined it results into problem of scope.
2. Problem of understanding : These problems are faced
when customer cannot clearly specify what they need
from the system.
3. Problems of volatility: These problems occurs when
requirements are unpredictable or change over period
of time.
 • Requirements elicitation can be accomplished through
interviewing and observation.
1. Requirements discovery and understanding : The basic
requirements from the stakeholders are collected through direct
communication.
2. Requirement classification and organization : The
requirements collected from the stakeholder may be
unstructured in nature. This activity tries to organize and
arrange requirements into clear and related groups.
3. Requirements prioritization and negotiation : Every
stakeholder think of the system from his/her own perspective
and a result the requirements gathered may conflict each other.
It becomes therefore essential to arrange these requirements
as per the priority.
4. Requirements documentation : Requirements are collected are
documented in order to use them for the next cycle.
 Collaborative prioritization Gathering Approaches.
• 1. Collaborative requirements gathering : Gathering the
requirements by conducting the meetings between developer and
customer.
• Fix the rules for preparation and participation.
• The main motive is to identify the problem, give the solutions for
the elements, negotiate the different approaches.
• 2. Quality Function Deployment (QFD) : In this technique, translate
the customer need into the technical requirement for the
software.
• QFD system designs a software according to the demands of the
customer.
QFD consist of three types of requirement:
i) Normal requirements :The objective and goal are stated for the system through
the meetings with the customer.
• For the customer satisfaction these requirements should be there.
ii) Expected requirement : These requirements are implicit.
• These are the basic requirement that not be clearly told by the customer, but
also the customer expect that requirement.
iii) Exciting requirements : These features are beyond the expectation of the
customer.
• The developer adds some additional features or unexpected feature into the
software to make the customer more satisfied.
For example, The mobile phone with standard features, but the developer
adds few additional functionalities like voice searching, multi-touch screen
etc. then the customer more exited about that feature.
• 3. Usage scenarios : These are also referred as use cases. It provides
specification about the users interact with the system.
• They describe steps , events or action that occurs during the interaction.
 Software Requirement specification (SRS)
• A software requirements specification (SRS) is a document that
describes what the software will do and how it will be expected
to perform.
1. Correctness:
User review is used to ensure the correctness of requirements
stated in the SRS. SRS is said to be correct if it covers all the
requirements that are actually expected from the system.
2. Complete:
It indicates every sense of completion including the numbering
of all the pages, resolving the to be determined parts to as
much extent as possible as well as covering all the functional
and non-functional requirements properly.
3. Clear/ Unambiguous : Every requirement specified in SRS
should be clear to understand . It should not lead to any
ambiguity.
4. Verifiable: There should be some cost-effective process to check
whether the final product meets every requirement specified in
the SRS.
5. Consistency: There should not be requirements which are
conflicting with each other in the SRS.
6. Stability : It refers to the chances of the requirements to be
changed in future.
Advantages of SRS:
• An SRS establishes the basis for agreement between the customer
and the supplier on what the software product will perform.
• An SRS provides a specification for validation of the final
product/software.
• A high-quality SRS results in high-quality product/software.
• A high-quality SRS reduces the development cost.
 Developing the Use Cases (UML)
Step 1: Identify who is going to be using the system directly. These
are the Actors.
• The main component of use case development is actors. An actor
is a specific role played by a system user and represents a category
of users that demonstrates similar behaviors when using the
system. A primary actor is one having a goal requiring the
assistance of the system.
• A secondary actor is one from which the system needs assistance
to satisfy its goal. One of the actors is designated as the system
under discussion. A person can play several roles and thereby
represent several actors, such as computer-system operator or
end user.
 • Example of use cases as follow:
Consider a Online Career guidance portal. We define 4 actors: the
administrator, the student, the counselor and the subject experts,
the main actor is a student , who interact with the system in a
number of different ways as given below:
i. To create an identity within the system (for authentication).
ii. To request for a paper for a subject.
iii. To view his/her result.
iv. To post a query to a counselor.
Consider this use cases where a student creates a identity and
perform task for authentication.
• Thus, the entire use case description can be shown using a
template with the following structure:
i. Name of use case
ii. Primary actor
iii. Secondary actors
iv. Goal in context.
 v. Preconditions
vi. Post conditions.
vii. Main flow of events.
viii. Exceptional flow of events.
We give a template description of the above use case of creating
an identify for a student actors as follows:
Use case : Sign up.
Primary actor : Student.
Secondary actor : Administrator.
Goal in context : to create a login id and password for a student.
Preconditions : Availability of the system homepage.
Post condition : A valid login id and pass is generated and mailed
to the student user.
 Building the analysis model
• The main aim of the analysis model is to provide explanation of
the required informational, functional and behavioral aspects
for software.
• Hence we say that the analysis model is snapshot of user
requirements at any point of time.
• The analysis model keeps changing as when the stakeholder
requirements get updated.
5.1 Elements of the Analysis Model :
• There are many different ways to capture and represent the
requirements for a software system.
• There are some elements which are given below:
1. Scenario-based Element.
2. Class-based Element.
3. Behavioral Element.
1. Scenario-based Element :
• Here the software is described from the user point of view using
scenario-based approach. For ex ,consider a use case to hire an
employee.
• For ex, an employee can be hired through walk-in interviews,
through campus selections, through referrals etc. so each of these
methods are nothing but different scenarios for hiring an employee
2. Class-based Element :
• A collection of things that have similar characteristics and
common behaviors i.e., objects are categorized into classes.
• For example, in fig 3.4 shows a student class with its attributes
and operations.
• Some analysis model also shows the manner in which the classes
collaborate with each other to implement the use case.
3. Behavioral Elements :
• The behavior of a software is nothing but the services it provide to the external
world. This shows the way the system is designed and implemented .
• A state machine diagram is one method for representing the behavior of a
system by illustrating its state and the events that cause the system to change
state.
• For example, consider an ATM machine. figure shows the difference states it
goes through, during the execution of Money withdrawal Use case.
 Analysis Pattern
• Analysis patterns define or suggest solutions within the
application domain that can be reused across multiple
applications.
• A best example of this concept is the use case for User
Authentication.
• There are two main benefits, as suggested by Geyer-Schulz and
Hahsler, with respect to the use of analysis patterns as given
below:
i. Analysis patterns speed up the development of abstract analysis
models that capture the main requirements by providing
reusable analysis models.
ii. It also help to change the analysis models into a design model
by suggesting design pattern and reliable solutions for common
problems.
 Agile Requirements Engineering.
• Agile requirements engineering focus on some important
issues that are common in software project .i.e. high
requirements volatility, incomplete knowledge of
development technology and customer are not able to clear
their ideas until they see working prototype.
• The main aim of agile requirement engineering is to provide a
smooth pathway for the transfer of ideas from stakeholders
to the software team.
• The agile process helps to prioritize the features of a product,
analyze them, design and implement them. This in turn
provides a pathway to an early creation and testing of working
prototypes of a product.
 Negotiating Requirements
• The quality of software developed is directly related with the
requirements specified. The stakeholders can have different
expectations and perceptions towards the system.
• Conflicts are unavoidable during requirements elicitation
process because of different roles, responsibilities of
stakeholders. Because of this conflicts negotiating requirement is
essential.
• Boehm defines set of negotiating activities to be performed at
the beginning of the software engineering process as follow:
i. Identification of system or subsystem’s key stakeholders.
ii. Determining “win conditions ” for each stakeholder.
iii. Negotiation of the stakeholder’s “win conditions ” in order to
overcome the conflicts.
• Fricker, suggest bidirectional communication process known as
‘handshaking’, development team communicates to customer a
proposed solution to requirements together with impact and
intention.
 Validating Requirements
• It is a process which checks whether the requirement gathered
defines the system expected by the user.
i. Validity checks : As user requirements may change with the
changing environment it is required to check whether
requirement model shows the real needs of the client.
ii. Consistency checks : It is required to check that requirements
are not conflicting or contradicting each other.
iii. Completeness checks : Ensures all constraints and functions
are bounded and specified clearly in SRS.
iv. Realism checks : It checks whether the requirements specified
shows an essential features of the system and whether it is
cost effective to implement these features.
v. Verifiability : These checks are performed to find whether
implemented requirements are testable in order ensure the
delivered system meets the specification.
 • Validation techniques which can be used individually or in
combination are:
i. Requirements review : Review team conduct systematic review
of the requirement in order to find bugs and inconsistencies.
ii. Prototyping : The Working system is developed and given to
end-user. Feedback from the end-user can help in updating the
requirements.
iii. Test-case generation : Every requirement specified should be
testable, so tests are developed for every requirement specified
by the user leading to test-driven development.

***************************END*************************