Requirements Engineering Process & Requirements Elicitation

Question 1

requirements sepcification

Answer 1

elicitation
analysis
documentation
validation

Question 2

requirements managament

Answer 2

prioritisation
change and release management
traceability

Question 3

Characteristics of an “ideal” RE process

Answer 3

• strongly interactive
• close and intensive collaboration between
  
  • stakeholders (know the domain and the problem)
  • requirements engineers (know how to specify)
• very short feedback cycles
• risk-aware and feasibility-aware
  
  • technical risks/feasibility
  • deadline risks/feasibility
• careful negotiation / resolution of conflicting requirements
• focus on establishing shared understanding
• strives for innovation

Question 4

requirements elicitation

Answer 4

the process of seeking, capturing and consolidating requirements from available sources

• determine the stakeholders’ desires and needs
• elicit information from all available sources and consolidate it into well-documented requirements
• all while remembering to:
  
  • make stakeholders happy, not just satisfy them
  • work value-oriented and risk-driven

Question 5

Stakeholder analysis

Answer 5

identify them
classify them
determine concrete people

Question 6

Artefact based elicitation

Answer 6

background studies
questionares
prototypes and mockups
user feedback

Question 7

stakolder-driven elicitation

Answer 7

interview
observation
group session/workshop

Question 8

background studies

Answer 8

• Collect, read, summarise documents about:
  
  • the organization: organizational charts, business plans, financial reports, meeting minutes, etc.
  • the domain: books, surveys, articles, regulations, reports on similar systems in the same domain
  • the system-as-is: documented workflows, procedures, business rules; exchanged documents; defect/complaint reports, change requests, etc.
• Goal: get the basics and prepare before meeting stakeholders => prerequisite for other techniques
• Data mining problem: huge documentation, irrelevant details, outdated information

Question 9

questionares

Answer 9

• Effective for acquiring subjective info quickly, cheaply, remotely from many people
• Helpful for preparing better focused interviews
• List of questions to selected stakeholders, each with a list of possible answers
  
  • Multiple choice question: answer(s) to be selected
    from answer list
  • Weighting question: list of statements to be weighted qualitatively (‘high’, ‘low’, …), or quantitatively (percentages)
  • Open question: users give free text as answers, a
    manual analysis is needed later. Can be time intensive!
• Before questions include a brief context of the questionnaire & privacy statement!
• Make sure you use inclusive language and to have accessible size fonts and colours
• Formulating well-designed surveys can be tricky!
• Make sure you have several trial runs before distributing!

Question 10

storyboards

Answer 10

• Storyboards show the setting of your software product, e.g.
  
  • Who are the people involved?
  • What’s the environment?
  • What problem is your software product solving?
• How does the software product solve it? The last one usually
  shows the user being happy with the product
• Tells a story by a sequence of snapshots
  
  • Snapshot = sentence, sketch, picture, etc.
  • Sometimes structured with annotations:
    WHO are the characters, WHAT happens to them, WHY this happens, WHAT IF this does / does not happen, etc.
• Goal: make sure that all stakeholders are on the main page with regard to the product vision and main use case scenarios
• Passive mode (for validation): stakeholders are told the story
• Active mode (for joint exploration): stakeholders contribute to the story

Question 11

Prototypes & Mockups

Answer 11

• Goal: check requirements adequacy from direct user feedback, by showing reduced sketch of software-to-be in action
  
  • focus on unclear, hard-to-formulate requirements to elicit further
• Quick implementation: by use of paper, very high-level programming language, executable specification language, or generic services

Question 12

prototype

Answer 12

paper based
- Light weight
- Easy to make: matter of minutes!
- Print-out available widgets/phone templates
- No need perfect pictures, rough ideas are enough
- Mix levels of details

Question 13

mockups

Answer 13

• Done in digital form
• Two types:
  
  • Disposable: thrown away (product = adequate requirements)
  • Evolutionary: transformed towards efficient code
• Higher fidelity than prototypes
• Many available tools: Photoshop, Mockingbird, Omnigraffle, PowerPoint

Question 14

interview

Answer 14

• often used technique for elicitation
• Steps:
  
  1. Select stakeholder specifically for information to be acquired
     (domain expert, manager, salesperson, end-user, consultant,
     etc.)
  2. Prepare interview questions (in case of structured interviews)
  3. Organise meeting with interviewee, ask questions, record answers (with explicit permission!)
  4. Write report from interview transcripts
  5. Submit report to interviewee for validation & refinement
• Single interview may involve multiple stakeholders
  
  • Pro: saves times
  • Con: weaker contact; individuals less involved, speak less freely

Question 15

types of interview

Answer 15

structured
unstructured
semi-structured

Question 16

Interviews: pros & cons

Answer 16

+ May reveal info not acquired through other techniques how things are running really, personal complaints, suggestions for improvement

+ On-the-fly acquisition of information appearing
relevant (new questions triggered from previous answers)

– Acquired information might be subjective (hard to
assess)
– Potential inconsistencies between different
interviewees
– Effectiveness critically relies on interviewer’s attitude,
appropriateness of questions

Question 17

observation

Answer 17

• Focus on task elicitation in the system-as-is
• Understanding a task is often easier by observing people performing it (rather than verbal or textual explanation)
• Passive observation: no interference with performers
  
  • Protocol analysis: task performers concurrently explain what they are doing
  • Ethnographic studies: over long periods of time, try to
    discover emergent properties of social group involved
• Active observation: you get involved in the task,
  even become a team member

Question 18

observation +/-

Answer 18

+ May reveal

• tacit knowledge that would not emerge otherwise
• hidden problems through tricky ways of doing things
• culture-specific aspects to be taken into account

+ Contextualisation of acquired information

• Slow & expensive: to be done over long periods of time, at different times, under different workload conditions
• Potentially inaccurate (people behave differently when observed)
• Focus on system-as-is

Question 19

Workshops

Answer 19

• More perception, judgement, invention from interactions within group of diverse people
• Elicitation takes place in series of group gatherings (a few days each) + follow-up actions
• Structured workshops:
  
  • Each participant has a clear role (moderator, manager, developer, …)
  • Contributes to requirement elaboration according to their role, towards reaching synergies
  • Generally focused on high-level requirements (goal and vision)
• Unstructured workshops (brainstorming): Participants have a less clearly defined role. Two separate stages:
  
  1. Idea generation to address a problem:
     
     • as many ideas as possible from each participant
     • without censorship/criticism
  2. Idea evaluation:
     
     • by all participants together
     • according to agreed criteria (e.g. value, cost, feasibility)
     • to prioritise ideas

Question 20

Workshops +/-

Answer 20

+ Less formal interactions than interviews may reveal hidden aspects of the system

+ Potentially wider exploration of issues and ideas, more inventive ways of addressing problems

+ Synergies of agreed conflict resolutions

-Group composition is critical
- time consuming for key, busy people
- heavily relying on leader expertise & skills
- group dynamics, dominant persons => biases, inadequacies

-Risk of:
- missing focus & structure: rambling discussions, little concrete outcome, waste of time
- superficial coverage of more technical issues

Question 21

Typical problems in requirements elicitation

Answer 21

• Inconsistencies among stakeholders in
  
  • needs and expectations
  • terminology
• Stakeholders who know their needs, but can’t express them
• Stakeholders who don’t know their needs
• Stakeholders with a hidden agenda
• Stakeholders thinking in solutions instead of problems
• Stakeholders frequently neglect attributes and constraints ⇒ Elicit them explicitly