ì  Análise  e  Modelação  de  Sistemas  

AulaT03    -­‐  Engenharia  de  Requisitos        Referências:  

1  Conceptual  Modeling  of  Informa5on  Systems  (Secção  1.4)  2  Nuseibeh,  B.  and  Easterbrook,  S.  2000.  Requirements  engineering:  a  roadmap.  

ACM,  New  York,  NY,  35-­‐46,  DOI=  hUp://doi.acm.org/10.1145/336512.336523  

3  IEEE  Std  830  -­‐  IEEE  Recommended  Prac5ce  for  SoYware  Requirements  Specifica5ons  

4  Aulas  AMS  do  IST  

   

Engenharia  de  requisitos  

ì  Abordagem  sistemá>ca  à  documentação,  validação  e  gestão  de  requisitos  

ì  Processo  de  Engenharia  de  requisitos  ì  Elicitação  de  requisitos  ì  Análise  de  Requisitos  ì  Negociação  de  requisitos  ì  Especificação/documentação  de  requisitos  ì  Validação  de  requisitos  

Modelação  

2  

Requisitos  e    “Stakeholders”  

ì  Requisitos  ì  Condição  ou  capacidade  que  deve  ser  sa5sfeita  pelo  sistema  ì  Originada  de  

ì  Decisões  ou  pedidos  dos  “stakeholders”  ì  Impostas  por  standards,  regulamentos,  leis,  etc.  

ì  “Stakeholders”  ì  Qualquer  um  envolvido  no  ciclo  de  vida  do  sistema    

ì  Análise,  desenho,  desenvolvimento,  manutenção,  …  ì  Qualquer  capaz  de  impor  requerimentos  ao  sistema  

ì  Dono,  u6lizador  …  

É  qualquer  um  interessado  no  sistema  ou  afectado  por  ele…    Modelação  

3  

Importância  dos  requisitos…  

ì  Requisitos  ì  Mudam  ì  Diferentes  interpretações  do  problema  ì  Problemas  de  comunicação    

ì  Qualidade  dos  sistemas  de  informação  ì  Funcionalidade  (requisitos  funcionais)  ì  Usabilidade  e  experiência  de  u5lização  (requisitos  não  

funcionais)  ì  U5lidade  (alinhamento  requisitos-­‐objec5vos  do  negócio)  

Modelação  

4  

Modelação  de  Sistemas  e  Requisitos  

Modelação  

5  

Requisitos  Gerais  

Requisitos  Específicos  

Necessidade…   Objec5vos  do  Sistema  

Modelação  do  sistema  

Modelação  do  comportamento   Modelação  da  estrutura  

Modelação  do  subsistema  

Modelação  do  comportamento   Modelação  da  estrutura  

Modelação  do  subsistema  

Modelação  do  comportamento   Modelação  da  estrutura  

Modelação  do  subsistema  

Modelação  do  comportamento   Modelação  da  estrutura  

Modelação  

6  

Elicitação  de  

requisitos  

Análise  e  Negociação  de  

requisitos  

Especificação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio  •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,…  •  …  

Processo  Geral  da  engenharia  de  requisitos  

Modelação  

7  

Elicitação  de  requisitos  

Análise  e  negociação  de  

requisitos  

Documentação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio    •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,  …  •  …  

Processo  geral  da  engenharia  de  requisitos  

Modelação  conceptual  

Tipos  de  requisitos  

•  Requisitos  funcionais  –  Especifica  as  funções  do  sistema  e  das  suas  componentes  –  Relacionada  com  as  capacidades  específicas  do  sistema  –  Representados  no  desenho  do  sistema  

•  Requisitos  não  funcionais  –  Refere-­‐se  ao  comportamento  geral  do  sistema  na  realização  das  suas  funções  

–  Tipos  de  requisito  não  funcionais:  –  Performance;  Escalabilidade;  Disponibilidade;  Confiabilidade;  

Facilidade  de  Manutenção;  Segurança;  Sa5sfacção  de  regulamentos;  Usabilidade,  Interoperabilidade,  Flexibilidade,  Extensibilidade  

–  Representados  na  arquitectura  do  sistema  Modelação  

8  

Tipos  de  Requisitos  (Eng.  Software)  

ì  Requisitos  de  u>lizador.  Estes  requisitos  foram  escritos  segundo  pontos  de  vista  dos  u5lizadores  finais,  normalmente  expressados  na  forma  narra5va.  Abrangem  requisitos  funcionais  e  não  funcionais  de  tal  forma  que  sejam  compreendidos  pelos  u5lizadores  que  não  tenham  conhecimento  técnico  detalhado.  

