REQUIREMENT DISCOVERY PART I. Requirement discovery – includes those techniques to be used to by...

21
REQUIREMENT DISCOVERY PART I

Transcript of REQUIREMENT DISCOVERY PART I. Requirement discovery – includes those techniques to be used to by...

Page 1: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

REQUIREMENT DISCOVERY PART I

Page 2: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems & solution requirements from the user community.

System requirement – a description of the needs & desires for an information system that describes functions, features & constraints.

Page 3: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

A function or feature that must be included in an information system to satisfy the business need and be acceptable to the users.

Ex of functional requirement;Calculate student’s GPACapture account holder’s information

Page 4: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Description of the features, characteristics & attributes of the system as well as any limitations.

Classifications of non functional requirements;Performance, information, economy, control

(security), efficiency & services.

Page 5: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

System requirement is features that MUST be included in the system to satisfy business requirements & acceptable to users.

They serve as benchmark. 5 categories of requirements ;

Outputs InputsProcessesPerformancesControls

Page 6: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Scalability The ability to adjust system capacity as business

requirements change in the future Transaction volume has a significant impact on

operating costs. When volumes exceeds the system’s expectations, maintenance cost increases sharply.

Data storage is an important concern as well

Total Cost of Ownership (TOC) Important to identify & document indirect cost

as chances for system that may seem inexpensive initially might turn up to be the most expensive one!

Page 7: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

OverviewFirst step is to identify the information needed

by asking a series of questions, then carry out the fact finding technique & document the results. Finally prepare a system requirement document to be presented.

Who, What, When, Where & How?Current System Proposed system

What is done? What should be done?

Where is it done? Where should be done?

When it is done? When should be done?

Who does it? Who should do it?

How is it done? How should it be done?

Page 8: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Sampling Sampling might include ; records, reports,

operational logs, data entry documents, complaint summaries, work request.

Sample techniques include; systematic sampling, stratified sampling & random sampling.

Document review Provide better understanding how the current

system is supposed to work System documentation sometimes out of date so

changes are done, resulting in the change on documented procedures.

Page 9: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Research Includes; reviewing journals & books to obtain

background information, technical material & news about industry trends & developments.

Internet is becoming one of the most preferred research tools through the search engines.

Observation Observation of the current working system gives

you additional perspective & better understanding of the system procedures.

It can also provide the knowledge needed to test & install future changes.

Page 10: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Advantages of observation Data gathered is highly reliable Analyst can see what is exactly being done Observation technique is inexpensive. Allows the analyst to do work measurements.

Disadvantages of observation Hawthorne experiment proves that the act of

observation can alter behaviour so you may not get accurate data since they might perform differently.

Work being observed may not include the level of difficulty or volume normally experienced.

The task being observed is subject to various interruptions

Some tasks may not be performed in the manner in which the analyst observed .

Page 11: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Observation guidelines Determine the who,what,when,how & why of the

observation. Obtain permission from appropriate supervisors /

managers Inform those whom will be observed of the

purpose of the observation Keep a low profile Take notes during / immediately following the

observation Do not interrupt the individual at work Do not focus heavily on trivial activities Do not make assumptions Review observation notes with appropriate

individuals.

Page 12: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Discovery prototyping The act of building small scale or working model

of the users requirements to discover / verify those requirements.

Prototyping is most useful when; User requirement is not clear or well

understood.One or few users & stakeholders are involved

with the systemPossible designs are complex & require concrete

form to fully evaluateCommunication problem have occurred in the

past between users & analystTools & data are readily available to rapidly

build working system.

Page 13: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Process of prototyping Identify basic requirementsDevelop initial prototypeReviewRevise & enhancing prototype.

Advantages of prototypingReduced time & cost Improved & increased user involvement\

Disadvantages of prototyping Insufficient analysisUser confusion of prototype & finished systemExcessive development time of the prototype.Expense of implementing prototyping

Page 14: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Dynamic System Development Method (DSDM) A framework for delivering business solution that relies

heavily upon prototyping as a core technique. Expanding upon most understood definition of prototype.

DSDM prototypes intended to be incremental, evolving from simple form into a complex one.

4 categories of prototypes as recommended by DSDM;Business prototypes – to define & demonstrate

business processes being automatedUsability prototypes – to define & refine user

interface design look, feel, usability etcPerformance & capacity prototypes – predict how

system will perform under peak loads & evaluate non functional aspects.

Capability/technique prototypes – evaluate a design approach or concept.

Page 15: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Joint Requirement Planning (JRP) A technique for drawing out user requirements

through joint planning sessions of software users & information technology personnel.

Provide an open environment for people to discuss what they do, how they do & what critical information they need etc.

End product will be a written documentation

Joint Requirements Planning (JRP) participants Individuals involved in JRP session includes

sponsor, facilitator, users & managers, scribe & IT staff

Page 16: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Sponsor – individual from top management who has authority that spans across departments.

Facilitator – responsible for leading all sessions that are held for a systems project

Users & managers – responsible to give information relating to the business process to be automated.

Scribes – responsible to keep records pertaining to everything discussed in the meeting using CASE tools.

IT staff – responsible to develop models & other documentations related to facts communicated during the meeting.

Page 17: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Steps to plan JRP session Involves 3 steps;

Selecting a location – if possible JRP sessions to be conducted away from the company workspace, so that they can concentrate better. Room should have pc, writing utensils, projectors, white board etc

Selecting the participants – analyst, sponsors, managers, users, IT staffs & scribes are all included.

Preparing the agenda – preparation is the key to JRP sessions. Facilitator to prepare agenda for all that dictates;The opening - expectation of the session & rulesBody – detail of topics & issues addressedConclusion – summarize the day’s session &

remind about the unsolved issues.

Page 18: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

How to conduct a JRP session Starts with opening remarks, introductions & a

brief overview of the agenda & objectives for the session.

Facilitator will direct the meeting using the prepared agenda & they follow these guidelines; Do not deviate from the agenda

stay on schedule Ensure the scribes able to take notes Avoid the use of technical jargon Apply conflict resolution skills Allow for ample breaks Encourage group consensus Allow everyone to participate without dominating the

session.

Page 19: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Brainstorming A technique for generating ideas in a short time

during a group meeting. Guidelines ;

Isolate participants in a room Make sure all understand the problem & issues Appoint 1 person to record ideas to be viewed by

all Remind everyone of the brainstorming rules Call out their ideas spontaneously Analyze those ideas only after all run out of ideas

then improve it further. Emphasize on the quantity of the ideas not

quality! No criticism

Page 20: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Brainstorming sequence One member should review the topic of

brainstorming using why, how / what question Everyone should think about the question silently &

record their ideas on a piece of paper Everyone suggest ideas by calling them out or go

around the room having them read all of their ideas before the next person starts.

One member writes down all the ideas on the board

Making final decision When all ideas have been recorded, combine ideas

as much as possible if the contributor agrees. Each member votes on the ideas & chooses which

one should be given priority

Page 21: REQUIREMENT DISCOVERY PART I.  Requirement discovery – includes those techniques to be used to by system analyst to identify or extract system problems.

Benefits of JRP] Encourage partnership between business &

software experts Enable the business side to identify & define their

need for a software Reducing design & development time by clarifying

software requirements up front Driving software architecture & platform decisions Lowering deployment & maintenance cost by

resolving issues early in the SDLC Improve the quality of the solution by combining

the ideas of variety of people. Increasing end user & project team knowledge of

the system & satisfaction with the result.