ESPECIFICAÇÃO DE REQUISITOS

Prévia do material em texto

REQUISITOS DE SOFTWARE 
Engenharia de Software I 
prof. André de Paula 
E-mail: andrepns@gmail.com 
Objetivos 
• Entender o que são requisitos 
• Ter um conceito dos tipos de requisitos 
• Conhecer documentos relacionados aos 
requisitos 
• Entender o relacionamento da fase de 
requisitos com outras fases da engenharia de 
Software. 
Conceitos 
• Requisitos: descrições das funções e das 
restrições do sistema. 
• Engenharia de requisitos: é o processo de 
descobrir, analisar, documentar e verificar 
essas funções e restrições. 
Conceitos 
• Requisitos do usuário: declarações, em 
linguagem natural e em diagramas, sobre as 
funções que o sistema deve fornecer e as 
restrições sob as quais deve operar. 
• Requisitos do sistema: detalha as funções e as 
restrições de sistema. As vezes chamado de 
especificação funcional, deve ser preciso. Ele 
pode servir como um contrato. 
Tipos de requisitos 
• Requisitos funcionais: especificam o que o 
sistema deve fazer. 
• Requisitos não funcionais: especificam os 
atributos de qualidade gerais que o sistema 
deve satisfazer 
Requisitos funcionais 
• Descrevem a funcionalidade ou os serviços 
que se espera que o sistema forneça. 
• Como requisitos de usuário, são descritos de 
um modo bastante geral. 
• Como requisitos de sistema, descrevem a 
função de sistema detalhadamente, suas 
entradas e saídas, exceções etc. 
Requisitos funcionais 
• Exemplos de requisitos funcionais de usuário: 
– O usuário deverá ser capaz de buscar todo o 
conjunto inicial de banco de dados ou selecionar 
um subconjunto a partir dele. 
– O sistema fornecerá telas apropriadas para o 
usuário ler documentos no repositório de 
documentos. 
– Cada pedido será alocado a um único identificador 
(ORDER_ID), que o usuário poderá copiar para a 
área de armazenagem permanente da conta. 
Requisitos funcionais 
• Especificação de requisitos funcionais. 
– Completa: todas as funções requeridas pelo 
usuário devem estar definidas 
– Consistente: os requisitos não devem ter 
definições contraditórias. 
– Todos os requisitos devem ter apenas uma 
interpretação. (ambiguidade) 
– Todos os requisitos devem ser verificáveis, ou seja, 
deve ser possível constatar se eles foram 
atendidos ou não. 
Requisitos não funcionais 
• Não dizem respeito diretamente às funções especificas fornecidas 
pelo sistema. 
• Estão relacionados com a qualidade do sistema. 
– Portabilidade 
– Confiabilidade 
– Desempenho 
– Testabilidade 
– Modificabilidade 
– Segurança 
– Apresentação 
– Reusabilidade 
– Entendibilidade 
– Aceitabilidade 
– Interoperabilidade 
 
Requisitos não funcionais 
• Exemplos de requisitos não funcionais: 
– O número significativo de dígitos para o qual a 
precisão deve ser mantida em todos os cálculos 
numéricos é 10 
– O tempo de resposta do sistema deve ser sempre 
inferior a 5 segundos. 
– O software deve ser desenvolvido usando linguagem C 
em um sistema baseado no UNIX 
– Um livro pode ser deletado do Sistema de 
Gerenciamento de Biblioteca apenas pelo 
Administrador de Banco de Dados. 
Atividade de Definição dos requisitos 
• identificação dos casos de uso. 
– representações de funções do produto 
• Atores 
– representações dos usuários e outros sistemas 
que interagem com o produto 
Atividade de Definição dos requisitos 
• Casos de uso 
– Representa funções completas do produto. 
– Deve gerar um ou mais benefícios para o cliente 
ou os usuários. 
– Serve de base para determinar: 
• Classes e operações, durante a Análise; 
• Casos de testes de aceitação, durante os Testes; 
• Roteiros de manual de usuário, durante a 
Implementação. 
Atividade de Definição dos requisitos 
• Casos de uso 
Atividade de Definição dos requisitos 
• Casos de uso 
– Na página anterior vimos casos de uso de um 
sistema de informatização de mercearia. 
– Durante a “Definição dos requisitos”, basta 
resumir cada caso de uso em uma descrição 
sucinta. 
– O fluxo do caso de uso, que detalhará os passos 
correspondentes, será definido no “Detalhamento 
dos requisitos funcionais”. 
Atividade de Definição dos requisitos 
• Casos de uso 
 
Atividade de Definição dos requisitos 
• Atores 
– Papéis dos usuários do produto(software). 
– Cada ator representa uma classe de usuários 
definida na Especificação dos requisitos do 
software 
– Modelam os papéis e não as pessoas dos usuários. 
– Atores não humanos, modelam outros sistemas 
que devam interagir com o produto. 
Atividade de Definição dos requisitos 
• Atores 
Atividade de Definição dos requisitos 
• Atores 
– Atores podem ser identificados através dos 
seguintes critérios: 
 • quem está interessado em certo 