ì  Requisitos  de  sistema.  Estes  requisitos  são  especificações  detalhadas  descrevendo  as  funções  que  o  sistema  será  capaz  de  executar.  Só  requisitos  funcionais  

ì  Requisitos  não  funcionais:  Os  requisitos  não  funcionais  descrevem  qualidades  do  sistema  (como  o  sistema  é)  ao  invés  das  suas  funcionalidades  (o  que  ele  faz).  

Modelação  

9  

Exemplos  (funcionais)….  

Modelação  

10  

(exemplo  de  “Systems  analysis  and  design  with  UML”  –  ISBN:  978-­‐0471348061)  

Exemplos  (não  funcionais)  

Modelação  

11  

(exemplo  de  “Systems  analysis  and  design  with  UML”  –  ISBN:  978-­‐0471348061)  

IEEE/ANSI  830-­‐1993  propõe  uma  estrutura  

para  os  documentos  de  especificação  de  

requisitos  

Modelação  

12  

Norma  IEEE  para  documentos  de  requisitos  

Modelação  13  

Elicitação  de  

requisitos  

Análise  e  Negociação  de  

requisitos  

Especificação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio  •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,…  •  …  

Processo  Geral  da  engenharia  de  requisitos  

Elicitação  de  requisitos  

ì  Processo  de  descoberta  de  requisitos  para  um  sistema  através  da  comunicação  com  os  “stakeholders”  

ì  Este  processo  apoia-­‐se  em  várias  técnicas:  ì  Ques5onários  ì  Análise  de  documentos  ì  Entrevistas  ì  Workshops/Seminários  ì  Observação  ì  Técnicas  etnográficas  (inserção  no  ambiente  onde  o  sistema  

vai  funcionar)  ì  Proto5pagem  ì  …  

Modelação  

14  

Questionários  ì  Relevantes  para:  

ì  Alto  número  de  “stakeholders”  da  mesma  natureza  e  com  as  mesmas  necessidades  

ì  Foco  em  requisitos  funcionais  

ì  Processo  ì  Seleccionar  par5cipantes  ì  Definir  as  perguntas  e  5po  de  respostas  (abertas,  fechadas,  

escalas)  ì  Definir  estratégias  para  assegurar  um  alto  número  de  

respostas  de  qualidade  ì  Comunicar  resultados  aos  “stakeholders”  

ì  Para  validar  e  mo5var  Modelação  

15  

Análise  de  documentos  ì  Quando  já  há  processos  ou  sistemas  operando  

(cenário  “as-­‐is”),  mas  há  a  necessidade  de  mudar  o  processo  e/ou  sistema  (cenário  “to-­‐bo”)  

ì  Documentos  Opicos  ì  Formulários  ì  Relatórios  ì  Manuais  de  processos  ì  Manuais  de  sistema  ì  Manuais  de  u5lizador  ì  …  

Modelação  

16  

Entrevistas  ì  Relevantes  

ì  Número  reduzido  e  bem  iden5ficado  de  stakeholders,  par5cularmente  com  poder  de  decisão,  altamente  especializados  e  com  diferentes  visões  do  sistema  

ì  Foco  em  requisitos  funcionais  

ì  Processo  ì  Prepare-­‐se  cuidadosamente  ì  Defina  claramente  os  objec5vos  da  entrevista  ì  Seleccione  os  stakeholders  e  forneça  detalhes  com  

antecedência  de  forma  a  eles  poderem  preparar-­‐se  também  ì  Formule  as  suas  perguntas  de  forma  clara  e  concisa  

Modelação  

17  

Seminários/Workshops  ì  Relevantes  para  

ì  Sistemas  novos  cujos  requisitos  dependem  de  grupos  heterogéneos  de  stakeholders  que  representam  diferentes  classes  de  u5lizadores  ou  decisores  

ì  Requer  um  ambiente  organizacional  flexível  e  relaxado  (será  que  existe??)  

ì  Processo  ì  Prepare  vários  workshops  (2,  3,…)  num  local  apropriado  e  com  o  tempo  

suficiente  (1  dia  completo),  8  a  12  par5cipantes  é  a  dimensão  ideal  ì  Um  par5cipantes  deve  registar  as  decisões  tomadas  ì  Um  par5cipante  deve  agir  como  moderador  (com  habilidades  de  

comunicação)  ì  1  o  2  membros  da  equipa  de  desenho  devem  estar  presentes  (num  papel  

PASSIVO,  só  a  ouvir)  ì  Contar  com  o  suporte  de  um  alto  execu5vo  para  efeitos  de  credibilidade  e  

sensação  de  compromisso  Modelação  

18  

Observação  e  Etnografia  

