🌰

Papers in a nutshell

This page contains the key aspects of the literature recommend in class. It is by no means complete, but helps with an evidence-best selection of a requirements elication technique.

Key takeaways
If a key phrase is taken from Hickey and Davis (2003) its marked with (1) and for Zowghi and Coulin (2005) with (2).
Method (optional explanation)
When to use? When not?
Collaborative Sessions / Brain storming
When dealing with a large autonomous set of stakeholders (1) Needed if interview or observation would just deliver knowledge about the current system (1) Used to develop a preliminary mission statement for the project and target system (2) It promotes freethinking and expression of innovative solutions (2)
Group work
Groups involve and commit stakeholders directly and promote cooperation (2) Group work might be hard to organize (2) Requires expertise and experience to ensure that some personalities do not dominate the discussion. The composition and cohesion within the group is key (2) Not well suited in highly political situations, as participants cannot speak freely (2)
Joint Application Development (Investigate problem and possible solutions in a discussion)
Like brainstorming, but main goals of the system are already established (2) Decisions can be made rapidly and issued be resolved quickly (2)
Introspection (analyst develops requirements based on what he believes stakeholders want or need)
Starting point for other elicitation techniques. Should be used alongside other techniques like interviews (2) Only effective if analyst is familiar with the domain, the goals, and the business processes (2)
Interview
Gather initial background information when working on new projects (1) When dealing with politics (1) When conflicts among stakeholders are present (1) When users or customers are inaccessible, interviews with visionaries can be used (1) Good to collect large amounts of data quickly (2) Usefulness of interviews is highly dependent on the skills of the interviewer (2) Use open interviews, if there is a limited understanding of the domain as a precursor to more focused, structured interviews (2) Structure interviews are rigorous and effective, but limit the investigation of new ideas (2)
Questionaires
Apply when problem is concrete (1) Market research surveys help to understand external customer needs (1) Provide an efficient way to collect information from multiple stakeholders quickly, but are limited in the depth of knowledge (2) Useful as informal checklists to ensure fundamental elements are addressed early on (2) Questionnaires lack the opportunity to delve further on a topic or expand new ideas. There is no mechanism for participants to clarify or correct misunderstandings (2)
Teambuilding
Support for other elicitation techniques through mutual trust (1)
Ethnography (Observation of users in their natural setting) / Observation
Good if, users are very busy (1) Good if users and old system is available (1) Asses political and power relationships in a new organization (1) Good for collaborative work settings, where several users interact or to study contextual factors like usability. Social patterns and complex relationships of stakeholders can be uncovered (2) Observation is very expensive to perform and requires skill from the analyst to grasp the actions being performed (2) Stakeholders might be tempted to adjust their workflow under observation (2)
Apprenticing (learn task under supervision of experienced user)
Analyst can gain experience in the domain (2) Good if users have difficulties explaining their actions (2)
Protocol Analysis (stakeholder performs task and talks it through aloud)
Can provide additional insights on the process itself and its rationale (2) The execution of the task is altered and thus deviate from the true process. Infrequent / trivial steps might not be explained by the user, as they are taken for granted (2)
Issue List (maintain a list of outstanding issues)
Enables the team to stay focus and not get distracted of new issues (1)
Models e.g., flow diagrams, state charts etc.
Model drafts on a white board help the thought process (1) Employ multiple models to better understand the customer’s problem (1) Useful if customers or users are available (1) Commonly used for communication, uncovering missing information, organizing information from other techniques or to uncover inconsistencies (1)
Old systems
Good if a new system replaces an existing one (1) (2) Do not overemphasize the old system (1) Good to capture domain knowledge, identify reusable concepts and components (2) Domain knowledge in the form of detailed descriptions can be gathered and can serve as a basis for other elicitation techniques (2) Reuse old requirement specifications and validate new requirements against other domain instances (2)
Requirements Categorization
Good to distinguish between needs and all wants of stakeholders (1) Good to draw the system boundary (1)
Conflict awareness and resolution
Good to understand the power structure, the politics, and the political camps (1)
Prototyping
Only do rapid prototyping if it can be done rapidly (1) Apply only if there is mutual trust (1) Useful if users are unfamiliar with the available solutions or for projects that involve human-computer interaction (2) Users play an active role in developing the requirement (2) Very costly in terms of time and money. Users might become attached to prototypes and thus refuse alternatives (2)
Formal methods
Useful in later stages of the system development (1)
Extreme Programming (long omni-present customer instead of explicit requirement elicitation)
Good if domain undergoes an enormous and constant flux (1)
Task analysis (decompose tasks into subtasks until you end up with concrete actions and events)
Task analysis provides information on the interaction of both the user and the system and determine the knowledge used or required to carry them out. Task analysis provides insights on the user-system-interaction as well as contextual description of the activities that take place (2)
Goal Based approaches ( decompose the system into subgoals until individual requirements are elicited)
The process is more complicated and concrete than traditional methods than traditional tree-structure diagram (2) Can reveal detailed relationships between the domain entities, requirements, and objectives of the system (2)
Repertory Grids ( asking stakeholders to develop attributes and assign values to the matrix entries)
Good to identify and represent the similarities and differences between different domain entities (2) Only useful when eliciting requirements from experts, who are familiar with the level of abstraction (2)
Card Sorting (sort a series of cards with domain entities into groups. Stakeholders must reason about their sorting)
Domain must be sufficiently understood by both the analyst and participant (2)
Laddering ( stakeholders are asked a series of prompting questions and must arrange the answers into a structure)
Stakeholders are forced to express their domain understanding in a logical way (2) It’s used to classify domain entities and clarify requirements (2)
Scenarios (specific description of current and future processes including actions and interactions between users and the system)
Useful for understanding and validating requirements and for the development of test cases (2)
Viewpoints (model domain from different perspectives e. g., operation implementation and interfaces)
Useful if system entities have detailed and complicated relationships with each other (2) Good for organizing and prioritizing requirements (2) It’s difficult to represent non-functional requirements easily and require a high effort (2)
Decision matrices
Adapted from Zowghi and Coulin (2005)
​
Adapted from Zowghi and Coulin (2005). C= approach that can be used in cooperation and A = alternative to approach.
Sources
Hickey, A. M., & Davis, A. M. (2003). Elicitation technique selection: How do experts do it? Journal of Lightwave Technology, 169–178. https://doi.org/10.1109/ICRE.2003.1232748​
Zowghi, D., & Coulin, C. (2005). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. In A. Aurum & C. Wohlin (Eds.), Engineering and Managing Software Requirements (pp. 19–46). Springer-Verlag. https://doi.org/10.1007/3-540-28244-0_2​

