Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Scenarios and Use Cases in Software Engineering, Lecture notes of Software Engineering

The use of scenarios in requirements analysis to describe a specific use of a proposed system. It explains that scenarios capture the system as viewed from the outside, using specific examples. The document also provides an example scenario of a student using an online exam system, detailing the steps involved. related to university topics such as software engineering, requirements analysis, and computer science.

Typology: Lecture notes

2021/2022

Uploaded on 05/11/2023

anwesha
anwesha 🇺🇸

4.9

(10)

4 documents

1 / 27

Toggle sidebar

Related documents


Partial preview of the text

Download Scenarios and Use Cases in Software Engineering and more Lecture notes Software Engineering in PDF only on Docsity! Cornell  University   Compu1ng  and  Informa1on  Science         CS  5150  So(ware  Engineering   Scenarios  and  Use  Cases       William  Y.  Arms   Scenarios   Scenario      A  scenario  is  a  scene  that  illustrates  some  interac>on  with  a  proposed   system.    A  scenario  is  a  tool  used  during  requirements  analysis  to  describe  a     specific  use  of  a  proposed  system.    Scenarios  capture  the  system,  as   viewed  from  the  outside,  e.g.,  by  a  user,  using  specific  examples.   Note  on  terminology    Some  authors  restrict  the  word  "scenario"  to  refer  to  a  user's  total   interac>on  with  the  system.    Other  authors  use  the  word  "scenario"  to  refer  to  parts  of  the   interac>on.    In  this  course,  the  term  is  used  with  both  meanings.   Developing  a  Scenario  with  a  Client:    a  Typical  Student   Purpose:    Scenario  that  describes  the  use  of  an  online  Exam  system  by  a   representa>ve  student   Individual:    [Who  is  a  typical  student?]    Student  A,  senior  at  Cornell,  major  in   computer  science.  [Where  can  the  student  be  located?  Do  other   universi7es  differ?]   Equipment:    Any  computer  with  a  supported  browser.    [Is  there  a  list  of   supported  browsers?  Are  there  any  network  restric7ons?]   Scenario:     1.    Student  A  authen>cates.  [How  does  a  Cornell  student  authen7cate?]   2.    Student  A  starts  browser  and  types  URL  of  Exam  system.  [How  does  the   student  know  the  URL?]   3.    Exam  system  displays  list  of  op>ons.    [Is  the  list  tailored  to  the  individual   user?]     Developing  a  Scenario  with  a  Client  (con>nued)   4.  Student  A  selects  CS  1234  Exam  1.     5.  A  list  of  ques>ons  is  displayed,  each  marked  to  indicate  whether   completed  or  not.    [Can  the  ques7ons  be  answered  in  any  order?]   6.  Student  A  selects  a  ques>on  and  chooses  whether  to  submit  a  new   answer  or  edit  a  previous  answer.    [Is  it  always  possible  to  edit  a   previous  answer?    Are  there  other  op7ons?]   7.  [What  types  of  ques7on  are  there:  text,  mul7ple  choice,  etc.?]    The   first  ques>on  requires  a  wri]en  answer.  Student  A  is  submi^ng  a   new  answer.  The  student  has  a  choice  whether  to  type  the  solu>on   into  the  browser  or  to  a]ach  a  separate  file.  Student  A  decides  to   a]ach  a  file.  [What  types  of  file  are  accepted?]   Developing  a  Scenario  with  a  Client  (con>nued)   8.  For  the  second  ques>on,  the  student  chooses  to  edit  a  previous  answer.   Student  A  chooses  to  delete  a  solu>on  previously  typed  into  the  browser,   and  to  replace  it  with  an  a]ached  file.  [Can  the  student  edit  a  previous   answer,  or  must  it  always  be  replaced  with  a  new  answer?]   9.  As  an  alterna>ve  to  comple>ng  the  en>re  exam  in  a  single  session,  Student   A  decides  to  saves  the  completed  ques>ons  work  to  con>nue  later.  [Is  this   always  permiMed?]   10.  Student  A  logs  off.   11.  Later  Student  A  log  in,  finishes  the  exam,  submits  the  answers,  and  logs   out.    [Is  this  process  any  different  from  the  ini7al  work  on  this  exam?]   12.  The  Student  A  has  now  completed  the  exam.  The  student  selects  an  op>on   that  submits  the  exam  to  the  grading  system.    [What  if  the  student  has  not   aMempted  every  ques7on?  Is  the  grader  no7fied?]   Scenarios  for  Analyzing  Special  Requirements   Scenarios  are  very  useful  for  analyzing  special  requirements.   Examples   •  Reversals.    In  a  financial  system,  a  transac>on  is  credited  to  the  wrong   account.    What  sequence  of  steps  are  used  to  reverse  the  transac>on?   •  Errors.    A  mail  order  company  has  several  copies  of  its  inventory  database.   What  happens  if  they  become  inconsistent?     •  Malfeasance.    In  a  vo>ng  system,  a  voter  has  houses  in  two  ci>es.    What   happens  if  he  a]empts  to  vote  in  both  of  them?   Scenarios  for  error  recovery   Murphy's  Law:  "If  anything  can  go  wrong,  it  will".    Create  a  scenario  for   everything  that  can  go  wrong  and  how  the  system  is  expected  to  handle  it.   Modeling  Scenarios  as  Use  Cases   Models   Scenarios  are  useful  in  discussing  a  proposed  system  with  a  client,   but  requirements  need  to  be  made  more  precise  before  a  system  is   fully  understood.     This  is  the  purpose  of  requirements  modeling.   A  use  case  provides  such  a  model.   There  is  a  good  discussion  of  use  cases  in  Wikipedia.  The  approach   used  in  this  course  is  less  complex  than  the  Wikipedia  ar7cle.   Two  Simple  Use  Cases   12   Borrow  Book   BookBorrower   Record  Pressure   PressureSensor   Use  Cases  for  Exam  System   Take  Exam   ExamTaker   Check  Grades   Request Regrade  Three  separate   use  cases   Describing  a  Use  Case   Some  organiza>ons  have  complex  documenta>on  standards   for  describing  a  use  case.     At  the  very  least,  the  descrip>on  should  include:   •  The  name  of  the  use  case,  which  should  summarize  its   purpose   •  The  actor  or  actors   •  The  flow  of  events   •  Assump>ons  about  entry  condi>ons     Outline  of  Take  Exam  Use  Case   Name  of  Use  Case:  Take  Exam   Actor(s):  ExamTaker   Flow  of  events:   1.  ExamTaker  connects  to  the  Exam  server.       2.  Exam  server  checks  whether  ExamTaker  is  already  authen>cated  and   runs  authen>ca>on  process  if  necessary.   3.  ExamTaker  selects  a  exam  from  a  list  of  op>ons.   4.  ExamTaker  repeatedly  selects  a  ques>on  and  either  types  in  a   solu>on,  a]aches  a  file  with  a  solu>on,  edits  a  solu>on  or  a]aches  a   replacement  file.     Rela>onships  Between  Use  Cases:  <<includes>>   ExamTaker   Authen>cate   Take  Exam   <<includes>>   <<includes>>   Check  Grades   The  Authen>cate  use  case  may  be   used  in  other  contexts   Rela>onships  Between  Use  Cases:  <<extends>>   Take  Exam  ExamTaker   Connec>on   Fails   <<extends>>   <<includes>>    is  used  for  use  cases  that  are  in  the  flow  of  events  of  the   main  use  case.   <<extends>>    is  used  for  excep>onal  condi>ons,  especially  those  that   can  occur  at  any  >me.   Scenarios  and  Use  Cases  in  the  Development  Cycle   Scenarios  and  use  cases  are  both  intui>ve  -­‐-­‐  easy  to  discuss  with   clients   Scenarios  are  a  tool  for  requirements  analysis.   •  They  are  useful  to  validate  use  cases  and  in  checking  the   design  of  a  system.   •  They  can  be  used  as  test  cases  for  acceptance  tes>ng.   Use  cases  are  a  tool  for  modeling  requirements.   •  A  set  of  use  cases  can  provide  a  framework  for  the   requirements  specifica>on.     •        Use  cases  are  the  basis  for  system  and  program  design,  but  are   o(en  hard  to  translate  into  class  models     An  Old  Examina>on  Ques>on   The  Pizza  Ordering  System   The  Pizza  Ordering  System  allows  the  user  of  a  web  browser  to  order   pizza  for  home  delivery.    To  place  an  order,  a  shopper  searches  to  find   items  to  purchase,  adds  items  one  at  a  7me  to  a  shopping  cart,  and   possibly  searches  again  for  more  items.       When  all  items  have  been  chosen,  the  shopper  provides  a  delivery   address.    If  not  paying  with  cash,  the  shopper  also  provides  credit  card   informa7on.   The  system  has  an  op7on  for  shoppers  to  register  with  the  pizza  shop.     They  can  then  save  their  name  and  address  informa7on,  so  that  they  do   not  have  to  enter  this  informa7on  every  7me  that  they  place  an  order.     Develop  a  use  case  diagram,  for  a  use  case  for  placing  an  order,  PlaceOrder.     The  use  case  should  show  a  rela>onship  to  two  previously  specified  use   cases,  Iden7fyCustomer,  which  allows  a  user  to  register  and  log  in,  and   PaybyCredit,  which  models  credit  card  payments.       An  Old  Examina>on  Ques>on   Shopper   PlaceOrder   <<includes>>   Iden>fyCustomer   PaybyCredit   <<includes>>   Correct  solu1on   Is  link  is   op>onal   An  Old  Examina>on  Ques>on   Wrong  Solu1on   SearchMenu   PaybyCredit   <<includes>>   Iden>fyCustomer   <<includes>>   AddtoCart   Pay   Shopper  
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved