Please enable JavaScript.
Coggle requires JavaScript to display documents.
Documentação de Requisitos (Critérios de Qualidade para Requisitos…
Documentação de Requisitos
Tipos de Documentação
Linguagem Natural
Vantagens
nenhum stakeholder precisa aprender uma nova notação
é a forma mais aplicada na prática
linguagem pode ser utilizada para uma grande variedade de finalidades
apropriada para documentar requisitos em qualquer das 3 perspectivas
Desvantagens
requisitos de diferentes tipos e perspectivas correm o risco de serem misturados
Pode resultar em requisitos ambíguos
Modelos Conceituais
Desvantagens
Não podem ser utilizados universalmente como a linguagem natural
Exigência de conhecimentos específicos de modelagem
Vantagens
Garantia de que os modelos criados retratam informações relacionadas com a respectiva perspectiva
Forma mais compacta da documentação dos requisitos, facilitando a compreensão
Exemplos de Modelos Conceituais
Diagrama de caso de uso
Visão geral das funções do sistema
Diagramas de classe
Modelagem estrutural dos dados e estruturamento de termos
Diagrama de atividades
Modelagem de sequências
Diagramas de estados
Modelam comportamentos desencadeados por determinados eventos
Documentos de Requisitos Híbridos
Tipicamente é uma combinação de modelos conceitos e linguagem natural para permitir que sejam documentados decisões, explicações importantes e outras informações relevantes
Estruturas dos Documentos
Estrutura Padronizada
Vantagens
permitem uma leitura e validação seletiva dos documentos de requisitos
permitem a verificação automática dos documentos de requisitos (por exemplo, para verificar a completude do documento)
Permitem a rápida localização de conteúdos desejados
Simplificam a inclusão de novos membros na equipe
permitem a reutilização simplificada dos conteúdos dos documentos de requisitos
Exemplos
RUP (Rational Unified Process)
Geralmente utilizado para sistemas de software orientados a objeto
O cliente cria um modelo de negócio que contém diferentes artefatos do mundo dos negócios (regras de negócio, casos de uso e metas de negócio), os quais servem de base para requisitos do sistema ao longo do ciclo do desenvolvimetno
O contratado usa as estruturas da especificação de requisitos de sistema (software requirements specification, ou SRS) para documentar todos os requisistos de software confome a norma IEE 830
IEE 830 sugere dividir o documento de requisitos em 3 capítulos principais
Introdução
Descrição Geral
Requisitos Específicos
Modelo-V
Especificação de Requisitos do Cliente
criado pelo contratante
descreve todas as exigências impostas ao contratado em relação ao contrato (entregáveis e serviços)
o que é feito e para que algo é feito
exigências dos usuários também são documentadas, incluindo restrições ao sistema e ao processo de desenvolvimento
conhecido como caderno de encargos
Especificação de Requisitos do Sistema
contém sugestões de implementação elaborados pelo contratado
descreve como concretizar os requisitos e as restrições do caderno de encargos
conhecido como caderno de obrigações
Conteúdos Padrão
Introdução
Contém informações sobre o documento como um todo
Elementos
Cobertura do sistema
indica o nome do sistema e os principais objetivos e vantagens que resultam da implementação do sistema
Stakeholder
lista de stakeholders e suas informações relevantes
Definições, acrônimos e abreviações
termos utilizados que podem ser usados de forma consistente em todo o documento
Referências
todos os documentos referenciados pelo documento de requisitos são listados aqui
Visão geral
breve descrição do conteúdo e da estrutura das seções do documento de requisitos
Finalidade
discute o propósito para o qual o documento foi criado e identifica o público-alvo do documento de requisitos
Perspectiva Geral
documentam-se informações adicionais que aumentam a compreensibilidade dos requisitos
Elementos
Ambiente do sistema
resultados da definição sobre os limites do sistema e do contexto
Descrição da arquitetura
documenta-se as interfaces operacionais do sistema
Funcionalidade do sistema
descreve globalmente as funcionalidades e tarefas do sistema
Usuários e público-alvo
listagem dos diferentes usuários do sistema que compõem o público-alvo
Restrições
listagem de todas as condições que não foram documentadas até este ponto e que podem interferir na engenharia de requisitos
Pressupostos
Documenta-se as decisões globais sobre o contexto do sistema nos quais os requisitos se baseiam
Requisitos
Contém requisitos funcionais e requisitos de qualidade
Apêndices
informações adicionais que completam o documento
características dos usuários
normas
convenções
informações gerais sobre o documento de requisitos
Índice
Contém um sumário e um índice remissivo
Poder ser uma seção crítica que deve ser atualizada constatemente
Design do Documento
Coleção de requisitos representada de forma sistemática, tipicamente para um sistema ou componente, atendendo a determinados critérios
Por que Documentar?
Requisitos formam a base para o desenvolvimento do sistema
A qualidade do dopcumento de requisitos tem forte impacto sobre o desenvolvimento do projeto
Requisitos têm relevância legal
ajuda a resolver conflitos legais entre duas ou mais partes
Documentos de requisitos são complexos
Sem uma documentação adequada, manter a situação sob controle pode se tornar bastante difícil para os envolvidos
Requisitos devem ser acessíveis para todas as partes envolvidas
Quando os requisitos podem ser acessados de forma permanente, evitam-se incertezas e desconhecimentos, e novos membros da equipe podem rapidamente colocar-se a par do projeto
Uso dos Documentos de Requisitos
Servem de base para diferentes tarefas
Planejamento
definição de pacotes concretos de trabalho e marcos para a implementação do sistema
Projeto Arquitetônico
Implementação
Teste
Possibilidade de desenvolver casos de teste que podem ser utilizados mais tarde na validação do sistema
Gerenciamento de Mudanças
pode ser utilizado como base para analisar até que ponto outras partes do sistema serão atingidas quando os requisitos mudam
Uso e Manutenção do Sistema
utilizado para fins de manutenção e apoio
analisar defeitos e deficiências concretas que surgirem durante o uso do sistema
Gerenciamento de Contrato
principal objeto de um contrato entre um contratante e um contratado
Critérios de Qualidade para Documentos de Requisitos
Não-ambiguidade e consistência [IEEE 830-1998]
requisitos individuais devem ser consistentes e não ambíguos
requisitos individuais não podem se contradizer mutuamente
Identificação única de um documento de requisitos
Estrutura clara
Permita leitura seletiva
O documento de requisitos deve ser abrangente e claramente estruturado
Modificabilidade e extensibilidade [IEEE 830-1998]
Devem ser passíveis de gerenciamento pelo controle de versões do projeto
Conteúdo e estrutura devem promover a modificabilidade
Completude [IEEE 830-1998]
Cada função do sistema deve ser descrita com todos os dados de entrada (inputs), os fatores que o influenciam e as reações exigidas do sistema
Fatores formais, evidências, referências e fontes contribuem para a completude
Requisitos de qualidade devem ser anotados
Rastreabilidade [IEEE 830-1998]
proporciona apoio para o gerenciamento de mudanças
Relacionamento com outros documentos de desenvolvimento
Critérios de Qualidade para Requisitos
Acordado
Um requisito está acordado se ele está correto na opinião dos stakeholders, e todos os stakeholders o aceitam como válido
Priorizado
stakeholders devem classificar os requisitos com determinada prioridade
Não ambíguo
Todos os leitores do requisito devem chegar ao mesmo entendimento do requisito
Válido e atualizado
Um requisito deve representar os fatos e condições do contexto do sistema de forma a ser válido no que se refere às características atuais do contexto do sistema
Correto
Representação de forma adequada da ideia do stakeholder
Consistente
O requisito não pode contradizer-se
Verificável
Um requisito deve ser descrito de forma a permitir sua verificação
Realizável
A implementação de cada requisito deve ser possível, observadas as restrições organizacionais, legais, técnicas ou financeiras
Rastreável
Um requisito é rastreável se a sua origem e implementação, bem como a sua relação com outros documentos, podem ser retraçadas, isto é, se o requisito permite o rastreamento das mesmas
Identificadores únicos de requisitos
Completo
Cada requisito individualmente deve descrever completamente a funcionalidade que ele especifica
Compreensível
Devem ser compreensíveis para cada stakeholder
Princípios Fundamentais de Compreensibilidade
Frases curtas e parágrafos curtos
não utilizar mais do que sete frases
Formular apenas um requisito por frase
Utilize a voz ativa para formular requisitos, empregando apenas um verbo de processo
Evitar usar frases longas e complexas
Glossário
Definição
Coleção de definições para termos, apresentando os seguintes elementos
Termos técnicos específicos do contexto
Abreviações e acrônimos
Conceitos do dia-a-dia que possuem um sentido específico no dado contexto
Sinônimos
Termos diferentes com o mesmo sentido
Homônimos
Termos idênticos com sentidos diferentes
Regras para Usar um Glossário [IEEE 610.12-1990]
O glossário deve ser gerenciado de forma centralizada
somente pode haver um glossário válido
A responsabilidade deve ser atribuída
uma pessoa deve ficar responsável por manter o glossário e assegurar sua consistência e atualização
O glossário deve ser mantido ao longo do projeto
deve ser mantido ao longo do ciclo de vida do projeto
A utilização do glossário deve ser obrigatória
O glossário deve incluir as fontes dos termos
O glossário deve ser aprovado pelos stakeholders
Os verbetes no glossário devem possuir uma estrutura consistente
recomenda-se utilizar um template para definições de glossário
Recomenda-se iniciar a compilação do glossário já no começo do projeto
Perspectivas dos requisitos
Perspectiva estrutural
perspectiva estático-estrutural dos requisitos do sistema
Perspectiva comportamental
documenta informações sobre o sistema e sobre como o sistema está integrado ao contexto do sistema a partir dos estados do sistema
Perspectiva funcional
documenta quais informações (dados) são recebidas do contexto do sistema e processadas pelo sistema ou por uma de suas funções