Arquivar por categoria Requisitos de Software
Modelo para documentação de requisitos simplificado
Postado por Ronneesley como Documentação em 21 de abril de 2009
No artigo anterior, mostrei um modelo para descrição de requisitos, mas na prática existem alguns problemas quanto a leitura deste tipo de documentação:
- Normalmente a cada 3 (três) requisitos descritos naquele modelo de documentação oculpa 1 (uma) página;
- O cliente não possui ou não dedica tempo para ler documentos grandes; e
- Documentações naquele modelo se tornam grandes.
Por este motivo, uma prática recomendável é fazer um modelo simplificado daquele documento, o que cria então 2 (dois) documentos de requisitos, sendo este totalmente derivado daquele documento.
Para cada tabela do modelo anterior é criada uma tabela neste documento, mas apenas com a linha “Nome do Requisito”. Veja o exemplo abaixo:
| Nome do requisito |
Desta forma, teria outro documento apenas com os nomes dos requisitos. Particularmente colocaria uma linha a mais para identificar o requisito que é a linha “Identificação do Requisito”. Desta forma o documento ficaria assim:
| Identificação do Requisito | |
| Nome do requisito |
Deste modo, o cliente poderá visualizar este documento simplificado e caso se enteresse abre o documento de requisitos detalhado procurando pelo “Identificador do Requisito”.
Modelo para documentação de requisitos
Postado por Ronneesley como Documentação em 21 de abril de 2009
Um grande problema depois de enteder o que o cliente necessita é saber documentar o conhecimento explicito adquirido. Lembrando que existem dois tipos de conhecimentos: tácito e explicito.
Documentações podem ser feitas em textos abertos sem formatações ou utilizando um modelo para documentação. Ambos os modos atendem o objetivo, entretanto utilizar um modelo possibilita o rastreamento e uma melhor organização.
Existem vários modelos para documentação de requisitos, inclusive modelos específicos para trabalhos específicos. Veja o modelo que utilizo:
| Identificação do Requisito | Valor numérico sequencial |
| Nome do Requisito | Descrição resumida de um requisito |
| Fonte Responsável pelo Requisito | Nome do interessado que fez o analista ver o requisito |
| Data | Data da conversa com o interessado, ex: 21/04/2009 13:00 |
| Local e/ou Reunião | Onde foi realizada a conversa, ex: empresa XYZ |
| Obrigatoriedade | ( ) Imprescindível ( ) Desejável |
| Classificação quanto à prioridade | ( ) Alta ( ) Baixa |
| Classificação quanto ao risco | ( ) Alto ( ) Baixo |
| Especificação do Requisito | Descrição um pouco mais aprofundada do requisito, acredito que muitas pessoas dividem esta descrição em duas colunas: ações do usuário e do sistema, mas particularmente não gosto muito |
| Dicionário de Dados | Dicionário de dados, lembra análise estruturada (Separei esta por minha conta, pois muitas pessoas descreviam na coluna acima) |
| Responsável pelo Requisito | Analista responsável pelo levantamento ou realização do requisito |
Mesmo com os modelos é necessário saber descrever requisitos. Então, não se considere um analista somente pelo fato de saber fazer uma tabela.
SWEBOK – Requisitos de Sistema e de Software
Postado por Ronneesley como Fundamentos em 24 de março de 2009
Finalmente a última etapa sobre os fundamentos dos requisitos, fecha as definições contidas no SWEBOK, entretanto serão mencionados casos práticos sobre o assunto, nos próximos artigos.
“Uma combinação de elementos para realizar um objetivo definido. Estes incluem: hardware, software, firmware, pessoas, informação, técnicas, facilidades, serviços e outros elementos de suporte”
[International Council on System Engineering]
Requisitos de sistemas são todos os requisitos do sistema como um todo.
Requisitos de software são derivações dos requisitos do sistema.
Esta definição é um pouco abstrata, mas cada parte será detalhada nos próximos artigos.
SWEBOK – Requisitos Quantificáveis
Postado por Ronneesley como Fundamentos em 24 de março de 2009
São requisitos que devem ser declarados sem abiguidade, e se possível de forma quantitativa
Exemplos:
- O software deve aumentar o rendimento dos operadores em 20%; e
- O software deve ter probabilidade de falha em um tempo de no máximo 3 minutos.
Requisitos de reabilitação obrigam determinadas arquiteturas.
Exemplos de como NÃO FAZER:
- O software deve ser honesto; e
- O software deve ser amigável ao usuário.
Finalmente, o próximo artigo será o final para encerrar a definição de requisitos segundo o SWEBOK, o tema será Requisitos -> De sistema e de software.
SWEBOK – Requisitos Emergentes
Postado por Ronneesley como Fundamentos em 23 de março de 2009
Estes requisitos não são identificados por simples componentes, mas da satisfação de várias dependências de como o software deve operar.
Característica: São extremamente dependentes da arquitetura do sistema.
Exemplo: Um requisito de rendimento para call center, que depende do sistema de telefone, sistema de informação e operadores.
Simples a definição, porém complexo de ser identificado.
No próximo artigo será definido requisitos quantificáveis.
SWEBOK – Requisitos Funcionais e Não Funcionais
Postado por Ronneesley como Fundamentos em 20 de março de 2009
Dentre os requisitos de um projeto é muito importante saber destinguir:
- Requisitos funcionais; e
- Requisitos não funcionais.
Requisitos funcionais são aqueles que descrevem funções que o sistema deve executar, exemplos:
- Formatação de textos;
- Adaptação de sinais; e
- Cadastros de “entidades”.
Requisitos não funcionais são aqueles que descrevem restrições para a solução, exemplos:
- Requisitos de performace;
- Requisitos de manutenção;
- Requisitos de segurança; e
- Requisitos de confiança (estabilidade).
Deve-se prestar muita atenção nos requisitos não funcionais, pois eles podem fazer com que sua solução para um determinado problema, não possa ser aplicada, por exemplo:
- O cliente solicita o desenvolvimento de um sistema financeiro, em seguida é desenvolvido todos os requisitos como solicitado, mas não houve a preocupação com os requisitos de segurança; e
- O cliente solicita o desenvolvimento de um sistema de investimentos, em seguida é desenvolvido todos os requisitos como solicitado, mas não houve a preocupação com os requisitos de performace.
Desta forma pode-se concluir que nestes casos os sistemas não serão usado.
No próximo artigo, defineirei Requisitos -> Propriedades emergentes.
SWEBOK – Produto e Processo de Requisitos
Postado por Ronneesley como Fundamentos em 19 de março de 2009
Após o entendimento do que é um requisito, pode-se dividí-los em:
- Parâmetros de Produtos; e
- Parâmetros de Processos.
Quem já projetou ou desenvolveu qualquer software já viu esses dois tipos de requisitos, mesmo que não soubesse destinguí-los.
Parâmetros de Produtos são os requisitos que “influênciam o que o software deve realizar”
Exemplo: O sistema deve verificar os pré-requisitos antes do aluno se matricular em um curso.
Parâmetros de Processos são “regras para o desenvolvimento do software”
Exemplo: O sistema deve ser escrito em Java
Alguns requisitos podem influênciar em requisitos de processo, pois determinam práticas que restringem o ambiente. Se algum sistema tivesse que ser desenvolvido em uma linguagem de alta performace, o engenheiro de software seria forçado a escolher uma como C ou C++, deixo claro que existem outras, e descrever este requisito na documentação.
No próximo post será definido Requisitos -> Funcionais e Não Funcionais
Engenharia de Software pelo guia SWEBOK
Postado por Ronneesley como Fundamentos em 19 de março de 2009
Quem gosta de Engenharia de Software já deve conhecer o guia para os engenheiros de software chamado de SWEBOK, até então não conhecia tal guia, mas estou admirando-o muito. O SWEBOK é dividido em 10 (dez) áreas de conhecimento, são elas:
- Requisitos;
- Projeto;
- Construção;
- Testes;
- Manutenção;
- Gerência de configuração;
- Gerência de engenharia;
- Processos de engenharia;
- Ferramentas e métodos de engenharia; e
- Qualidade.
Vamos realizar o estudo de cada um destes tópicos ao longo do tempo, por enquanto vamos iniciar o estudo de Requisitos de Software (1).
Quem trabalha com projeto ou desenvolvimento de software já deve ter escutado este termo, os requisitos do software “expressa as necessidades e restrições do software“, assim se um participante de qualquer projeto deseja saber o que o software deve atender a maneira mais simples é olhar a documentação dos requisitos.
Muitas empresas possuem problemas de comunicação devido a falta de conversas/reuniões com o cliente ou usuário, afim de levantar as reais necessidades de um sistema ou até mesmo na transmissão do que o analista quis descrever como característica do sistema na documentação, desta forma se trata de uma parte bem delicada de qualquer projeto de software.
Este tema “Requisitos de software” também não deve ser confundido com apenas a documentação dos requisitos, que normalmente é um documento em formato (PDF) que é repassado para os demais participantes, sendo na verdade o estudo de todas as técnicas a serem aplicadas para se chegar em requisitos bem definidos, desde reuniões até como se expressar de maneira clara, facilitando o entendimento de toda a equipe.
Primeiro deve-se ter em mente que uma solução é: “a combinação de soluções mais simples de forma a chegar a um objetivo”, que neste caso é o requisito.
Para quem já estuda, estudou ou é praticante, sabe que existe uma instuição chamada IEEE (Institute of Eletrical and Electronics Engineers) que descreve várias características dos Engenherios de Software.
No próximo post será definido Requisitos de Software -> Produtos e Processos de Requisitos