ì  Observação  dos  u5lizadores  no  seu  local  de  trabalho  e  registar  manualmente  (limitado),  ou  com  gravadores  de  audio  ou  vídeo  (caro)  

ì  A  etnografia  é  uma  prá5ca  de  observação  os  aspectos  de  uma  cultura  dentro  da  cultura.  O  observador  é  membro  do  grupo  observador.  

ì  Técnica  relevante  para  elicitar  requisitos  sociais  e  organizacionais  mas  relacionados  com  a  forma  em  que  as  pessoas  realmente  trabalham  (e  porquê),  em  vez  da  forma  em  os  documentos  ou  processos  indicam  como  deveriam  trabalhar  

 Modelação  

19  

Modelação  

20  

Elicitação  de  

requisitos  

Análise  e  Negociação  de  

requisitos  

Especificação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio  •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,…  •  …  

Processo  Geral  da  engenharia  de  requisitos  

Bons  requisitos  (ISO  Std  830):  ì  Correctos  

ì  Não  ambíguos  

ì  Completos  

ì  Consistentes  

ì  Ordenados  pela  sua  importância  e/ou  estabilidade  

ì  Vericáveis  

ì  Suscepvveis  de  modificação  

ì  Rastreáveis  

Modelação  

21  

Análise  de  requisitos  

ì  O  propósito  da  análise  de  requisitos  é  encontrar  problemas,  falhas,  inconsistências,  etc.  

ì  A  análise  de  requisitos  deve  estar  interligada  com  a  elicitação  ì  É  importante  manter  “check  lists”  

Modelação  

22  

Check  list  de  requisitos  

ì  Cada  requisito  deve  ser  avaliado  em  relação  a  se:  ì  Inclui  informação  (prematura)  de  desenho  ou  implementação?  ì  É  um  único  requisito  ou  pode  ser  decomposto  em  vários  ì  É  um  requisito  real  ou  “desejo  cosmé5co”?  ì  Implica  tecnologia  não  standard?  ì  Está  alinhado  com  os  objec5vos  do  negócio?  ì  É  suscepvvel  de  uma  ou  várias  interpretações?  ì  É  realista  face  à  tecnologia,  custos,  ou  outras  restrições?  ì  É  possível  desenhar  testes  para  avalia-­‐lo?    

Modelação  

23  

Matriz  de  interacção  de  requisitos  

ì  Técnica  que  ilustra  a  interacção  entre  requisitos,  e  mostra  conflictos  e  sobre  posições  ì  0  =>  Requisitos  independentes  ì  1  =>  Requisitos  em  conflicto  ì  100=>  Requisitos  sobrepostos  (dizem  ou  mesmo)  ì  Nota:  a  sobreposição  pode  ser  total  ou  parcial  

Modelação  

24  

R  e  q  u  i  r  e  m  e  n  t   R  1   R  2   R  3   R  4   R  5   R  6  R  1   0   0   1  0  0   0   1   1  R  2   0   0   0   0   0   0  R  3   1  0  0   0   0   1  0  0   0   1  0  0  R  4   0   0   1  0  0   0   1   1  R  5   1   0   0   1   0   0  R  6   1   0   1  0  0   1   0   0  

Modelação  

25  

Elicitação  de  

requisitos  

Análise  e  Negociação  de  

requisitos  

Especificação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio  •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,…  •  …  

Processo  Geral  da  engenharia  de  requisitos  

Negociação  de  requisitos  

ì  Encontrar  soluções  para  questões  como  os  requisitos  em  conflicto  ou  sobrepostos,  mas  também  outros  problemas  como  requisitos  não  realistas….  

ì  Requer  tempo,  paciência  e  consensos  (como  imaginam  é  um  trabalho  que  o  computador  não  pode  fazer)  

ì  Processo:  ì  Informar:  colocar  as  questões  aos  stakeholders  relevantes  ì  Discussão:  ouvir  aos  stakeholders;  definir  prioridade  dos  

requisitos…  ì  Solução:  tomar  decisões      

ì  Implica  apagar,  mudar,  refinar,  ….  os  requisitos  em  questão  

Modelação  

26  

Modelação  

27  

Elicitação  de  

requisitos  

Análise  e  Negociação  de  

requisitos  

Especificação  de  requisitos  

Validação  de  requisitos  

Documento  de  requisitos  

Especificação  do  sistema  

•  Objectivos  do  negócio  •  Necessidades  dos  utilizadores  •  Informação  sobre  o  domínio  •  Informação  sobre  sistemas  existentes  •  Leis,  regulações,  standards,…  •  …  

Processo  Geral  da  engenharia  de  requisitos  

Especificação  de  requisitos:  Use  Cases  

