Requirements Engineering and Management INFO 627

1
Requirements Engineeringand ManagementINFO 627

• Understanding User Needs
• Glenn Booker

2
Extracting Requirements

• Three common syndromes often make finding
  requirements difficult
• Yes, But
• Undiscovered Ruins
• User and the Developer
• Many of the techniques well use are specifically
  to prevent these syndromes

3
Yes, But Syndrome

• Two reactions are common when a user sees the new
  system for the first time
• This is great (and other compliments)
• Yes, but what if it did this too? Or What
  about this idea? Or Wouldnt it be nice if?
  Or Whatever happened to?
• The latter are based on the system not being what
  they expected

4
Yes, But Syndrome

• Some Yes, But may prove very useful while
  others may need excessive changes to the scope
  of the system
• Avoid this by making sure the user sees early
  prototypes of the system, so they have clear
  expectations of what they will be getting

5
Undiscovered Ruins Syndrome

• Tourist So, how many undiscovered ruins are
  there?
• The more requirements are found, the more remain
  to be discovered
• Indeed, requirements are often never fully
  complete
• Identifying all stakeholders helps find many
  undiscovered ruins

6
User and the Developer Syndrome

• Users and developers speak different languages,
  producing a communication gap
• To avoid this
• Developer should learn and use the users
  terminology
• Try different ways to discover requirements
• Try seeing the users perspective literally,
  if need be

7
Fishing for Requirements

• Well eventually discuss seven techniques for
  eliciting (discovering) requirements
• Interviewing and questionnaires
• Requirements workshops
• Brainstorming and idea reduction
• Storyboards
• Use cases
• Role playing
• Prototyping

8
System Features

• The development team must be active in order to
  find requirements
• Listen for phrases which hint at requirements,
  and see if that is their intent
• Ask Do you want to add that as a requirement?
  or otherwise assess the ideas importance
• Start with identifying needs

9
Stakeholder and User Needs

• The top of our pyramid, the needs to be met by
  the system are a possible starting point
• Often the needs are expressed by a key problem
  the system should solve what will fix the
  situation
• Some users will express features how the need
  can be addressed

10
Features

• Features describe what kind of functionality
  should meet the need
• A feature is a service provided by the system to
  meet some need
• Should try to abstract the underlying need to
  understand why the feature will be helpful
• A need does not describe anything about the
  system itself a feature does

11
Which is Which?

• In the heat of meeting with a user, it isnt
  critical to identify immediately whether
  something is a need or a feature
• May help to capture the ideas, and sort them out
  later (brainstorming)
• For examples of features, see any software ad!

12
How Many Needs and Features?

• Needs are fairly few maybe ten or less
• Features are about an order of magnitude more
  common maybe 25-100 features (book prefers
  under 50), depending on the size of the system
• See Table 8-1 for examples (p. 90)
• Features are handy for scope discussions

13
Features vs. Requirements

• Features will be fleshed out in more detail to
  provide detailed requirements later on
• Priorities can be tentatively decided at the
  features level
• Defer to later, Implement now, Investigate
  further, etc.
• Describe desired features to help manage them
  more easily

14
Attributes of Features

• Common attributes for tracking features are
• Status, such as proposed, approved, rejected
• Priority, such as high, medium, or low
• Effort, to rank how much effort is needed to
  implement feature again high, medium, low
• Risk, to identify how challenging that feature is
  to implement

15
Attributes of Features

• Stability to identify how likely that feature is
  to change, or how likely the means to implement
  the feature will change
• Target release related to priority, what version
  of the system will implement this feature?
• Assigned to identifies the lead person for
  analysis or implementation of this feature
• Reason or Source where did this feature come
  from? Good for traceability later on

16
Interviewing

• Interviewing appears simple, and is quite direct,
  but developing the right questions can be
  challenging
• Want to avoid bias and assumptions in the
  questions
• For related ideas, look up police interrogation
  techniques we arent that intense, but some
  concepts apply here too

17
Interviewing

• Previous experience with related systems can
  hinder interviewing produces preconceived ideas
  of what will be said
