Buscar

Aula 02 Análise de Requisitos

Prévia do material em texto

ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
1 
 
- MÓDULO 2 - 
ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 
 
1. INTRODUÇÃO 
 
 Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de 
um software. Na maioria das vezes o cliente não sabe o que é necessário, os usuários finais não 
sabem descrever as funcionalidades que lhe trarão benefícios e suas necessidades certamente 
mudarão ao longo do projeto. 
 Diante deste cenário, antes de qualquer trabalho técnico é importante a aplicação de um 
conjunto de tarefas da Engenharia de Requisitos. Estas levam a um entendimento de qual será o 
impacto do software sobre o negócio, o que o cliente quer e como os usuários finais irão interagir 
com o sistema. Tudo isso objetivando especificações precisas do comportamento do software e 
sua evolução. 
Segundo Pressman, na perspectiva do processo de software, a engenharia de requisitos é 
uma ação importante que se inicia durante a atividade de comunicação e continua na modelagem, 
construindo uma ponte para o projeto e para a construção. 
 
2. REQUISITO 
 
Um requisito é definido como “uma condição ou uma capacidade com a qual o sistema 
deve estar de acordo”. Pode ser desde uma indicação abstrata, de alto nível, até uma 
especificação matemática detalhada. 
Em resumo, definem o que o sistema deve fazer e sob quais limitações ele é requisitado a 
operar. 
São exemplos de requisitos: 
- “O sistema deve ser capaz de dar baixa no pagamento de uma Nota Fiscal”; 
- “O sistema deve ser capaz de realizar pagamentos por transferências bancárias”; 
- “O sistema deve suportar pelo menos 20 transações por segundo”; 
- “O sistema deve realizar backup uma vez por dia.” 
 
3. IDENTIFICAÇÃO E ELICITAÇÃO DE REQUITOS 
 
 Da perspectivas da Engenharia de Software, a Elicitação de Requisitos é talvez a parte 
mais crítica do processo de desenvolvimento de software. Estudos indicam que os requisitos que 
foram detectados depois do software implementado ou erros na análise de requisitos são até 20 
vezes mais caros de se corrigir do que qualquer outro tipo de erro. Enfim, o sucesso das etapas 
posteriores depende da qualidade dos requisitos gerados. 
 A Elicitação de Requisitos corresponde a identificar junto aos clientes/usuários quais são 
os objetivos do sistema, o que deve ser acompanhado, como o sistema se encaixa no contexto de 
necessidades do negócio e como será a utilização do sistema no dia-a-dia. 
No processo de especificação dos requisitos alguns fatores constituem um problema. São 
aspectos a serem observados: 
 - Virem de várias fontes; 
 - Não refletirem as reais necessidades dos usuários do sistema; 
 - Serem inconsistentes e/ou incompletos; 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
Deverá constar no documento de visão
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
2 
 
- Podem ter um alto custo para mudanças, depois de acordados; 
- Mal entendidos entre clientes e desenvolvedores. 
 
 Neste cenário uma ilustração bastante pertinente é a apresentada na figura 1. 
 
Figura 1 - Requisitos 
 
Para ajudar a superar este problemas, os desenvolvedores deve abordar os requisitos de 
forma simples, prática e organizada. Os seguinte passos são recomendados: 
 - Avaliar a viabilidade técnica e de negócio para o sistema proposto; 
 - Identificar as pessoas que vão auxiliar a explicar os requisitos e compreender seus 
preconceitos organizacionais; 
 - Definir o ambiente técnico no qual o sistema será instalado; 
 - Identificar regras de domínio que limitam a funcionalidade ou desempenho do software a 
ser construído; 
 - Definir um ou mais métodos de elicitação dos requisitos; 
 - Solicitar a participação de várias pessoas a partir de diversos pontos de vista; 
 - Identificar requisitos ambíguos que serão candidatos a prototipação. 
 
 Os documentos criados como consequência da elicitação de requisitos dependerá do 
tamanho do software a ser construído: 
 - As necessidades e viabilidades estruturadas; 
 - Limite de escopo do software; 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
