Requirements Analysis

& Specification

1
 Software Requirement?
 The services that the customer requires from a
system and the constraints under which it operates
 Customer Needs or Demands with respect to SuD

 The description of
 what the system should do
 the service or services that it provides and
 the constraints on its operation.

2
 Types of Requirements
 Functional requirements
 Non- functional requirements

3
 Functional Requirements
 Functionality or services that the system is expected
to provide.
 describes what the product should do
 Functional requirements may also explicitly state what
the system shouldn‘t do
 Functional requirements specification should be:
 Complete:
 All services required by

 the user should be defined

 Consistent:
 Should not have contradictory definition (also avoid
ambiguity, don‘t leaver for different interpretations)

4
 Example
 User story: As an existing user, I want to be
able to log into my account.

 Functional requirements:
 The system must allow users to log into their account
by entering their email and password.
 The system must allow users to log in with their Google
accounts.
 The system must allow users to reset their password by
clicking on "I forgot my password" and receiving a link
to their verified email address.

5
 Non functional Requirements
 Also known as "quality requirements“
 constraints on how the product should do it
 Constraints on the implementation of the
functional requirements in terms of performance,
security, reliability, scalability, portability etc..
 Example
 Functional requirement: "The system must allow
the user to submit feedback through a contact form in
the app."
 Non-functional requirement: "When the submit
button is pressed, the confirmation screen must load
within 2 seconds."

6
 Requirement Analysis and
Specification
 Definition:
 The process of defining user expectations to build a new
software product or to modify an existing one is known as
requirement analysis.
 Sometimes known as
 requirement engineering

 requirements gathering

 requirements capture in software engineering.

7
 Requirements Engineering Process
 Requirements engineering (RE) refers to the process
of defining, documenting, and maintaining
requirements in the engineering design process.

 Requirement engineering provides the appropriate

mechanism to
 understand what the customer desires
 analyzing the need
 assessing feasibility
 negotiating a reasonable solution
 specifying the solution clearly
 validating the specifications and
 managing the requirements as they are transformed into a
working system
8
RE Process
1. Feasibility Study
2. Requirement
Elicitation and
Analysis
3. Software Requirement
Specification
4. Software Requirement
Validation
5. Software Requirement
Management

9
 1. Feasibility Study
 Assess the practicality, viability and potential success
of the proposed software solution
 Types
 Technical Feasibility
 necessary technological resources for success

 Operational Feasibility
 anticipates the impact of a new project on daily
business operations
 Economic Feasibility
 An estimate of the cost of the overall project & ROI

 Legal Feasibility
 ensures that proposed endeavors align with existing
laws, encompassing data protection, social media
regulations etc..
 Schedule Feasibility
 assess how much time the project will take to complete.10
 2. Requirement Elicitation
and Analysis
 Also known as the gathering of requirements
 Obtaining information from stakeholders
 Requirements are identified with the help of customers and
existing systems processes, if available.
 Activities
 Prepare for Elicitation:
 The purpose here is to understand the elicitation activity
scope, select the right techniques, and plan for
appropriate resources.
 Conduct Elicitation:
 The purpose here is to explore and identify information
related to change.
 Confirm Elicitation Results:
 In this step, the information gathered in the elicitation
session is checked for accuracy.
11
 Problems of Requirements
Gathering and Analysis
 Getting all, and only, the right people involved.
 Stakeholders often don't know what they want
 Stakeholders express requirements in their terms.
 Stakeholders may have conflicting requirements.
 Requirement change during the analysis process.
 Organizational and political factors may influence
system requirements.

12
 3. Software Requirement
Specification
 A document which is created by a software analyst
after the requirements collected from the various
sources
 the requirement received by the customer written in
ordinary language.
 It is the job of the analyst to write the requirement in
technical language so that they can be understood
and beneficial by the development team.
 The models used
 ER diagrams - detailed logical representation of the data for
the organization
 DFDs - shows the flow of data through a system
 Data dictionaries - repositories to store information about all
data items defined in DFDs.
13
 4. Software Requirement
Validation
 The process of checking that requirements defined for
development, define the system that the customer
wants.
 Need?
 The user might demand illegal, impossible solution or
experts may misinterpret the needs.
 Check against the following conditions –
 If they can practically implement
 If they are correct and as per the functionality and specially
of software
 If there are any ambiguities
 If they are full
 If they can describe

14
 Requirements Validation
Techniques
 Requirements reviews/inspections:
 systematic manual analysis of the requirements.
 Prototyping:
 Using an executable model of the system to check
requirements.
 Test-case generation:
 Developing tests for requirements
 Automated consistency analysis:
 approach is used for the automatic detection of an error,
such as non-determinism, missing cases, a type error
 Using CASE tool
 Simulation
 Simulating system behavior in order to verify
requirements
15
 5. Software Requirement
Management
 The process of managing changing requirements
during the requirements engineering process and
system development.
 New requirements emerge during the process as
business needs a change, and a better
understanding of the system is developed.

16
Requirements Gathering /
Elicitation Techniques

17
 1. Stakeholder Analysis
 Stakeholders can include team members,
customers, any individual who is impacted by the
project or it can be a supplier.
 Stakeholder analysis is done to identify the
stakeholders who will be impacted by the system.

18
 2. Brainstorming
 This technique is used to generate new ideas and find
a solution for a specific issue.
 The members can be domain experts, SMEs, etc..
 Multiple ideas and information give you a repository
of knowledge and you can choose from different
ideas.
 Rules
 The time limit for the session should be predefined.
 Identify the participants in advance. One should include 6-8
members for the session.
 The agenda should be clear enough for all the participants.
 Once you get all the information, combine the ideas, and
remove the duplicate ideas.
 Once the final list is ready, distribute it among other
19
 Advantages and disadvantages
of BS
 Benefits:
 Creative thinking is the result of the brainstorming
session.
 Plenty of ideas in a short time.
 Promotes equal participation.
 Drawbacks:
 Participants can be involved in debating ideas.
 There can be multiple duplicate ideas.

20
 3. Interview
 Face to face communication
 useful for building strong relationships between
business analysts and stakeholders.
 Benefits:
 Interactive discussion with stakeholders.
 The immediate follow-up to ensure the interviewer’s
understanding.
 Encourage participation and build relationships by
establishing rapport with the stakeholder.
 Drawbacks:
 Time is required to plan and conduct interviews.
 Commitment is required from all the participants.

21
 4. Document Analysis/Review
 Gather business information by reviewing/examining
the available materials that describe the business
environment.
 Document analysis includes
 reviewing the business plans
 technical documents
 problem reports
 existing requirement documents, etc.
 This is useful for
 updating an existing system
 migration projects.

22
 Cons & Pros of Doc analysis
 Benefits:
 Existing documents can be used to compare current
and future processes.
 Existing documents can be used as a base for future
analysis.
 Drawbacks:
 Existing documents might not be updated.
 Existing documents might be completely outdated.
 Resources worked on the existing documents might not
be available to provide information.
 This process is time-consuming.

23
 5. Focus Group
 Relevant stakeholders provide feedback to refine
processes, ideas, or solutions
 The feedback and comments are recorded for use in
later phases of requirements elicitation
 A moderator manages this session
 Benefits:
 can get information in a single session rather than
conducting one to one interview.
 Active discussion with the participants creates a healthy
environment.
 One can learn from other’s experiences.
 Drawbacks:
 It might be difficult to gather the group on the same date
and time.
 Skilled Moderator is required 24
 6. Interface Analysis
 Analysis is the idea of deconstructing how external
and internal systems interact with each other and
with end-users
 Enables business analysts to identify potential
requirements, uncover limitations, and determine
interoperability issues between hardware and
systems
 Benefits:
 Identifies missed requirements.
 Determine regulations or interface standards.
 Uncover areas where it could be a risk for the project.
 Drawbacks:
 The analysis is difficult if internal components are not
available.
 It cannot be used as a standalone elicitation activity. 25
 7. Onsite Observation
 Also referred as job shadowing
 Observe the activity, task, tools used and events
performed by others
 Need to inform that participants performance is not
judged.
 During the session, the observer should record all the
activities and the time taken to perform the work by
others

26
 Advantages & Disadvantages of
Observation
 Benefits:
 The observer will get a practical insight into the work.
 Improvement areas can be easily identified.

 Drawbacks:
 Participants might get disturbed.
 Participants might change their way of working during
observation and the observer might not get a clear
picture.
 Knowledge-based activities cannot be observed.

27
 8. Prototyping
 prototyping enables business owners and end-users
