Cornell

 University  
Compu1ng  and  Informa1on  Science  

 
 
 
CS  5150  So(ware  Engineering  
Models  for  Requirement  Analysis    
and  Specifica@on  
 
 
William  Y.  Arms  
Models  for  Requirements  Analysis  and  Specifica@on  

As  you  build  understanding  of  the  requirements  through  viewpoint  

analysis,  scenarios,  use  cases,  etc.,  use  models  to  analyze  and  specify  
requirements.    The  models  provide  a  bridge  between  the  client's  
understanding  and  the  developers'.  
The  cra;  of  requirements  analysis  and  specifica1on  includes  
selec1ng  the  appropriate  tool  for  the  par1cular  task.  
•  A  variety  of  tools  and  techniques.      
•  Many  familiar  from  other  courses.  
•  No  correct  technique  that  fits  all  situa@ons.  
 Models:  Useful  Texts  

Grady  Booch,  James  Rumbaugh,  Ivar  Jacobson,  The  Unified  Modeling  

Language.    Addison-­‐Wesley  1999.  
The  next  few  slides  are  based  on  the  approach  taken  in  this  book  (BRJ).  
Grady  Booch,  et  al.,  Object-­‐Oriented  Analysis  and  Design  with  Applica?ons,  
third  edi@on.  Benjamin/Cummings  2007.  
Rob  Pooley,  Perdita  Stevens,  Using  UML  SoAware  Engineering  with  Objects  
and  Components,  second  edi@on.  Addison-­‐Wesley  2005.  
 Models  

A  model  is  a  simplifica1on  of  reality  

•      We  build  models  so  that  we  can  be^er  understand  the  system  we  
are  developing.  
•      We  build  models  of  complex  system  because  we  cannot  
comprehend  such  a  system  in  its  en@rety.  
Models  can  be  informal  or  formal.    The  more  complex  the  project  
the  more  valuable  a  formal  model  becomes.  
 
BRJ  
 Principles  of  Modeling  

•      The  choice  of  what  models  to  create  has  a  profound  

influence  on  how  a  problem  is  a^acked  and  how  a  solu@on  is  
shaped.    
•      No  single  model  is  sufficient.    Every  nontrivial  system  is  best  
approached  through  a  small  set  of  nearly  independent  
models.  
•      Every  model  can  be  expressed  at  different  levels  of  precision.  
•      Good  models  are  connected  to  reality.  
BRJ  
 The  Unified  Modeling  Language  

UML  is  a  standard  language  for  modeling  so;ware  systems  

•      Serves  as  a  bridge  between  the  requirements  specifica@on  and  the  
implementa@on.  
•      Provides  a  means  to  specify  and  document  the  design  of  a  so(ware  
system.  
•      Is  process  and  programming  language  independent.  
•      Is  par@cularly  suited  to  object-­‐oriented  program  development.  
 Ra@onal  Rose  

Ra@onal  Rose  is  an  IBM-­‐owned  system  for  crea@ng  and  managing  
UML  models  (diagrams  and  specifica@ons).  
It  is  available  on  computers  in  the  Computer  Science  MEng  Lab.  
 Models:  Diagrams  and  Specifica@on  in  UML  

In  UML,  a  model  consists  of  a  diagram  and  a  specifica1on.  

A  diagram  is  the  graphical  representa@on  of  a  set  of    
elements,  usually  rendered  as  a  connected  graph  of  ver@ces    
(things)  and  arcs  (rela@onships).  
Each  diagram  is  supported  by  technical  documenta1on  that  specifies  in  
more  detail  the  model  represented  by  the  diagram.  
A  diagram  without  a  specifica@on  is  of  li^le  value.  
 Data-­‐Flow  Models  

An  informal  modeling  technique  to  show  the  flow  of  data  through  a  
system.  

External  en@@es  

Processing  steps  

Data  stores  or  sources  

Data  flows  
 Data-­‐Flow  Model    
Example:  University  Admissions  (first  a^empt)  

Rejec@on  
Applica@on   Completed  
form   Assemble   applica@on  
Applicant   Evaluate  
applica@on  

Acceptance  

Shows  the  flow,  but  where  is  

the  data  stored?    Is  there  
suppor@ng  informa@on?  
 Data-­‐Flow  Model    
Example:  Assemble  Applica@on  

Acknowledgment   Acknowledgment  

Applica@on   AND   Evalua@on  

Completed  
form   Receive   request  
applica@on   Begin  
documents   evalua@on  
Applicant  
AND  
Suppor@ng  
documents  
Does  this  model  cover  
all  situa@ons?    Are  
there  special  cases?   Applicant  
Pending  
database  
database  
 Data-­‐Flow  Model  
Example:  Process  Completed  Applica@on  

The  requirements  will  need  a  

descrip@on  of  the  decision-­‐making  
process.  
Rejec@on  
Evalua@on  
request  
Acceptance   Financial     Offer  
Evalua@on  
aid  

Special  
request  

Applicant  
database  
 Decision  Table  Model  

University  Admission  Decision  

SAT  >  S1  T  F  F  F  F  F  

GPA  >  G1  -­‐  T  F  F  F  F  

SAT  between  S1  and  S2  -­‐  -­‐  T  T  F  F  

GPA  between  G1  and  G2  -­‐  -­‐  T  F  T  F  

Accept  X  X  X        

Reject        X  X  X  

Each  column  is  a  separate  decision  case.    The  columns  are  

processed  from  le(  to  right.  
Note  that  the  rules  are  specific  and  testable.  
 Flowchart  Models  

An  informal  modeling  technique  to  show  the  logic  of  part  of  a  
system  and  paths  that  data  takes  through  a  system.  

Opera@on  

Decision  

Manual  opera@on  

Report  
 Flowchart  Model  
Example:  University  Admissions  Assemble  Applica@on  

New   Applica@on  
applicant?   complete?  
Form   F   Update   T  
received   database    
T   F  
Evaluate  
No@fy  
New  database   student  
record  

No@fy   Compare  this  example,  

student   which  shows  the  logic,    
with  the  dataflow  model,  
which  shows  the  flow  of  
data.  
 Modeling  Tools:  Pseudo-­‐code  

An  informal  modeling  technique  to  show  the  logic  behind  part  of  a  system.  
Example:    University  Admission  Decision  
admin_decision  (applica@on)  
if  [email protected]  ==  null  then  error  (incomplete)  
if  [email protected]  >  S1  then  accept(applica@on)  
else  if  [email protected]  >  G1  then  accept(applica@on)  
else  if  [email protected]  >  S2  and  [email protected]  >  G2    
 then  accept(applica@on)  
else  reject(applica@on)    
The  nota@on  used  for  pseudo-­‐code  can  be  informal,  or  a  standard  used  by  a  
so(ware  development  organiza@on,  or  based  on  a  regular  programming  
language.    What  ma^ers  is  that  its  interpreta@on  is  understood  by  
everybody  involved.  
 Modeling  Tools:  Transi@on  Diagrams  

A  system  is  modeled  as  a  set  of  states,  Si      

A  transi1on  is  a  change  from  one  state  to  another.  
The  occurrence  of  a  condi1on,  Ci,  causes  the  transi@on    
from  one  state  to  another    
Transi1on  func1on:  
 f  (Si,  Cj)  =  Sk  
Example  

0
S1 S2
1 0
1

0 S3 1
 Finite  State  Machine  Model    
Example:  Therapy  Control  Console    
 
Example:    Radia1on  Therapy  Control  Console  
You  are  developing  requirements  for  the  operator's  control  console.    
In  an  interview,  the  client  describes  the  procedures  that  the  
operator  must  follow  when  opera@ng  the  machine.  
You  use  a  finite  state  machine  model  to  specify  the  procedures.      
This  shows  the  client  that  you  understand  the  requirements  and  
specifies  the  procedures  for  the  developers.  
 

This  scenario  and  state  diagram  are  based  on  a  published  

example.    Unfortunately  I  have  no  record  of  the  source.    If  you  
know  it,  please  contact  me  so  that  I  can  acknowledge  the  author.  
 Finite  State  Machine  Model  
Therapy  Control  Console:  Scenario  

Scenario  
The  client  provides  the  following  rough  scenario.  
"The  set  up  is  carried  out  before  the  pa@ent  is  made  ready.  The  
operator  selects  the  pa@ent  informa@on  from  a  database.    This  provides  
a  list  of  radia@on  fields  that  are  approved  for  this  pa@ent.    The  operator  
selects  the  first  field.    This  completes  the  set  up.  
"The  pa@ent  is  now  made  ready.    The  lock  is  taken  off  the  machine  and  
the  doses  with  this  field  are  applied.    The  operator  then  returns  to  the  
field  selec@on  and  chooses  another  field."    
 Finite  State  Machine  Model  
State  Transi@on  Diagram  
Discuss  each  state  and  
transi@on  with  the   [Select  field]  
client.  

[Enter]   [Enter]   [lock  off]   [Start]  

Beam  
Pa@ents   Fields   Setup   Ready   on  

[Stop]  

[lock  on]  
[Select  pa?ent]  
 Finite  State  Machine  Model  
State  Transi@on  Table  
Select   Select  
Enter   lock  off   Start   Stop   lock  on  
Pa?ent   Field  

Pa@ents   Fields  

Fields   Pa@ents   Setup  

Setup   Pa@ents   Fields   Ready  

Beam  
Ready   Pa@ents   Fields   Setup  
on  
Beam  
Ready   Setup  
on  
This  table  can  be  used  for  requirements  defini@on,  program  
design,  and  acceptance  tes@ng.  
 Transi@on  Diagram  for  User  Interfaces    
Example:  CS  5150  Web  Site  (part)  

home  

assign-­‐
syllabus   projects   books   tests   integrity   about  
ments  

course  
concepts   examples   surveys  
materials  

scripts  
 En@ty-­‐Rela@on  Model  

A  requirements  and  design  methodology  for  rela1onal  databases  

•      A  database  of  en@@es  and  rela@ons  
•      Tools  for  displaying  and  manipula@ng  en@ty-­‐rela@on  diagrams  
•      Tools  for  manipula@ng  the  database  (e.g.,  as  input  to  database  
design)  
En@ty-­‐rela@onship  models  can  be  used  both  for  requirements  
specifica@on  and  for  the  design  specifica@on.  
 
 Modeling  Tools:  En@ty-­‐Rela@on  Diagram  

An  en@ty  (noun)  

A  rela@on  between  en@@es  (verb)  

An  en@ty  or  rela@on  a^ribute  

Note:  There  are  various  nota?ons  used  for  en?ty-­‐rela?onship  diagrams.    

This  is  the  nota?on  used  by  Chen  (1976).  
 Modeling  Tools:  En@ty  Rela@onship  Diagram  
Example:    CS  5150  Project  

Major   IsClient  

1  
1  
 CS  5150   Client    team  
Student   Project   member    

1  
6  to  8   0:n  
1  
IsMember   IsContact  
En@ty  Rela@onship  Diagram  as  a  Design  Tool  
Example:  Database  Schema  for  Web  Data  

Nota@on:  Each  table  represents  an  en@ty  

                                   Each  arrow  represents  a  rela@on  
 Petri  Net  Models  
A  Petri  Net  models  parallelism  

Event    
A   S  

Event  1  
S  
A  
Event  n  
.  
  S1  

A  
Event  1  
..
Sm  
Event  n  
 Prototyping  Requirements  

Rapid  prototyping  is  the  most  comprehensive  of  all  modeling  

methods    
 A  method  for  specifying  requirements  by  building  a  system  
that  demonstrates  the  func@onality  of  key  parts  of  the  
required  system  
Par@cularly  valuable  for  user  interfaces  
 Requirements  Defini@on:  Data  Dic@onaries  

A  data  dic1onary  is  a  list  of  names  used  by  the  system  
•      Name  (e.g.,  "start_date")  
•      Brief  defini@on  (e.g.,  what  is  "date")  
•      What  is  it?  (e.g.,  integer,  rela@on)  
•      Where  is  it  used  (e.g.,  source,  used  by,  etc.)  
•      May  be  combined  with  a  glossary  
As  the  system  is  developed,  the  data  dic@onary  in  the  requirements  is  the  
basis  of  the  system  data  dic@onary,  which  is  part  of  the  final  specifica@on.  
 
 A  Note  on  Class  and  Object  Models  

This  course  teaches  class  and  object  models  as  a  tool  for  design,  not  for  
modeling  requirements.  
Some  people  recommend  class  and  object  models  for  requirements  
defini@on,  but  it  is  difficult  to  use  them  without  constraining  the  system  
design.  
Flow  charts  and  finite  state  machines  are  supported  by  UML  as  design  
models,  but  are  equally  useful  for  requirements.