3 
 
 - Lista de clientes/usuários que participaram da elicitação de requisitos; 
 - Cenários de usos capazes de fornecer uma ideia de uso sistema; 
 - Protótipo que porventura tenha sido desenvolvido. 
 
 Cada documento deve ser revisado por todos que participaram desta fase do projeto. 
 Uma boa elicitação de requisitos parte das seguinte características: 
 - Definir técnicas de coleta baseadas em fatores operacionais, táticos e financeiros; 
 - Criar um planejamento capaz de alcançar as metas estabelecidas, como prazo, curso e 
qualidade; 
 - Promover a integração e comprometimento de todos os envolvidos no processo; 
 - Identificar os documentos e procedimentos que definem as politicas de negócio da 
empresa. 
 
3.1. Técnicas para Elicitação de Requisitos 
 
Para realizar a elicitação de requisitos é possível a aplicação de algumas técnicas, a saber: 
- Reuniões formais; - Reuniões informais; 
- Entrevistas; - Questionários; 
- Brainstorming; - Cenários (Caso de Uso); 
 - Prototipação; - Análise de Documentos; 
- Manual de Sistemas Legados. - JAD (Join Application Development); 
- Observações e análises sociais (etnografia); 
- Workshops (Brainstorming, interpretação de papéis, revisão de requisitos existentes); 
 
3.2. Fases da Elicitação de Requisitos 
 
 Um projeto de Elicitação de Requisitos tem as seguinte fases: 
 - Planejamento (Como deve ser feito): Identificar fontes e técnicas; 
 - Elicitação de Requisitos (O que deve ser coletado): Identificar funcionalidades, identificar 
requisitos e riscos; 
 - Documentação (Como devo documentar): Documento de visão. 
 
3.3. Identificação dos Requisitos 
 
 Identificar requisitos significa identificar as funcionalidades que o software deve ter para 
atender as necessidades do usuário. 
 Fazer esta identificação significa responder a duas perguntas: 
 - O que o software deve fazer? 
 - Quais funcionalidades ele deve ter? 
 
 É necessário ainda identificar as principais características do software como: 
 - Performance: Qual é o tempo de resposta adequado? 
 - Segurança: Quais requisitos de segurança o software precisa? 
 - Usabilidade: O software deve seguir uma identidade visual e as interfaces devem ser 
intuitivas e amigáveis. 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelarHighlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
4 
 
3.4. Tipos de Requisitos 
 
 Os requisitos podem ser divididos em duas categorias, conforme figura 2: 
 
Figura 2 – Requisitos de Software 
 
3.4.1. REQUISITOS FUNCIONAIS 
 
 Estes definem funcionalidades do sistema, ou seja, aquilo que deve fazer, as funções 
necessárias para atender os objetivos da aplicação. Exemplo: 
 - Cadastrar Alunos; 
 - Emitir Boletim de notas; 
 - Fazer uma transação no banco de dados; 
 - Cadastrar um registro de atendimento; 
 - Imprimir relatórios; 
 - Etc. 
 
Podem ser escritos em alto nível, se forem voltados ao cliente, ou podem ser especificados 
em detalhe, para desenvolvedores. 
 
3.4.2. REQUISITOS NÃO FUNCIONAIS 
 
 Expressam restrições sob as quais o sistema deve operar ou qualidades específicas que o 
software deve ter, como performance, portabilidade, segurança, usabilidade, etc. Descrevem 
também a qualidade do serviço (QoS). 
 A não consideração ou esquecimento desses fatores constitui uma das principais razões 
de uma eventual insatisfação dos usuários com relação ao software. 
 Os requisitos não funcionais também são chamados de RNF ou Requisitos Suplementares. 
Exemplo: 
 - Confidencialidade; - Portabilidade; 
 - Confiabilidade; - Precisão; 
 - Performance; - Integridade; 
 - Qualidade; - Segurança; 
 - Usabilidade; - Etc. 
 
 Os requisitos não funcionais dividem-se em outros três grupos de requisitos: 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
5 
 
