The document discusses requirements analysis and specification. It describes how requirements gathering involves determining user needs through various techniques like interviews, surveys, prototyping and observation. The requirements analysis phase aims to fully understand requirements, remove inconsistencies and document them clearly. The specification phase defines the requirements in a Software Requirements Specification document, which serves as a contract between developers and customers. The SRS should describe functionality without specifying solutions and have properties like consistency, traceability and verifiability.

1. CHAPTER -2
REQUIREMENTS ANALYSIS AND
SPECIFICATION

2. 2
Requirements Analysis and Specification
• Many projects fail: because
- developers start implementing the system
without determining what they are building
and what the customer really wants.
- Lack of user involvement
- Lack of resources
- Unrealistic expectations
- Lack of planning

3. 3
Requirements Analysis and Specification
• Goals of requirements analysis and specification phase:
– fully understand the user requirements
– Define the requirements in a manner that is clear to the
client. This may be a written specification, prototype system,
or other form of communication.
– Define the requirements in a manner that is clear to the
people who will design, implement, and maintain the
system.
– remove inconsistencies, anomalies, incompleteness from
requirements
– document requirements properly in an SRS document

4. 4
Requirements Analysis and Specification
• Consists of two distinct activities:
•Requirements Gathering and
Analysis
•Requirements Specification

5. Requirements Gathering
• It is also known as requirements elicitation.
• Requirements Gathering is very difficult task
especially
- as requirements are never available in form
of single document
- neither requirements are completely
obtainable from single customer.
- when there is no working model of the
problem.

6. 6
ROLE OF A SYSTEM ANALYST
• The person who undertakes requirements
analysis and specification:
– known as systems analyst:
– collects data pertaining to the product
– analyzes collected data:
• to understand what exactly needs to be done.
– writes the Software Requirements Specification
(SRS) document.

7. 7
Requirements Gathering (CONT.)
• Some desirable attributes of a
good system analyst:
–Good interaction skills,
–imagination and creativity,
–experience.

8. Requirements Gathering (CONT.)
• There are various ways to discover requirements
• Interviews
- Interviews are strong medium to collect requirements. Several types of
interviews such as:
- Structured (closed) interviews, Non-structured (open) interviews, Oral
interviews, Written interviews, One-to-one interviews, Group interviews
• Surveys
- Organization may conduct surveys among various customer by querying
about their expectation and requirements from the upcoming system.
• Questionnaires
- A document with pre-defined set of objective questions and respective
options is handed over to all customers to answer, which are collected and
compiled.

9. Requirements Gathering (CONT.)
• Domain Analysis
- The expert people in the domain can be a great help to analyze general
and specific requirements.
• Brainstorming
- An informal debate is held among various stakeholders and all their
inputs are recorded for further requirements analysis.
• Prototyping
- The prototype is shown to the client and the feedback is noted. The
client feedback serves as an input for requirement gathering.
• Observation
-Team of experts visit the client’s organization or workplace. They observe
the actual working of the existing installed systems.

10. 10
Requirements Analysis
• Requirements analysis involves:
–obtaining a clear, in-depth
understanding of the product to be
developed,
–to analyze the collected information
–remove all ambiguities, incompleteness
and inconsistencies by further
discussions with the end-users and the
customers.

11. 11
Requirements Analysis (CONT.)
• Several things about the project should be
clearly understood by the analyst:
– What is the problem?
– Why is it important to solve the problem?
– What are the possible solutions to the problem?
– What complexities might arise while solving the
problem?
– What exactly are the data inputs to the system and
what exactly are the data outputs by the system?

12. Requirements Analysis (CONT.)
• Three main types of problems in requirements
that analyst need to identify are:
- Ambiguity
- Inconsistency
- incompleteness

13. Ambiguity
• A requirements is anomalous when several
interpretations of that requirement is possible.
• Example: in office automation, the office clerk
mentioned that during the final grade
computation, if any student scores sufficiently
low grade in semester, then his parents should be
informed. But clerk can provide well defined
criteria what can be “sufficiently low grade”.

14. 14
Inconsistent requirement
• Some part of the requirement:
– contradicts with some other part.
• Example:
– One customer says turn off heater and open
water shower when temperature > 100 C
– Another customer says turn off heater and
turn ON cooler when temperature > 100 C

