View
128
Download
2
Category
Preview:
Citation preview
Fundamentos de Engenharia de Software
Requisitos de Software
Fases do Desenvolvimento de SW
Viabilidade
Requisitos
Projeto
Cod. Módulos
Integração
Entrega
Manutenção
Requisitos de Software
A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). (Wikipedia)
Tipos de requisitos
Funcionais tratamento da informação
Não funcionais outras características
Exemplos de categorias de requisitos (IEEE-830)
Requisitos funcionais
Tecnologia utilizada
Processo de desenvolvimento
Desempenho
Operação
Manutenção e portabilidade
Backup e Recuperação
Legais
Treinamento
Qualidades de um bom MR
escalável funciona para modelos grandes
legível linguagem do usuário
robusto fácil de ser mantido
Componentes do MR
Modelo de Casos de Uso
Maquete
Modelo de Classes do Domínio
Maquete
Modelo de Classes de Domínio
I- Requisitos de SW
Característica do SW que: o usuário necessita para resolver um
problema ou alcançar um objetivo satisfaz contrato, padrão,
especificação ou outra formalidade
Níveis de Requisitos
Negócio: Mais abstratos, atendem aos interesses das partes
interessadas no negócio
Produto: Mais detalhados, atendem aos interesses dos
desenvolvedores do SI
Requisitos do Negócio
Definem: escopo e os objetivos do projeto sua viabilidade financeira estimativa de seus benefícios
Objetivo: ajudar o processo decisório
Formato: Business Case (BC)
Conteúdo de um BC
1. Nome da intervenção2. Descrever o problema ou oportunidade3. Porque é um problema ou oportunidade4. Qual a natureza da intervenção5. Qual o resultado da intervenção6. Quem serão os gestores/usuários7. Estimativa do prazo
( 1 página)
Requisitos do Produto
Definidos nos estágios iniciais do desenvolvimento de um Sistema de Informação
Descrevem: Comportamentos do sistema Atributos
Exemplos
R1-O SI deve possuir comandos de correção de ortografia
R2-O SI deve garantir o sigilo de todas informações pessoais
R3-O Sensor de porta deve ser amostrado 10 vezes por segundo
R4-O SI deve ser desenvolvido em .Net
II – Requisitos e CMMI
Capability Maturity Model Integration (CMMI)
Recomendações de práticas específicas e genéricas
Organizadas por Área de Processo (AP) Inclui práticas de planejamento,
engenharia e gerência Organizado em níveis
Objetivos e práticas
Objetivos Genérico: características que devem estar presentes
para satisfazer a institucionalização dos processo Específicos: características que devem estar
presentes para satisfazer uma AP Práticas
Genéricas:práticas que contribuem para a institucionalização dos processos
Específicas: atividades que visam atingir um objetivo específico
Requirements Management
RM- Requirements Management
Objetivos: gerenciar todos os requisitos recebidos ou
gerados pelo projeto Identificar inconsistências entre os
requisitos e os planos e produtos do projeto
Requirements Development
RD – Requirements Development
Objetivo: produzir e verificar os requisitos de: clientes (SG-1) produtos e componentes (SG-2) analisar e validar requisitos (SG-3)
RD - SG 1: Desenvolver Requisitos do Negócio
1.1-Elicitar necessidades das partes interessadas
(identificar de forma pró-ativa requisitos necessidades, restrições e interfaces para todas fases do ciclo de vida)
1.2-Desenvolver os requisitos dos clientes
(consolidar e resolver conflitos entre os desejos, expectativas das partes interessadas; colocar num documento único com os requisitos dos clientes)
RD – SG 2: Desenvolver Requisitos do Produto
2.1-Estabelecer requisitos de produtos e componente
2.2-Alocar os requisitos ao produto
2.3-Identificar requisitos de interface do produto com sistemas externos
III - Padrão IEEE-830
Documento com diretrizes para especificação de requisitos de software
Composto de 3 partes Introdução Descrição geral Requisitos específicos
Padrão IEEE-830 (2)
Introdução Propósito Escopo Definições Referências Visão Geral
Padrão IEEE-830 (3)
Descrição geral Perspectiva do produto Funções do produto Característica do usuário Restrições Condições e dependências
Padrão IEEE-830 (4)
Requisitos específicos Interface externa Funções Desempenho Projeto
IV - Qualidades dos requisitos
Correto Sem ambigüidade Completo Consistente Priorizado Verificável Modificável Rastreável
Correto
Qualquer um dos requisitos representa algo que deve estar presente no sistema
Os requisitos reais devem coincidir com os requisitos identificados para o sistema.
Sem ambigüidade
Tem uma única interpretação por todos os interessados
Interessados devem incluir tanto responsáveis pelo negócio como os desenvolvedores
Completo
Reflete todas as necessidades de todas as partes interessadas.
Necessidades incluem requisitos funcionais e não-funcionais.
Consistente
Livre de assertivas contraditórias.
Sentenças contraditórias: A deve ser verdadeira. A deve ser falsa.
Priorizado
Contém uma relação de ordem de importância entre os requisitos.
Ordem de importância dos requisitos auxilia na definição da ordem de implementação.
Verificável
Existe uma forma efetiva de saber se a implementação cumpre o requisito.
O requisito deve fornecer métricas e critérios que auxiliem a avaliação do requisito.
Modificável
Alterações podem ser feitas de maneira simples
Também chamado de robustez do modelo
Rastreável
Requisitos podem ser associados aos artefatos produzidos pelo processo de desenvolvimento de software
Processo de Requisitos
Elicitar
Modelar
Verificar e validar
V-Elicitação de requisitos
Elicitar requisitos: “extrair” os requisitos das partes interessadas
É um processo construtivo: os requisitos não “existem” antes da atividade
Elicitar requisitos
Elicitar requisitos é um problema inerentemente complexo devido a psicologia de expressar desejos incertos numa linguagem ambígua.
Computerworld relata que 95% de todos os projetos de software não cumprem prazo e custo; 93% dos problemas advém de falhas de comunicação.
Standish Group International relata que a falta de envolvimento das partes interessadas é o principal fator da falha dos projetos de SI.
Formas de elicitação
Entrevistas Questionários Prototipação Estudo de documentos JAD
Exemplos de Sessão de Requisitos
1. Definir as maneira com que os usuários irão interagir com o novo sistema (Casos de Uso). Coletar amostras das entradas e saídas desejadas pelos usuários. Primeiramente mantenha-se nos processos de negócio para depois detalhar os dados necessários.
2. Priorizar os Casos de Uso. Por exemplo, utilizando a técnica Delphi.
3. Validar e rever os cenários dos Casos de Uso. 4. Especificar, usando técnicas de prototipagem, as interfaces
(telas e relatórios) do sistema. 5. Organizar os Casos de Uso, restrições, premissas e outros
requisitos num Documento de Especificação de Requisitos de Software (DERS).
Processo de Requisitos
Elicitar
Modelar
Verificar e validar
V-Requisitos do Sistema
Funcionais Comportamento do Sistema
Como o sistema age e reage, ou seja, a sua atividade externamente observável e que pode ser validada.
Descrito na forma de Casos de Uso de Sistema (“system use cases”).
Não-Funcionais Segurança Desempenho Tecnologia
Caso de uso
Uma seqüência de passos Executado por um (ou mais) ator(es) Durante a interação com o sistema Atende um objetivo (goal)
Conteúdo padrão de um Caso de Uso
Nome do caso Atores Pré e pós condições Fluxo normal Fluxos alternativos Fluxos de Exceção
Nome do caso
Escolher nomes que expressem o processo Nomes no infinitivo
emprestar devolver manter
Atores
Ator quem interage com o sistema humano ou máquina
Atores primários para quem o sistema foi desenvolvido
Atores secundários suportam a operação
Exemplo de atores
Exemplo de Diagrama de Caso de Uso
Pré-condição
Aquilo que deve ser verdadeiro antes do caso ser iniciado Exemplos:
Ao alugar um carro existirem veículos na filial
Ao inscrever em disciplina ser aluno matriculado
Pós-condição
Aquilo que se espera que seja o estado do mundo ao fim do caso Ao descontar cheque
saldo da conta corrente atualizada Ao inscrever em disciplina
aluno esteja na lista da turma
Fluxos de casos de uso
descrevem caminhos que podem ser seguidos durante o uso do do sistema.
A) Venda normalB) Produto não está disponívelC) Cancelamento de ItemD) Cancelamento da Venda
Fluxo normal
Fluxo
Fluxo: seqüência de passos Cada passo tem um número Cada passo descreve:
envio de informação do ator para o sistema resultado de um processamento pelo sistema atualização realizada na memória interna informação enviada pelo sistema ao ator
Elementos de um fluxo
Como e quando o caso de uso é iniciado O caso de uso se inicia quando …… acontece.
A sequência de interações entre ator e sistema (Ação do ator x Resposta interna ou externa)
Informações/eventos que são trocados entre um ator e o sistema Cliente informa o número da agência e da conta corrente. (Ação do ator) Sistema apresenta o saldo atual da conta. (Resposta externa)
Armazenamento/Atualização de informações no sistema Sistema cria um novo pedido contendo o nome do criador, data de criação e
coloca o pedido na situação ‘Pendente’. (Resposta interna) Indicação de validações realizadas pelo sistema
O Sistema verifica se o sócio pode fazer empréstimos Como e quando o caso de uso termina
Quando ….. acontece, o caso de uso é encerrado
Exemplo de Fluxo Normal
1. Cliente informa período de locação; 2. Executar Caso de Uso "Verificar Disponibilidade"; 3. Cliente seleciona o modelo desejado; 4. Executar Caso de Uso "Identificar Cliente"; 5. Cliente seleciona forma de pagamento; 6. Executa Caso de Uso "Verificar Crédito"; 7. Cliente informa dados do Motorista; 8. Sistema produz contrato; 9. Cliente assina contrato; 10. Cliente recebe chave do carro.
Dicas de escrita (1)
Voz ativa e com o tempo presente. Cliente informa produto desejado e quantidade Sistema inclui item no carrinho de compras do cliente.
Indicar quem realiza a ação. Cliente informa produto desejado e quantidade
Uso consistente de termos (Rapdis). Evitar adjetivos e advérbios. Cuidado com pronomes (seu, sua, dele, ...) Estilo consistente e padronizado de descrição. Independente de tecnologia
Dicas de escrita (2)
Explicitar informações enviadas, recebidas e armazenadas: Evite “sistema apresenta dados do produto”.
Evitar o detalhamento de dados e regras de negócio nos fluxos. Use documentos anexos devidamente referenciados.
Fluxos Alternativos (1)
Conjunto de caminhos que podem ser seguidos durante o uso do sistema.
A) Venda normalB) Cancelamento da vendaC) Cancelamento do item
Curso normal
Fluxos Alternativos (2)
Cada fluxo alternativo é descrito na seção fluxos alternativos do caso de uso. Defina o título do fluxo alternativo com uma frase que
denote o sub-objetivo que o usuário deseja com esse fluxo.
Defina onde esse fluxo pode acontecer (em relação ao fluxo normal).
Detalhe as interações entre o ator e o sistema, seguindo as mesmas diretrizes do detalhamento do fluxo normal.
Defina o que ocorre ao final da execução do fluxo alternativo.
Fluxos Alternativos (3)
Remover cópia do aluguelDurante a Identificação das Cópias: Atendente seleciona uma ou mais cópias, e solicita a retirada das cópias
selecionadas do aluguel. Sistema remove as cópias selecionadas do aluguel, atualizando o valor total
do aluguel. Caso de uso volta ao fluxo normal com o atendente podendo informar novas cópias.
Cancelar o aluguel:Enquanto o Pagamento não foi realizado Atendente solicita o cancelamento do aluguel Sistema cancela o aluguel, e o caso de uso se encerra.
Fluxos de Exceção (1)
Cada passo de um caso de uso tem um objetivo Quando o objetivo não pode ser alcançado diz-se
que o caso falha Toda falha deve ser recuperada A recuperação envolve ações alternativas
Fluxos de Exceção (2)
Falhas são anotadas fora do roteiro
Notação:
<passo><letra> : <evento> <ação>
<passo> passo do caso
<letra> seqüencial para as exceções
<evento> causa da exceção
<ação> atividade de recuperação
Regras de Negócio (RN)
Regras Foco do detalhamento dos casos de uso está
nas interações. Existem regras que regem estas interações. As regras são descritas em uma seção à parte. As regras são capturadas na modelagem de
negócio ou no levantamento de requisitos do sistema.
Ex: R2: Cálculo do Preço de Aluguel de uma Cópia:
lançamento (…), normal (…), promoção (…)
Definições de RN Sentença que define ou restringe algum aspecto do negócio. Sua
intenção é afirmar a estrutura do negócio ou controlar ou influenciar o comportamento do negócio. (BRG, 1995)
Diretiva que tenciona influenciar ou conduzir o comportamento do negócio. Tais diretivas existem em suporte a política do negócio, a qual é formulada em resposta aos riscos, ameaças ou oportunidades (BRG, 1998)
Sentença explícita de uma restrição que existe na ontologia do negócio (Appleton D., 1984)
Condições que governam os eventos do negócio de tal forma que eles ocorram numa forma aceitável para o negócio (von Halle, 2002)
Políticas recomendadas e obrigatórias que governam a interação entre empregados, clientes, fornecedores e sistemas automatizados (von Halle, 2002)
As regras são as decisões ... (von Halle) ...é uma sentença compacta a respeito de um aspecto do negócio. É
uma restrição, no sentido de que ela estabelece o que tem de ser o caso ou o que tem de não ser o caso (Morgan, 2002)
Processo de Requisitos
Elicitar
Modelar
Verificar e validar
VI-Verificação / Validação
Verificação / Validação
Validação: Estamos construindo o produto correto?
Verificação: Estamos construindo o produto de forma
correta?
Técnicas de validação Storyboard:
Passivo: esboços de telas, relatórios (em papel ou eletrônico), onde o usuário narra o cenário.
Ativo: animação (apresentação com slides ou outro software), onde o software narra o cenário.
Interativo: permite a simulação da forma mais realista possível, onde o usuário participa da execução do cenário.
Protótipo: Mostra as informações essenciais e a
navegação Descartável Sem preocupação com implementação
Check List
Todas as necessidades estão sendo cobertas pelos macro-requisitos? Todo macro-requisito atende pelo menos uma necessidade? Todos os atores foram identificados e corretamente definidos na
perspectiva do sistema? Todo ator está associado a pelo menos um caso de uso? Todos os casos de uso foram capturados? Existe uma definição sucinta para cada caso de uso? Todo caso de uso está associado a pelo menos um macro-requisito? Todo macro-requisito está associado a pelo menos um caso de uso? Todas as entradas e saídas estão especificadas? O comportamento do sistema em todas as situações eventuais ou de
exceção está especificado? Todas as regras envolvidas estão especificadas? Todas as transformações de dados estão especificadas? Todos os dados e suas regras de validação estão especificados? Os critérios de especificação de casos de uso estão sendo
corretamente seguidos?
Recommended