a) Requisitos do produto: Requisitos que especificam que o software entregue deve se 
comportar de um determinado modo, por exemplo: ser confiável, robusto, rápido, etc. 
b) Requisitos organizacionais: Requisitos que são consequência das políticas e 
procedimentos organizacionais, como padrões, processos, etc. 
c) Requisitos externos: Requisitos que são externos ao sistema e seu desenvolvimento, 
por exemplo: legislação, interoperabilidade, etc. 
 
 A figura 3 ilustra ainda suas subdivisões: 
 
 
Figura 3 – Requisitos não Funcionais e suas ramificações 
 
Os Requisitos não funcionais podem ser extremamente difíceis de especificar 
precisamente. Porém, devem ser verificáveis usando alguma medida que possa ser objetivamente 
testada, como propõe a tabela 1. 
 
Tabela 1 - Mensuração de RNF 
PROPRIEDADE MEDIDA 
Desempenho Transações por segundo; Tempo de resposta para eventos; etc. 
Armazenamento Megabytes; Número de chips ROM; 
Usabilidade Tempo de treinamento; Número de cliques de mouse; 
Confiabilidade Tempo médio entre falhas; Taxa de ocorrência de falhas; Disponibilidade; 
Robustez Tempo para recomeçar depois de uma falha; Probabilidade de corrupção 
de dados após falha; 
Portabilidade Porcentagem de declarações dependentes de plataforma; Número de 
plataformas-alvo. 
 
 
 Além dos requisitos funcionais e não funcionais existem ainda outras definições de 
requisitos que não serão estudadas, mas que valem ser citadas: 
 - Requisitos de Domínio: vêm do domínio da aplicação do sistema e refletem 
características do domínio. São transformados, posteriormente, em requisitos funcionais ou 
restrições (RNFs). Exemplo: A desaceleração do trem deve ser computada como: Dtrem = 
Dcontrole + Dgradiente; 
 - Requisitos permanentes (estáveis): derivados da atividade principal da organização. 
Exemplo: em um hospital sempre haverá requisitos relativos aos médicos, aos pacientes, aos 
tratamentos, etc. Derivados do modelo de domínio; 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
6 
 
- Requisitos Voláteis: Requisitos que se modificam durante o desenvolvimento ou quando o 
sistema está em uso. Exemplo: Requisitos resultantes de políticas governamentais; 
 
3.5. Identificação de Riscos 
 
 Os riscos são a principal razão de falhas em um projeto de software. Identificando-os é 
possível criar um plano para reduzi-los. 
 No documento de visão é necessário identificar uma lista de riscos existentes, como: 
 - Política: Influência de política de negócios, leis, decretos ou normas que regulam a 
finalidade da aplicação; 
 - Tecnologia: Ferramentas emergentes e integração com sistemas legados; 
 - Recursos: Orçamento restrito, contratação de terceiros; 
 - Habilidade: Falta de domínio da tecnologia (habilidade e experiência); 
 - Requisitos: Requisitos não plenamente conhecidos. 
 
3.6. Identificação das Restrições 
 
 São restrições impostas sobre o desenvolvimento de software, como a adequação a custos 
e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface 
do usuário, componentes de hardware e softwares a serem adquiridos. 
 Exemplo: 
 - O projeto requer uma tecnologia como webservices; 
 - Necessita de hardware específico como um servidor exclusivo de banco de dados. 
 
3.7. Documentos de Visão 
 
 Depois de concluída a identificação e elicitação de requisitos é necessário documentar o 
que foi feito através do Documento de Visão. Este documento tem as seguinte seções: 
 - Declaração dos problemas; 
 - Lista de Stakeholders; 
 - Lista de requisitos; 
 - Lista de Riscos; 
 - Lista de Restrições. 
 
 Um exemplo simples de documento de visão pode ser visto na figura 4. 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
Deverá constar no documento de visão
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
Deverá constar no documento de visão
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelarHighlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
7 
 
 
Figura 4 – Documento de Visão 
Fonte: Rildo F. Santos 
 
 
4. ANÁLISE DE REQUISITOS 
 