to visualize realistic models of applications before
they are finally developed
 Frequent demos are given to the client
 Prototypes can be used to create a model of SuD and
describe the process using diagrams.
 Benefits:
 Gives a visual representation of the product.
 Stakeholders can provide feedback early.
 Drawbacks:
 If the system is highly complex  Prototyping time
consuming.
 Stakeholders may focus on the design rather than the
requirements
28
 9. Joint Application Development
(JAD)/ Requirement Workshops
 This technique is more process-oriented and formal as
compared to other techniques
 structured meetings involving end-users, PMs and
subject matter expert
 Types
 Formal Workshops:
 highly structured and are usually conducted with the
selected group of stakeholders.
 The main focus of this workshop is to define, create,
refine business requirements.
 Business Process Improvement Workshops:
 These are less formal

 existing business processes are analyzed and process

improvements are identified.
29
 Pros & Cons of JAD/Workshop
 Benefits:
 Documentation is completed within hours and is
provided quickly back to participants for review.
 can get on the spot confirmation on requirements.
 Successfully gathered requirements from a large group
in a short period.
 Consensus can be achieved as issues and questions are
asked in the presence of all the stakeholders.
 Drawbacks:
 Stakeholder’s availability might ruin the session.
 The success rate depends on the expertise of the
facilitator.
 A workshop motive can’t be achieved if too many
participants.

30
 10. Survey/Questionnaire
 A set of questions is given to stakeholders to
quantify their thoughts.
 After collecting the responses from stakeholders,
data is analyzed to identify the area of interest of
stakeholders.
 Rules
 Questions should be based on high priority risks.
 Questions should be direct and unambiguous.
 Once the survey is ready, notify the participants and
remind them to participate.

31
 Types of questions
 Open-Ended
 Respondent is given the freedom to provide answers in
their own words rather than selecting from predefined
responses.
 This is useful but at the same time, this is time-
consuming as interpreting the responses is difficult.
 Close Ended
 It includes a predefined set of answers for all the
questions and the respondent has to choose from those
answers.
 Questions can be multiple choice or can be ranked from
not important to very important.

32
 Pros & Cons of Questionnaire
 Benefits:
 Easy to get data from a large audience.
 Less time is required for the participants to respond.
 can get more accurate information as compared to
interviews.
 Drawback:
 All the Stakeholders might not participate in the
surveys.
 Questions may not be clear to all the participants.
 Open-ended questions require more analysis and time

33
 Formal system specification
 Need ?
 Ambiguity – to avoid
 Natural language descriptions of software can be
ambiguous, leading to misunderstandings.
 Completeness – To capture all requirements
 Informal descriptions may not capture all requirements
or behaviors.
 Verification – to verify properties
 Formal specifications can be used to verify properties
of the software, such as correctness and consistency.

34
Types of Formal Specifications
 Model-based
 Use of mathematical models (e.g., state machines,
Petri nets) to describe the system's behavior.
 Logic-based
 Use of logical expressions (e.g., predicate logic,
temporal logic) to specify properties and constraints.

35
Process of Formal Specification
 Requirements Elicitation
 Gather and analyze requirements from stakeholders.
 Specification Development
 Develop formal specifications using appropriate languages
and techniques.
 Specification Review
 Review the formal specifications for correctness,
completeness, and consistency.
 Verification
 Use formal methods to verify that the specifications meet
the requirements.
 Maintenance
 Update the specifications as the software system evolves.

36
 Application of Formal
Specifications
 Critical Systems
 Used in the development of safety-critical and mission-
critical systems where correctness is paramount.
 Concurrent and distributed systems
 Useful for specifying and verifying concurrent and
distributed systems.
 Security systems
 Helps in specifying and analyzing security properties of
software systems.

37
 Pros and Cons of FS
 Benefits
 Clarity: Provides a precise and clear description of the
requirements and behavior.
 Consistency: Helps identify inconsistencies and ambiguities
early in the development process.
 Verification: Facilitates formal verification techniques to
ensure that the software meets its requirements.
 Documentation: Serves as comprehensive documentation
for the software system.
 Challenges
 Complexity: Formal specifications can be complex and
require expertise to develop and understand.
 Tool Support: Limited tool support for creating, analyzing,
and maintaining formal specifications.
 Cost: Developing formal specifications can be time-
consuming and expensive compared to informal methods. 38