Arquivar por categoria Fundamentos
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