Requirements: The Old Way and the New Way

1,558 views
1,441 views

Published on

In this webinar, John Parker will discuss how methods used to define and manage requirements need to change whether Agile or waterfall development is used. He will address the following topics.
- The Difference between Business, Stakeholder and Solution Requirements
- Requirements: One time or Incremental delivery
- Requirements Review and Validation: One Time or Continuous
- Requirements Documentation: Paper Documents or Electronic
- Elicitation: Interviews or Stakeholder Collaboration
- What is Requirements and What is Design
- How Better Discovery Practices can Improve Agile

Download the recording here: http://bit.ly/1q4UBo4

Published in: Software

Requirements: The Old Way and the New Way

  1. 1. 0© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Title Here Requirements: The Old Way and The New Way
  2. 2. 1© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. John E. Parker •  Chief Visionary Officer of Enfocus Solutions Inc. •  Previous Positions o  President and CEO of Enfocus Solutions Inc. inception through February 2013 o  EVP and Cofounder, Spectrum Consulting Group o  EVP and CTO, MAXIMUS Inc. o  Outsourced CIO for HSHS (Large Healthcare System) o  KPMG Partner •  Expertise o  IT Strategic Planning o  Business Analysis o  Recovering Troubled and Challenged Projects o  Enterprise Architecture o  Development Methodologies (Agile, Waterfall, RUP, Design First, FDD, TDD) o  Financial and Cost Benefit Analyses o  Business Process Improvement, Reengineering, and Management Contact: •  http://enfocussolutions.com •  info@enfocussolutions.com
  3. 3. 2© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirement Trends (2014 and Beyond) 1.  Agile adoption will continue to grow at a fast pace and will significantly change the way requirements are developed and managed. 2.  User Stories will become the de facto standard for solution requirements. 3.  Paper requirement documents will be relics of the past; requirements will be maintained electronically in backlogs. 4.  Personas will be developed and maintained and used for developing user stories and for gaining a better understanding of user needs and what is required for faster user adoption. 5.  Solution scope will be defined using Features and will be monitored by EPMOs. Features will drive agile development, and be integral to portfolio management, business architecture and release planning. 6.  More efficient and effective validation methods will be used to ensure the right product is being built and to reduce waste. 7.  User stories will be developed collaboratively by Product Owners and the Teams. Traditional requirements analysts will go away.
  4. 4. 3© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirement Trends (Continued) 8.  Development of requirements will be defined collaboratively instead of using traditional interviewing techniques that are used today. 9.  More emphasis will be placed on Discovery. This will become key for driving agile development 10.  Better techniques will be employed to align projects with business strategy and deliver better business outcomes. 11.  Discovery will address what needs to change to address the business need or problem (Impacts) . 12.  Lean Startup Concepts such as Minimal Viable Product will be used to validate assumptions, concepts, and ideas. Validating ideas through code will become too expensive and cause too many delays. 13.  Requirements and Design processes will merge. Business process models (BPMN) and Prototyping will become widely used as visualization aids for documenting Features which will drive user stories. 14.  Review and approval of requirements will be done electronically by stakeholders.. 15.  More emphasis will be placed on Transition Requirements as the BAs role focuses more on enabling business change instead of writing solution requirements.
  5. 5. 4© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirement Trends (Continued) 16.  More emphasis will be placed on Business and Stakeholder requirements. 17.  The role of the Business Analyst will change significantly from what it is today. The Business Analyst of tomorrow will be much more focused on enabling Business Change instead of writing solution requirements. The Business Analyst will focus much more on the core concepts of the BACCM. Analysts that have been focused on writing solution requirements will no longer be needed and will go away. Business Analysis skills are needed more than ever. 18.  PMI will place much more emphasis on requirements and will likely offer a certification in Requirements Management and and add Requirements Management as a knowledge area. IIBA will focus much more on enabling business change when BABOK V3 is released this year. There will continue to be tension between the two professional organizations. 19.  Agile Delivery tools will continue to grow. Five vendors will continue to dominate this market (JIRA, Version One, Rally, IBM, and Microsoft). 20.  A new breed of tools such as Enfocus Requirements Suite™ will emerge for Agile Discovery which will focus on discovery and validation of features that deliver business value. 21.  Organizations that have a strong product discovery capability will have a significant competitive advantage over organizations that do not.
  6. 6. 5© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Business Analysis Core Concept Model Core  Concept   Defini-on   Change   a  controlled  transforma.on  of   an  organiza.on   Need   a  problem,  opportunity  or   constraint  with  poten.al   value  to  a  stakeholder   Solu-on   a  specific  way  of  sa.sfying  a   need  in  a  context     Value   the  importance  of  something   to  a  stakeholder  in  a  context   Stakeholder   a  group  or  individual  with  a   rela.onship  to  the  change  or   the  solu1on   Context   the  part  of  the  environment   that  encompasses  the  change  
  7. 7. 6© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Enabling     Business  Change  
  8. 8. 7© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Agile  Adop-on  and  a  Message  to  BAs  
  9. 9. 8© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Agile Adoption •  Data from Forrester's Q3 2013 Global Agile Software Application Development Online Survey indicates that a whopping 90% of all teams practicing Agile development have adopted Scrum. •  The 2013 VersionOne Agile Survey shows that 88% of organizations are now practicing some form of Agile development •  The 2013 VersionOne Agile Survey shows that over half (52%) are using Agile to manage the majority of their projects.
  10. 10. 9© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. © 2013 Forrester Research, Inc. Reproduction Prohibited 1.  Improved  quality  (56%)   2.  More  opportuni.es  for  mid-­‐course   correc.ons  (56%)   3.  Overall  improved  customer  and  business   sa.sfac.on  (38%)   4.  BeLer  business-­‐IT  alignment  (37%)   5.  Improved  .me  to  market  (32%)     Agile: Top 5 Reported Benefits
  11. 11. 10© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Agile  is  an  effec-ve  delivery  process!   However,  agile  is  not  effec-ve  for  discovering   what  to  build.    
  12. 12. 11© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Delivery  Track   Develop  releasable  soQware  based  on  validated  backlog  items.   Dual Track Agile: Emerging Concept Discovery  Track   Discover  business  and  customer  needs  and  generate  validated   product  backlog  items.  
  13. 13. 12© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Why the Discovery Track? •  Elimination of Features with Little or No Value—focuses on validating needs and achieving a good user experience. •  Less Rework—reduces the number of iterations to reduce time and costs. •  Cost Effective Validation—validates ideas in the fastest, least expensive way. •  Better User Experience—validates prototypes instead of coding to validate ideas. Benefits of Discovery: •  Who is the customer? •  What is the customers’ problem? •  Who are the users •  How will the solution help the user in their day to day activities? •  How will solving this problem help our business? •  How will success be measured? Answers the questions: To evaluate market opportunities, reduce new product risk, and put the right things on the product roadmap.
  14. 14. 13© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Discovery   Features  &  Impacts                 Delivery   Stories  &  Tasks                 PPM   Projects   Objec-ves/KPIs   Enterprise   Architecture   DevOps   Builds  &  Releases                 Agile  Tool  Landscape   TFS   •  Configura.on  Management   •  Development  Automa.on   •  Build  Automa.on   •  Code  Repository   •  Con.nuous  Integra.on   •  Monitoring   Automated  Tes-ng   HPQC   TESTCOMPLETE  
  15. 15. 14© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. PorUolio   Management   Discovery   Development   Release  &   Transi-on  Mgmt.   Transforma-on   Must  transi.on  from   managing  tasks  to   managing  value.   Must  transi.on  from   wri.ng  requirements  to   enabling  business  change   Must  transi.on  from   waterfall  to  agile   development   Adopt  and  implement  agile   prac.ces  (DEVOPS)   Primary  Work  Unit   Projects   Impacts   Features   Sprints   Releases   Key  Trend   EPMO  Transforma.on   Dual  Track  Agile   Scrum   Kanban   Devops   Requirements   Business  Requirements   Stakeholder  Requirements   Solu.on  Requirements   (User  Stories)   Transi.on     Requirements   Leadership   &Teams   Por]olio  Manager   Discovery  Manager   Discovery  Team   Product  Owner   Agile  Team   Release  Manager   Release  Team   Success  Measure   Successful   Business  Outcomes   Effec.ve   Business  Change   Valuable   SoQware   Con.nuous   Integra.on   Cultural   Challenges   Integra.ng  Business  and   IT  PMOs  will  be   challenging.  Migra.ng   from  a  task  to  value   mentality  will  require   new  skills  and  training.   Migra.ng  from  managing   project  to  managing   value  streams  will  also  be   difficult.   This  will  be  a  new  concept   for  many  organiza.ons  as   they  move  from  solu.on   requirements  to  enabling   business  change.  BAs  will   need  to  be  retrained  and   develop  new  skills.   Moving  from  waterfall   to  Agile  prac.ces  will   be  difficult  for  many   organiza.ons   Implemen.ng  DEVOPS  will   be  challenging  for   organiza.ons  that  are  use   to  opera.onal  stability  with   few  changes   Agile Organizational Transformation
  16. 16. 15© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. A Troubling Statistic for BAs The 2013 VersionOne Agile Survey shows that product owners are getting more knowledgeable about Agile. Business Analysts have taken their spot at the bottom of the pack. Note to BAs: If you do not start learning Agile, then you better start preparing your resume or planning your retirement. If you plan on continuing writing solution requirements in the way you did in the past, they you are in for a rude awakening.
  17. 17. 16© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Different  Types  of  Requirements  
  18. 18. 17© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. BABOK and PMBOK Requirement Types •  Business requirements, describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken. •  Stakeholder requirements, describe needs of a stakeholder or stakeholder group. •  Solution requirements, describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements: o  Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product. o  Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc. •  Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to- be” state. •  Project requirements, describe the actions, processes, or other conditions the project needs to meet. •  Quality requirements, capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
  19. 19. 18© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Business Requirements Purpose   Business  requirements  are  statements  of  the  business  ra.onale  for  authorizing  the   project.  Business  requirements  include  a  high-­‐level  descrip.on  of  the  soQware   requirements  using  features  that  align  to  business  goals  and  objec.ves.   Documenta-on   Methods   •  Vision   •  Problem  Statement   •  Objec.ves   •  Impacts   •  Feature  Defini.ons   Examples   •  Es.mates  for  Customers   •  Customer  Invoicing   •  Payments  to  Contractors   Documents   Documents  that  contain  business  requirements  may  be  referred  to  as  a  project  charter,   vision  and  scope,  business  case,  marke.ng  requirements,  statement  of  work,  document  of   understanding,  product  vision,  or  project  scope   Audience   The  audience  for  business  requirement  typically  includes  the  project  team  members,  the   business  team  members,  project  sponsors,  and  other  stakeholders  involved  in  the  project.   Project  Risk   Expected  Business  Outcomes  will  not  be  achieved.  
  20. 20. 19© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Stakeholder Requirements Purpose   Stakeholder  Requirements  are  stated  from  the  user's  point  of  view  and  describe  what  is   needed  for  the  user  to  do  his  or  her  job.    (Some.mes  called  User  Requirements)   Documenta-on   Methods   •  Personas   •  Scenarios   •  Use  Cases   •  Needs   •  Business  Process  Models   •  Prototypes   Documents   Documents  that  contain  user  requirements  are  oQen  called  user  requirement  documents,   opera.onal  capabili.es,  concept  of  opera.ons,    use  cases,  or  business  process  models.   Audience   Users  are  the  primary  audience  for  the  user  requirements,  however,    technical  staff  can   also  benefit  from  understanding  user  needs  and  should  review  user  requirements.     Project  Risks   User  needs  will  not  be  met  resul.ng  in  refusal  to  use  the  system  or  costly  workarounds.  
  21. 21. 20© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solution Requirements - Functional Purpose   Func.onal  requirements  describe  product  capabili.es—things  that  the  product  must  do   for  its  users  or  allow  its  users  to  do  with  the  soQware.  Func.onal  requirements  are  the   doing  part  of  soQware—the  ac.ons,  tasks,  and  behaviors  that  users  generally  interact   with.   Documenta-on   Methods   •  Shall  Statements   •  User  Stories   Examples   •  “The  system  shall  provide  the  capability  for  schedulers  to  assign  contractors  to  jobs  in   their  local  area.”     •  “The  system  shall  permit  the  inventory  manager  to  search  for  available  inventory   items.”     •  “The  system  shall  no.fy  the  operator  when  the  temperature  exceeds  the  maximum   set  value.”   Documents   Func.onal  requirements  are  generally  documented  in  a  func.onal  requirements   documents,  soQware  requirements  document,  systems  requirements  specifica.ons  or   product  backlog   Audience   The  audience  for  the  func.onal  requirements  is  developers.   Project  Risks   Costly  rework,  budget  and  schedule  overruns,  subop.mal  solu.ons  that  deliver  liLle  value   to  the  business.  
  22. 22. 21© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solution Requirements – (Nonfunctional) Purpose   Nonfunc.onal  requirements  are  proper.es  that  the  product  must  have  that  may  not  be   evident  to  the  user,  including  quality  aLributes,  constraints,  and  external  interfaces.   Documenta-on   Methods   Usually  documented  as  shall  statements.  Some  organiza.ons  have  tried  to  use  User   Stories,  but  these  do  not  work  well  defined  as  user  stories.   Examples   •  “The  response  .me  for  loading  all  es.mate  informa.on  onto  the  screen  shall  be  no   more  than  six  seconds  aQer  the  user  submits  the  es.mate  request.”     •  “During  the  peak  holiday  season  between  November  1st  and  January  5th,  the   inventory  search  capability  shall  permit  500  simultaneous  users  to  search  for   inventory  items.”   Documents   Non  func.onal  requirements  are  documented  in  soQware  requirements  documents.   Audience   The    audience  for  non-­‐func.onal  requirements  is  developers.   Project  Risks   Costly  rework,  budget  and  schedule  overruns,  subop.mal  solu.ons  that  fail  to  achieve   service  level  objec.ves.  
  23. 23. 22© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solution Requirements – (Transition) Purpose   Describe  what  is  needed  to  transi.on  from  the  current  (AS-­‐IS)  to  the  the  future  state  (TO-­‐ BE).  Includes  such  things  as  data  conversion  and  training  requirements.     Documenta-on   Methods   Usually  documented  as  shall  statements.   Examples   •  Data  Conversion   •  User  Access  and  Security  Setup   •  Organiza.onal  Change   •  User  prepara.on  and  Training   •  Produc.on  turnover  and  transi.on   •  Customer  and  supplier  prepara.on  and  transi.on   •  Business  Con.nuity   Documents   •  SLAs   •  Data  Conversion  Plan   •  Organiza.onal  Change  and  Training  Plan   Audience   The    audience  for  non-­‐func.onal  requirements  is  people  involved  in  the  transi.on  team   including:  produc.on  support  and  help  desk,  DBAs,  Trainers,  business  management,  and   others   Project  Risks   Systems  delays,  customer  service  interrup.ons,  costly  roll-­‐backs,  and  lack  of  user   adop.on.  
  24. 24. 23© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. What  Are  the  Expected  Business  Outcomes?   What  Business  Changes  Need  to  be  Made?   What  are  the  Solu.on  Components?   What  do  the  Customers  and  Users  Need?   What  is  Needed  to  Meet    Stakeholder  Needs?   How  do  we  Transi.on  to  the  New  Solu.on?   Objec.ves   Impacts   Features   Stakeholder  Requirements   Solu.on  Requirements   Transi.on  Requirements   Business  Requirements   Types of Requirements
  25. 25. 24© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirements  Development  and  Management   The  Old  Way  and  the  New  Way  
  26. 26. 25© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirements Change The  Old  Way  –  Freeze  Requirements   Large  requirement  documents  were  prepared,   reviewed  and  approved.    The  requirements  were   considered  frozen  aQer  approval  received.     The  New  Way  –  Baseline  Features   Individual  features  are  baselined  and  placed  into  bundles   represen.ng  development  itera.ons  or  sprints.   The  New  Way  –  Elabora-on  through  Conversa-ons   Requirements  are  con.nually  clarified  and  elaborated   through  conversa.ons  held  between  developers  and   business  SMEs.  Design  decisions  are  documented  as   requirement  aLributes.   The  Old  Way  –  Everything  Defined  Upfront   All  requirement  details  were  fully  defined  up-­‐front.   From Frozen Requirements to Anticipated Changes The  New  Way  –  Con-nual  Process   Requirements  development  and  management    is  a   con.nual  process  that    mirrors  the  systems  development   lifecycle.  Developing  and  managing  requirements  runs   con.nuously  through  the  life  of  the  project.  An.cipa.ng   requirement  change  is  part  of  the  process.   The  Old  Way  –  Long  Development  Cycles   Requirements  were  considered  a  phase  of  the   development  lifecycle.  Requirements  were  developed   up-­‐front  and  given  to  development.    AQer  the   requirements  were  approved,  the  requirements   development  phase  ended.  
  27. 27. 26© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirement Documentation The  Old  Way  –  Documents   •  BRD  –  Business  Requirements  Document   •  MRD-­‐  Market  Requirements  Document   •  URD  –  User  Requirements  Document   •  FRD  –  Func.onal  Requirements  Document   •  UIRD  –  User  Interface  Requirements  Document   •  SRS  –  Systems  Requirements  Specifica.on   The  New  Way  –  Data   •  Objec.ves   •  Impacts   •  Features   •  Stories   •  Sprint  Plans   •  Releases   The  New  Way  –  Integrated  Database   Mul.ple  disciplines  working  together  to  create  an   integrated  requirement  repository  that  includes   business,  stakeholder,  and  solu.on  requirements.   The  Old  Way  –  Mul-ple  Versions  of  Paper  Documents   A  single  analyst  crea.ng  versions  of  requirement   documents  in  Word  and  then  wai.ng  for  stakeholders  to   review  and  approve.     The  New  Way  –  Data  Integra-on   Requirement  data  is  transmiLed  to  applica.on   and  tes.ng  environments  electronically.     The  Old  Way  –  Paper  Documents   Large  paper  documents  were  sent  to  Development  for   building  and  tes.ng  the  system.   From Paper Documents to Structured Information
  28. 28. 27© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Business Requirements The  Old  Way  –  Business  Case  for  Funding  Only   Most  organiza.ons  prepared  a  business  case  to  get   funding,  but  the  business  case  was  never  used  aQer   that.   The  New  Way  –  Living  Business  Cases   Business  Cases  will  be  developed  and  maintained   throughout  the  life  of  the  project.  They  will  also  play  a   key  role  in  benefits  realiza.on.   The  New  Way  –  Success  Measured  by  Business   Outcomes   Project  success  is  measured  by  whether  the  project   achieved  expected  business  outcomes.   The  Old  Way  –  Success  measured  by  Time  &   Budget   Project  success  was  measured  whether  the  project  was   delivered  all  scope,  on  .me  and  on  budget.   The  New  Way  –  Business  and  IT  Accountability   Business  requirements  will  be  developed  and   maintained  collabora.vely  by  the  business  and  IT.   The  Old  Way  –  IT  Accountability   PMs  and  BAs  prepared  business  requirements  with   limited  review  by  the  project  sponsor.   From Necessary Evil to Strategic Driver The  New  Way  –  Strategic   Business  requirements  will  be  key  to  obtain  funding,   delivering  business  value  and  achieving  business   outcomes.   The  Old  Way  –  Ignored   Business  requirements  were  oQen  ignored  or  poorly   defined.    They  were  oQen  viewed  as  a  waste  
  29. 29. 28© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Stakeholder Requirements The  Old  Way  –  Use  Cases   Most  organiza.ons  prepared  use  cases  to  capture   stakeholder  requirements.   The  New  Way  –  Personas  and  Scenarios   There  will  be  much  wider  use  of  personas  and   scenarios  to  capture  stakeholder  requirements.   The  New  Way  –  People,  Process,  and  Technology   Stakeholder  requirements  will  now  focus  more   broadly  than  just  technology.  They  will  define  what   people,  process,  and  technology  changes  are  needed   to  meet  the  business  need.   The  Old  Way  –  Technology   Use  cases  were  developed  to  iden.fy  what  func.onal   requirements  were  needed  for  the  technical  solu.ons   The  New  Way  –  Valida-on  through   MVPs  ,Prototypes,  and  Simula-on   Stakeholder  requirements  will  be  validated  using   more  effec.ve  methods  such  as  building  prototypes,   modeling  and  simula.on.   The  Old  Way  –  Valida-on  through  Review  and   Approval   Stakeholder  requirements  were  validated  through  review   and  approval   From Use Cases to Enabling Business Change The  New  Way  –  UCD  and  BPMN   Defining  stakeholder  requirements  will  require   business  analysis,  user  centered  design,  and   business  process  modeling  skills.   The  Old  Way  –  Use  Cases   Use  cases  were  defined,  oQen  with  liLle  regard  to  the   business  process.    This  oQen  created  subop.mal   technology  solu.ons  that  did  not  meet  business  needs.  
  30. 30. 29© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solution Requirements The  Old  Way  –  All  Requirements  Up  Front   All  requirements  were  defined  upfront  and  given   to  developers  aQer  approved  by  stakeholders.   The  New  Way  –  Just  Enough  Just  in  Time   Requirements  are  developed  con.nuously  throughout   the  project.  Requirements  are  defined  in  barely  enough   detail  and  elaborated  through  conversa.ons  between   users  and  developers.   The  New  Way  –  Collabora-ve  Conversa-ons   Anyone  can  draQ  a  user  story.    The  user  stories  are   refined  through  face  to  face  conversa.ons  between   the  user  and  developer.   The  Old  Way  –  Requirements  Analysts   A  requirement  analyst  wrote  the  requirements.    The   requirements  were  reviewed  and  approved  by   stakeholders  and  given  to  Developers.   The  New  Way  –  Requirements  Changes  An-cipated   Requirements  are  con.nuously  added  to  the  product   backlog.   The  Old  Way  –  Requirements  were  Frozen   Requirements  were  frozen  aQer  review  and  approval   by  stakeholders.   From All Up Front to Just Enough Just in Time The  New  Way  –  User  Stories   Requirements  are  wriLen  as  user  stories.   The  Old  Way  –  Shall  Statements   Requirements  were  wriLen  in  the  form  of  “Shall”   statements.  
  31. 31. 30© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Transition Requirements The  Old  Way  –  Never  Done   Most  teams  seldom  developed  transi.on   requirements;  they  focused  solely  on  solu.on   requirements.   The  New  Way  –  Drive  Release  Management   Transi.on  requirements  will  be  key  for  managing  release   and  transi.on  management  ac.vi.es.   The  New  Way  –  Used  for  Effec-ve  Transi-on   Transi.on  requirements  will  become  beLer  understood   and  used  for  a  variety  of  things  such  as   •  Data  Conversion   •  Business  Con.nuity   •  Produc.on  Turnover   •  Organiza.onal  Change  and  Training   •  User  Support   •  Release  Management   The  Old  Way  –  Data  Conversion   When  transi.on  requirements  were  developed,  they   were  mostly  used  for  data  conversion.   From Poorly Defined to Essential The  New  Way  –  DevOps   Many  organiza.ons  are  adop.ng  KanBan  and  other  agile   methods  where  there  is  a  need  for  more  frequent   deployments.  Transi.on  requirements  play  a  major  role  in   facilita.ng  this  change  and  the  handoffs  between   development  and  opera.ons.   The  Old  Way  –  Rigid  Release  Schedule   In  the  past,  organiza.ons  had  rigid  release  schedules   for  deployment  of  soQware.  
  32. 32. 31© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Requirements Validation The  Old  Way  –  Review  and  Approve   Large  requirement  documents  were  prepared  and   reviewed  and  approved  by  business  stakeholders.     The  New  Way  –  Con-nuous  Review  and  Valida-on   Requirements  are  stored  in  an  repository    and   con.nuously  validated  as  part  of  the  development   process.  Valida.on  is  done  through  ac.ve  communica.on   with  documenta.on  of  design  decisions.   The  New  Way  –  Requirements  Validated  by  Feature   Requirements  are  validated  Feature  by  Feature  instead   of  all  at  one  .me.  Validators  only  validate  requirements   that  pertain  to  them.    Valida.on  efforts  are  led  by  the   Feature  Sponsor.     The  Old  Way  –  All  Requirements  Validated  at  Once   A  large  requirement  document  is  produced  in  Word  and   given  to  business  stakeholders  for  approval.    AQer   significant  amount  of  .me  has  passed  awai.ng  for   necessary  approvals,  the  requirements  are  given  to   development.     The  New  Way  –  Developer,  QA,  and  Business     Developers  validate  requirements  for  understanding  and   clarity.    Testers  validate  requirements  for  testability.     Business  confirms  that  requirements  meet  business  needs.   The  Old  Way  –  Business  Validated  Requirements   Requirements  were  signed  off  by  the  business  and  simply   given  to  developers  to  build  the  solu.on   From Long Wait Times to Continuous Review and Validation The  New  Way  –  Minimal  Viable  Product   Lean  Startup  Methods  such  as  MVP  will  be  used  to  validate   concepts  and  assump.ons.    This  will  result  in  faster  product   delivery  and  much  lower  development  costs.   The  Old  Way  –  Review  and  Code   Concepts,  assump.ons  and  requirements  were  either   validated  by  review  and  approval  or  placed  in  a  backlog   and  coded  in  the  case  of  agile.  
  33. 33. 32© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Collaboration From Non-Communicating Silos to Collaborative Team The  Old  Way  –  Interviews   Requirements  Analysts  mostly  elicited  requirements   through  interviews  of  stakeholders.    The  stakeholders   were  asked  to  review  and  approve  the  requirements   aQer  all  requirements  were  gathered.     The  New  Way  –  Collabora-vely  Maintained   Requirements  are  developed  in  a  collabora.ve  way.   Stakeholders  are  able  to  see  their  needs  in  their  own   words  and  how  they  map  to  solu.on  requirements.   The  Old  Way  –  No  Developer  Par-cipa-on   Requirements  were  given  to  the  development  aQer   they  have  been  approved  by  the  business  stakeholders   The  New  Way  –  Ac-ve  Developer  Par-cipa-on   Requirements  are  developed  in  a  collabora.ve  way.   Developers  review  requirements  to  ensure  they  are   understood  as  they  are  being  developed.   The  Old  Way  –  Minimal  QA  Involvement   Requirements  were  given  to  QA  when  development   received  them  given  them  liLle  opportunity  to  fully   understand  them  and  develop  meaningful  tests   The  New  Way  –  Ac-ve  QA  Par-cipa-on   QA  is  ac.vely  involved  in  the  requirements  process   ensuring  at  a  minimum  that  the  requirements  are   testable.    They  are  oQen  involved  in  developing  test   cases  which  become  part  of  the  requirements   documenta.on.  
  34. 34. 33© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solution Scope (Features) From Poorly Defined to Carefully Defined and Managed The  Old  Way  –  Poorly  Defined   Solu.on  Scope  was  not  well  defined.  Many   organiza.ons  started  with  project  scope  and  falsely   believed  solu.on  scope  was  defined  by  the   requirements.   The  New  Way  –  Carefully  Defined   Solu.on  scope  is  carefully  defined  and  managed  using   Features  crea.ng  a  shared  vision  of  what  needs  to  be   done  and  Impacts  showing  the  changes  that  need  to  be   made.  The  solu.on  scope  is  then  used  to  elicit   requirements  and  manage  the  project.   The  Old  Way  –    Vision  and  Scope  Statement   When  solu.on  scope  was  defined,  it  was  oQen  defined   in  the  form  of  a  vision  and  scope  statement.    These   were  oQen  at  too  high  of  a  level  to  be  effec.ve  in   managing  the  project.   The  New  Way  –  Impacts  and  Features   Solu.on  scope  is  defined  as  Impacts  and  Features.     Features  define  the  func.onality  that  will  be   developed.  Impacts  are  used  to  describe  the  context.   The  Old  Way  –  Not  Priori-zed  or  Managed   The  Scope  was  oQen  wriLen  as  a  textual  descrip.on   and  might  describe  what  was  included  and  what  was   not.    However,  priori.za.on  was  seldom  done  as  part   of  scoping.    Requirements  were  seldom  related   formally  to  solu.on  scope.   The  New  Way  –  Priori-zed  and  Managed   Scope  is  defined  in  the  form  of  Impacts  and  Features.     Features  are  priori.zed  based  on  business  value  and   .ed  to  specific  business  objec.ves.  Low  value  features   are  eliminated  from  the  project.      
  35. 35. 34© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Business Change (Impacts) From Running Blind to Having full Transparency of Gaps and Risks The  Old  Way  –  Seldom  Done   In  the  past,  architectural  impact  analysis  was  seldom  if   ever  done.   The  New  Way  –       An    Impact  Analysis  is  done  as  part  of  every  project.   Impacts  are  used  to  assess  the  following  areas:   •  People  (Stakeholders)   •  Business  Processes   •  Technology  (IT  Services)   •  Data  (Master  Data,  Knowledge  and  Analy.cs)   •  Governance  (Business  Rules)   The  Old  Way  –  Developing  Technical  Solu-ons   The  focus  was  purely  was  on  providing  technical   solu.ons.     The  New  Way  –  Enabling  Business  Change   Business  people  work  with  IT  to  iden.fy  needed   solu.ons  and  define  holis.c  solu.ons  to  solve   business  problems.     The  Old  Way  –  Running  by  the  Seat  of  the  Pants   Since  impact  analysis  were  seldom  performed,  project   managers  did  not  have  a  good  grasp  on  gaps  and  risks   oQen  discovering  significant  surprises  late  in  the   process   The  New  Way  –  Knowledge  and  Insight   Project  managers  know  the  impact,  capability  gaps,   and  risks.    They  are  able  to  deliver  solu.ons  that   address  the  gap  and  beLer  able  to  mi.gate  risks.  
  36. 36. 35© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Solu-on  Requirements   User  Stories  Become  the  Standard  for  Func-onal  Requirements  
  37. 37. 36© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Business Solutions User Story Format
  38. 38. 37© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. The Three Cs of User Stories •  Stories  are  tradi.onally  wriLen  on  note  cards   •  Cards  may  be  annotated  with  es.mates,   notes,  etc.   Card   •  Details  behind  the  story  come  out  during   conversa.ons  between  stakeholders,  product   owner  and  team   Conversa.on   •  Acceptance  tests  confirm  that  the  story  was   coded  correctly  Confirma.on  
  39. 39. 38© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. User Story and Acceptance Criteria As  a  social  networker   I  want  to  upload  my  profile  picture  into  Facebook   So  that  my  online  friends  can  see  what  I  look  like.       Given  the  user  has  a  valid  Facebook  account  and  a  digital   picture  on  her  computer,   When  she  uploads  a  picture  in  Facebook,   Then  her  the  picture  should  be  visible  to  all  her  friends  in  her   network.   Story   Acceptance   Criteria   Conversa-ons   •  Must  be  able  to  accept  any  size  picture  and  scale  to  fit   •  Only  the  owner  of  the  account  can  upload  a  picture   •  Must  accept  gif,  png,  pdf,  and  jpg      
  40. 40. 39© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Who Writes User Stories? •  Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member. •  Also, note that who writes a user story is far less important than who is involved in the discussions of it.
  41. 41. 40© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. INVEST Independent   Can  be  built  independently  –  few  dependencies   Nego.able   Describes  func.onality  to  be  nego.ated   between  the  customer  and  development     Valuable   Provides  value  to  the  business   Es-mable   Has  enough  detail  to  be  understandable  and   es.mable  without  being  too  detailed   Small   They  should  be  small  -­‐  should  fit  into  a  release   Testable   Worded  in  a  way  that  they  can  be  tested,  traced,   and  verified  
  42. 42. 41© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. •  User stories do not work well for nonfunctional requirements. Employing user stories for NFRs is like forcing a square peg in a round pole. •  Non-functional requirements relate to qualities of the system(security, reliability, and performance) that cut across user facing features. •  The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one- shot like a user story. •  Make sure that you engage with technical stakeholders in your organization, such as architects, user experience designers, and operations teams. These people can help an agile team spot NFR that are not captured in your user stories. User  Stories  do  not  Work  Well     for  Nonfunc-onal  Requirements   Consider  nonfunc-onal  requirements  from  the  start!  
  43. 43. 42© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Start  with  Features  Not  User  Stories  
  44. 44. 43© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Waste: 45% of Functionality is never used Source: Standish Group Report at XP Conference 2002 by Jim Johnson
  45. 45. 44© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Start with Features Not User Stories •  Generally, most requests from customers come as feature requests, not a set of well-defined user stories that are ready for development. •  It is features, not user stories that are delivered to customers and provide value to the customer. •  A feature usually contains several user stories. •  A feature can span several sprints, user stories should never span more than one sprint. When this happens, it only indicates you're missing granularity in your user stories. •  Features can be tested by the end-users, user stories are not necessarily fully testable by the end-user. In many cases testing a user-story until fully integrated with the rest of the feature might only make sense to the developer. •  Features are sometimes Epics or Themes in the Agile.
  46. 46. 45© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Breaking Down Projects Into Small Components •  The Standish Group flatly state that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.” •  It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project. •  Small projects deliver a valuable result that is actually used to create a return on investment (ROI). •  The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. Source  2013  CHAOS  Manifesto  Report,  Standish  Group   Think  Big,  Act  Small   Breaking  down  a  project   this  way  requires  business   analysis  skills  as  the  focus  is   breaking  down  the   solu.on(Product)  and  not   defining  phases  and  tasks.  
  47. 47. 46© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Reducing and Managing Solution Scope •  Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. •  Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. •  Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one. Think  Big,  Act  Small   Defining  solu.on  scope  is     in  the  business  analysis   domain.  However,  few   business  analyst  do  a  good   job  in  this  area.   Source  2013  CHAOS  Manifesto  Report,  Standish  Group  
  48. 48. 47© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Define Solution Scope using Features Project   Objec.ve  1   Objec.ve  2   Objec.ve  3   Feature  A   Feature  B   Feature  C   Feature  D   Feature  F   Feature  G   Feature  H  Feature  E   Story   Story   Story   •  The  basic  principle  is  to  reduce  a  complex  project  into  small,  easy-­‐to-­‐understand   units  called  features.  This  means  taking  one  small  step  at  a  .me  rather  than  tackling   the  whole  project  in  one  go.   •  Each  Feature  should  have  a  Business  Analyst  and  a  Sponsor  from  the  Business.   •  Features  should  be  priori.zed  based  on  business  value.   •  Each  feature  should  be  developed,  verified  and  validated.        
  49. 49. 48© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Features Link  Features  to  Objec.ves   Describe  the  Business  Value   Provided   Priori.ze  based  on  Value,   Complexity  and  Effort   Assess  what  is  required  for   implementa.on  and  user   adop.on  
  50. 50. 49© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Agile  Business  Requirements   User  Stories  Do  Not  Define  Business  Needs  
  51. 51. 50© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
  52. 52. 51© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. •  Achieved a 55% ROI •  Increased production throughput by 26% •  Consolidated applications from 29 to 11 •  Achieved a total savings of $14 million in 9 months •  Increased the number of sales leads by 30% •  Increased labor efficiency by 32% •  Cut procurement costs by 21% •  Reduced Inventory by 37% Business  Outcomes   The  success  of  a  project  should  be  measured  based  on  business  outcomes:  
  53. 53. 52© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Start with Objectives Value  Area   Type  of  Objec-ve   Focus   Measures   User   Adop-on   Reac.on   What  is  needed  to   simplify  user  ac.vi.es?   •  Usefulness   •  Perceived  Value   •  Mo.va.on   Learning   What  do  users  need  to   become  proficient  with   the  solu.on?   •  Skills   •  Competencies   Applica.on   How  can  we  get  users  to   adopt  the  solu.on?   •  Extent  of  Use   •  Frequency  of  Use   •  Elimina.on  of   Workarounds   Business     Outcomes   Impact   What  are  the  expected   business  outcomes?   •  Increased  Revenue   •  Lower  Costs   •  Greater  Throughput   •  Less  Defects   ROI   What  is  the  expected   ROI?   •  Monetary  Return   Based  on  informa1on  provided  by  ROI  Ins1tute  
  54. 54. 53© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Discovery   Align  to  Business  Objec-ves  and  Deliver  Customer  Value   Business  Need  or  Problem  and   Organiza.onal  Context   Business  Objec.ves   Business  Objec.ves   Business  Objec.ves   Feature   Feature   Feature   Feature      Feature   Feature   Feature   Feature   Feature   Feature   Feature   Feature   Included  Features   Descoped  Features   People   Process   Technology   Data   Governance   Impact  Analysis   •  Adop.on  (Artudes  and  Culture)   •  Learning  (Skills  and  Competencies)   •  Applica.on  (Performance)   •  Impact  (Outcomes)   •  ROI   {  
  55. 55. 54© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Agile  Stakeholder  Requirements   Agile  Delivery  Does  Not  Mean    Agile  Business  Change  
  56. 56. 55© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. USERS   Users  use  your  product.  They  register,  login,  push  the  buLons   and  move  the  pixels.  They  are  the  people  who  day  in  day  out   decide  if  they  love  it,  hate  it,  or  lie  somewhere  in  between.   Different  users  use  different  aspects  of  your  product,  so  they   fall  into  different  classes.  For  example,  you  might  find  sales   reps,  sales  mangers,  marke.ng  managers,  and  administrators   all  as  users  in  a  CRM  system.     CUSTOMERS   Customers  buy  your  product.  They  find  it.  Evaluate  it.  Decide   to  purchase  it,  and  ul.mately  pay  for  it.  No  customers  means   no  business  so  they  maLer  a  lot.     To  understand  your  customers,  you  have  to  understand  who   is  making  the  decision  to  buy  your  product,  and  it’s  oQen  a   group,  which  in  common  parlance  is  called  a  decision  making   unit  (DMU).     Users vs. Customers
  57. 57. 56© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Customer and User Discovery •  The goal of Customer Discovery is to find a market for you product and to build a product that prospective customers will buy. Customer discovery techniques include: o  Developing Customer Personas o  Needs exploration with the DMU o  Product validation with the DMU o  Pricing analysis and testing o  Marketing sizing •  The goal of User Discovery is to create a product that delights users. Products that users love get far more traction than ones they don’t like. User discovery techniques include: o  Developing User Personas o  Contextual interviews o  Walking through a prototype o  A/B testing on a site o  Scrappy usability tests o  User diaries o  Analyzing usage data
  58. 58. 57© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Focus on the Job Virtually  all  products  and  services  are  acquired  to   help  get  a  job  done.  In  the  outcome-­‐driven   paradigm  the  focus  is  not  on  the  customer,  it  is  on   the  job:  the  job  is  the  unit  of  analysis.       When  companies  focus  on  helping  the  customer   get  a  job  done  faster,  more  conveniently,  and  less   expensively  than  before,  they  are  more  likely  to   create  products  and  services  that  the  customer   wants.     Only  aFer  a    company  chooses  to  focus  on  the  job,   not  the  customer,  are  they  capable  of  reliably   crea1ng  customer  value.  
  59. 59. 58© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Discover What is Required for User Adoption User Personas. Understand what users activities are. Prototypes. Document characteristics and expectations of different user types. Scenarios. Design and validate the user experience.
  60. 60. 59© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. User Personas and Roles Role   Persona   What  do  I  want  to  Do?   How  will  it  help  me?   Brandon   Equity  Trader     •  27   •  Single   •  Marathon  runner   •  Works  hard  and  par.es   hard   Wants  to  see  current   market  condi.ons   • Buy  and  sell  equi.es   • Real  .me  decisions   • Raid  search  tools   Judy     Por]olio   Manager   • 35   • Married   • Loves  yoga,  fine  dining  and   wine   • PHD  in  Finance   Wants  to  maintain  an   effec.ve  por]olio   • Perform  scenario   modeling   • Maintain  diverse   por]olios   Craig   IT  Support   • 25   • The  phone  is  part  of  his  life   • Wants  to  impress   • Loves  coffee   Understand  users’   problems  and  solve  them   •   Take  control  of  users   applica.ons   • Review  and  mine  audit   logs     Janet   Rela.onship    Manager     • 53   • Loves  social  networking   • Married,  3  children   • Poli.cally  powerful   Cross  sell  products  to   customers   • Track  contacts  made  with   customers   • More  flexible  repor.ng  
  61. 61. 60© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Personas and Scenarios are Used in User Stories
  62. 62. 61© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Increase  Up-­‐Sells  on  Sales  Orders  by  20%  by  January  2014.     •  Build  up-­‐sell  business  rules  and  data  rela.onships  considering   customer  profile  and  products  being  ordered.   •  Add  up-­‐sell    sugges.ons  to  Web-­‐based  order  processing  system.   •  Add  up-­‐sell  sugges.ons  to  Call-­‐Center  order  processing  system.   •  Produce  reports  and  queries  to  measure  performance   Objec-ve   Features   Personas   •  On-­‐line  Customer   •  Call  Center  Sales  Agent   •  Sales  Data  Manager   •  Director  of  Sales   Systems   •  Web  Order  Entry  System   •  Call  Center  Order  Processing   •  Product  Master  Data   •  Upsell  Business  Rules   Stories   •  As  the  Director  of  Sales,  I  want  to  know  the  amount  of  sales  that  were   generated  from  up-­‐sell  recommenda.ons  provided  to  the  customer  so  I   can  op.mize  the  data  to  produce  more  up-­‐sells.   •  As  the  Director  of  Sales,  I  want  to  know  the  percentage  of  sales  orders   that  had  up-­‐sell  items  so  that  I  can  op.mize  sales  opportuni.es   Putting it All Together
  63. 63. 62© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Summary •  Agile adoption will continue to grow and user stories will be the standard format for solution requirements. There will be many problems as agile begins to scale specifically with coordinating agile delivery with business change, cultural change, Devops, and grooming managing ever growing product backlogs. •  Requirements will be developed collaboratively as user stories. The focus for project mangers and business analyst will be on defining and validating Features and enabling business change. Traditional requirements analysts focused on writing solution requirements will need to develop new skills or retire. •  Paper requirement documents will vanish. Requirements and related data will be maintained electronically in backlogs. Review and approval will be done electronically and continuously. •  Businesses that have developed a strong Discovery capability will have a significant competitive advantage over those organizations that have not. •  New tools such as Enfocus Requirements Suite™ will emerge as key for managing discovery and business change.
  64. 64. 63© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. You  need  Enfocus  Requirements  Suite  to     Succeed  in  Agile  Discovery.   We  help  you  deliver  be_er  business  outcomes,   more  quickly  and  at  less  cost.  
  65. 65. 64© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Thank You Learn  how  to  deliver   more  business  value   on  your  projects     Please  request  a   consulta.on.   www.enfocussolu.ons.com  

×