Depois que os requisitos foram coletados, os produtos de trabalho servem como base para 
a análise de requisitos. A análise de requisitos visa a descobrir alguns problemas e torná-los mais 
consistentes antes da especificação formal. 
Neste ponto, o documento de visão é um documento importante na análise de requisitos. 
A análise de requisitos deve ser: 
- Correta: O requisito deve ser encontrável no software; 
- Não ambígua: Deve ter apenas uma interpretação; 
- Completa: Deve incluir RF e RNF; 
- Consistente: Não existir conflito entre os requisitos; 
- Verificável: Possibilidade de verificar e validar cada requisito; 
- Modificável: Requisitos serem facilmente alterados. 
 
4.1. Atividades da Análise de Requisitos 
 
 A análise de requisitos possibilita ao analista especificar as funcionalidades, classificando e 
detalhando os requisitos encontrados na coleta. Os requisitos funcionais serão descritos e os não 
funcionais serão classificados. As figuras 5, 6 e 7 exemplificam estas atividades. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
8 
 
 
Figura 5 – Descrição de Requisito Funcional 
Fonte: Rildo F. Santos 
 
 
Figura 6 – Descrição de Requisito não Funcional 
Fonte: Rildo F. Santos 
 
 
Figura 7 – Lista de Stakeholders 
Fonte: Rildo F. Santos 
 
 Além disso, os requisitos devem ser priorizados e negociados com o cliente. Esta atividade 
é importante para conciliar conflitos com os stakeholders. Eles podem pedir mais do que pode ser 
feito, ou ainda terem necessidades especiais. 
 
4.2. Documento de Requisitos 
 
 O resultado final desta fase é um documento de requisitos cujo objetivo é classificar e 
descrever os requisitos de software, usuários e entidades externas. 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
9 
 
 O formado do documento de requisitos é sugerido pela IEEE/ANSI 830-1993 e propõe a 
estrutura exemplificada na figura 8. 
 
 
Figura 8 – Documento de Requisitos 
 
 
5. ESPECIFICAÇÃO DE REQUISITOS 
 
O termo especificação tem vários significados , podendo ser: 
- Um documento escrito; 
- Um modelo gráfico; 
- Um modelo matemático formal; 
- Uma coleção de cenários de uso, etc. 
 
A abordagem utilizada depende da necessidade específica de cada projeto, podendo ser 
documentos escritos combinados com modelos gráficos para sistemas maiores e cenários de uso 
para sistemas mais simples, etc. 
 Os diagramas da UML podem ser largamente empregados para esta tarefa como se vê no 
esquema da figura 9. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
10 
 
 
 Figura 9 – Esquema para Especificação de Requisitos 
Fonte: Rildo F. Santos 
 
 
5.1. Especificação de Requisitos com Caso de Uso 
 
 Após a análise de requisitos o documento a ser elaborado é a Especificação de Requisitos, 
feitas com Caso de Uso segundo a especificação da UML. Um conjunto de Casos de Uso é 
importante para se compreender o que o usuário quer. Um caso de uso descreve uma 
funcionalidade (requisito) a ser oferecido pelo sistema. 
 Os casos de uso expressam: 
 - Diálogo entre usuário e sistema; 
 - O que o sistema deve fazer. (Não como fazer); 
 - Formam a base para teste e documentação. 
 
5.2. Casos de Uso 
 
É uma técnica desenvolvida por Ivar Jacobson e são parte integrante da UML. São 
descrições textuais das funcionalidades do sistema a partir da perspectiva do usuário. 
Além da aplicação na especificação de requisitos, os casos de uso são utilizados por 
Arquitetos, Analistas, Projetistas e Implementadores, Testadores, Gerentes e Escritores da 
documentação. 
Os diagramas de caso de uso fazem com que o sistema, subsistemas e classes fiquem 
acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos 
interagem com o sistema. 
Um exemplo de caso de uso pode ser observado na figura 10. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
11 
 
 
Figura 10 – Caso de Uso – Sistema de Vendas 
 
5.2.1. NOTAÇÃO 
 
O diagrama de Caso de Uso é representado por atores, casos de uso e relacionamentos 
entre estes elementos. 
Estes relacionamentos podem ser: 
- associações entre atores e casos de uso; 
- generalizações entre os atores; 
- generalizações, extends e includes entre os casos de uso. 
 