ì  Especifica  requisitos  funcionais  relacionado-­‐os  com  cenários  de  u5lização/comportamentais  

ì  Descrevem  a  interacção  entre  o  sistema  e  en5dades  externas  (um  actor)  

ì  Descrição  provista  do  ponto  de  vista  do  actor.  Desta  forma  descreve  “quem”  faz  o  quê  e  como  é  afectado  pelo  sistema  

Modelação  

28  

Especificação  de  requisitos:  Use  Cases  II  

ì  No  documento  de  requisitos  podem  ser  apresentados    antes  que  a  lista  de  requisitos,  porque  facilitam  uma  rápida  compreensão  da  funcionalidade  requerida  

ì  Os  use  cases  são  úteis  para  ligar  o  documento  de  requisitos  com  a  modelação  detalhada  do  comportamento  do  sistema  

Modelação  

29  

Validação  dos  requisitos  

ì  Validação:  mostrar  que  os  requisitos  definem  com  exac5dão  o  sistema  pretendido    

ì  Técnicas:  ì  Revisão  de  requisitos:  análise  sistemá5ca  dos  requisitos  por  um  

ou  mais  revisores  ì  Proto5pagem:  validar  requisitos  com  potenciais  u5lizadores  ì  Generação  de  casos  de  teste:  assegurar  que  os  requisitos  são  

verificáveis  ì  Os  requisitos  são  expressados  em  ferramentas  que  incluem  

funções  para  verificar  a  consistência  

Modelação  

30  

Algumas  ferramentas  

ì  hUp://easyweb.easynet.co.uk/~iany/other/vendors.htm  

ì  hUp://www.volere.co.uk/tools.htm  

ì  hUp://www.soYdevtools.com/modules/weblinks/viewcat.php?

cid=93  

ì  hUp://soYware.forbes.com/requirements-­‐management-­‐soYware  

ì  hUp://www.paper-­‐review.com/tools/rms/read.php  

ì  …  Modelação  

31  

Exercício:  Funcional  vs  Não  funcional  

1  A  apresentação  da  lista  de  todos  os  clientes  em  ordem  alfabé5ca  não  pode  demorar  mais  de  5  segundos  (Não  funcional  –  Performance)  

2  Listar  todos  os  clientes  em  ordem  alfabé5ca  (Funcional)  3  O  sistema  de  gestão  de  base  de  dados  deve  ser  sempre  a  

versão  aprovada  de  MySQL  mais  recente  (Não  funcional  –  ambiente  operacional)  

4  Cada  vez  que  se  cria  um  novo  u5lizador,  deve  enviar-­‐se  uma  no5ficação  por  email  ao  departamento  de  marke5ng  (Funcional)  

Modelação  

32  

Exercício:  Funcional  vs  Não  funcional  

5  Todas  as  interfaces  devem  ser  bilingues  (Português  e  Inglês)  (Não  funcional-­‐usabilidade)  

6  O  cliente  coloca  pedidos  através  do  sistema  (Funcional)  7  O  cliente  coloca  pedido  até  2  min  depois  de  registar-­‐se  

(Não  funcional  –performance)  8  O  sistema  deverá  estar  indisponível  entre  24h00  e  1h00  

para  os  backups  (Não  funcional  -­‐  disponibilidade  )  9  A  auten5cação  far-­‐se-­‐á  via  disposi5vos  biométricos  

(não  funcional  –  segurança)  

Modelação  

33  

Exercício  Check  list  de  requisitos  

ì  Quais  elementos  da  checklist  falham  os  seguintes  requisitos?  1  O  u5lizador  introduz  pedidos  através  de  uma  interface  web  

ì  Introduz  informação  prematura  2  O  u5lizador  gere  os  seus  pedidos    

ì  Pode  ser  decomposto  em  vários,  é  suscepvvel  de  várias  interpretações  

3  O  u5lizador  pode  visualizar  a  sua  encomenda  em  três  dimensões  ì  É  requisito  cosmé5co  

Modelação  

34  

Exercício  Check  list  de  requisitos  

ì  Quais  elementos  da  checklist  falham  os  seguintes  requisitos?  4  O  u5lizador  introduz  os  seus  pedidos  através  de  uma  “brain  

computer  interface  (u5liza  tecnologia  não  standard)  5  O  u5lizador  analisa  os  pedidos  (suscepvvel  de  várias  

interpretações)  6  O  u5lizador  visualiza  os  seus  pedidos  (sobre-­‐posto  com  5)  7  O  sistema  organiza  os  pedidos  do  u5lizador    

ì  Pode  ser  decomposto  em  vários,  é  suscepvvel  de  várias  interpretações  

Modelação  

35