requisito; 
• onde o produto será usado; 
• quem se beneficiará do produto; 
• quem fornecerá informação ao 
produto; 
• quem usará informação do produto; 
• quem removerá informação do 
produto; 
• quem dará suporte e manutenção 
ao produto; 
• quais os recursos externos usados 
pelo produto; 
• quais os papéis desempenhados por 
cada usuário; 
• quais os grupos de usuários que 
desempenham o mesmo papel; 
• quais os sistemas legados com os 
quais o produto deve interagir. 
Atividade de Definição dos requisitos 
• Atores 
– Para cada ator, deve-se incluir uma descrição 
sucinta das responsabilidades do respectivo papel. 
– Identificar as características mais importantes do 
respectivo grupo de usuários. 
Atividade de Definição dos requisitos 
• Atores 
– Exemplo de descrição de atores: 
Atividade de Definição dos requisitos 
• Atores 
– Exemplo de descrição de características dos usuários 
Atividade de Definição dos requisitos 
• Atores 
– Atores são usados para representar também 
sistemas externos. 
– Podem incluir: 
• Sistemas legados 
• Produtos comerciais de software 
• Outros componentes de um sistema maior 
• Recursos de hardware e comunicação que devam 
receber um tratamento específico por parte do 
produto. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– Cada diagrama de casos de uso especifica os 
relacionamentos entre casos de uso e atores. 
– Os relacionamentos indicam a existência de 
comunicação entre atores e casos de uso. 
– Um caso de uso pode estar associado a mais de 
um ator. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– A comunicação será representada como ligação 
sem direção quando a iniciativa parte do ator. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– Quando a iniciativa parte do caso de uso (Por 
exemplo, alarmes, mensagens, dados enviados 
para outros sistemas etc.), a comunicação deve 
ser direcionada para o ator. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– Atores genéricos e específicos são ligados por 
relacionamentos de herança. 
– “gerente de vendas” e “gerente de compras” têm 
alguns aspectos em comum, que são abstraídos 
através do ator “gerente”. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– Os diagramas de casos de uso podem ser 
simplificados, mostrando-se um caso de uso 
comum (aos atores específicos) comunicando-se 
apenas com o ator genérico. 
Atividade de Definição dos requisitos 
• Relacionamento entre casos de uso e atores 
– A identificação dos atores, além ser o ponto de 
partida para a especificação das interfaces de 
usuário, ajuda bastante a identificar os casos de 
uso relevantes. 
Atividade de Definição dos requisitos 
• Relacionamento entrecasos de uso e atores 
– Os casos de uso normalmente expressam: 
• quais as tarefas de cada ator; 
• que informação cada ator cria, armazena, consulta, altera ou 
remove; 
• que informação cada caso de uso cria, armazena, consulta, altera 
ou remove; 
• que mudanças externas súbitas devem ser informadas ao produto 
pelos atores; 
• que ocorrências no produto devem ser informadas a algum ator; 
• que casos de uso darão suporte e manutenção ao sistema; 
• quais os casos de uso necessários para cobrir todos os requisitos 
funcionais 
Atividade de Definição dos requisitos 
• Diagrama de contexto 
– diagrama de casos de uso mais importante 
– é um diagrama de blocos que mostra as interfaces 
do produto com seu ambiente de aplicação 
– Mostra os diversos tipos de usuários e outros 
sistemas com os quais o produto deva interagir 
– deve indicar fontes e sorvedouros de dados 
– Se o produto fizer parte de um sistema maior, 
deve também identificar as interfaces entre o 
produto e o restante do sistema 
Atividade de Definição dos requisitos 
• Diagrama de contexto 
– Neste diagrama, os usuários, sistemas externos e 
outros componentes de um sistema maior são 
representados por atores, enquanto que os casos 
de uso representam as possíveis formas de 
interação do produto com os atores. Devem ser 
mostrados apenas os casos de uso que se 
comunicam diretamente com os atores, através de 
interfaces. 
Atividade de Definição dos requisitos 
• Diagrama 
de contexto 
Atividade de Definição dos requisitos 
• Diagrama de contexto 
– Uma definição completa do contexto de um 
produto pode incluir outros aspectos, como: 
• restrições de memória principal ou secundária; 
• modos de operação (por exemplo, processamento em 
lote ou manutenção); 
• requisitos de adaptação a ambientes específicos (por 
exemplo, que aspectos devem ser configuráveis 
durante a instalação em determinado local). 
 
BIBLIOGRAFIA 
• PRESSMAN S. R. Engenharia de Software 6ª 
ed. São Paulo: McGraw-Hill, 2006. 
• LARMAN, C. Utilizando UML e padrões: 2ª ed. 
Porto Alegre: BookMan, 2004. 
• PAULA, W.P.F. Engenharia de Software: 
Fundamentos, Métodos e Padrões. 2 ed. Rio 
de Janeiro: LTC, 2005. 
• SOMMERVILLE, Ian - Engenharia de Software . 
6ª ed. São Paula: Addison Wesley, 2003.