Know about the requirement analysis process and the way of finding software requirement specification

1. Requirements
Engineering
Ajay Mani Paudel
Executive Director, NLP Hub
Founder & CEO, Quantasoft Technology

2. Introduction
“process of finding out and finalizing Software
Requirements Specification (SRS)”
© Ajay Mani Paudel

3. Software Intensive Systems
SIS = Software + Hardware + Context
Software runs on some hardware and is developed for a purpose
that is related to human activities
© Ajay Mani Paudel

4. Software Quality
Q = f (S, P)
Where,
Q is Quality; f is Function; S is Software; P is Purpose
Simply, quality is measured on fitness for purpose
So in this sense Requirement Engineering is mostly about identifying the purpose
© Ajay Mani Paudel

5. Identifying Purpose
Identifying Purpose = Defining Requirements
Extremely hard task!
– Sheer complexity of the purpose/requirements
– Often, people don’t know what they want until you show to them
– Changing requirements
– Multiple stakeholders with conflicting requirements
© Ajay Mani Paudel

6. Completeness & Pertinence
Completeness -> having all the necessary or appropriate parts
If Not: Missing requirements
Pertinence -> the quality or state of being relevance
If Not: Extra requirements
Gathering an adequate, accurate, complete, and pertinent set of requirements that identify the
purpose of a software system is an arduous task.
© Ajay Mani Paudel

7. Pertinence Quiz
Consider an information system for a gym. In the list below, mark all the
requirements that you believe are pertinent.
1. Members of the gym shall be able to access their training programs
2. The system shall be able to read member cards
3. The system shall be able to store members commute time
4. Personal trainers shall be able to add clients
5. The list of members shall be stored as a linked list
© Ajay Mani Paudel

8. Completeness Quiz
1. Members of the gym shall be able to access their training programs
2. The system shall be able to read member cards
3. The system shall be able to store members commute time
4. Personal trainers shall be able to add clients
5. The list of members shall be stored as a linked list
Is the above list complete?
© Ajay Mani Paudel

9. Completeness Quiz
Some Missing Functional Requirements might be like;
– Registration for the customers
– Fitness Program Creation
– Membership Types
© Ajay Mani Paudel

10. Irrelevant Requirement Quiz
Why can irrelevant requirements be harmful?
1. They may lead to missing functionality in the final product
2. They can introduce inconsistency
3. They can waste project resources
4. They may introduce bugs in the software system
© Ajay Mani Paudel

11. RE Definition Breakdown
Requirement Engineering (RE) is a set of activities concerned with identifying and
communicating the purpose of a software-intensive system, and the context in
which it will be used. Hence, RE acts as the bridge between the real-world needs
of users, customers, and other constituencies affected by a software system, and
the capabilities and opportunities afforded by software intensive technologies.
Designers
need to
know how
and where
the system
will be used
Not a phase
or a stage
Communication
is as important
as analysis
Quality means fitness-for-
purpose. Cannot say anything
about quality unless you
understand the purpose
Needed to
identify all the
stakeholders –
not just the
customer and
the user
…and partly
about what
is possible
Requirements
are partly
about what is
needed..
© Ajay Mani Paudel

12. What is Requirement domain?
Application Domain Machine Domain
D – Domain
Properties
R – Requirements
C – Computer
P – Program
S –
Specifica
tion
© Ajay Mani Paudel

13. Requirement Domain Quiz
Referring to the previous slide figure we discussed, indicate for each of the
following items, whether they belong to the machine domain (1), application
domain (2), or their intersection (3).
– An algorithm sorts a list of books in alphabetical order by the first author’s
name
– A notification of the arrival of a message appears on a smart watch
– An employee wants to organize a meeting with a set of colleagues
– A user clicks a link on a web page
© Ajay Mani Paudel

14. Functional & Non-Functional
Requirements
Functional Requirements
– What the system does with computation?
– Functionality of the system
– Well defined satisfaction criteria
Non-Functional Requirements
– Refer to system non-functional properties, system qualities
– Such as security, accuracy, performance, cost, usability, adaptability, interoperability,
reusability and so on
© Ajay Mani Paudel

15. User & System Requirements
User Requirements
– Written for customers
– Often in natural language, no technical details
– For the efficient communication with customer, stakeholders
System Requirements
– Written for developers
– Detailed functional & non-functional requirements
– Clearly and more rigorously specified
© Ajay Mani Paudel

16. Which of the following requirements
are non-functional requirements?
1. The Bowling Alley program keeps track of the score during a game
2. The word-count program should be able to process large files
3. The login program for a website should be secure
4. The Vending Machine program should take coins as an input from the user
© Ajay Mani Paudel

