a) Requisitos Funcionais (RF): são as <strong>de</strong>clarações das funções que o sistema <strong>de</strong>veoferecer, como ele se comporta com entradas particulares e como o sistema <strong>de</strong>ve secomportar em situações específicas. O termo “função” é usado no sentido genérico daoperação que po<strong>de</strong> ser realizada pelo sistema, seja por meio <strong>de</strong> comandos dosusuários, seja pela ocorrência <strong>de</strong> eventos internos ou externos ao sistema. Em algunscasos, os requisitos funcionais po<strong>de</strong>m também, explicitamente, <strong>de</strong>finir o que o sistemanão <strong>de</strong>ve fazer;b) Requisitos Não-Funcionais (RNF): são as restrições nas funções oferecidas pelosistema. Incluem restrições <strong>de</strong> tempo; restrições no processo <strong>de</strong> <strong>de</strong>senvolvimento;padrões; e <strong>de</strong> qualida<strong>de</strong>s globais <strong>de</strong> um software, como custo, confiabilida<strong>de</strong>,manutenibilida<strong>de</strong>, portabilida<strong>de</strong>, usabilida<strong>de</strong>, <strong>de</strong>sempenho, <strong>de</strong>ntre outras. Alguns<strong>de</strong>sses requisitos são provavelmente traduzidos em funções (operacionalizados), aolongo do processo <strong>de</strong> <strong>de</strong>senvolvimento <strong>de</strong> software (Chung et al., 2000).Resumidamente, os requisitos funcionais <strong>de</strong>screvem “o que” o sistema <strong>de</strong>ve fazer,enquanto que os requisitos não funcionais fixam restrições sobre “como” os requisitosfuncionais serão implementados.Entretanto, <strong>de</strong>vido às novas concepções a respeito <strong>de</strong> estratégias na gestão dasorganizações, vários estudiosos afirmam que a classificação tradicional não mais apresentarespostas à compreensão <strong>de</strong> todas as facetas que compõem o ambiente das atuaisorganizações. Para melhor compreensão da organização, é necessário não analisar somenterequisitos funcionais, mas também os aspectos organizacionais e sociais.Dessa maneira, a classificação mais mo<strong>de</strong>rna <strong>de</strong> requisitos agrega a conceituação <strong>de</strong>requisitos organizacionais (Loucopoulos e Karakostas, 1995), (Kotonya e Sommerville,1998), (Davis, 1993):c) Requisitos Organizacionais: dizem respeito às metas da empresa, suas políticasestratégicas adotadas, os relacionamentos entre os seus atores junto com seusrespectivos objetivos.Segundo essa nova visão, a Engenharia <strong>de</strong> Requisitos po<strong>de</strong> ser dita como a área doconhecimento preocupada na comunicação com agentes organizacionais, com respeito a suasvisões, intenções e ativida<strong>de</strong>s relativas às suas necessida<strong>de</strong>s <strong>de</strong> suporte <strong>de</strong> computadores,<strong>de</strong>senvolvimento e manutenção <strong>de</strong> uma especificação <strong>de</strong> requisitos a<strong>de</strong>quada a um sistema(Loucopoulos e Karakostas, 1995).12
Po<strong>de</strong>-se afirmar que os requisitos na visão mo<strong>de</strong>rna não se preocupam apenas com "como"o sistema <strong>de</strong>ve fazer, mas sim com "o que" o sistema <strong>de</strong>ve fazer, associado com "o porque"fazer, compreen<strong>de</strong>ndo a intencionalida<strong>de</strong> dos fatos organizacionais.A inter<strong>de</strong>pendência entre as organizações, entre as unida<strong>de</strong>s internas <strong>de</strong> uma organização eentre os membros <strong>de</strong> uma equipe <strong>de</strong> trabalho é cada vez maior no atual estágio <strong>de</strong><strong>de</strong>senvolvimento da socieda<strong>de</strong>. A principal razão para se consi<strong>de</strong>rar os requisitosorganizacionais, está na ajuda à compreensão <strong>de</strong> interações complexas entre as organizações eas pessoas envolvidas, on<strong>de</strong> projetistas e <strong>de</strong>senvolvedores <strong>de</strong>vem dar atenção especial aoscomponentes organizacionais (razões, motivações, porquês) no <strong>de</strong>senvolvimento <strong>de</strong> seusprodutos.2.1.2 Processo <strong>de</strong> Engenharia <strong>de</strong> RequisitosSegundo a ISO (1988), processo é <strong>de</strong>finido como "um grupo <strong>de</strong> ativida<strong>de</strong>s interrelacionadasque se caracterizam por uma série <strong>de</strong> entradas específicas que agregam valor efornecem uma série <strong>de</strong> saídas específicas para clientes externos e internos".O Processo <strong>de</strong> Engenharia <strong>de</strong> Requisitos, segundo Sommerville e Sawyer (1997), é umconjunto estruturado <strong>de</strong> ativida<strong>de</strong>s para extrair, validar e manter um documento <strong>de</strong> requisitos.Uma completa <strong>de</strong>scrição do processo po<strong>de</strong>rá incluir quais ativida<strong>de</strong>s são realizadas, aestruturação ou particionamento, quem é responsável, as entradas e saídas <strong>de</strong>sta ativida<strong>de</strong> e asferramentas usadas para suportar a engenharia <strong>de</strong> requisitos.Tabela 2.1: Entradas e Saídas do Processo <strong>de</strong> Engenharia <strong>de</strong> Requisitos. (Kotonya e Sommerville, 1998)ENTRADAInformações dossistemas existentesNecessida<strong>de</strong>s dosstakehol<strong>de</strong>rsPadrões organizacionaisNormas e regulamentosInformações do domínioSAÍDARequisitos <strong>de</strong>finidosEspecificação do sistemaMo<strong>de</strong>los do sistema13DESCRIÇÃOInformação sobre a funcionalida<strong>de</strong> dos sistemas a serem substituídos ou <strong>de</strong>outros sistemas que interagem com o sistema que está sendo especificado.Descrição do que os stakehol<strong>de</strong>rs necessitam do sistema para suportar seustrabalhos.Padrões usados na organização relativos às práticas <strong>de</strong> <strong>de</strong>senvolvimento <strong>de</strong>sistemas, gerenciamento da qualida<strong>de</strong>, etc.Regulamentações externas tais como regulamentações <strong>de</strong> saú<strong>de</strong> esegurança que se aplicam ao sistema.Informações gerais sobre o domínio da aplicação do sistema.DESCRIÇÃOUma <strong>de</strong>scrição dos requisitos do sistema que seja entendida pelosstakehol<strong>de</strong>rs e que tenha sido acordado por estes.Esta é uma especificação mais <strong>de</strong>talhada da funcionalida<strong>de</strong> do sistema.Um conjunto <strong>de</strong> mo<strong>de</strong>los, tais como, mo<strong>de</strong>lo <strong>de</strong> fluxo <strong>de</strong> dados, mo<strong>de</strong>lo <strong>de</strong>objeto, mo<strong>de</strong>lo <strong>de</strong> processo, etc., que <strong>de</strong>screve o sistema sob diferentesperspectivas.
- 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 24 and 25: Uma incorreta identificação de re
- 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