User:Marc Wiki Rademakers/Requirements Interviews
![](/upwiki/wikipedia/commons/thumb/f/f6/Requirement_interview.jpg/220px-Requirement_interview.jpg)
Requirements interviews, also known as requirements-gathering interviews, is a method used to gather information about the needs and goals of stakeholders in a project. Interviews are the most traditional and commonly used requirements elicitation technique[1][2]. They are typically conducted by a project manager or business analyst and involve interviewing stakeholders who will be affected by the project. A requirements interview aims to gather detailed information about the project's objectives, constraints, and requirements. This information is then used to create a requirements document, which serves as the foundation for the project's design and development. The results or requirements gathered from interviews depend heavily on the interviewer's skills and requires a well designed interview. There are guidelines the interviewer can use which explain how to prepare for the interview, how to conduct the interview, and what to do to follow up[3]. There are best practices that can help the interviewer in taking the right approach with requirements interviews in different situations. Lastly, solutions are proposed for common mistakes interviewers make when conducting interviews[1].
Guidelines
[edit]Designing an interview can be a hard task and it is easy to forget important parts. This can lead to imprecise and incomplete interviews caused by ambiguity in communication[3]. The interview questions are mostly open-ended and focused on understanding the stakeholders' needs and goals, rather than on specific solutions. They can take various forms, such as one-on-one interviews, focus groups, or survey questionnaires, and are inherently informal[4]. Interviews can be divided into three main interview types: unstructured, structured and semi-structured[5]. Conducting an interview consists of three steps:
Before conducting an interview, it is important to prepare properly. This includes defining the purpose of the interview, selecting the right person for the interview, researching the interviewee, developing a list of questions, and arranging the logistics. To define the purpose of the interview, the interviewer needs to understand why the interview is being conducted and how the interviewee will benefit. Select the right person for the interview, based on their knowledge and perspectives. Researching the interviewee entails gathering both professional and personal information. Decide upon using open or closed questions and ask both domain knowledge and process knowledge questions. As for logistics, choose the location, contact the interviewee to schedule the meeting, and add the meeting to the interviewer's schedule with a meaningful description. Also consider online meetings are also an option.
Before starting an interview, it is important to build rapport with the interviewee and lay out expectations. This can provide insights into the interviewee's mindset, help create relationships on multiple levels, and ensure that all parties understand the goal and expectations of the interview. During the interview, ask meaningful questions to focus on what needs to be learned. Use active listening to turn stated requirements into actual requirements. It is important to listen for the underlying intent, feelings, and needs of the interviewee. It is also important to take notes using the purpose of the interview as a guideline. This includes using the purpose of the interview as a guideline to decide how to take notes and choosing the appropriate tools, such as a notepad, pen, paper, etc. Take time to wrap up the interview and to save time for a proper conclusion. Summarizing what was covered and thanking the interviewee for their time is also essential. Following up on any items discussed during the interview is important in order to ensure that all parties have a clear understanding of the conversation.
At the end of the interview, thank the interviewee for their time and participation. Check notes taken during the interview before following up to ensure that all important information has been captured. This step is important as it helps to identify any missing or unclear information that may need further clarification or elaboration.
Best practices
[edit]Best practices for requirement interviews | Description of practice in requirement engineering | General description |
---|---|---|
Develop a rapport with the interviewee | During requirement interviews, the interviewer does not always have the opportunity to develop long-term relationships with interviewees. It is important to develop a rapport with interviewees during each interview session.[6][7] | Requirement engineer begins the interview with small talk.
Requirement engineer shows interest in interviewee to develop a relationship. |
Be flexible and opportunistic | The requirement engineer will naturally be unaware of the scope of the requirements prior to the interview. A flexible and open approach to the interview process allows the interviewer to recognize relevant requirements and follow-up with them in the moment. [8][9] | Interviewer probes into a relevant subject brought up by the interviewee to find more requirements.
Interviewer is able to ask relevant questions to retrieve all requirements. |
Use a co-creative interview strategy | The requirement engineer structures the interview in a co-creative way, enabling the interviewee to engage more easily during the interview. This will also give the interviewee a sense of ownership during the development op requirements. [10] | Requirement engineer makes comments and shows interest in the interviewee to increase interviewee's sense of ownership of the product requirements. |
State and verify the conclusions drawn from interviews | The requirement engineer must make sure to clearly state conclusions and requirements. Also, these conclusions are always verified by the interviewee to ensure correctness and completeness.[11][12] | Requirement engineer often presents his interpretation of possible requirements.
Requirement engineer verifies the requirements generated through interviews. |
Avoid misinterpretations | The requirement engineer documents the exact words of the interviewee. When something is not clear, the requirement engineer asks questions to make sure both parties are on the same page.[13][14] | Requirement engineer asks clarifying questions to ensure they fully understand the interviewee. |
Use projective questioning techniques | The requirement engineer asks questions that are easy to follow, interpretable, and realistic. The interviewee will understand the questions more easily.[15][16] | Requirement engineer uses stories, metaphors, or hypothetical situations when framing questions. |
Encourage deep thinking | The requirement engineer encourages the interviewee to analyze their ideas and answers to generate more detailed and deeper meanings for responses.[15][17][10] | Requirement engineer formulates questions which requires the interviewee to: use reasoning, analyze, and be critical. |
Mistakes
[edit]An empirical study by Bano et al.[1] aimed to identify common mistakes made by novices during their first requirements elicitation interviews. The study involved 110 post-graduate students in the University of Technology Sydney, who were teamed up in 28 groups to conduct requirements elicitation interviews with a business owner (played by an experienced academic). The study identified 34 unique mistakes classified into 7 high-level themes and provides examples of mistakes made by the novices to assist educators and trainers. The following mistakes are made during requirements interview (based on the study by Bano et al.):
Question formulation
[edit]- Vague questions[18]: It is good to use open-ended questions, but avoid them from being vague or ambiguous. If it is the case that the interviewee does not understand your question, change it. Estimate if the interviewee understands the question, because it is likely that they will answer the question either way.
- Technical questions: Try avoiding technical jargon or concepts. There is a high chance that the interviewee is not a computer or information scientist. Adjust the question such that the interviewee understands it.
- Irrelevant or incorrect questions: Avoid questions that are out-of-scope as this costs time. For example: Asking a question that relates to employee wages, while the interviewee has said that employee wages are not of your concern. Avoid questions that focus too direct on the solution as this can confuse the interviewee. Instead work towards the solution by asking question that can lead to a solution. Avoid long questions.
Question omission
[edit]Not asking for additional stakeholders. This often happens and important stakeholders are being left out[19]. Always take into account the possibility that your interviewee knows only part of the information. Ask who the interviewee about potential stakeholders No probing questions. Always ask probing question to make sure you understand the answer, when you understood something, but also when you suspect you misunderstood something. Rephrase it with your own terms. This makes it easier when reading back the interview. Not asking about the existing system or process. It is crucial that the as-is situation is understood. Not asking about feature priority: Take into account that some features have a higher priority than others. This way the features with higher priorities can get more attention rather than focusing on features with lower priority. Not asking about the problem domain: Document the problem domain yourself and ask when domain-specific terms are used.
Order in the interview
[edit]Make sure that the order of the topics you cover in your interview are logical. Ask for example first about the bigger picture, and then go into more detail. Or ask welcome questions like the name of the interviewee before questions about the product. Do not go back and forth among topics. Finish off a topic before moving on to a new one. However it sometimes may be necessary to clear previous topics up.
Communication skills
[edit]Effective communication is crucial for analysts during customer interviews to ensure a shared understanding. The analyst must put in extra effort to bridge the semantic gap and draw out the customer's tacit knowledge. However, effective communication can be a recurring challenge for analysts when dealing with customers and is a common issue in the requirements elicitation process[20].
- Unnatural dialogue style: When talking to interviewees, it's important to speak in a natural manner and let them lead the conversation. Ask questions that will help you understand their thoughts and feelings, without making them feel like they are being interrogated. This will help create a more natural dialogue and give you the chance to really get to know the person.
- Language-related issues: Are you a non-native speaker interviewer? Practice your pronunciation upfront to minimize mistakes and try to speak in a correct and clear way. Native speaker? Try to speak clearly and avoid grammar mistakes.
- Low and unclear tone: Make sure that the interviewee can hear you. Test upfront if you speak with the right volume. Make sure that you speak with the right tone. Speaking with an unclear low tone can be irritating and does not imply that you want to know the information that you are asking.
- Poor listening skills: Always listen carefully to what the interviewee has to say and react to his/her words. An interview is a conversation, not an interrogation.
Analyst behavior
[edit]The way analysts conduct themselves during interviews can affect the customer's perspective and how they respond. In particular, if the analyst displays overconfidence, it can lead to a flawed understanding of the problem area and hinder the analyst's ability to consider alternative or contradictory information[21].
- Confidence: Lack of confidence. Do not underestimate yourself and do not let the interviewee give the idea that you will do a bad job. Overconfidence and arrogance. It is an interview where you try to retrieve information from the project stakeholders you work for. Do not act like you have all the answers already.
- Passive attitude: Always make sure you participate actively in the conversation by reacting properly to answers. Be the lead in the interview.
- Unprofessional behavior: Always stay professional. It may happen that you create a relationship with your stakeholder over a longer period of time. However it is important to keep in mind that a requirements elicitation interview is a work task. Being professional helps to keep you focused and gets you the most from the interview.
Interaction with the interviewee
[edit]The effectiveness of an interview depends greatly on the interaction between the analyst and customer. It falls on the analyst to establish a welcoming atmosphere that encourages open communication with the customer[22][23][24].
- Common mistakes: Not creating rapport. It is good to start with small talk to get to know the interviewee. Understand how the interviewee is feeling. Create a bond and show that you are a nice person. Do not influence the interviewee with your own thoughts and opinions.
Planning
[edit]Not having a planned choreopraphy of task divisions for taking notes and asking questions while conducting the interview are mistakes made during design and execution of the interview. This can result in gathering the wrong requirements[25].
- Common pitfalls: Poor time management, e.g., too fast or too slow. Lack of preparation on the domain. Lack of interview planning. Long pauses during the interview.
See also
[edit]In research:
- Interview (research)
- Structured interview
- Unstructured interview
- Qualitative research interview
- User research
- Functional requirement
- Non-functional requirement
- Requirements analysis
- Requirements Elicitation
- Requirement prioritization
References
[edit]- ^ a b c Bano, Muneera; Bano, Muneera; Zowghi, Didar; Ferrari, Alessio; Spoletini, Paola; Donati, Beatrice (2018). "Learning from Mistakes: An Empirical Study of Elicitation Interviews Performed by Novices". 2018 IEEE 26th International Requirements Engineering Conference (RE). Banff, AB: IEEE: 182–193. doi:10.1109/RE.2018.00027. ISBN 978-1-5386-7418-5.
- ^ Sutcliffe, Alistair; Sawyer, Pete (2013). "Requirements elicitation: Towards the unknown unknowns". 2013 21st IEEE International Requirements Engineering Conference (RE). IEEE. doi:10.1109/re.2013.6636709.
- ^ a b c d e Ferrari, Alessio; Spoletini, Paola; Gnesi, Stefania (2016-03-26). "Ambiguity and tacit knowledge in requirements elicitation interviews". Requirements Engineering. 21 (3): 333–355. doi:10.1007/s00766-016-0249-3. ISSN 0947-3602.
- ^ Zowghi, Didar; Coulin, Chad, "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools", Engineering and Managing Software Requirements, Berlin/Heidelberg: Springer-Verlag, pp. 19–46, ISBN 3-540-25043-3, retrieved 2023-01-24
- ^ Coulin, Chad; Zowghi, Didar, "Requirements Elicitation for Complex Systems", Requirements Engineering for Sociotechnical Systems, IGI Global, pp. 27–52, retrieved 2023-01-24
- ^ "McGraw-Hill Companiese". Lexikon des gesamten Buchwesens Online. Retrieved 2023-01-13.
- ^ Slade, Sam; Sergent, Shane R. (2022), "Interview Techniques", StatPearls, Treasure Island (FL): StatPearls Publishing, PMID 30252339, retrieved 2023-01-13
- ^ Dhillon, Jaspaljeet Singh; Ramos, Czarina; Wünsche, Burkhard C.; Lutteroth, Christof (2011). "Designing a web-based telehealth system for elderly people: An interview study in New Zealand". 2011 24th International Symposium on Computer-Based Medical Systems (CBMS): 1–6. doi:10.1109/CBMS.2011.5999157.
- ^ Luck, Rachael (2007). "Learning to talk to users in participatory design situations". Design Studies. 28 (3): 217–242. doi:10.1016/j.destud.2007.02.002. ISSN 0142-694X.
- ^ a b Scheinholtz, Lauri Ann; Wilmont, Ilona (2011), "Interview Patterns for Requirements Elicitation", Requirements Engineering: Foundation for Software Quality, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 72–77, ISBN 978-3-642-19857-1, retrieved 2023-01-13
- ^ Nuseibeh, Bashar; Easterbrook, Steve (2000). "Requirements engineering". Proceedings of the Conference on The Future of Software Engineering. New York, NY, USA: ACM. doi:10.1145/336512.336523.
- ^ Firesmith, Donald (2003). "Specifying Good Requirements". The Journal of Object Technology. 2 (4): 77. doi:10.5381/jot.2003.2.4.c7. ISSN 1660-1769.
- ^ Dekker, S.W.A.; Nyce, J.M.; Hoffman, R.R. (2003). "From contextual inquiry to designable futures: what do we need to get there?". IEEE Intelligent Systems. 18 (2): 74–77. doi:10.1109/mis.2003.1193660. ISSN 1541-1672.
- ^ Yeong, May Luu; Ismail, Rosnah; Ismail, Noor Hassim; Hamzah, Mohd. Isa (2018-11-10). "Interview Protocol Refinement: Fine-Tuning Qualitative Research Interview Questions for Multi-Racial Populations in Malaysia". The Qualitative Report. doi:10.46743/2160-3715/2018.3412. ISSN 2160-3715.
- ^ a b Rosenthal, Stephen R.; Capper, Mark (2006). "Ethnographies in the Front End: Designing for Enhanced Customer Experiences*". Journal of Product Innovation Management. 23 (3): 215–237. doi:10.1111/j.1540-5885.2006.00195.x. ISSN 0737-6782.
- ^ Donoghue, S (2010-03-15). "Projective techniques in consumer research". Journal of Family Ecology and Consumer Sciences /Tydskrif vir Gesinsekologie en Verbruikerswetenskappe. 28 (1). doi:10.4314/jfecs.v28i1.52784. ISSN 0378-5254.
- ^ Leifer, Richard; Lee, Sunro; Durgee, Jeffrey (1994). "Deep structures: Real information requirements determination". Information & Management. 27 (5): 275–285. doi:10.1016/0378-7206(94)90022-1. ISSN 0378-7206.
- ^ Donati, Beatrice; Ferrari, Alessio; Spoletini, Paola; Gnesi, Stefania (2017), "Common Mistakes of Student Analysts in Requirements Elicitation Interviews", Requirements Engineering: Foundation for Software Quality, Cham: Springer International Publishing, pp. 148–164, ISBN 978-3-319-54044-3, retrieved 2023-01-24
- ^ Pacheco, Carla; Garcia, Ivan (2012). "A systematic literature review of stakeholder identification methods in requirements elicitation". Journal of Systems and Software. 85 (9): 2171–2181. doi:10.1016/j.jss.2012.04.075. ISSN 0164-1212. Retrieved January 24, 2023.
- ^ Saiedian, H; Dale, R (April 2000). "Requirements engineering: making the connection between the software developer and customer". Information and Software Technology. 42 (6): 419–428. doi:10.1016/s0950-5849(99)00101-9. ISSN 0950-5849.
- ^ Pitts, Mitzi G; Browne, Glenn J (January 2007). "Improving requirements elicitation: an empirical investigation of procedural prompts". Information Systems Journal. 17 (1): 89–110. doi:10.1111/j.1365-2575.2006.00240.x. ISSN 1350-1917.
- ^ "Question Generation and the Systems Analysis Process", Questions and Information Systems, Psychology Press, pp. 57–72, 2013-04-15, ISBN 978-0-203-76314-8, retrieved 2023-01-24
- ^ Coughlan, Jane; Lycett, Mark; Macredie, Robert D. (June 2003). "Communication issues in requirements elicitation: a content analysis of stakeholder experiences". Information and Software Technology. 45 (8): 525–537. doi:10.1016/s0950-5849(03)00032-6. ISSN 0950-5849.
- ^ Gallivan, Michael J.; Keil, Mark (January 2003). "The user-developer communication process: a critical case study". Information Systems Journal. 13 (1): 37–68. doi:10.1046/j.1365-2575.2003.00138.x. ISSN 1350-1917.
- ^ Gallivan, Michael J.; Keil, Mark (January 2003). "The user-developer communication process: a critical case study". Information Systems Journal. 13 (1): 37–68. doi:10.1046/j.1365-2575.2003.00138.x. ISSN 1350-1917.