31
Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Embed Size (px)

Citation preview

Page 1: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Object-Oriented System Analysis and Design

Chapter III- Requirement ElicitationCollecting and organizing users requirement-

WHAT- User needs

Page 2: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Basic objectives of the chapter

2

Define requirement and related concepts?Understand requirement identification

and collection techniquesusing traditional methodessential use case modelingCRC modelingessential user interfaces modelingSupplementary specifications

Being familiar with validating, organizing and documenting requirements

Page 3: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

What is a RequirementWhat is a Requirement ??

04/19/233

It is a statement describing either 1) an aspect of what the proposed system must

do, or 2) a constraint on the system’s development. In either case it must contribute in some way

towards adequately solving the customer’s problem;

the set of requirements as a whole represents a negotiated agreement among the stakeholders.

A collection of requirements is a requirements document.

Page 4: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Types of Requirements

04/19/234

Functional requirements Describe what the system should do

Non-functional requirementsQuality requirements

Constraints on the design to meet specified levels of quality such as availability, performance, usability, etc

Pseudo requirementsPlatform requirements

Constraints on the environment and technology of the system

Process requirements Constraints on the project plan and development

methods

Page 5: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Functional Requirements

04/19/235

What inputs the system should acceptWhat outputs the system should produceWhat data the system should store that

other systems might useWhat computations the system should

performThe timing and synchronization of the above

Page 6: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Quality Requirements All must be verifiableExamples: Constraints on

◦ Response time◦ Throughput◦ Resource usage◦ Reliability◦ Availability◦ Recovery from failure◦ Allowances for maintainability and

enhancement◦ Allowances for reusability

04/19/236

Page 7: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont..

04/19/237

Requirement elicitationIs about a communication b/n developers and

user in defining a new systemFailure to do so will lead to “unwanted”

systemFocus on describing the purpose of the

systemResults in system specification

Page 8: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont..

04/19/238

System specification Vs Analysis modelRepresent same informationDifference only on the language and notation

they useBoth describe more of external aspect of the

system visible to users (users' view)They occur concurrently and iteratively

Page 9: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

How to conduct?

04/19/239

Through techniques likeTraditional methods like interviewEssential use caseCRC model

Identifying initial analysis objectsEssential user interfaceIdentification of non-functional requirement

All the above techniques will help us in making domain analysis

Page 10: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Domain Analysis

04/19/2310

The process by which a software engineer learns about the domain to better understand the problem:The domain is the general field of business or

technology in which the clients will use the software, e.g. Finance, personnel, marketing, etc

A domain expert is a person who has a deep knowledge of the domain e.g. accountant for finance system

Benefits of performing domain analysis:Faster developmentBetter systemAnticipation of extensions

Page 11: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Defining the Problem and the Defining the Problem and the ScopeScope

04/19/2311

A problem can be expressed as: A difficulty the users or customers are facing, Or as an opportunity that will result in some

benefit such as improved productivity or sales.

The solution to the problem normally will entail developing software/system

A good problem statement is short and concise

Page 12: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Defining the ScopeDefining the Scope

04/19/2312

Narrow the scope by defining a more precise problem List all the things you might imagine the

system doing Exclude some of these things if too broadDetermine high-level goals if too narrow

Example: A university registration system

Page 13: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…

04/19/2313

Initial list of problems with very broad scope

Narrowed scope

Scope of another system

exam scheduling

room allocation

fee payment

browsing courses

registeringexam scheduling

room allocation

fee payment

browsing courses

registering

Page 14: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Example: Library SystemExample: Library System

04/19/2314

Idea: A Library Management System should be designed. Information on books, CDs, DVDs, Journals, etc. can be stored and retrieved

Possible RequirementsSearching by Title, Author, and/or ISDN should be

possibleUser Interface should be web-based (accessible via

WWW Browser)At least 20 transactions per seconds should be

possibleAll services should be available within 10 minutes Users have no access to personal data of other

users

Page 15: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Member of Elicitation team?Identify stakeholders

(any one who could be affected by the implementation of the system)- customers, end-users.

Choose best Subject matter expert (SME)(who knows the business, think logically,

communicate well, willing to invest time on the software development)

Choose good facilitator or scriber (with good communication skill)

04/19/2315

Page 16: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Remarks on the process

04/19/2316

Result in the specification of the system that the client and user can understand (natural language)

It should be validated forcorrectness (according to the user)completeness (all requirements)Consistency (No contradiction)Unambiguousness (clear)realistic (that can be implemented)

Page 17: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Reviewing Requirements

04/19/2317

Each individual requirement should Have benefits that outweigh the costs of

development Be important for the solution of the current problem Be expressed using a clear and consistent notation Be unambiguous Be logically consistent Lead to a system of sufficient quality Be realistic with available resources Be verifiable Be uniquely identifiable Does not over-constrain the design of the system

Page 18: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Requirements documents...

04/19/2318

The document should be:sufficiently complete well organized clear agreed to by all the stakeholders

Traceability:

Design document

....due to requirement 1.2

Requirements document

1.1 XXXX .... because 1.2 YYYY

rationale

Page 19: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Difficulties and Risks in Domain and Requirements Analysis guides

04/19/2319

Lack of understanding of the domain or the real problem Do domain analysis and prototyping

Requirements change rapidlyPerform incremental development, build flexibility into

the design, do regular reviews Attempting to do too much

Document the problem boundaries at an early stage, carefully estimate the time

It may be hard to reconcile conflicting sets of requirements Brainstorming, JAD sessions, competing prototypes

It is hard to state requirements precisely Break requirements down into simple sentences and

review them carefully, look for potential ambiguity, make early prototypes

Page 20: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

How to Elicit (collect) Requirement)

