CS 5150 Software Engineering Requirements Analysis, Summaries of Software Engineering

Download CS 5150 Software Engineering Requirements Analysis and more Summaries Software Engineering in PDF only on Docsity! Cornell  University   Compu1ng  and  Informa1on  Science         CS  5150  So(ware  Engineering   Requirements  Analysis       William  Y.  Arms   Process  Step:  Requirements   Requirements  define  the  funcEon  of  the  system  from  the  client's   viewpoint.   •  The  requirements  establish  the  system's  funcEonality,  constraints,   and  goals  by  consultaEon  with  the  client,  customers,  and  users.     •  The  requirements  may  be  developed  in  a  self-­‐contained  study,  or  may   emerge  incrementally.   •  The  requirements  form  the  basis  for  acceptance  tesEng.   The  development  team  and  the  client  need  to  work  together  closely   during  the  requirements  phase  of  a  so(ware  project.     •  The  requirements  must  be  developed  in  a  manner  that  is   understandable  by  both  the  client  and  the  development  staff.       Requirements  in  the  Modified  Waterfall  Model   The  requirements  need   conEnual  updaEng  as  the   project  conEnues.   Requirements   System  design   Program  tesEng   OperaEon  &  maintenance   Program  design   ImplementaEon  (coding)   Acceptance  &  release   Feasibility  study   Requirements  with  Incremental  Development   Each  sprint  has  its  own  set   of  requirements.   Sprint  1   Release     Sprint  1   Sprint  2   Sprint  3   Release   Sprint  2   Release   Sprint  3   Requirement  Goals     •  Understand  the  requirements  in  appropriate  detail.   •  Define  the  requirements  in  a  manner  that  is  clear  to  the  client.    This  may   be  a  wrieen  specificaEon,  prototype  system,  or  other  form  of   communicaEon.       •  Define  the  requirements  in  a  manner  that  is  clear  to  the  people  who  will   design,  implement,  and  maintain  the  system.   •  Ensure  that  the  client  and  developers  understand  the  requirements  and   their  implica1ons.   Many  CS  5150  projects  use  the  first  presentaEon  and  the  accompanying   report  to  confirm  the  requirements  with  the  client.   "Our  understanding  of  your  requirements  is  that  ...”     Requirements  Analysis:  Interviews  with  Clients   Client  interviews  are  the  heart  of  the  requirements  analysis.   Clients  may  have  only  a  vague  concept  of  requirements.   •      Allow  plenty  of  Eme.   •      Prepare  before  you  meet  with  the  client.   •      Keep  full  notes.   •      If  you  do  not  understand,  delve  further,  again  and  again.   •      Repeat  what  you  hear.   For  your  CS  5150  projects  you  will  need  to  schedule  several  meeEngs   with  your  client  to  analyze  the  requirements.   Small  group  meeEngs  are  o(en  most  effecEve.     Requirements  Analysis:  Understand  the  Requirements     Understand  the  requirements  in  depth   •      Domain  understanding    Example:    Manufacturing  light  bulbs   •      Understanding  of  the  real  requirements  of  all  stakeholders    Stakeholders  may  not  have  clear  ideas  about  what  they   require,  or  they  may  not  express  requirements  clearly.        They  are  o(en  too  close  to  the  old  way  of  doing  things.   •      Understanding  the  terminology    Clients  o(en  use  specialized  terminology.    If  you  do  not   understand  it,  ask  for  an  explanaEon.     Keep  asking  quesEons,  “Why  do  you  do  things  this  way?”    “Is  this   essen2al?”  “What  are  the  alterna2ves?”   Requirements  Analysis:  New  and  Old  Systems   A  new  system  is  when  there  is  no  exisEng  system.    This  is  rare.   A  replacement  system  is  when  a  system  is  built  to  replace  an  exisEng  system.   A  legacy  system  is  an  exisEng  system  that  is  not  being  replaced,  but  must   interface  to  the  new  system.   Clients  o(en  confuse  the  current  system  with  the  underlying  requirement.   In  requirements  analysis  it  is  important  to  dis1nguish:   •        features  of  the  current  system  that  are  needed  in  the  new  system   •  features  of  the  current  system  that  are  not  needed  in  the  new  system   •        proposed  new  features   Requirements  Analysis:  Viewpoint  Analysis   Viewpoint  Analysis   Analyze  the  requirements  as  seen  by  each  group  of  stakeholders.   Example:    University  Admissions  System   •      Applicants   •      University  administraEon    Admissions  office    Financial  aid  office    Special  offices  (e.g.,  athleEcs,  development)   •      Academic  departments   •      Compu2ng  staff    Opera2ons  and  maintenance   Requirements  Analysis:  Special  Studies   Understanding  the  requirements  may  need  studies:   Market  research    focus  groups,  surveys,  compeEEve  analysis,  etc.    Example:    Windows  XP  T-­‐shirt  that  highlighted  Apple’s  strengths   Technical  evalua1on    experiments,  prototypes,  etc.    Example:    Windows  XP  boot  faster   Defining  and  CommunicaEng  Requirements Objec1ves   •  Record  agreement  between  clients  and  developers   •  Provide  a  basis  for  acceptance  tesEng   •  Provide  visibility   •  Be  a  foundaEon  for  program  and  system  design   •  Communicate  with  other  teams  who  may  work  on  or  rely  on   this  system   •  Inform  future  maintainers   Defining  and  CommunicaEng  Requirements:     OpEon  2  –  Lightweight  Processes   Lightweight  processes  use  a  outline  specifica1on  +  other  tools   •  DocumentaEon  describing  key  requirements  in  appropriate  detail.   •  Reviewed  by  client  and  developers.   Details  provided  by  supplementary  tools,  e.g.,   •  User  interface  mock-­‐up  or  demonstraEon.   •  Models,  e.g.,  data  base  schema,  state  machine,  etc.   Clients  understand  prototypes  beeer  than  specificaEon   •  IteraEve  or  incremental  development  processes  allows  the  client  to   appreciate  what  the  final  system  will  do.   Lightweight  Processes  (conEnued)   With  lightweight  processes,  experience  and  judgment  are  needed  to   disEnguish  between  details  that  can  be  le(  for  later  in  the  development   process  and  key  requirements  that  must  be  agreed  with  the  client  early  in   the  process.   Examples  where  detailed  specifica1ons  are  usually  needed    Business  rules  (e.g.,  reference  to  an  accounEng  standard)    Legal  restraint  (e.g.,  laws  on  retenEon  of  data,  privacy)    Data  flow  (e.g.,  sources  of  data,  data  validaEon)   A  common  fault  is  to  miss  crucial  details.    This  results  in  misunderstandings   between  the  client  and  the  developers.    Yet  the  whole  intent  of  lightweight   processes  is  to  have  minimal  intermediate  documentaEon.     Requirements  in  Government  Systems   22   Government  systems  in  the  USA  and  abroad  have  a  reputaEon  for  poor   funcEonality  combined  with  delays  and  cost  over-­‐runs.   My  personal  opinion  is  that  the  method  of  contracEng  is  a  major  contributor   to  these  problems.   •  Responsible  use  of  taxpayers  money  leads  to  contracts  in  which  each  sub-­‐ process  has  a  defined  deliverable  at  an  agreed  price.   •  In  parEcular  most  contracts  demand  a  detailed  requirement  specificaEon   before  the  contract  for  design  and  implementaEon  are  placed.   •  This  leads  to  a  waterfall  model  of  development,  o(en  with  penalEes  for   modificaEons  of  the  requirements.   But  in  many  government  systems  the  requirements  are  not  well  understood.   •  They  should  use  a  development  process  in  which  the  requirements  are   flexible  and  the  design  evolves  iteraEvely.   •  Contracts  for  such  development  processes  are  difficult  to  write,  but  they   lead  to  beeer  so(ware.       Example  of  Non-­‐FuncEonal  Requirements   Example:  Library  of  Congress  Repository   Use  technology  that  the  client's  staff  are  familiar  with:   •  Hardware  and  so(ware  systems  (IBM/Unix)   •  Database  systems  (Oracle)   •  Programming  languages  (C  and  C++)   Recognize  that  the  client  is  a  federal  library   •  RegulaEons  covering  government  systems,  e.g.,  accessibility  to   people  with  disabiliEes   •  Importance  of  developing  a  system  that  would  be  respected  by   other  major  libraries   Requirements:  NegoEaEon  with  the  Client   Some  requests  from  the  client  may  conflict  with  others:   Recognize  and  resolve  conflicts      (e.g.,  funcEonality  v.  cost  v.  Emeliness)   Example:          Windows  XP  boot  faster:  shorter  Eme-­‐out  v.  recognize  all   equipment  on  bus     Requirements:  NegoEaEon  with  the  Client   SomeEmes  the  client  will  request  funcEonality  that  is  very  expensive  or   impossible.    What  do  you  do?   •  Talk  through  the  requirement  with  the  client.    Why  is  it  wanted?  Is   there  an  alternaEve  that  is  equivalent?     •  Explain  the  reasoning  behind  your  concern.    Explain  the  technical,   organizaEonal,  and  cost  implicaEons.     •  Be  open  to  suggesEons.    Is  there  a  gap  in  your  understanding?     Perhaps  a  second  opinion  might  suggest  other  approaches.   Before  the  requirements  phase  is  completed  the  client  and  development   team  must  resolve  these  quesEons.   Example    NaEonal  Science  FoundaEon  grant  system,  client  asked  for  every   format  that  had  ever  been  used  in  proposals  (e.g.,  scienEfic  samples).     A(er  negoEaEon,  agreed  that  the  first  phase  would  support  only  PDF.