Tough Requirements Problems and Proven Solutions The Human Element

1
Tough Requirements ProblemsandProven
SolutionsThe Human Element
Linda Shafer IEEE Computer Society Publications
Board July 12, 2007
2
Software Requirements Problems Involving People
Risks

• Inappropriate skills for requirements
  elicitators and/or gatherers
• Insufficient User Involvement
• Creeping User Requirements
• Ambiguous Requirements
• Gold Plating
• Minimal Specification
• Overlooked User Classes
• Unprioritized Requirements
• Is there a single problem that does not involve
  the human element ?

3
Inappropriate skills for Requirementselicitators/
gathers

• Find analysts that are pretty much like good
  parents, teachers, friends
• Look for basic people skills
• Listening
• Open-mindedness
• Feeling
• Compassion
• A bit right-brained
• Consider looking into the SEI PM-CMM (People
  Management Capability Maturity Model

4
Insufficient Customer Involvement

• Developers
• Try working with users and having as much fun as
  developing -- if you cant, ask management to
  allow you to return to design or coding or
  testing
• Dont think you already know what the customers
  need
• Customers
• Make time to participate
• Dont use a user surrogate determine requirements
• Managers
• Make involvement a priority

5
Creeping User RequirementsRequirements are but
a snapshot in time

• Create a Concept of Operations Document and/or a
  Vision and Scope Document
• Set realistic expectations of the size and
  complexity of requirements
• Have an effective change process expect
  constant modifications Clearly state
• Business objectives
• Strategic vision
• Scope
• Limitations
• Success criteria
• Expected product usage

6
Ambiguous Requirements

• Recognize that individuals will interpret a
  statement in different ways
• Recognize that multiple readers may have
  different understandings of text means
• Beware the use of Red Flag words
• Employ models, figures, tables
• Object Oriented models
• Structured Analysis models

7
Gold Plating

• Dont add excess functionality -- the customer
  wont appreciate it
• Create a traceability matrix and use it

8
Minimal Specification

• See Ambiguous Requirements
• Try to separate the What from the How but
  understand and accept that there will be varying
  degrees of vagueness and detail

9
Overlooked User Classes

• Look for
• Different subsets of use
• Different frequencies of use
• Varying experience levels
• Prototype
• See Ambiguous Requirements

10
Unprioritized Requirements

• Triage -- what to include in the first place
• Expect the inevitable Changes
• Together, with the customer,determine the Value,
  Cost, Risk
• Dont bow to the loudest voice political power
• Create a scale for feature set (version)
  implementation -- at least High, Medium, Low)
• Accommodate stakeholders having conflicting ideas
  about relative importance

11

• Thank You !!
• And
• Alan Davis
• Karl Wiegers
• Tom DeMarco
• And, we didnt even talk about the human
• element vis á vis Project Management,
• high quality