04/19/2320

Research/Document AnalysisThe document Analysis is a method by which

the system analyst go through each documents used and relevant to all the processes covered by the system.

The documents will give information about the data to be captured and the presentation of the data to the users of the system.

Page 21: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…

04/19/2321

Direct ObservationDirect observation is a method used to

verify the already gathered information and to add on to requirement.

The method will help to see how users behave and do things in their day to day activity.

Questionnaires and SurveysThe Survey Method is an electronic or

paper based method of soliciting needs or requirements from stakeholders.

The survey method is a list of questions, directed at identifying stakeholder needs or requirements.

Page 22: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…

04/19/2322

InterviewsAn interview is a conversation with

stakeholders to elicit or validate needs and requirements.

An interview may include one or more stakeholders.

The interview may also involve a question and answer session used to discover other potential stakeholders and any discrepancies between needs; the high-level requirements derived from those needs; and the resulting detailed requirements.

Interviews facilitate obtaining approval from stakeholders on their needs, requirements, and any changes to them.

Page 23: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Gathering and Analysing Requirements

04/19/2323

On Observation Read documents and discuss requirements with usersShadowing important potential users as they do their

work ask the user to explain everything he or she is doing

Session videotaping On Interviewing

Conduct a series of interviews Ask about specific details Ask about the stakeholder’s vision for the future Ask if they have alternative ideasAsk for other sources of information Ask them to draw diagrams

Page 24: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…

04/19/2324

Joint Application Design (JAD): The Joint Application Development (JAD)

technique is an extended, facilitated workshop.

It involves collaboration between users, managers and systems analysts and system designers to identify needs or requirements in a concentrated and focused group discussion.

Page 25: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont... On Brainstorming Appoint an experienced moderator Arrange the attendees around a table Decide on a ‘trigger question’ Ask each participant to write an answer

and pass the paper to its neighbour

Joint Application Development (JAD) is a technique based on intensive brainstorming sessions

04/19/2325

!

!

! !

!

!

Page 26: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Elicitation – Essential use Elicitation – Essential use casecaseUse Cases are used to capture the intended

behaviour of the system under development (requirements of a system)

In terms of Use case, actors and relationships (use case diagram) and use case documentation

04/19/2326

Page 27: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Requirement Elicitation tasks (using use case)Identify actors: Hints

Actors are external to the system- human or another system

Represent roles Question you should ask

Which user group are supported by the syetm to perform their task?

Which user groups execute the systems major function?

Will the system interact with any external hardware or software?

04/19/2327

Page 28: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…Identify use cases

First identify scenarios or examples of system usage and compile or represent some similar scenarios with one case.

Question to be askedWhat are the tasks that the actor wants the

system to perform?

04/19/2328

Page 29: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

Cont…Cont…

04/19/2329

Identify relationshipsTo reduce complexity and increase understandability

Communication(association), include (use), extend, and generalization

Questions to be asked Is there any relationship that needs to be factored out

among use cases? If yes ‘include’ will solve it Is there any exceptional or optional cases? If yes

“extend” will solve it Is there two or more possibilities for accomplishing a

case? If yes “generalization” will solve it

Page 30: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

So…So…

04/19/2330

Now at this stage you have some understanding about the system/software to be developed from functional point of view

What is next should beAgain collecting requirements from structural

point of view

Page 31: Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

System Modeling will continueSystem Modeling will continue

04/19/2331