Method (optional explanation)	When to use? When not?
Collaborative Sessions / Brain storming	When dealing with a large autonomous set of stakeholders (1) Needed if interview or observation would just deliver knowledge about the current system (1) Used to develop a preliminary mission statement for the project and target system (2) It promotes freethinking and expression of innovative solutions (2)
Group work	Groups involve and commit stakeholders directly and promote cooperation (2) Group work might be hard to organize (2) Requires expertise and experience to ensure that some personalities do not dominate the discussion. The composition and cohesion within the group is key (2) Not well suited in highly political situations, as participants cannot speak freely (2)
Joint Application Development (Investigate problem and possible solutions in a discussion)	Like brainstorming, but main goals of the system are already established (2) Decisions can be made rapidly and issued be resolved quickly (2)
Introspection (analyst develops requirements based on what he believes stakeholders want or need)	Starting point for other elicitation techniques. Should be used alongside other techniques like interviews (2) Only effective if analyst is familiar with the domain, the goals, and the business processes (2)
Interview	Gather initial background information when working on new projects (1) When dealing with politics (1) When conflicts among stakeholders are present (1) When users or customers are inaccessible, interviews with visionaries can be used (1) Good to collect large amounts of data quickly (2) Usefulness of interviews is highly dependent on the skills of the interviewer (2) Use open interviews, if there is a limited understanding of the domain as a precursor to more focused, structured interviews (2) Structure interviews are rigorous and effective, but limit the investigation of new ideas (2)
Questionaires	Apply when problem is concrete (1) Market research surveys help to understand external customer needs (1) Provide an efficient way to collect information from multiple stakeholders quickly, but are limited in the depth of knowledge (2) Useful as informal checklists to ensure fundamental elements are addressed early on (2) Questionnaires lack the opportunity to delve further on a topic or expand new ideas. There is no mechanism for participants to clarify or correct misunderstandings (2)
Teambuilding	Support for other elicitation techniques through mutual trust (1)
Ethnography (Observation of users in their natural setting) / Observation	Good if, users are very busy (1) Good if users and old system is available (1) Asses political and power relationships in a new organization (1) Good for collaborative work settings, where several users interact or to study contextual factors like usability. Social patterns and complex relationships of stakeholders can be uncovered (2) Observation is very expensive to perform and requires skill from the analyst to grasp the actions being performed (2) Stakeholders might be tempted to adjust their workflow under observation (2)
Apprenticing (learn task under supervision of experienced user)	Analyst can gain experience in the domain (2) Good if users have difficulties explaining their actions (2)
Protocol Analysis (stakeholder performs task and talks it through aloud)	Can provide additional insights on the process itself and its rationale (2) The execution of the task is altered and thus deviate from the true process. Infrequent / trivial steps might not be explained by the user, as they are taken for granted (2)
Issue List (maintain a list of outstanding issues)	Enables the team to stay focus and not get distracted of new issues (1)
Models e.g., flow diagrams, state charts etc.	Model drafts on a white board help the thought process (1) Employ multiple models to better understand the customer’s problem (1) Useful if customers or users are available (1) Commonly used for communication, uncovering missing information, organizing information from other techniques or to uncover inconsistencies (1)
Old systems	Good if a new system replaces an existing one (1) (2) Do not overemphasize the old system (1) Good to capture domain knowledge, identify reusable concepts and components (2) Domain knowledge in the form of detailed descriptions can be gathered and can serve as a basis for other elicitation techniques (2) Reuse old requirement specifications and validate new requirements against other domain instances (2)
Requirements Categorization	Good to distinguish between needs and all wants of stakeholders (1) Good to draw the system boundary (1)
Conflict awareness and resolution	Good to understand the power structure, the politics, and the political camps (1)
Prototyping	Only do rapid prototyping if it can be done rapidly (1) Apply only if there is mutual trust (1) Useful if users are unfamiliar with the available solutions or for projects that involve human-computer interaction (2) Users play an active role in developing the requirement (2) Very costly in terms of time and money. Users might become attached to prototypes and thus refuse alternatives (2)
Formal methods	Useful in later stages of the system development (1)
Extreme Programming (long omni-present customer instead of explicit requirement elicitation)	Good if domain undergoes an enormous and constant flux (1)
Task analysis (decompose tasks into subtasks until you end up with concrete actions and events)	Task analysis provides information on the interaction of both the user and the system and determine the knowledge used or required to carry them out. Task analysis provides insights on the user-system-interaction as well as contextual description of the activities that take place (2)
Goal Based approaches ( decompose the system into subgoals until individual requirements are elicited)	The process is more complicated and concrete than traditional methods than traditional tree-structure diagram (2) Can reveal detailed relationships between the domain entities, requirements, and objectives of the system (2)
Repertory Grids ( asking stakeholders to develop attributes and assign values to the matrix entries)	Good to identify and represent the similarities and differences between different domain entities (2) Only useful when eliciting requirements from experts, who are familiar with the level of abstraction (2)
Card Sorting (sort a series of cards with domain entities into groups. Stakeholders must reason about their sorting)	Domain must be sufficiently understood by both the analyst and participant (2)
Laddering ( stakeholders are asked a series of prompting questions and must arrange the answers into a structure)	Stakeholders are forced to express their domain understanding in a logical way (2) It’s used to classify domain entities and clarify requirements (2)
Scenarios (specific description of current and future processes including actions and interactions between users and the system)	Useful for understanding and validating requirements and for the development of test cases (2)
Viewpoints (model domain from different perspectives e. g., operation implementation and interfaces)	Useful if system entities have detailed and complicated relationships with each other (2) Good for organizing and prioritizing requirements (2) It’s difficult to represent non-functional requirements easily and require a high effort (2)

Relevante Objekte empfehlen

Next - Internetrecht

Mitschrift

Last modified 5mo ago