5.2.1.1. Ator 
 
 Os casos de uso são executados por atores. Eles constituem as entidades externas do 
ambiente do sistema. São papéis que os usuários do sistema devem desempenhar nas 
interações. Uma “instância de ator” pode ser desempenhada tanto por um indivíduo quanto por um 
sistema ou mesmo por um dispositivo. É representado conforme figura 11. 
 
 
Figura 11 – Ator 
 
 É importante ressaltar que os atores representam papéis/perfis e não pessoas. 
Tipicamente os atores são identificados nas declarações de problemas do Documento de Visão ou 
através de entrevista com stakeholders. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
12 
 
5.2.1.2. Generalização/Especialização de Atores 
 
É possível definir tipos gerais de atores e especializá-los usando o relacionamento de 
especialização, conforme exemplificado na figura 12. 
 
Figura 12 – Especialização de Ator 
 
Deve-se usar quando um ator (filho) é um tipo de outro ator mais genérico (pai). 
 
5.2.1.3. Caso de Uso 
 
Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso, 
conforme figura 13. Um caso de uso define uma grande função do sistema. A implicação é que 
uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser 
estruturado. 
 
Figura 13 – Caso de Uso 
 
5.2.1.4. Relacionamento entre um ator e um caso de uso 
 
Define umafuncionalidade do sistema do ponto de vista do usuário, conforme figura 14. 
 
Figura 14 – Relacionamento entre ator e caso de uso 
 
5.2.1.5. Relacionamento de Inclusão 
 
Um Caso de Uso base incorpora o comportamento de outro Caso de Uso. O 
relacionamento é utilizado para evitar a descrição do mesmo fluxo de eventos várias vezes. 
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
13 
 
 
Figura 15 – Relacionamento de Inclusão 
 
Deve-se usar quando o mesmo comportamento se repete em mais de um Caso de Uso e o 
processo de realizar X sempre envolve realizar Y pelo menos uma vez. 
 
5.2.1.6. Relacionamento de Extensão 
 
 Modela partes opcionais da execução de um Caso de Uso. Modela fluxos que são 
executados somente em determinados casos, sob determinadas circunstâncias ou que dependem 
de escolha de um ator. 
 
Figura 16 – Relacionamento de Extensão 
 
 Deve-se usar quando se deseja modelar um comportamento opcional de um Caso de 
Uso. 
 
5.2.1.7. Relacionamento de Generalização/Especialização 
 
 Relaciona um Caso de Uso especializado a um mais geral. O filho herda o comportamento 
do pai, podendo adicionar e redefinir passos em pontos arbitrários do comportamento original, 
conforme ilustra a figura 17. 
 
Figura 17 – Relacionamento de Generalização 
 
 Deve-se usar quando se necessita identificar Casos de Uso semelhantes e um deles for 
uma forma especial (uma especialização) do outro. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
14 
 
 Na figura 18 é possível observar outro exemplo de caso de uso. 
 
Figura 18 – Caso de uso 
 
5.2.2. TIPOS DE CASO DE USO 
 
 Os casos de uso podem ser concretos ou abstratos. Um caso de uso concreto é iniciado 
por um ator e constitui um fluxo completo de eventos. Um caso de uso abstrato nunca é 
instanciado diretamente. Casos de uso abstratos geralmente são: 
- Incluídos em outros Casos de Uso; 
- Estendidos de outros Casos de Uso; 
- Generalizações de outros Casos de Uso. 
 
Atores “enxergam” apenas casos de uso concretos. 
 
5.2.3. CASOS DE USO E CENÁRIOS 
 
 Os casos de uso exibem as funcionalidades na perspectiva do usuário. Contudo, é 
possível completar esta função através da construção de cenários. 
 Um cenário é como uma instância de um caso de uso, isto é, um caminho lógico com início 
e fim. Suas principais características são: 
 - Não contém declarações condicionais; 
 - Pode ter o mesmo começo, mas com fim diferente; 
 - É uma narrativa de uma situação; 
 - Devem descrever os caminhos corretos e errados. 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