15. 15
Incomplete requirement
• Some requirements have been
overlooked.
• Example:
– In chemical plant automation software,
• One requirement is, if internal temperature exceeds
200 C, then alarm bell must be sounded.
• There is no provision for resetting the alarm bell in
any of the requirements.

16. 16
Software Requirements Specification
• Main aim of requirements
specification:
–systematically organize the
requirements arrived during
requirements analysis
–document requirements properly.

17. 17
Software Requirements Specification
• The SRS document is useful in various
contexts:
–statement of user needs
–contract document
–reference document
–definition for implementation

18. 18
Software Requirements Specification: A Contract Document
• Requirements document is a reference
document.
• SRS document is a contract between the
development team and the customer.
– Once the SRS document is approved by the
customer,
• any subsequent controversies are settled by referring
the SRS document.

19. 19
Software Requirements Specification: A Contract
Document
• Once customer agrees to the SRS document:
– development team starts to develop the product
according to the requirements recorded in the SRS
document.
• The final product will be acceptable to the
customer:
– as long as it satisfies all the requirements recorded
in the SRS document.

20. 20
SRS Document (CONT.)
• The SRS document is known as black-box
specification:
– the system is considered as a black box whose
internal details are not known.
– only its external (i.e. input/output) behaviour is
documented.
S
Input Data Output Data

21. 21
SRS Document (CONT.)
• SRS document concentrates on:
– what needs to be done
– carefully avoids the solution (“how to do”) aspects.
• The requirements at this stage:
–written using end-user terminology.

22. Categories of Users of SRS Document
(CONT.)
• Different categories of users of SRS documents are:
• Users, customers and marketing personnel
- To ensure that the system as described will meet
their needs.
• Software developers
- They are developing exactly what is required by the
customer.
• Test engineers
- The requirements are understandable from the
functionality point of view.

23. Categories of Users of SRS Document
(CONT.)
• User documentation writers
- They are able to write user manuals.
• Project managers
- They can estimate the cost of the project
easily.
• Maintenance engineers
- To determine what modifications to the
systems functionalities would be needed for a
specific purpose.

24. 24
Properties of a goodSRS document
• It should be concise
– and at the same time should not be ambiguous.
• It should specify what the system must do
– and not say how to do it.
• Easy to change.,
– i.e. it should be well-structured.
• It should be consistent.
• It should be complete.

25. 25
Properties of a goodSRS document
(cont...)
• It should be traceable
– To verify the result of the phase with previous
phase
– To analyze the impact of change.
• It should be verifiable
– To determine whether or not requirements have been met
in an implementation
– e.g. “system should be user friendly” is not verifiable

26. 26
Examples of Bad SRS Documents
• Unstructured Specifications:
– Narrative essay --- one of the worst types of
specification document:
• Difficult to change,
• difficult to be precise,
• difficult to be unambiguous,
• scope for contradictions, etc.
• Forward References:
– References to aspects of problem
• defined only later on in the text.

27. 27
Examples of Bad SRS Documents
• Overspecification:
– Addressing “how to” aspects
– For example, “Library member names should be
stored in a sorted descending order”
– Overspecification restricts the solution space for
the designer.
• Contradictions:
– Contradictions might arise
• if the same thing described at several places in different
ways.

28. Problems without a SRS document
The important problems are:
• Without developing the SRS document, the system would not be
implemented according to customer needs.
• Software developers would not know whether what they are
developing is what exactly required by the customer.
• Without SRS document, it will be very much difficult for the
maintenance engineers to understand the functionality of the
system.
• It will be very much difficult for user document writers to write the
users’ manuals properly without understanding the SRS document.

29. 29
SRS Document (CONT.)
• SRS document, normally contains
three important parts:
–functional requirements,
–Non functional requirements,
–Goal of implementation.

30. 30
SRS Document (CONT.)
• It is desirable to consider every system:
– performing a set of functions {fi}.
– Each function fi considered as:
– transforming a set of input data to
corresponding output data.
Input Data Output Data
fi

31. 31
Example: Functional Requirement
• F1: Search Book
– Input:
• an author’s name:
– Output:
• details of the author’s books and the locations of
these books in the library.
Author Name Book Details
f1

32. 32
Functional Requirements
• Functional requirements describe:
–A set of high-level functions
–A high-level function is one using
which the user can get some useful
piece of work done.
–Each high-level requirement:
• takes in some data from the user
• outputs some data to the user

