1. The role of the Analyst in requirements Elicitation
CS Requirements Engineering Brian Fogarty & Mara Kelly Previously on CS4566……..
The role of the Analyst in requirements Elicitation

2. Requirements Elicitation
“The process of finding out what the requirements are.”
You’d imagine is quiet easy. Just ask the stakeholders what their requirements and we can do the rest from there.
You’d imagine its just like gathering information.?????? Wouldn’t you???
Well its not

3. Requirements Elicitation
Requirements Elicitation is more than just gathering information. It’s a more structured proactive way of formulation the necessary requirements to insure the best outcome.
You first need to decide what technique to use.

4. Elicitation Techniques
Traditional
Joint
User Centre
Traditional ; Techniques that the analyst himself may have used in the past and feel it may work again
Joint techniques; Are a system that a group has used previously and the feel that this might be the way to go
User Centre ; Techniques the organisation have used, are tried and tested and I wish they’d go back to them (ha ha Ha) ( aren’t I gas!!!!!)
The Analyst has to come up with a strategy!!!

5. Which What Where Who You need to know: Elicitation strategy
What are you looking for?
◦ Everything you can find out about Goals, Tasks, functionality, expectations.. 
Where are you looking?
Who are all your sources
Which elicitation techniques to use for each source of requirements…
To do this Analyst needs 3 main skills.

6. Skills Required Analytical Skills Investigative skills
Can be a juggling act An Analyst needs three main skills for dealing particularly for organisational information systems
He needs to make knowledge Explicit so that it can be readily articulated, codified, accessed and verbalized.
Needs to be able to Know the difference between requirements and everything else.
Communication Skills

7. not just ‘order takers’
Some other skills……
not just ‘order takers’
Effective requirements analysts are not just ‘order takers’
Don’t just pass information from one person to the next trying to please everybodys last whim

8. Some other skills…… all levels of the organisation
Conflict / Resolution
Dealing with people at all levels of the organisation
Have to be able to talk with the MD of company as well as the person that has just started
Resolving conflicts
A lot of this can be sorted, where we explain later, about whereby accurate notes can avoid the “but that’s not what you asked for “ arguments

9. Some other skills…… Problems/Solutions New Material
3. Identifying problems
4. Distinguishing solutions from problems
5. Absorbing new material quickly
( even though it may not be your area of expertise you must learn the critical points quickly)

10. Some other skills…… Organising and running workshops
Selling’ the new system/product
6. Organising and running workshops
To integrate the new systems seamlessly
7. Selling’ the new system/product.
Sometimes the changes have to be sold to people that are reluctant to change the existing system.

11. Also need to be good at……
Planning; Most important to have a strategy for Elicitation
Listening: Deny yourself to put somebody with very strong opinions at the centre of the whole project. Listen to all sides
Difference between;
Taking notes: Means writing down exactly what they said.
and
Making notes: Your own interpretation of the conversation in the meetings as I said in the conflict/resolution slide

12. Barriers to elicitation for the analyst
Requirements elicitation process involves human interaction
The business analyst must bridge the gap between people in different contexts and implement the abstract analysis
Requirements Elicitation is complicated by 3 syndromes
Requirements elicitation process involves human interaction of multi-stakeholders with different thinking capabilities which makes it complicated and difficult
The business analyst must bridge the gap between people in different contexts and implement the abstract analysis
Requirements Elicitation is complicated by 3 syndromes: “Yes, But,” ”Undiscovered Ruins,” and “User and the Developer” syndrome

13. “Yes, But” Syndrome
Typical user reaction to seeing the proposed system the first time is:
“Yes, but, now that I see it what about this…?Wouldn’t it be nice if…?”
This is human nature
Typical user reaction to seeing the proposed system the first time is:
“Yes, but, now that I see it what about this…?Wouldn’t it be nice if…?”
This is human nature and happens because users are not always software experts who are good at visualising designs until they have a physical example
Techniques to remove early “Buts” like early delivery of prototypes should be applied so development efforts can be applied to software that has passed the “Yes, but” stage

14. “Undiscovered ruins” Syndrome
The search for Requirements can be a search for undiscovered ruins
The more you find, the more you realise are there
Software development teams must accept they may never find all possible requirements, and accept when they have found “enough”
The search for Requirements can be a search for undiscovered ruins
The more you find, the more you realise are there
Software development teams must accept they may never find all possible requirements, and accept when they have found “enough”

15. “User and the developer” Syndrome
Communication gaps often exist between the users and developers
The two are often from different worlds
Communication gaps often exist between the users and developers
The two are often from different worlds: they may speak different languages, have different professional and personal backgrounds, motivations, and objectives
The analyst must be good at playing different roles to gain insight into these different worlds

16. Analyst Interviewing for requirements elicitation
The “Requirements interview” is the most indispensable, and flexible technique in requirements analysis
Planning is important!
Take versus make notes
Question Types
Post Interview
The “Requirements interview” is the most indispensable, and flexible technique in requirements analysis
Planning is important! The business analyst needs a well defined plan for interviews with the stakeholders. But, the analyst must also be able to deal with unexpected information
It is necessary to take notes of what is said, and make notes with your own conclusions drawn from the interview
Question types include: direct, open-ended, clarifying, and leading
Post interview the analyst must send a copy of the notes to the interviewee to approve and edit any conclusions made. Then store interview records in a project file

17. Thank you for Listening
CS Requirements Engineering Brian Fogarty & Mara Kelly
The role of the Analyst in requirements Elicitation
Thank you for Listening
The “Requirements interview” is the most indispensable, and flexible technique in requirements analysis
Planning is important! The business analyst needs a well defined plan for interviews with the stakeholders. But, the analyst must also be able to deal with unexpected information
It is necessary to take notes of what is said, and make notes with your own conclusions drawn from the interview
Question types include: direct, open-ended, clarifying, and leading
Post interview the analyst must send a copy of the notes to the interviewee to approve and edit any conclusions made. Then store interview records in a project file