Análise e Concepção de Sistemas Página 20 Um sistema pequeno certamente produzirá a solução para uma pequena quantidade de problemas, um sistema grande certamente atingirá uma grande quantidade de problemas.
3.3 3.3 3.3
3.3Tipos de RequisitosTipos de RequisitosTipos de RequisitosTipos de Requisitos
Uma maneira de dividir os requisitos do sistema é separá-los entre requisitos funcionais e não funcionais.
Um requisito funcional requisito funcional requisito funcional requisito funcional representa algo que o sistema deve fazer, ou seja, está relacionado com um processo/funcionalidade que o sistema deve executar ou com informação que o sistema deve manter. Exemplos típicos incluem a emissão de relatórios e a realização e manutenção de cadastros.
Requisitos não funcionais Requisitos não funcionais Requisitos não funcionais
Requisitos não funcionais falam da forma como os requisitos funcionais devem ser alcançados. Eles definem propriedades e restrições do sistema. Muitos requisitos não funcionais são também requisitos de qualidade, como exigências de desempenho e robustez. Outros são restrições ou exigências de uso de uma ou outra tecnologia. Existem muitas formas de se dividir os requisitos não funcionais, a figura a seguir apresenta uma dessas formas Segundo G. Kotonya e I. Sommerville.
Figura – Requisitos Não Funcionais Segundo G. Kotonya e I. Sommerville.
Análise e Concepção de Sistemas Página 21 3.4
3.4 3.4
3.4Problemas com os utilizadoresProblemas com os utilizadoresProblemas com os utilizadoresProblemas com os utilizadores
Um problema comum é o utilizador pedir algo como requisito porque pensa ser uma forma de implementar uma desejada funcionalidade. Esse erro, além de comum, é provavelmente prejudicial ao sistema se não for detectado.
A verdade é que apesar de o analista ter que atender aos stakeholders, não tem que atender exactamente ao que eles dizem, mas sim ao que eles realmente precisam. O trabalho de análise é um trabalho de investigação, realizado em conjunto os utilizadores.
3.5 3.5 3.5
3.5Descrição de RequisitosDescrição de RequisitosDescrição de RequisitosDescrição de Requisitos
Normalmente as especificações de requisitos são escritas em linguagem natural (inglês ou português, por exemplo). O problema, claro, é que a forma como falamos e normalmente escrevemos é bastante ambígua. Isso exige que se adoptem algumas técnicas básicas, principalmente um formato padronizado, por um estilo de linguagem e uma organização que facilite a manipulação do conjunto de requisitos.
Algumas indicações para escrever requisitos são: • Use frases e parágrafos curtos.
• Use a voz activa. • Use verbos no futuro.
• Use os termos de forma consistente e mantenha um glossário.
• Para cada requisito, avalie se a partir de sua definição é possível determinar se foi realizado ou não.
• Garanta que todos os requisitos são verificáveis imaginando (e possivelmente documentando) uma forma de fazê-lo.
• Verifique requisitos agregados (termos como “eeee” e “ouououou” são uma boa indicação) e divida-os.
• Mantenha um nível de detalhe único em todos os requisitos
Uma forma que se pode adoptar para descrever cada requisito segundo (Robertson, J. and Robertson, S. Volere Requirements Specification, 2004) é:
• Número identificador,
Para facilitar a discussão, identificamos todos os requisitos de forma única.
• Tipo
Classificando-o como funcional, não funcional,...
Análise e Concepção de Sistemas Página 22
• Descrição
• Justificativa • Fonte do requisito
A pessoa ou o grupo que o originou. • Critério de aceitação
Uma medida que possa ser usada para garantir que o requisito foi alcançado.
• Satisfação do utilizador
Um grau, de 1 (nenhum interesse) a 5 (extremamente satisfeito), por exemplo, indicando a satisfação do cliente se esse requisito for alcançado.
• Insatisfação do utilizador
Um grau, de 1 (nenhum interesse) a 5 (extremamente insatisfeito), por exemplo, indicando a satisfação do cliente se esse requisito não for alcançado.
• Dependências
Referências a outros requisitos que dependem de alguma forma desse requisito.
• Conflitos
Referência aos requisitos que de alguma forma conflituam com este. • Material de apoio
Listagem de material de apoio para atender este requisito. • Histórico
Documentação da criação e das mudanças efectuadas
3.6 3.6 3.6
3.6Documento de RequisitosDocumento de RequisitosDocumento de RequisitosDocumento de Requisitos
É um documento formal usado para registar e comunicar os requisitos dos/aos stakeholders.
• Descreve:
Os serviços e funções que o sistema deve providenciar As restrições nas quais o sistema deve funcionar
Todas as propriedades do sistema, i.e., propriedades emergentes Definições de outros sistemas, com o qual o sistema alvo deverá comunicar e ou integrar-se
Análise e Concepção de Sistemas Página 23 Restrições sobre o(s) processo(s) usado para desenvolver o sistema Descrição das plataformas computacionais (hardware, redes, ...) sobre as quais o sistema deverá correr
O documento de requisitos pode ser escrito segundo a norma IEEE/ANSI 830IEEE/ANSI 830IEEE/ANSI 830IEEE/ANSI 830----1993199319931993, segundo a forma:
1. Introdução
1.1 Propósito do documento de requisitos 1.2 Contexto do produto
1.3 Definições, acrónimos e abreviaturas 1.4 Referências
1.5 Visão geral do documento 2. Descrição geral
2.1 Perspectiva do produto 2.2 Funções do produto
2.3 Características dos utilizadores 2.4 Restrições gerais
2.5 Assunções e dependências 3. Requisitos específicos
Envolve requisitos funcionais, não-funcionais e de interface 4. Apêndices
3.7 3.7 3.7
3.7Dependência de RequisitosDependência de RequisitosDependência de RequisitosDependência de Requisitos
É importante notar que os requisitos não são independentes uns dos outros. Muitos requisitos só podem ser implementados se outros requisitos forem implementados antes. Por exemplo, é impossível fazer um relatório de vendas, sem que se faça o cadastro as vendas previamente no sistema. Uma das actividades mais importantes da gestão de requisitos é manter esse relacionamento de dependência, que influenciará todo desenvolvimento e Processo do sistema.
Para isso existem algumas soluções possíveis. Uma delas é manter uma tabela de dependência de requisitos, outra solução passa por manter uma base de dados de requisitos que inclua relações de dependência.
3.8 3.8 3.8
3.8Prioridades de RequisitosPrioridades de RequisitosPrioridades de RequisitosPrioridades de Requisitos
Devem ser levados em conta os seguintes factores que influenciam na determinação de prioridades (Robertson, J. and Robertson, S. Prioritization Analysis, 2004):
Análise e Concepção de Sistema
• Valor para o comprador
• Tempo para implementar
• Facilidade técnica de implementar
• Facilidade do negócio para implem
• Valor para o negócio
• Obrigação por alguma autoridade externa
3.9 3.9 3.9
3.9Questionando RequisitosQuestionando RequisitosQuestionando RequisitosQuestionando Requisitos Em vários momentos do proje
lista a ser abertamente questionada respondem as perguntas 5W2H5W2H5W2H5W2H
Se o requisito passar por todas as questões em alguns, pode ser que a pergunta não seja analisado cada caso.
Os maiores problemas serão
Qualquer ambiguidade é um risco, porém no início do proje
necessária, pois decisões importantes ainda não foram tomadas. Cabe ao analista saber “em que pé está” o proje
3.10 3.10 3.10
3.10 O processo de Levantamento de RequisitosO processo de Levantamento de RequisitosO processo de Levantamento de RequisitosO processo de Levantamento de Requisitos Para levantar requisitos é necessária uma
necessidades dos utilizadores
de Sistemas Valor para o comprador Tempo para implementar
Facilidade técnica de implementar Facilidade do negócio para implementar Valor para o negócio
Obrigação por alguma autoridade externa
Questionando Requisitos Questionando Requisitos Questionando Requisitos Questionando Requisitos
Em vários momentos do projecto, é importante tratar a lista de requisitos como uma lista a ser abertamente questionada. Deve-se analisar de que forma os requisitos
5W2H 5W2H5W2H
5W2H (Who, When, Where, What, Which, How, How much todas as questões, temos um requisito muito bom. Se falhar em alguns, pode ser que a pergunta não seja ainda pertinente, porém deve ser
serão sempre encontrados na ambiguidade dos requisitos. idade é um risco, porém no início do projecto a ambigu
pois decisões importantes ainda não foram tomadas. Cabe ao analista o projecto e qual o nível de detalhe adequado aos requisitos
O processo de Levantamento de Requisitos O processo de Levantamento de Requisitos O processo de Levantamento de Requisitos O processo de Levantamento de Requisitos
vantar requisitos é necessária uma interacção entre aqueles que conhecem a utilizadores e stakeholders.
Página 24 to, é importante tratar a lista de requisitos como uma analisar de que forma os requisitos Who, When, Where, What, Which, How, How much). , temos um requisito muito bom. Se falhar pertinente, porém deve ser
idade dos requisitos. cto a ambiguidade é pois decisões importantes ainda não foram tomadas. Cabe ao analista
to e qual o nível de detalhe adequado aos requisitos.
Análise e Concepção de Sistemas Página 25 É um processo interactivo de comunicação, onde, por aproximações sucessivas, a equipa de desenvolvimento constrói um modelo aceite pelos utilizadores (ver figura abaixo).
O processo de levantamento de requisitos faz parte da engenharia de requisitos e requer: Levantamento, análise e negociação de requisitos.
Podemos esquematizar o processo de engenharia de requisitos da seguinte maneira:
Figura – Processo de ER ,adaptado de KOTONYA; SOMMERVILLE, 1998.
Análise e Concepção de Sistemas Página 26 Uma vez identificados os requisitos, é possível iniciar a actividade de análise, quando os requisitos levantados são usados como base para a modelagem do sistema. Tanto no levantamento quanto na análise de requisitos, é importante documentar requisitos e modelos.
Conforme visto anteriormente, sobre a documentação de requisitos, dois documentos são normalmente utilizados: o Documento de Requisitos e o Documento de Especificação de Requisitos, que regista os requisitos de sistema e os vários diagramas resultantes do trabalho de análise.
Os documentos produzidos são, então, verificados e validados. Adicionalmente, um esforço de garantia da qualidade deve ser realizado, visando garantir conformidade em relação a padrões e ao processo estabelecidos pela organização.
Caso, utilizadores e stakeholders estejam de acordo com os requisitos, o processo de desenvolvimento pode avançar; caso contrário, deve-se retornar à actividade correspondente para resolver os problemas identificados.
Em paralelo a todas as actividades anteriormente mencionadas, há a gestão de requisitos, que se ocupa em gerir as mudanças nos requisitos.
De forma resumida temos o seguinte esquema para o processo de ER.
Análise e Concepção de Sistemas Página 27 3.11
3.11 3.11
3.11 Técnicas de levantamento de requisitosTécnicas de levantamento de requisitosTécnicas de levantamento de requisitosTécnicas de levantamento de requisitos Questionários
Análise de documentos Entrevistas
JAD (Joint Application Design) – Dinâmica de grupos. Casos de Utilização (cenários)
Etnografia Prótotipagem
Planeamento de Questionários Planeamento de Questionários Planeamento de Questionários Planeamento de Questionários
• Seleccionar participantes
Elementos representativos dos stakeholders • Definir questionário
Selecção das questões • Administrar o questionário
Definir estratégias para obter um bom número de respostas • Dar seguimento (Follow-up) do questionário
Enviar os resultados do questionário aos participantes
Obs: Os questionários permitem atingir mais pessoas que serão afectadas pelo sistema. Conseguem-se obter informações como postura, crenças, comportamentos e características dessas pessoas.
Análise de documentos: Análise de documentos: Análise de documentos: Análise de documentos:
• Contém informação do sistema “as-is”
• Documentos típicos:
Formulários Relatórios
Manuais de procedimento
• Procurar elementos adicionados aos formulários pelos utilizadores • Procurar elementos não utilizados
Análise e Concepção de Sistema Planeamento de Entrevistas Planeamento de Entrevistas Planeamento de Entrevistas Planeamento de Entrevistas
• Ler material de suporte
• Estabelecer os objectivos da entrevista • Decidir quem entrevistar
• Preparar o entrevistado
• Decidir os tipos de questões e a sua estrutura
Obs: Entrevistas é o tipo mais comum que consiste em conversas direccionadas com um propósito específico e com formato “pergunta
descoberta de problemas a serem tratados, levantar procedimentos importantes e saber a opinião e expectativas do entrevistado sobre o sistema. Tem como passos principais, o planeamento, condução da entrevista, e a elaboração de um
Existem técnicas para apoio e estruturas bem definidas para essa actividade. Exemplo:
de Sistemas Planeamento de Entrevistas Planeamento de Entrevistas Planeamento de Entrevistas Planeamento de Entrevistas
Ler material de suporte
ectivos da entrevista Decidir quem entrevistar
Preparar o entrevistado
Decidir os tipos de questões e a sua estrutura
Obs: Entrevistas é o tipo mais comum que consiste em conversas direccionadas com um propósito específico e com formato “pergunta-resposta”. Tem como objectivo, a descoberta de problemas a serem tratados, levantar procedimentos importantes e saber a opinião e expectativas do entrevistado sobre o sistema. Tem como passos principais, o planeamento, condução da entrevista, e a elaboração de um
Existem técnicas para apoio e estruturas bem definidas para essa actividade.
Análise e Concepção de Sistema
Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista:
• Estrutura em pirâmide
Começar com uma pergunta especí genérica.
Usar com entrev • Estrutura em fúnil
Começar com uma pergunta ge específica.
Forma amigável de começar Usar quando os entrevistados
• Estrutura em diamante
Combina as ap
Mantém o entrevistado interessado usando perguntas variadas
O esquema apresentado no livro ( seguinte:
de Sistemas
Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista: Vamos ver como estruturar uma entrevista:
Estrutura em pirâmide
Começar com uma pergunta específica, fechar com uma pergunta
Usar com entrevistados relutantes.
Começar com uma pergunta genérica, fechar com uma pergunta
Forma amigável de começar a entrevista.
Usar quando os entrevistados têm uma relação efectiva com o assunto Estrutura em diamante
Combina as aproximações anteriores, por isso demora mais tempo Mantém o entrevistado interessado usando perguntas variadas
O esquema apresentado no livro (Systems analysis and design with UMLSystems analysis and design with UMLSystems analysis and design with UMLSystems analysis and design with UML
Página 29 fica, fechar com uma pergunta
nérica, fechar com uma pergunta
m uma relação efectiva com o assunto
roximações anteriores, por isso demora mais tempo Mantém o entrevistado interessado usando perguntas variadas
Análise e Concepção de Sistema
Exemplo do documento de entrevistas:
Cenários Cenários Cenários Cenários
Criam-se exemplos reais com uma abstracta descrição das funções providas pelo sistema. São importantes para identificar o estado do sistema antes do cenário, o fluxo normal dos eventos do cenário, excepções no fluxo normal, informações sobre as actividades que ocorrem em paralelo e descrição do estado após o cenário.
Prototipagem Prototipagem Prototipagem Prototipagem
• Protótipo
Versão inicial de um sistema para experimentação
• Permite aos utilizadores identificar os pontos fortes e fracos do sistema • Algo concreto que pode ser criticado
• Protótipos devem estar disponíveis durante o levantamento de requisitos
• Utilizadores podem experimentar “o sistema”
• Estabelece a fiabilidade e utilidade do sistema • Essencial para definir o “
• Pode ser usado nos teste
documentação.
• Obriga a estudar com detalhe os requisitos Encontrar inconsistências e omissões
de Sistemas
Exemplo do documento de entrevistas:
se exemplos reais com uma abstracta descrição das funções providas pelo sistema. São importantes para identificar o estado do sistema antes do cenário, o fluxo normal dos eventos do cenário, excepções no fluxo normal, informações sobre as
ocorrem em paralelo e descrição do estado após o cenário.
Versão inicial de um sistema para experimentação.
Permite aos utilizadores identificar os pontos fortes e fracos do sistema Algo concreto que pode ser criticado.
pos devem estar disponíveis durante o levantamento de requisitos Utilizadores podem experimentar “o sistema”.
Estabelece a fiabilidade e utilidade do sistema.
Essencial para definir o “look and feel” da interface com o utilizador
Pode ser usado nos testes do sistema e no desenvolvimento de
Obriga a estudar com detalhe os requisitos Encontrar inconsistências e omissões.
Página 30 se exemplos reais com uma abstracta descrição das funções providas pelo sistema. São importantes para identificar o estado do sistema antes do cenário, o fluxo normal dos eventos do cenário, excepções no fluxo normal, informações sobre as
ocorrem em paralelo e descrição do estado após o cenário.
Permite aos utilizadores identificar os pontos fortes e fracos do sistema.
pos devem estar disponíveis durante o levantamento de requisitos.
” da interface com o utilizador.
Análise e Concepção de Sistemas Página 31 Prototipagem te
Prototipagem te Prototipagem te
Prototipagem tem as seguintes desvantagens:m as seguintes desvantagens:m as seguintes desvantagens: m as seguintes desvantagens:
• Custos de aprendizagem.
• Custos de desenvolvimento.
• Estende a planificação do desenvolvimento.
• São incompletos
Pode não ser possível prototipar requisitos críticos. Abordagens à prototipagem
Abordagens à prototipagem Abordagens à prototipagem Abordagens à prototipagem
• Prototipagem em papel
Representação em papel do interface do sistema. • Prototipagem ‘Wizard of Oz’
Uma pessoa (wizard) simula as respostas do sistema de acordo com as entradas do utilizador.
• Prototipagem executável
Utilização de uma ambiente de desenvolvimento rápido para desenvolver um protótipo executável.
3.12 3.12 3.12
3.12 Análise e negociação de requisitosAnálise e negociação de requisitosAnálise e negociação de requisitosAnálise e negociação de requisitos
Em essência, a fase de análise é uma actividade de modelagem. A modelagem nesta fase é dita conceitual, pois se preocupa com o domínio do problema e não com soluções técnicas para o mesmo.
• A análise tem os seguintes objectivos:
Encontrar problemas, falhas e inconsistências • A análise é intercalada com o levantamento de requisitos
• A análise é suportada por uma lista de verificação de problemas As listas de verificação têm os seguintes itens:
• Desenho prematuro do sistema
Verificar se o requisito inclui informação prematura sobre o design ou a implementação
• Combinação de requisitos
Verificar se a descrição do requisito descreve um único requisito ou se pode ser dividida em diferentes requisitos
• Requisitos desnecessários
Verificar se o requisito é apenas uma adição “cosmética” ao sistema.
• Utilização de HW não-standard
Análise e Concepção de Sistemas Página 32 Para tomar esta decisão é necessário saber os requisitos da plataforma a suportar
• Conformidade com os objectivos de negócio
Verificar se o requisito é consistente com os objectivos do negócio definidos na introdução do documento de requisitos
• Requisitos ambíguos
Verificar se o requisito pode ser lido de forma diferentes por diferentes pessoas
Quais as interpretações possíveis? • Requisitos realistas
Verificar se o requisito é realista tendo em conta a tecnologia a ser usada para implementar o sistema
• Requisitos “testáveis”
Verificar se os engenheiros de teste podem derivar um teste a partir da descrição do requisito que mostre que o sistema satisfaz esse requisito
Negociação de requ Negociação de requ Negociação de requ Negociação de requisitosisitosisitosisitos
• Conflitos não são falhas
Reflectem diferentes necessidades e prioridades.
• Negociação de requisitos tenta encontrar uma solução de concordância
• A negociação de requisitos pode ser um processo demorado
A planificação de processo de ER deve ter em conta o tempo dispendido na negociação
3.13 3.13 3.13
3.13 ResumoResumoResumoResumo::::
O processo de ER deve garantir que não haja: Falta de envolvimento dos clientes ou dos técnicos Omissão de necessidades do negócio
Conflitos de linguagem Requisitos não podem ser:
• Ambíguos, incorrectos, implícitos, inconsistentes, incompletos, não mensuráveis.
Falta de gestão de requisitos
• Responsabilidades indefinidas
• Cronogramas não cumpridos
Análise e Concepção de Sistemas Página 33 Para exemplos de documento de requisitos ver os documentos
“ACS-Aula04-Cap3-exemplo-documentoRequisitos1” e
ACS-Aula04-Cap3-exemplo-documentoRequisitos2” no site da disciplina (https://sites.google.com/site/isupeacs).
Exerc Exerc Exerc Exercício: ício: ício: ício: C
C C
Contextoontextoontexto: Diante da necessidade da utilização de sistemas automáticos de prevenção ontexto e contenção de incêndios, o projecto FireGuardFireGuardFireGuardFireGuard vem com a proposta de se inserir nesse mercado, criando um produto, cuja missão é prover a detecção e contenção automática de incêndios com segurança em tempo real e tolerante a falhas.
