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
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.)
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
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