33. 33
Functional Requirements
• For each high-level requirement:
–every function is described in terms of
• input data set
• output data set
• processing required to obtain the output
data set from the input data set

34. 34
Non-functional Requirements
• Characteristics of the system which
can not be expressed as functions:
•maintainability,
•portability,
•usability, etc.

35. 35
Non-functional Requirements
• Non functional requirements include:
– reliability issues,
– performance issues,
– human-computer interface issues,
– Interface with other external systems,

36. Non-functional Requirements
• Example of Non-Functional requirements:
- The user interface of the software should be
useable by the factory shop floor workers who
may not have even high school degree.

37. Non-functional Requirements
• IEEE 870 standard lists four types of non-
functional requirements:
- External interface requirements
example: hardware, software, report
format, user interface
- Performance requirements
example: number of transactions completed
per unit time.
- Constraints
- Software system attributes

38. 38
Constraints
• Constraints describe things that the system
should or should not do.
– For example,
• standards compliance
• how fast the system can produce results
–so that it does not overload another
system to which it supplies data, etc.

39. 39
Examples of constraints
• Hardware to be used,
• Operating system
– or DBMS to be used
• Capabilities of I/O devices
• Standards compliance
• Data representations
– by the interfaced system

40. Goal of implementation
• It offers general suggestions regarding
development.
- Example: the developers may use these
suggestions while choosing among different
design solutions.
• A goal is not checked by the customer at the
time of acceptance testing.

41. Goal of implementation
• It document issues such as:
- Revisions to the system functionalities in the
future.
- New devices to be supported in the future.
- Reusability issues.

42. Organization of the SRS Document
42
1. Introduction to the Document
– 1.1 Purpose of the Product
– 1.2 Scope of the Product
– 1.3 Acronyms, Abbreviations, Definitions
– 1.4 References
– 1.5 Outline of the rest of the SRS
2. General Description of Product
– 2.1 Context of Product
– 2.2 Product Functions
– 2.3 User Characteristics
– 2.4 Constraints
– 2.5 Assumptions and Dependencies

43. Organization of the SRS
Document(contd)
• 3. Specific Requirements
– 3.1 External Interface Requirements
• 3.1.1 User Interfaces
• 3.1.2 Hardware Interfaces
• 3.1.3 Software Interfaces
• 3.1.4 Communications Interfaces
– 3.2 Functional Requirements
• 3.2.1 Class 1
• 3.2.2 Class 2
• …
– 3.3 Performance Requirements
– 3.4 Design Constraints
– 3.5 Quality Requirements
– 3.6 Other Requirements
• 4. Appendices
43

44. 44
Example Functional Requirements
• List all functional requirements
with proper numbering.
Search book availability in Library
• Req. 1: Search book
Once the user selects the “search” option,
• he is asked to enter the key words.
– The system should output details of all books
• whose title or author name matches any of the key
words entered.
• Details include: Title, Author Name, Publisher name,
Year of Publication, ISBN Number, Catalogue Number,
Location in the Library.

45. 45
Req. 1:
• R.1.1: Select search option
– Input: “search” option,
– Output: user prompted to enter the key words.
• R1.2: Search and display
– Input: key words
– Output: Details of all books whose title or author name
matches any of the key words.
• Details include: Title, Author Name, Publisher name, Year of
Publication, ISBN Number, Catalog Number, Location in the
Library.
– Processing: Search the book list for the keywords

46. 46
Example Functional Requirements
• Req. 2: Renew book
– When the “renew” option is selected,
• the user is asked to enter his membership number
and password.
– After password validation,
• the list of the books borrowed by him are displayed.
– The user can renew any of the books:
• by clicking in the corresponding renew box.

47. 47
Req. 2:
• R2.1: Select renew book
– Input: “renew” option selected,
– Output: user prompted to enter his
membership number and password.
• R2.2: Login
– Input: membership number and password
– Output:
• list of the books borrowed by user are displayed.
User prompted to enter books to be renewed or
• user informed about bad password
– Processing: Password validation, search books
issued to the user from borrower list and
display.

48. 48
Req. 2:
• R2.3: Renew selected books
– Input: user choice for renewal of the books issued
to him through mouse clicks in the corresponding
renew box.
– Output: Confirmation of the books renewed
– Processing: Renew the books selected by the in the
borrower list.