15 
 
 Exemplo: 
 “Em uma loja é descrito o cenário de compra de um produto: O cliente navega no catálogo 
de itens e adiciona-os a sua cesta de compras. Quando o cliente deseja pagar, fornece os dados 
do cartão de crédito e finaliza a compra. O sistema solicita o endereço para entrega do pedido. O 
sistema verifica a autorização do cartão e confirma a transação enviando um e-mail para o 
usuário.” 
 
 Este é um dos possíveis cenários. Caso haja algum problema neste processo teremos um 
novo cenário. 
 
5.2.4. FORMULÁRIO/ESPECIFICAÇÃO DE CASO DE USO 
 
Todo diagrama de caso de uso é acompanhado de um documentos denominado 
especificação de caso de uso. A seguir podemos observar um exemplo de especificação do caso 
de uso Fazer Pedido. 
 
Tabela 2 - Especificação de Caso de Uso 
NÚMERO UC001 
CASO DE USO Fazer Pedido 
DESCRIÇÃO Caso de uso que especifica o fluxo de ações para o cliente fazer um 
pedido no Sistema 
ATOR Cliente 
FLUXO PRINCIPAL Realizar o pedido de um produto 
P1. O caso de uso começa quando o cliente seleciona a opção “Fazer Pedido”; 
P2. O cliente fornece seu nome e endereço e fornece o código do produto [EXT1]; 
P3. O sistema fornece a descrição e o preço do produto [INC1]; 
P4. O cliente fornece as informações de pagamento e escolhe a opção “confirmar” [A1]; 
P5. O sistema verifica as informações fornecidas e envia os dados para o sistema de pagamento [E1]; 
P6. O caso de uso é encerrado. 
FLUXO ALTERNATIVO 
A1. No passo P4 cliente seleciona a opção “cancelar”; 
A1.1 O sistema não grava o pedido e o fluxo retorna para o passo P6. 
PONTOS DE EXTENSÃO 
EXT1. O sistema estende o caso de uso “Pedido em Oferta”. 
PONTOS DE INCLUSÃO 
INC1. O sistema inclui o caso de uso “Dar informação do produto”. 
REQUISITOS ESPECIAIS 
O usuário deve estar cadastrado no sistema. 
FLUXO EXCEPCIONAL 
E1. No passo P5 o sistema verifica que as informações fornecidas estão incorretas; 
E1.1 O sistema pede ao cliente para corrigir as informações e o fluxo retorna ao passo P4. 
PRÉ CONDIÇÃO Usuário deve estar logado no sistema. 
PÓS CONDIÇÃO O pedido deve ter sido gravado no sistema e marcado como 
confirmado. 
 
 Além das informações contidas na tabela 2, o Caso de Uso pode conter outros dados, 
como: 
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
16 
 
- Requisitos não Funcionais relacionados 
- Diagrama de atividades relacionado 
- Protótipo de interface 
- Outros diagramas 
 
O importante é que as necessidades sejam entendidas e acordadas por todas as partes 
interessadas. 
 
5.2.5. PASSOS PARA ESPECIFICAÇÃO DE REQUISTOS COM CASO DE USO 
 
 a) Identifique quais requisitos se relaciona com os casos de uso; 
 b) Identifique os atores e seus papeis; 
 c) Determine um nome para o caso de uso, que deve ser único; 
 d) Escreva cenários para o caso de uso; 
 e) Compile os cenários em um único formulário denominado especificação de caso de uso; 
f) Faça o diagrama de caso de uso. 
 
 
6. VALIDAÇÃO DE REQUISITOS 
 
Esta etapa visa demonstrar que os requisitos definem o sistema que o usuário realmente 
deseja. É uma etapa importante uma vez que o custo para remover um erro de requisito é grande. 
A validação de requisitos visa a assegurar que: 
- A versão do documento de requisitos descreve as funcionalidades e características do 
sistema satisfatoriamente; 
- Os requisitos são consistentes e de alta qualidade; 
- O documento de requisitos provê uma base adequada para Projeto e Implementação. 
 
