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

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

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.

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!!!

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.

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

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

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

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)

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.

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

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

“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

“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”

“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

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

Thank you for Listening CS4566 - 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