The document discusses requirements elicitation, which involves determining what a system or product needs to do from users and stakeholders. It notes that requirements elicitation is difficult because stakeholders may not know their needs, have conflicting needs, or changing needs. The document then describes different types of requirements like functional requirements, which define what a system does, and non-functional requirements, also called quality attributes, which define how the system achieves its functions. Examples of different types of requirements are also provided.

2. Sometimes called Requirements discovery.
It certainly seems simple enough to ask the customer,
the users, and others
What the objectives for the system or product are
What is to be accomplished
How the system or product fits into the needs of
the business and
Finally, how the system or product is to be used on
a day-to-day basis.
But it isn’t simple—it’s very hard.
Interaction … match
Requirements Elicitation

3. Requirements Elicitation & Analysis

4. Problem Statement
What Problem Are We Trying to Solve?
The customer has only a vague idea of
what is required
•The developer is willing to proceed with the “vague
idea” on the assumption that “we’ll fill in the details as
we go along”
•The customer keeps on changing requirements
•Because of these changes, the developer may make
errors in specifications and development … and so it
goes …

5. Requirements comes from users and stakeholders who
have demands and needs…
End-users, managers, engineers etc.,
Various problems typically arise:
o Stakeholders don’t know what they really want
o Stakeholders express requirements in their own terms
o Different stakeholders may have conflicting
requirements
o Organizational and political factors may influence the
system requirements
o The requirements change during the analysis process.
o New stakeholders may emerge.
Customers and other stake holders....

6. User strategies in providing needed information
SAMETHING strategy :-
 “Give me the same thing but in better format through the
computer”
 It indicates the user’s laziness, lack of knowledge, or both.
 The analyst has a little chance of succeeding because only
user can fully discover the real needs and problems.
KITCHEN SINK strategy:
 The user throws every thing into the requirement
definition.
 User provides an over statement of needs.
 It reflects user’s lack of experience.

7. User strategies in providing needed
information
SMOKING strategy :-
 Sets up a smoke screen by requesting several features
when only one or two are needed.
 The extra requests are used as bargaining power.
 It reflects the users experience in knowing what he / she
wants.

8. Examples of valid software requirements
8
• Requirement #1:
– The system shall maintain records of all payments
made to employees on accounts of salaries, bonuses,
travel/daily allowances, medical allowances, etc
• Requirement #2:
– The system shall allow user to search for an item by
title, author, or by international standard book
number.
• Requirement #3:
– The system shall support at least 20 transactions per
second.

9. Types of Requirements
9
1. Functional Requirements
2. Non Functional Requirements
[Quality Attributes ]
3. Pseudo Requirements

10. Functional Requirements
10
Describes system services or functions which are
expected by the users of the system.
How the system should react to particular
inputs,
How the system should behave in particular
situations.
• Describing what the system does, or capture the
functionality of the system
Functional requirements are the backbone of
the software Development.
• It depends on the complexity of the software system.

11. 11
• Requirement #1:
– Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall use to access that
order.
• Requirement #2:
– The user shall be able to search all of the initial set
of databases for the given search id.
• Requirement #3:
– The system shall provide proper authentication for
the users to read documents in the document store.
Examples of
Functional requirements

12. Non - Functional Requirements
12
NFRs are often called “Quality attributes”
More critical than functional requirements.
Represents 20% of the requirements of a system
Hardest to elicit and specify
Defining good NFRs requires not only the involvement of
the customer but the developers too
• All requirements must be verifiable
– If not ‘verifiable’ then there is no indications that these
requirements have been satisfied.
• Some must also be measured.
– Some may be directly measured; some measured via
simulation.
If not met, the system may be useless.
(They are not “second class” requirements.)

13. Non- Functional Requirements Classification
13

14. Product
Requirements:
Specifies that the delivered product
must behave in a particular way
e.g. execution speed, reliability, etc.
Organizational
Requirements:
are a consequence of organizational
policies and procedures
e.g. process standards used,
implementation requirements, etc.
External
Requirements:
arises from factors which are external to
the system and its development process
e.g. interoperability requirements,
legislative requirements, etc.
14

15. What are Quality Attributes…?
15
•A set of constraints the system must satisfy
and the standards which must be met by the
delivered system.
•Describes “how” the system achieves its
functional requirements
•Performance Reliability
•Usability Efficiency
•Maintainability
•Portability Scalability
•Security Integration etc.,

16. Performance – Response Time
16
Response time
particularly important for processes that
process a lot of data or use networks a great
deal.
Requirements might stipulate < two second
response.
Might use a Timing bar indicating progress…

17. 17
• The capability of the software to maintain the
level of performance of the system when used
under specified conditions
Reliability Criteria
• Maturity: Capability of the software to avoid
failure as a result of faults in the software.
• Fault tolerance: Capability of the software to
maintain a specified level of performance in
cases of software faults.
Reliability