• Make sure your knowledge of the problems context
  doesnt interfere with discovery of this clients
  problem
• Want to ask context-free questions

18
Context-free Questions

• Key is to ask about the users problem, without
  biasing the type of solution
• Who is the user?
• Who is the customer?
• What are their needs?
• What other ways can a solution be found?
• Some sales techniques can also help

19
Value-added Context

• After the problem is clearly understood, we can
  pursue possible types of solutions
• After all, our job is to fix the problem
• Identify what they think the solution might be
  sometimes they know best!
• Hence the entire interview often starts
  context-free, then adds focus on solutions

20
How to Interview

• Prepare specific context-free and context-related
  questions in advance, but be prepared to digress
  if its meaningful
• Research the person and organization to be
  interviewed
• Take notes manually during the interview
• Verify key points occasionally

21
What to Ask?
1E p. 96-98

• Typical structure for an interview may contain
  elements like these
• Establish profile verify who they are, what they
  do, what they produce, and what determines
  whether theyre successful
• Assessing the problem what problems remain
  unresolved? Why do they exist? How do you deal
  with it now? How do you think it should be solved?

22
What to Ask?

• Understand User Environment who uses the
  existing system? What are their educational and
  computer backgrounds? What platforms are in use?
  What other applications work with it?
• Recap the Problem make sure you understand the
  problem and its environment any other problems
  missed?

23
What to Ask?

• Analysts Input on Problem suggest other areas
  that might be troublesome, and see if theyre
  actual problems in this case
• Assess Solution summarize your proposed
  solutions key features and benefits, ask which
  ones are attractive
• Assess Opportunity how many people need this
  solution? How valuable would it be?

24
What to Ask?

• Assess Non-feature Needs ask about expectations
  for the ilities, performance, security,
  installation, support, and other kinds of
  non-features
• Other Requirements are they aware of any other
  legal, regulatory, environmental, or other
  constraints or standards
• Wrap Up ask for other questions, and if you can
  follow up with them if needed

25
What to Ask?

• Analysts Summary right after the interview is
  over, write down the three biggest needs or
  problems faced
• Do NOT have to use all these types of questions
  tailor the interview as needed
• If they start babbling about the problems they
  face, take notes quickly!

26
Compiling Data

• After a few interviews, the picture should become
  fairly clear
• Start identifying needs expressed by them
• Look for themes or common threads
• Tentatively sort them by priority

27
Questionnaires

• Questionnaires generally dont work in place of
  interviews, at least for requirements gathering
• Can identify some basic needs (profile, envir.)
• Cant explore interesting ideas or tangents
• Hard to follow up on, or clarify responses
• Missing interactive information from seeing
  people in person tone, body language, etc.

28
Requirements Workshops

• Often the best single requirements gathering
  technique
• Encourage rapid consensus (beware of the c
  word!)
• Gather stakeholders for a short, focused time to
  agree on key requirements
• See also JAD session discussions here too

29
Requirements Workshops

• Helps to have impartial, trained, outside
  facilitator
• Helps build the team, and achieve buy-in on
  project objectives
• Preparation for the workshop is critical
• Need the right people there representatives
  from key technical business areas

30
Requirements Workshops

• Need to have a location removed from everyday
  activities (distractions)
• Ensure working environment is good
• Send people materials to prepare in advance
• Encourage both context-specific and creative
  thinking
• Try to put aside previous bad patterns set
  expectations high for a fresh start

31
Requirements Workshops

• Facilitator should have been trained to lead such
  workshops, have excellent team building skills,
  be objective, and be strong enough to lead the
  workshop effectively
• Define the agenda (1E p. 108), which will include
  free idea generation (brainstorming), then
  consolidate the ideas

32
Requirements Workshops

• People generally already know each other, so
  icebreaker activities often not needed
• Helps to have ideas for defusing the situation
  (can get tense!) and yet keeping people focused
• Can help to have someone who can draw ideas
  between sessions

33
Requirements Workshops

• Make sure to capture minutes from sessions, and
  clearly document final decisions
• Identify areas which need follow-up (action
  items) make sure you know what will be done,
  who will do it, and when its due