17. Requirement Iterative Process
1. Elicitation
– Collection of requirements from stakeholders and other sources
2. Analysis
– Study and deeper understanding of requirements
3. Specification
– Collective requirements are suitably represented, organized and shared
4. Validation
– To ensure completeness, consistency and no redundancy
5. Management
– Accounts for changes to requirements during the lifetime of the project
© Ajay Mani Paudel

18. Requirement Origins
(Where do they come from?)
Stakeholders (Customers, Users, etc.)
– Ones that are affected by the system and its functionality
Application Domain (Social Requirement)
– Where the system is being used? (such as banks, schools, etc.)
– Since the characteristics of the environment affects
Documentation (Additional Source)
– Research papers, White Papers, Manuals, etc.
© Ajay Mani Paudel

19. Elicitation Problems
Thin spread of domain knowledge
– Rare & distributed sources
Knowledge is tacit
– Hard even to describe knowledge that they regularly use
Limited observability
– Partial commitment, introduces noises
Bias
– Unwillingness to tell, misleading or misguiding
© Ajay Mani Paudel

20. Traditional Techniques
(for requirement elicitation)
1. Background Reading
– Collecting information by reading existing documents such as company reports,
organizational charts, policy manuals, job descriptions, documentation of existing
systems and so on
– This technique is useful when one is not familiar with the organization operation
2. Hard data and samples
– To collect and choose the sample of population
– Hard data includes facts & figures such as forms, invoices, financial information,
survey results, marketing data and so on
© Ajay Mani Paudel

21. Traditional Techniques
(for requirement elicitation)
3. Interview
– Agenda, Interview question, or sometimes just conversation with on pre-set agenda
– Positive side: Can collect a rich set of information as they allow for uncovering opinions as well as hard
facts
– Negative side:. Collecting a lot of information is hard to analyze or even irrelevant. So, it requires
special skills that are difficult to master and require experience
4. Surveys
– Can quickly collect information from a large number of people. Moreover, they can be administered
remotely for example, by email, through internet
– Survey tends to severely constrain the information that the user can provide and might miss
opportunities to collect unforeseen, relevant information
5. Meetings
– Used for summarization of findings and collection of feedback, so as to confirm or refute what has
been learned
– Have clear stated objectives and planned carefully© Ajay Mani Paudel

22. Other Techniques
(Beside the Traditional Techniques)
 Collaborative Techniques
 Created to support incremental development of complex systems with large diverse user
populations. Such as brainstorming and so on
 Social Approaches
 Exploit social sciences to better collect information from the stakeholders and the
environment.
 Such as ethnographic techniques which are based on the idea of collecting information on
the participants by observing them in the original environment
 Cognitive techniques
 Leverage cognitive science approaches to discover expert knowledge for example they can
be used for the problem solving methods
© Ajay Mani Paudel

23. Modeling Requirements
Modeling enterprises
– Goals and objectives
– Organizational structure
– Task and dependencies
– Agents, roles, intentionality
Modeling information and behaviors
– Information structure
– Behavioral view
– Scenarios and use cases
– state machine models
– Sequence diagrams
– Information flow
Modeling system qualities (NFRs)
© Ajay Mani Paudel

24. Analyzing Requirements
1. Verification
– Check whether the requirements are implemented completely
2. Validation
– Whether the collected requirement define the system that the stakeholders want
3. Risk Analysis
– Identify and analyze the main risks involved with the development of the system
being considered.
– Aims to change the requirement model to eliminate or address those risks
© Ajay Mani Paudel

25. Requirements Prioritization
Classification of Requirements
1. Mandatory Requirements
2. Nice-to-have Requirements
3. Superfluous Requirements
© Ajay Mani Paudel

26. Requirements Prioritization
Quiz
Imagine that you have collected the following set of five requirements for an ATM
system but only have resources to satisfy two, possibly three of those. Suitably
prioritize the requirements.
1. The system shall check the pin of the ATM card before allowing the customer to
perform an operation
2. The system shall perform an additional biometric verification of the customer’s
identity before it allows the customer to perform an operation
3. The system shall allow customers to withdraw cash using an ATM card
4. The system shall allow customer to receive cash/balance receipt using an ATM card
5. The system shall allow customer to change their various information of an ATM
card
© Ajay Mani Paudel

27. Requirements Engineering
Process (Modern Approach)
1. Elicitation
– Extract requirements from various sources
2. Negotiation
– Between the stakeholders and developers, discussed for an agreement
3. Modelling
– Represent the requirements using one or more notation or formal reasons
4. Analysis
– Identify possible issue with our requirements
© Ajay Mani Paudel

28. Software Requirements
Specification (SRS)
According to IEEE, the properties of SRS should be
– Simple (not compound), one requirement = one specific piece of functionality
– Testable
– Organized (related requirements should be grouped)
– Numbered (for traceability)
© Ajay Mani Paudel