18. 18
The capability of the software to be
understood, learned, used and liked by
the user, when used under specified
conditions.
Usability Criteria
• Understandability: capability of the software
product to enable the user to understand
– whether the software is suitable, and
– how it can be used for particular tasks and
conditions of use.
Usability

19. 19
Usability Criteria
• Learnability: capability of the software product
to enable the user to learn its application
• Operability: capability of the software product
to enable the user to operate and control it.
• Likeability: capability of the software product to
be liked by the user.
Usability

20. 20
The capability of the software to
provide the required performance
relative to the amount of resources used,
under stated conditions
 Resources may include
 other software products,
 hardware facilities,
 materials, (e.g. print paper, diskettes).
Efficiency

21. 21
The capability of the software to be
modified.
• Modifications may include
– corrections,
– improvements or adaptation of the
software to changes in environment,
and in requirements and functional
specifications.
Maintainability

22. 22
Maintainability Criteria
• Changeability: The capability of the software
product to enable a specified modification to
be implemented.
• Stability: The capability of the software to
minimise unexpected effects from
modifications of the software
• Testability: The capability of the software
product to enable modified software to be
validated.

23. 23
The capability of software to be transferred
from one environment to another.
The environment may include organisational, hardware or
software environment.
Portability Criteria
 Adaptability: The capability of the software to be
modified for different specified environments
 Installability: The capability of the software to be
installed in a specified environment.
 Conformance: The capability of the software to
adhere to standards or conventions relating to
portability.
Portability

24. 24
Security is a multi-faceted quality
Difficult & specialized QA
Authentication: Applications can verify the identity
of their users and other applications with which they
communicate.
Authorization: Authenticated users and applications
have defined access rights to the resources of the
system.
Encryption: The messages sent to/from the
application are encrypted.
Security

25. 25
• Ease with which an
application can be
incorporated into a
broader application
context
• Use component in ways
that the designer did not
originally anticipate
• Typically achieved by:
– Programmatic APIs
– Data integration
Integration

26. Pseudo Requirements
• are requirements imposed by the client that
restrict the implementation of the system.
– Typical pseudo requirements are the
implementation language and the platform on
which the system is to be implemented.
• For life-critical developments, pseudo requirements
often include process and documentation
requirements (e.g., the use of a formal specification
method, the complete release of all work products).
• Pseudo requirements have usually no direct effect
on the users’ view of the system.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

27. Levels of description
 In general, there are four levels of
description, which can uniformly be
described with use cases
1. Work division. This set of use cases describes
the work processes of the users that are
relevant to the system but the focus is on
defining the boundaries between the users and
the system.
2. Application-specific system functions. This
set of use cases describes the functions that the
system provides that are related to the
application domain.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

28. Levels of description
3. Work-specific system functions. This set of use
cases describes the supporting functions of the
system that are not directly related with the
application domain. These include file management
functions, grouping functions, undo functions, and
so on.
4. Dialog. This set of use cases describes the
interactions between the users and the user interface
of the system. The focus is on designing resolving
control flow and layout issues.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

29. Completeness, Consistency, Clarity
and Correctness
• Requirements are continuously validated with
the client and the user
• Validation is a critical step in the development
process given both the client and developer
depend on the requirements specification.
• Requirements validation involves checking
that the
– specification is complete, consistent,
unambiguous, and correct
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

30. Completeness:
• It is complete if all the possible
scenarios through the system are
described, including exceptional
behavior. ie. All aspects of the system
are represented in the requirements
model
• Consistency: The requirements
specification is consistent if it does not
contradict itself.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

31. • Unambiguous: The SRS is
unambiguous if exactly one system is
defined [ i.e.., it is not possible to
interpret the specification two or more
different ways.]
• Correct: A system is correct if it
represents accurately the system that
the client needs and that the developer
intend to build
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

32. Realism, Verifiability & Traceability
The most desirable properties of
requirements specification.
• Realistic: The SRS is realistic if the
system can be implemented within
constraints.
• Verifiable: The SRS is verifiable if once
the system is built, repeatable tests can
be designed to demonstrate that system
fulfills the requirements specification.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

33. • Traceable: A requirement specification is
traceable if each requirement can be traced
through out the software development to its
corresponding system functions and vice
versa.
• Traceability enables the tester to access the
coverage of the test case, to identify which
requirements are tested and which are not.
• When evaluating changes, traceability
enables the analyst & developers to identify
all components and system functions that the
change would impact
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

34. Greenfield Engineering
Development starts from scratch
No prior system exists
Requirements come from end users and clients
Triggered by user needs
Re-engineering
Re-design and/or re-implementation of an existing
system using newer technology
Triggered by technology enabler
Interface Engineering
Provision of existing services in a new environment
Triggered by technology enabler or new market
needs
Requirements Engineering Models