09 - detalhamento dos requisitos
TRANSCRIPT
Desenvolvimento de Software I
Requisitos de software:Executando a fase de concepção
de um projeto
Profa. Msc. Renata Azevedo Santos Carvalho2012/2
Ciclo de vida
Concepção
Elaboração
Construção
Transição
Requisitos
Processo da Engenharia de requisitos
Elicitação Análise
ModelagemValidação
EspecificaçãoConcepção
Atividades da fase de concepção: Requisitos de software
Atividades
Determinação do contexto Definição do escopo Definição dos requisitos Detalhamento dos casos de uso Detalhamento dos requisitos de interface Detalhamento dos requisitos não-funcionais Classificação dos requisitos Revisão dos requisitos
Detalhamento dos casos de uso
Detalhamento dos casos de uso
Este detalhamento é feito a partir da descrição dos casos de uso;
Geralmente esta descrição é uma das tarefas mais demoradas, difíceis e importantes do fluxo de requisitos;
É feita por meio de textos estruturados; Consiste no detalhamento do fluxo principal,
subfluxos e fluxos alternativos de cada caso de uso, determinando a ação do usuário e a resposta do sistema;
Detalhamento dos requisitos funcionais Exemplo
Exercício – Diagrama de contexto e Detalhamento dos requisitos
Detalhamento dos requisitos de interface
Detalhamento dos requisitos de interface Levanta de forma detalhada, todos os
requisitos referentes a entradas e saídas do produto, tanto relacionado a interface do usuário quanto a interface externa com outro sistema (integração);
Detalhes importantes dos requisitos de interface incluem as fontes e os destinos dos dados, assim como os requisitos de formato destes;
Para interface de usuário poderá ser produzido um protótipo com as descrições e comportamentos desta;
Detalhamento dos requisitos de interface Exemplo de Interface externa
Detalhamento dos requisitos de interface Exemplo de Interface de usuário
Detalhamento dos requisitos não-funcionais
Detalhamento dos requisitos não-funcionais
Muitos requisitos não funcionais são globais, aplicando-se ao produto como um todo;
Um requisito não funcional pode ser específico de um caso de uso; por exemplo, a duração máxima de uma transação descrita por um caso de uso. Nesta situação, o caso de uso deve ser indicado na descrição do requisito não funcional;
Os requisitos não funcionais devem ser enunciados de forma precisa e quantitativa, mesmo que seja difícil formular valores razoáveis no levantamento dos requisitos de uma primeira versão de um produto;
Detalhamento dos requisitos não-funcionais Os requisitos não-funcionais podem ser
representados por:– Números de terminais suportados;– Números de usuários simultâneos;– Volume de informação que deve ser tratado;– O número esperado de transações por unidade
de Tempo;
Detalhamento dos requisitos não-funcionais Exemplos:
– A totalização da Operação de Venda não pode gastar mais do que 5 segundos, devendo ser realizada em 2 segundos, 80% das vezes;
– O Merci deverá ser desenhado de forma que possa ser expandido para mais de um terminal de caixa.
– O layout da nota fiscal utilizada pela mercearia deve ter sido previamente aprovado pela Secretaria de Receita.
– Um operador de caixa proficiente em máquina registradora deverá ser capaz de aprender a operar o Merci com um dia de treinamento.
– O Merci deverá restringir o acesso através de senhas para os usuários, conforme Características dos Usuários.
Classificação de requisitos
Classificação de requisitos
Nesta atividade, são marcados os requisitos que formarão o Cadastro dos Requisitos do Software;
– Cada interface;– Cada caso de uso;– Cada requisito não funcional.
Todo requisito cadastrado deverá receber um identificador único dentro do projeto, que permitirá a rastreabilidade do mesmo;
Classificação de requisitos
Os campos utilizados para classificação dos requisitos pode ser:
– Número - número de ordem do requisito no cadastro.– Nome do requisito - nome dado à interface, ao caso
de uso ou ao requisito não funcional, na Especificação de Requisitos do Software.
– Tipo - interface, caso de uso ou requisito não funcional.
Classificação de requisitos
Os campos utilizados para classificação dos requisitos pode ser:
– Importância - essencial, desejável ou opcional, conforme definido na priorização dos requisitos.
– Complexidade - estimativa do esforço e riscos de implementação, em comparação com outros requisitos do projeto; pode ser alta, média ou baixa.
– Estabilidade - estimativa da probabilidade de que o requisito venha ser alterado no decorrer do projeto, com base na experiência de projetos correlatos; pode ser alta, média ou baixa.
Classificação de requisitos
Exemplos
Revisão dos requisitos
Revisão de requisitos
A revisão dos requisitos tem por objetivo assegurar que a Especificação dos Requisitos do Software:
– Esteja conforme com o respectivo padrão, e com outros padrões aplicáveis ao projeto em questão;
– Atenda aos critérios de qualidade dos requisitos;– Forneça informação suficiente para o desenho do
produto, de seus testes de aceitação e do seu manual de usuário.
Os requisitos podem ser revisados pela própria equipe com a participação do usuário;
Qualidades dos requisitos
A Especificação de Requisitos deve satisfazer uma série de características de qualidade:
– Correta - Todo requisito presente na realmente é um requisito do produto a ser construído;
– Precisa - Todo requisito presente possui apenas uma única interpretação, aceita tanto pelos desenvolvedores quanto pelos usuários chaves;
– Completa - Reflete todas as decisões de especificação que foram tomadas;
– Consistente - Não há conflitos entre nenhum dos subconjuntos de requisitos presentes;
Qualidades dos requisitos
– Priorizada - Cada requisito é classificado de acordo com a sua importância, estabilidade e complexidade (essencial, desejável ou opcional);
– Verificável - Todos os seus requisitos são verificáveis;
– Modificável - Sua estrutura e estilo permitem a mudança de qualquer requisito, de forma fácil, completa e consistente;
– Rastreável - Permite a fácil determinação dos antecedentes e conseqüências de todos os requisitos.
Detalhamento dos requisitos de interface, classificação e revisãoEstudo de caso