Requirements: The Old Way and the New Way

65
0 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. Title Here Requirements: The Old Way and The New Way

description

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

Transcript of Requirements: The Old Way and the New Way

Page 1: Requirements: The Old Way and the New Way

0 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Title Here

Requirements: The Old Way and The New Way

Page 2: Requirements: The Old Way and the New Way

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 •  [email protected]

Page 3: Requirements: The Old Way and the New Way

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.

Page 4: Requirements: The Old Way and the New Way

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.

Page 5: Requirements: The Old Way and the New Way

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.

Page 6: Requirements: The Old Way and the New Way

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  

Page 7: Requirements: The Old Way and the New Way

6 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Enabling    Business  Change  

Page 8: Requirements: The Old Way and the New Way

7 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Agile  Adop-on  and  a  Message  to  BAs  

Page 9: Requirements: The Old Way and the New Way

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.

Page 10: Requirements: The Old Way and the New Way

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

Page 11: Requirements: The Old Way and the New Way

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.    

Page 12: Requirements: The Old Way and the New Way

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.  

Page 13: Requirements: The Old Way and the New Way

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.

Page 14: Requirements: The Old Way and the New Way

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  

Page 15: Requirements: The Old Way and the New Way

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

Page 16: Requirements: The Old Way and the New Way

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.

Page 17: Requirements: The Old Way and the New Way

16 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Different  Types  of  Requirements  

Page 18: Requirements: The Old Way and the New Way

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.

Page 19: Requirements: The Old Way and the New Way

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.  

Page 20: Requirements: The Old Way and the New Way

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.  

Page 21: Requirements: The Old Way and the New Way

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.  

Page 22: Requirements: The Old Way and the New Way

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.  

Page 23: Requirements: The Old Way and the New Way

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.  

Page 24: Requirements: The Old Way and the New Way

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

Page 25: Requirements: The Old Way and the New Way

24 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Requirements  Development  and  Management  The  Old  Way  and  the  New  Way  

Page 26: Requirements: The Old Way and the New Way

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.  

Page 27: Requirements: The Old Way and the New Way

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

Page 28: Requirements: The Old Way and the New Way

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  

Page 29: Requirements: The Old Way and the New Way

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.  

Page 30: Requirements: The Old Way and the New Way

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.  

Page 31: Requirements: The Old Way and the New Way

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.  

Page 32: Requirements: The Old Way and the New Way

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.  

Page 33: Requirements: The Old Way and the New Way

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.  

Page 34: Requirements: The Old Way and the New Way

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.      

Page 35: Requirements: The Old Way and the New Way

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.  

Page 36: Requirements: The Old Way and the New Way

35 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Solu-on  Requirements  User  Stories  Become  the  Standard  for  Func-onal  Requirements  

Page 37: Requirements: The Old Way and the New Way

36 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Business Solutions

User Story Format

Page 38: Requirements: The Old Way and the New Way

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  

Page 39: Requirements: The Old Way and the New Way

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      

Page 40: Requirements: The Old Way and the New Way

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.

Page 41: Requirements: The Old Way and the New Way

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  

Page 42: Requirements: The Old Way and the New Way

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!  

Page 43: Requirements: The Old Way and the New Way

42 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Start  with  Features  Not  User  Stories  

Page 44: Requirements: The Old Way and the New Way

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

Page 45: Requirements: The Old Way and the New Way

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.

Page 46: Requirements: The Old Way and the New Way

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.  

Page 47: Requirements: The Old Way and the New Way

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  

Page 48: Requirements: The Old Way and the New Way

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.        

Page 49: Requirements: The Old Way and the New Way

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  

Page 50: Requirements: The Old Way and the New Way

49 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Agile  Business  Requirements  User  Stories  Do  Not  Define  Business  Needs  

Page 51: Requirements: The Old Way and the New Way

50 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Page 52: Requirements: The Old Way and the New Way

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:  

Page 53: Requirements: The Old Way and the New Way

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  

Page 54: Requirements: The Old Way and the New Way

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  {  

Page 55: Requirements: The Old Way and the New Way

54 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Agile  Stakeholder  Requirements  Agile  Delivery  Does  Not  Mean    Agile  Business  Change  

Page 56: Requirements: The Old Way and the New Way

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

Page 57: Requirements: The Old Way and the New Way

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

Page 58: Requirements: The Old Way and the New Way

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.  

Page 59: Requirements: The Old Way and the New Way

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.

Page 60: Requirements: The Old Way and the New Way

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  

Page 61: Requirements: The Old Way and the New Way

60 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.

Personas and Scenarios are Used in User Stories

Page 62: Requirements: The Old Way and the New Way

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

Page 63: Requirements: The Old Way and the New Way

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.

Page 64: Requirements: The Old Way and the New Way

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.  

Page 65: Requirements: The Old Way and the New Way

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