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 areWhat is to be accomplishedHow the system or product fits into the needs ofthe business andFinally, how the system or product is to be used ona day-to-day basis.

But it isn’t simple—it’s very hard.

Interaction … match

Requirements Elicitation

Requirements Elicitation & Analysis

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 “vagueidea” on the assumption that “we’ll fill in the details aswe go along”

• The customer keeps on changing requirements• Because of these changes, the developer may make

errors in specifications and development … and so itgoes …

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 wanto Stakeholders express requirements in their own termso Different stakeholders may have conflicting

requirementso Organizational and political factors may influence the

system requirementso The requirements change during the analysis process.o New stakeholders may emerge.

Customers and other stake holders....

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.

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.

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.

Types of Requirements

9

1. Functional Requirements

2. Non Functional Requirements[Quality Attributes ]

3. Pseudo Requirements

Functional Requirements

10

Describes system services or functions which areexpected 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 systemFunctional requirements are the backbone of

the software Development. • It depends on the complexity of the software system.

11

• Requirement #1: – Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall use to access thatorder.

• Requirement #2:

– The user shall be able to search all of the initial setof databases for the given search id.

• Requirement #3:

– The system shall provide proper authentication forthe users to read documents in the document store.

Examples of Functional requirements

Non - Functional Requirements

12

NFRs are often called “Quality attributes”More critical than functional requirements.Represents 20% of the requirements of a systemHardest to elicit and specifyDefining good NFRs requires not only the involvement ofthe 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.)

Non- Functional Requirements Classification

13

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

What are Quality Attributes…?

15

•A set of constraints the system must satisfyand the standards which must be met by thedelivered system.

•Describes “how” the system achieves itsfunctional requirements

•Performance Reliability•Usability Efficiency•Maintainability•Portability Scalability•Security Integration etc.,

Performance – Response Time

16

Response time

particularly important for processes thatprocess a lot of data or use networks a greatdeal.

Requirements might stipulate < two secondresponse.

Might use a Timing bar indicating progress…

17

• The capability of the software to maintain thelevel of performance of the system when usedunder 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 incases of software faults.

Reliability

18

The capability of the software to beunderstood, learned, used and liked bythe user, when used under specifiedconditions.

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

Usability Criteria

• Learnability: capability of the software productto enable the user to learn its application

• Operability: capability of the software productto enable the user to operate and control it.

• Likeability: capability of the software product tobe liked by the user.

Usability

20

The capability of the software toprovide the required performancerelative 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

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

Maintainability

22

Maintainability Criteria

• Changeability: The capability of the softwareproduct to enable a specified modification tobe implemented.

• Stability: The capability of the software tominimise unexpected effects frommodifications of the software

• Testability: The capability of the softwareproduct to enable modified software to bevalidated.

23

The capability of software to be transferred from one environment to another.

The environment may include organisational, hardware orsoftware environment.

Portability Criteria

Adaptability: The capability of the software to bemodified for different specified environments

Installability: The capability of the software to beinstalled in a specified environment.

Conformance: The capability of the software toadhere to standards or conventions relating toportability.

Portability

24

Security is a multi-faceted quality Difficult & specialized QA

Authentication: Applications can verify the identityof their users and other applications with which theycommunicate.Authorization: Authenticated users and applicationshave defined access rights to the resources of thesystem.Encryption: The messages sent to/from theapplication are encrypted.

Security

25

• Ease with which anapplication can beincorporated into abroader applicationcontext

• Use component in waysthat the designer did notoriginally anticipate

• Typically achieved by:– Programmatic APIs– Data integration

Integration

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 onwhich the system is to be implemented.

• For life-critical developments, pseudo requirementsoften include process and documentationrequirements (e.g., the use of a formal specificationmethod, the complete release of all work products).

• Pseudo requirements have usually no direct effecton the users’ view of the system.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Levels of description In general, there are four levels of

description, which can uniformly bedescribed with use cases

1. Work division. This set of use cases describesthe work processes of the users that arerelevant to the system but the focus is ondefining the boundaries between the users andthe system.

2. Application-specific system functions. Thisset of use cases describes the functions that thesystem provides that are related to theapplication domain.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Levels of description3. Work-specific system functions. This set of use

cases describes the supporting functions of thesystem that are not directly related with theapplication domain. These include file managementfunctions, grouping functions, undo functions, andso on.

4. Dialog. This set of use cases describes theinteractions between the users and the user interfaceof the system. The focus is on designing resolvingcontrol flow and layout issues.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Completeness, Consistency, Clarity and Correctness

• Requirements are continuously validated withthe client and the user

• Validation is a critical step in the developmentprocess given both the client and developerdepend on the requirements specification.

• Requirements validation involves checkingthat the– specification is complete, consistent,

unambiguous, and correct

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Completeness:• It is complete if all the possible

scenarios through the system aredescribed, including exceptionalbehavior. ie. All aspects of the systemare represented in the requirementsmodel

• Consistency: The requirementsspecification is consistent if it does notcontradict itself.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

• Unambiguous: The SRS isunambiguous if exactly one system isdefined [ i.e.., it is not possible tointerpret the specification two or moredifferent ways.]

• Correct: A system is correct if itrepresents accurately the system thatthe client needs and that the developerintend to build

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Realism, Verifiability & Traceability

The most desirable properties ofrequirements specification.

• Realistic: The SRS is realistic if thesystem can be implemented withinconstraints.

• Verifiable: The SRS is verifiable if oncethe system is built, repeatable tests canbe designed to demonstrate that systemfulfills the requirements specification.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

• Traceable: A requirement specification istraceable if each requirement can be tracedthrough out the software development to itscorresponding system functions and viceversa.

• Traceability enables the tester to access thecoverage of the test case, to identify whichrequirements are tested and which are not.

• When evaluating changes, traceabilityenables the analyst & developers to identifyall components and system functions that thechange would impact

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

Greenfield EngineeringDevelopment starts from scratchNo prior system existsRequirements come from end users and clientsTriggered by user needs

Re-engineeringRe-design and/or re-implementation of an existingsystem using newer technologyTriggered by technology enabler

Interface EngineeringProvision of existing services in a new environmentTriggered by technology enabler or new marketneeds

Requirements Engineering Models