Avaliando TÃ©cnicas de Modelagem Organizacional ... - INF-Unioeste

More documents

Recommendations

Info

Uma incorreta identificação de requisitos de um software pode levar ao desenvolvimentode um produto que não atende aos reais objetivos para o qual foi planejado, resultando em umsoftware de baixa qualidade.A literatura possui várias definições para requisitos de software. Sommerville (2001)define requisitos de software como “um conjunto de atividades que o software devedesempenhar, com suas limitações e restrições, além de características não ligadasdiretamente às funções desempenhadas pelo software”.De acordo com (Sommerville e Sawyer, 1997), um requisito pode descrever uma:a) facilidade no nível do usuário: por exemplo, um corretor de gramática e ortografia;b) propriedade muito geral do sistema: por exemplo, o sigilo de informações;c) restrição específica no sistema: por exemplo, o tempo de varredura de um sensor;d) restrição no desenvolvimento do sistema: por exemplo: a linguagem C++ deverá serutilizada para o desenvolvimento do sistema.A IEEE (1997) define requisito como sendo:a) uma condição ou uma capacidade de que o usuário necessita para solucionar umproblema ou alcançar um objetivo;b) uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistemaou componente do sistema para satisfazer um contrato, um padrão, uma especificaçãoou outros documentos impostos formalmente;c) uma representação documentada de uma condição ou capacidade, conforme os itens(a) e (b).Macaulay (1996) possui uma definição bastante simples, na qual ele diz que requisito ésimplesmente algo que o cliente necessita. A visão de requisitos, segundo Davis (1993), nãose restringe a apenas o "quê" o sistema deva fazer, mas também a "como" deva fazer. Paraesse autor, a definição do IEEE não é muito boa, pois só trata da visão do “quê”.Já a IEEE (1984) define a Engenharia de Requisitos como “um processo de aquisição,refinamento e verificação das necessidades do cliente para um sistema de software,objetivando-se ter uma especificação completa e correta dos requisitos de software”.Segundo Boehm (1989), a Engenharia de Requisitos pode ser definida como “umaatividade que objetiva desenvolver uma especificação completa, consistente, não ambígua ecorreta dos requisitos, que sirva, inclusive, de base para um acordo entre as partes10
envolvidas no processo de desenvolvimento do software, onde se pactue, de forma concisa, "oque" o produto irá fazer”.Segundo Castro (1995), Engenharia de Requisitos é um campo amplo que compreendetodas as atividades necessárias para criar e manter a documentação de requisitos. Sua funçãoprincipal é aperfeiçoar os processos para o gerenciamento do ciclo de vida dos requisitos eaborda um ponto fundamental do desenvolvimento de software: a definição do que produzir.Para Kotonya e Sommerville (1998), a Engenharia de Requisitos é um termo relativamentenovo que foi criado para cobrir todas as atividades envolvidas em descobrimento,documentação e manutenção de um conjunto de requisitos para um sistema baseado emcomputador.A obtenção dos requisitos de software é uma tarefa complexa, visto que demanda de umconjunto de ideias que podem estar incompletas, sendo necessário transformar essas ideias emuma elaboração completa e consistente de técnicas de requisitos para um sistema de software.Dificilmente as especificações permanecem inalteradas durante o processo. Esta volatilidadepode ocasionar um custo e tempo maior.Segundo Kotonya e Sommerville (1998), erros nos requisitos são responsáveis pelosseguintes problemas:a) pelo atraso na entrega do sistema e pelo aumento do custo do desenvolvimento dosistema;b) pela insatisfação do cliente e dos usuários finais com o sistema. Eles podem não usarsuas facilidades ou podem ainda descartar por completo o sistema;c) pela falta de confiabilidade no uso do sistema, devido a erros regulares do sistema efalhas que levam à interrupção da operação normal do sistema;d) pelo aumento do custo de manutenção e evolução do sistema.Na seção seguinte, os diferentes tipos de requisitos de software serão classificados.2.1.1 Classificação de RequisitosDurante a fase de especificação dos requisitos, surge a necessidade de se estabelecer o tipode requisito de que se esteja tratando, a fim de melhorar a compreensão das necessidades docliente, bem como melhor modela-las. Numa visão mais tradicional, os requisitos sãoclassificados como funcionais e não funcionais, conforme apresentado por Sommerville(2001):11
Page 2 and 3: FERNANDO LUIZ GRANDOAVALIANDO TÉCN
Page 4 and 5: DEDICATÓRIAAos meus pais e minha i
Page 6 and 7: AGRADECIMENTOSA Deus, pela saúde e
Page 8 and 9: 3.24: Notações básicas para Caso
Page 10 and 11: Lista de Abreviaturas e SiglasB2BBP
Page 12 and 13: SumárioLista de Figuras ..........
Page 14 and 15: ResumoHoje em dia, o desenvolviment
Page 16 and 17: conjunto estruturado de atividades
Page 18 and 19: forma de satisfação de objetivos,
Page 20 and 21: será inserido não foi modelado e
Page 22 and 23: Já no Capítulo 4 o estudo compara
Page 26 and 27: a) Requisitos Funcionais (RF): são
Page 28 and 29: Kotonya e Sommerville (1998) descre
Page 30 and 31: Já Alencar (1999), propõe diretri
Page 32 and 33: Informações mais completas a resp
Page 34 and 35: confirmar teorias ou validar medida
Page 36 and 37: Sendo o GQM orientado a objetivos o
Page 38 and 39: No próximo capítulo são apresent
Page 40 and 41: Essa análise deve ser conduzida an
Page 42 and 43: Nas seções seguintes, serão apre
Page 44 and 45: Figura 3.2: Parte de um MO de uma B
Page 46 and 47: a) Entidade: é alguma coisa do dom
Page 48 and 49: componentes do Modelo de Objetivos;
Page 50 and 51: Figura 3.7: Exemplo de parte de um
Page 52 and 53: mesmo tempo seja capaz de lidar com
Page 54 and 55: Swimlanes (raias) (Tabela 3.3): fun
Page 56 and 57: Um exemplo de segmento de processo
Page 58 and 59: 3.4 A Técnica i*A técnica i*, pro
Page 60 and 61: Na dependência de tarefa, o Depend
Page 62 and 63: 3.4.2 O Modelo de Razões Estratég
Page 64 and 65: observa nas dependências do tipo o
Page 66 and 67: Os principais elementos do modelo s
Page 68 and 69: egras refletem políticas do negóc
Page 70 and 71: IFTHENELSE(sinistro é assegurado p
Page 72 and 73: alcançar o objetivo-alvo “Realiz
Page 74 and 75:
A especificação de um caso de uso
Page 76 and 77:
Analisando brevemente algumas das t
Page 78 and 79:
Capítulo 4Estudo Comparativo e Ava
Page 80 and 81:
Figura 4.1: Ciclo de vida de projet
Page 82 and 83:
solução: desenvolver um sistema d
Page 84 and 85:
M09: As respostas coletadas de um g
Page 86 and 87:
Figura 4.2: Diagrama BPMN para o m
Page 88 and 89:
Figura 4.4: Diagrama SR para o mód
Page 90 and 91:
Figura 4.6: Diagrama SR para o mód
Page 92 and 93:
Regra de Negócio 04: REALIZAR PEDI
Page 94 and 95:
Figura 4.9: Diagrama de Casos de Us
Page 96 and 97:
No Modelo de Conceitos podem ser vi
Page 98 and 99:
formuladas, com o intuito de fornec
Page 100 and 101:
possibilitando também a divisão d
Page 102 and 103:
sendo inserido. Kaabi, Souveyet e R
Page 104 and 105:
Para o estudo comparativo foi utili
Page 106 and 107:
Capítulo 5Considerações FinaisAp
Page 108 and 109:
de Uso de Negócio não consegue re
Page 110 and 111:
BIDER, I., JOHANNESSON, P. Tutorial
Page 112 and 113:
ESTRADA, H., MARTÍNEZ, A., PASTOR,
Page 114 and 115:
PENADÉS, M. C., CANÓS, J. H., SÁ
Page 116:
WHITE, S. Business Process Modeling
show all

Avaliando TÃ©cnicas de Modelagem Organizacional ... - INF-Unioeste

Create successful ePaper yourself

Delete template?

Save as template?