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?