Requirements Engineering - Werkcollege 2012: 04-Documentation

1,416 views
1,238 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,416
On SlideShare
0
From Embeds
0
Number of Embeds
107
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Requirements Engineering - Werkcollege 2012: 04-Documentation

  1. 1. Requirements  Engineering    Werkcollege  Spring  2012    Session  4:  SpecificaDon  &  DocumentaDon   Christoph Johann Stettina (stettina@liacs.nl)                            Leiden  University.  The  university  to  discover.  
  2. 2. Session  4:  Requirements  SpecificaDon  Today:  •  Business  process  modeling    •  Tayloris3c  knowledge  sharing  •  Requirements  specifica3on  templates  Why  is  it  important?  •  Documenta3on  of  elicited  requirements    •  Traceability,  Accountability  •  Acceptance  criteria                            Leiden  University.  The  university  to  discover.  
  3. 3.     Part  1  –  SpecificaDon  Business  Process  Modeling                          Leiden  University.  The  university  to  discover.  
  4. 4. What  is  a  business  process?  “A  collec3on  of  ac3vi3es  that  takes  one  or   more  kinds  of  input  and  creates  an  output   that  is  of  value  to  the  customer”    (Hammer  &  Champy,  1993)    Real  life  examples:    -  E-­‐payment  process    -  Visa  applica3on    -  Hotel  reserva3on    -  etc.                            Leiden  University.  The  university  to  discover.  
  5. 5. What  is  business  process  modeling?  Convergence  of  two  modeling  domains:    Process  modeling  l  Abstract  representa3on  of  a  process   architecture    Enterprise  or  business  modeling  l  Documen3ng  an  organiza3on  from  a  holis3c   perspec3ve                            Leiden  University.  The  university  to  discover.  
  6. 6. Why  modeling  business  processes?  -  To  have  a  formal  documenta3on  (as  point  of   reference)    -  To  allow  process  analysis  (e.g.,  reengineering)    -  To  communicate  processes    -  To  generate  executable  process  language   (e.g.,  BPEL)                            Leiden  University.  The  university  to  discover.  
  7. 7. Examples:  BPM  Supply  fulfillment,  Informal  &  Formal                              Leiden  University.  The  university  to  discover.  
  8. 8. How  to  Model  Business  Processes?  We  need  a  formal  way  to  model  BP,  so  that:      l  Widely  understood  (using  standard  nota3on)    l  Avoid  ambiguity,  inconsistency,  etc.  in   expressing  concepts    l  Allow  automated  assessments                            Leiden  University.  The  university  to  discover.  
  9. 9. CreaDng  an  AcDvity  Diagram        -  Iden3fy  the  scope  of  the  ac3vity  diagram   (e.g.,  a  use  case)    -  Add  start  and  end  points    -  Add  ac3vi3es    -  Add  transi3ons  from  the  ac3vi3es    -  Add  decision  points  (if  any)    -  Iden3fy  opportuni3es  for  parallel  ac3vi3es                              Leiden  University.  The  university  to  discover.  
  10. 10. CreaDng  an  AcDvity  Diagram  Another  Example                            Leiden  University.  The  university  to  discover.  
  11. 11. The  Swimlanes  -  Add  a  dimension  to   visualize  roles    -  Separate  the  diagram   into  parallel  lanes    -  Each  lane  presents   ac3vi3es  performed   by  each  role    -  Transi3ons  can  take   across  swimlanes                            Leiden  University.  The  university  to  discover.  
  12. 12. Case  Study:  In-­‐class  assignment    -  Analyze  &  model  the  current  business  process  of   the  OV-­‐chipkaart  from  the  customer  perspec3ve  -  Use  ac3vity  diagrams  to  support  your  model  -  What  are  the  differences?    Example:  Strippenkaart  Process                                Leiden  University.  The  university  to  discover.  
  13. 13.     Part  2  –  Knowledge  Sharing  Tayloris3c  &  Direct  Knowledge  Sharing                          Leiden  University.  The  university  to  discover.  
  14. 14. to press development teams to produce multitude ofdocuments throughout a software project.Knowledge  Sharing:  TaylorisDc  Way  TaylorisDc  Knowledge  Sharing  (Melnik  and  Maurer,  2009)   10% communication error !•  Division  of  labor  and  long  chains  of  transfer   (90%)5 = 59% info gets to developer•  5%  communica3on  errors  pro  transfer                             5% communication error ! →  only  77%  of  informa3on  reaches  developer   5 (95%) = 77% info gets to developer•  Projects  suffer  from  less  direct  links  (Keil  and  Carmel,   1995)  Figure 1. Knowledge Sharing: Tayloristic Way.                          Leiden  University.  The  university  to  discover.  
  15. 15. process. Knowledge  Sharing:  Direct  Way   Agile  Knowledge  Sharing  (Melnik  and  Maurer,  2009)   10% communication error ! •  Encourage  con3nuous  realignment  of  goals   90% info gets to developer and  customer  feedback   5% communication error ! process   •  Knowledge  sharing  a  highly  social   95% info gets to developer                            Leiden  University.  The  university  to  discover.  
  16. 16. Knowledge  Sharing  Exercise   (Melnik  and  Maurer,  2009)  Knowledge  Sharing  Exercise  (Melnik  and  Maurer,  2009)  •  Simula3on  of  Tayloris3c  knowledge  sharing  •  Form  small  teams  of  3-­‐6  people  •  Goal:  Reproduce  a  Drawing,  Time:  20  mins  Roles  •  Analyst  Describes  requirements  in  prose  on  paper  •  Messenger  Carries  notes  from  developers  and  back  •  Developer  Implement  the  specifica3on                            Leiden  University.  The  university  to  discover.  
  17. 17. Knowledge  Sharing  Exercise   (Melnik  and  Maurer,  2009)  Examples  (Melnik  and  Maurer,  2009)   Industry Team 1: Original IndustryTeam 1: Original SAIT Team 1: Product Industry Team 2: Original SAIT Team 1: Product S Ind Industry Team 1: Original Industry Team 1: Product Industry Team 2: Original In (a) (a) (b) (a) (b)                          Leiden  University.  The  university  to  discover.  
  18. 18.     Part  3  –  DocumentaDon  Requirements  Specifica3on  Templates                            Leiden  University.  The  university  to  discover.  
  19. 19. So[ware  Requirement  SpecificaDon  SRS  Templates    •  Help  to  structure  requirements  Standards    •  IEEE  830-­‐1998    •  IEEE  1362-­‐1998  •  VOLERE  Template                            Leiden  University.  The  university  to  discover.  
  20. 20. Requirement  SpecificaDon  Templates  •  Introduc3on  •  General  descrip3on  (overview  &  scope)  •  Specific  requirements                            Leiden  University.  The  university  to  discover.  
  21. 21. Requirement  SpecificaDon  Templates  IEEE  Recommended  PracDce  for  So[ware  Design  DescripDons  (IEEE  830,  1998)   1. Introduction 1.1 Purpose of the document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constrains 2.5 Assumptions and dependencies 3. Specific requirements 3.1 Functional requirements 3.2 External interface requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software quality attributes Appendices Index                          Leiden  University.  The  university  to  discover.  
  22. 22. FuncDonal  Requirements  Most  common  requirement  form  •  What  system  must  do  according  to  project  goal    •  Ac3ons  the  systems  takes:                                                                       Input  →  Behavior  →  Output  •  “System  must  do  <requirement>”  Measurable:  •  Criterion  in  terms  of  predicted  outcomes                            Leiden  University.  The  university  to  discover.  
  23. 23. Non-­‐FuncDonal  Requirements  SomeDmes  also  called  Quality  Requirements  •  System  performance,  throughput,  3ming  •  Look  and  feel,  usability,  security,  reliability  •  “System  must  be  <>”  Measurable:    •  Throughput,  3ming  and  stress  tests  •  Usability  tes3ng  with  users                            Leiden  University.  The  university  to  discover.  
  24. 24. Requirements  ≠  SoluDons  SoluDons  1.  Users  shall  be  able  to  pay  train  fares  via               OV-­‐chipkaart  2.  The  system  shall  be  password  protected  Requirements  1.  The  system  shall  allow  payment  of  mul3ple   transporta3on  systems  2.  The  system  shall  provide  access  only  to   authorized  users                            Leiden  University.  The  university  to  discover.  
  25. 25. Volere  Template  (Volere,  2010)   Requirement #:X Requirement Type: _ Event/use case: _ Description: Natural language statement in stakeholder words, describing the intent of the requirement Rationale: Reason behind the requirement. Help understanding the context. Originator: Person or stakeholder group Fit Criterion: Acceptance criteria defined in a quantified manner. To be used for acceptance testing. Customer Satisfaction: 1-5 Customer Dissatisfaction: 1-5 Dependencies: other Req. Conflicts: ___ Supporting Materials: Link to further references History: Creation dates and authors for traceability.                          Leiden  University.  The  university  to  discover.  
  26. 26. Templates:  In-­‐class  assignment  TranslaDon  of  requirements  •  Form  groups  of  2-­‐3  people  •  Groups  receive  VOLERE  and  SRS  Examples  •  Groups  A:  Translate  Volere  -­‐>  SRS  •  Groups  B:  Translate  SRS  -­‐>  VOLERE    •  10mins,  then  groups  switch  ar3facts    EvaluaDon  •  What  did  you  learn/experience?                              Leiden  University.  The  university  to  discover.  
  27. 27. Assignment:  Req.  SpecificaDon    Propose  requirements  and  a  business  process  for  a  fic3onal                OV-­‐chipkaart  without  logging  out.  You  can  use  other  technologies  (e.g.  RFID)  Deliverables  Your  requirements  in  a  SRS  (IEEE  Std-­‐830,  as  PDF),  include   •  1  Ac3vity  diagram   •  2  VOLERE  sheets   •  Provide  sufficient  textual  descrip3ons    Hand  in  via  email  Subject:  RE  assignment  –  Assignment  4  –  Specifica3on  Naming  conven3on  for  the  file:  stnumber_lastname.pdf.  Use  PDF.  One  solu3on  per  person.    •  Send  to:  stepna@liacs.nl    •  Deadline:  April  19,  2012                                Leiden  University.  The  university  to  discover.  
  28. 28. Bibliography  •  Fowler,  M.  (2004),  UML  dis3lled:  a  brief  guide  to  the  standard  object  modeling  language  (3  ed.),  Addison-­‐ Wesley,  p.  131,  ISBN  9780321193681  •  Hammer,  M.  &  Champy,  J.  (1994).  Reengineering  the  corpora3on:  A  manifesto  for  business  revolu3on.  New   York:  Harper.    •  IEEE,  Sosware  Engineering  Commitee  (1998)  IEEE  Recommended  Prac3ce  for  Sosware  Design  Descrip3ons.   ANSI/IEEE  Std  830,  October  1998  •  Keil,  M.,  Carmel,  E.  Customer-­‐Developer  Links  in  Sosware  Development.  Communica3ons  of  the  ACM,  38  (5):   33–44,  1995.  •  van  Lamsweerde,  A.  (2009)  Requirements  Engineering:  From  System  Goals  to  UML  Models  to  Sosware   Specifica3ons.  Wiley,  March  2009.  •  Melnik,  G.  and  Maurer,  F.  “Direct  verbal  communica3on  as  a  catalyst  of  agile  knowledge  sharing,”  in   Proceedings  of  the  Agile  Development  Conference.  Washington,  DC,  USA:  IEEE  Computer  Society,  2004,  pp.   21–31.  •  Taylor,  F.  Principles  of  Scien3fic  Management.  Norton,  New  York,  NY,  1967.  •  Volere  (2010)  Volere  Requirements  Specifica3on  Template.  Edi3on  15  —  2010.  Retrieved  2012-­‐04-­‐11.  htp:// www.volere.co.uk/template.htm                            Leiden  University.  The  university  to  discover.  

×