6.1. Técnicas de Validação de Requisitos 
 
 Para validação de requisitos podem ser utilizadas as seguintes técnicas: 
 a) Revisões (inspeções): Um grupo de pessoas se reúne, lê e analisa os requisitos, para 
identificar problemas e suas possíveis soluções. 
b) Prototipagem: Um protótipo executável demonstra os requisitos e ajudam os 
stakeholders a descobrir problemas. 
c) Geração de Casos de Teste: Casos de teste ajudam a mostrar se os requisitos estão 
ambíguos ou incompletos. 
 
 Revisões regulares devem ocorrer durante a formulação e definição dos requisitos. Tanto o 
cliente como a equipe de projeto devem estar envolvidas na revisão que podem ser formais (com 
documentos completos) ou informais. Uma boa comunicação pode evitar problemas nos estágios 
finais. 
 
 
 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlightricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
17 
 
7. GERENCIAMENTO DE REQUISITOS 
 
É o processo de gerenciar as mudanças nos requisitos durante o processo de Engenharia 
de Requisitos. 
Os requisitos são, inevitavelmente, incompletos e inconsistentes. Novos requisitos surgem 
à medida que as necessidades de negócios mudam e há um melhor entendimento do sistema. 
Diferentes pontos de vista normalmente têm requisitos diferentes (e conflitantes). Diante 
disso é possível afirmar que os requisitos sempre mudam, bem como a prioridade de cada um ao 
longo do projeto, como ilustra a figura 19. 
 
Figura 19 – Evolução dos requisitos 
 
Considerando que o ambiente de negócio e tecnológico do projeto mudam durante seu 
desenrolar é necessário gerenciar tudo isso. 
 Durante o processo de engenharia de requisitos, será necessário planejar: 
 - A identificação dos requisitos: Como os requisitos são individualmente identificados; 
 - Um processo de mudança de gerenciamento; 
 - Políticas de rastreabilidade: Manter o histórico dos requisitos, rastrear suas mudanças e 
seus possíveis impactos; 
 - Suporte de ferramenta: Necessário para auxiliar no processo de gerenciamento. 
 
7.1. Rastreabilidade 
 
 A rastreabilidade preocupa-se com as relações entre requisitos, suas fontes e o projeto do 
software. 
- Rastreabilidade de Fonte: Ligação entre o requisito e o stakeholder que o propôs (e sua 
necessidade original); 
- Rastreabilidade de Requisitos: Ligações entre requisitos que dependem entre si; 
- Rastreabilidade de Projeto: Ligação entre o requisito e o projeto (arquitetura, módulos, 
código) do software. 
 
7.2. Ferramentas 
 
É impossível rastrear requisitos sem uma ferramenta CASE adequada. Ela deve: 
- Armazenar os requisitos em um ambiente seguro e gerenciado; 
- Dar suporte ao gerenciamento de mudança dos requisitos; 
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ricardorodriguesbarcelar
Highlight
ENGENHARIA DE SOFTWARE 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
18 
 
- Permitir recuperar automaticamente a ligação (rastreabilidade) dos requisitos. 
 
7.3. Gerenciamento de Mudanças de Requisitos 
 
 Deve ser feito em qualquer proposta de mudança de requisito. Segue os seguintes 
estágios, conforme figura 20. 
 
Figura 20 – Gerenciamento de mudança de requisitos 
 
 - Análise do problema e especificação da mudança. Discute-se os problemas com os 
requisitos e propõe-se mudanças. 
 - Análise e custo da mudança. Avalia-se os efeitos da mudança em outros requisitos do 
sistema. 
 - Implementação das mudanças. O documento de requisitos e outros documentos são 
alterados de forma a refletir as mudanças. 
 
 
8. BIBIOGRAFIA BÁSICA 
 
PRESSMAN, R. S. Engenharia de Software. São Paulo. Makron Books, 2006. 
 
SOMMERVILLE, Ian. Engenharia de Software - Ed. Prentice Hall, 2007. 
 
SANTOS, F. Rildo. Análise de Requisitos de Software. Material instrucional. 
 
Norma IEEE/ANSI 830/1993

Outros materiais

Materiais relacionados

Perguntas relacionadas

Materiais recentes

Perguntas Recentes