• Autora

    Pós-Graduando em Especialização em Informática – Ênfase Análise de Sistemas pela UFMG, Bacharel em Sistemas de Informação (2006) pela Faculdades Pitágoras (Campus Fadom), técnica em Informática (2002) e em Contabilidade (1998). Atualmente Analista de Suporte Júnior III.

  • Direitos Autorais

    Alguns dos materiais (artigos, pdf’s, link’s) disponíveis ou utilizados na edição desse Blog, foram retirados de páginas da internet. Se acaso, algum desses itens for protegido por direitos autorais, queira o detentor do mesmo, me comunicar por email e o material será imediatamente retirado ou darei os devidos créditos!
  • Categorias

  • Arquivos

  • Análise de Sistemas

    • 14,496 hits

Requisitos de Sistemas

Requisitos são à base do desenvolvimento de um sistema. Desenvolver softwares de qualidade é investir na captura, na análise, na especificação, na avaliação e na gerência de requisitos. Assim obter no início do desenvolvimento requisitos de qualidade é essencial, mesmo que eles mudem durante o processo de desenvolvimento.

Sw Qualidade = análise, especificação, avaliação e gerência de requisitos.

Aqui iremos falar de algumas das diversas técnicas para levantamento de requisitos.

Para isto é necessário que o profissional responsável por esta tarefa tenha experiência necessária para poder analisar as necessidades da organização e as tecnologias a serem usadas pelo futuro sistema.

Mas, investir na qualidade de requisitos, não vêem sendo uma  boa prática entre os profissionais, grupos e empresas de desenvolvimento de software no nosso país.

Dificuldades dos analistas em trabalhar com analise de requisitos

D1. Os requisitos e seus modelos são intangíveis, abstratos. Um exemplo seria os diagramas de casos de uso, que muitas das vezes não são usados pelos analistas e usuários, no dia a dia, no trabalho da definição de um sistema a ser desenvolvido (quando é usado é para efeito de documentação e não de uma técnica de análise).

D2. A necessidade de relacionamento com os chamados usuários, a nível pessoal ou em grupos. Conversar, discutir, apresentar alternativas, convencer essas pessoas não costuma estar entre as habilidades e prioridades dos profissionais de TI. Sendo um problema na medida em que os usuários tendem a obter maior autonomia no uso das tecnologias da informação, com os avanços da web, o uso crescente de softwares sociais (blogs, wikis, redes sociais) no novo mundo do conhecimento.

Notas:

A respeito da situação de desenvolvimento de Sw, a maioria dos livros sobre requisitos mostra estatísticas conforme relação abaixo:

31% dos projetos são cancelados antes de serem completados

52,7% dos projetos custam 189% de sua estimativa inicial

Esta situação era conhecida como a crise do software. Fazer software ainda hoje é um processo artesanal, quando ficam prontos os seus usuário tem muitas reclamações.

Causas:

+ Importantes: Falta de comunicação do usuário – 13%

Requisitos /Especificações incompletas – 12%

Requisitos /Especificações que mudam – 12%

Os problemas de qualidade de software, na maioria das vezes  tem a ver com requisitos, são levantados de forma incompleta ou os analistas não conseguem estabelecer uma linguagem comum com os usuários, o que dificulta o  seu levantamento.

Outro problema sério está na essência do problema de desenvolvimento de software, já que este é um processo de construção de conhecimento. Mesmo que você gaste muito tempo dialogando com o usuário, no início do processo ele não tem idéia do que seria o software ideal para resolver os problemas da sua organização. Qualquer que seja a definição de requisitos feita na fase de definição ou iniciação do sistema, eles certamente modificarão.

Estes são os chamados projetos que FALHAM.

É preciso além de levantar requisitos, gerenciá-los, rastrear essas mudanças, saber suas implicações. O que a mudança afeta, quem tem autoridade para aprovar essa mudança, qual será o seu custo, como o cronograma de desenvolvimento será afetado.

Por outro lado as estatísticas sobre projetos que deram certo mostram que investir em requisitos vale a pena, principalmente em sistemas mais complexos, sendo mais típico em grandes organizações. Esse investimento passa certamente pelo melhor envolvimento com o os interessados no software (stackholders), principalmente o seu usuários e as gerências da organização que serão afetadas ou que pagarão pelo mesmo.

Fatores de sucesso:

Envolvimento do usuário  –  16%

Suporte Gerencial do alto executivo  –  14%

Requisitos definidos de forma clara  –  12%

Realizados no prazo e no custo estimados por:

Grandes empresas: 9%

Pequenas empresas: 16%

Estes são os chamados projetos de SUCESSO.

Custo relativo para modificações durante o desenvolvimento de um software

Custo

Estágio

1-2 Definição de Requisitos
5 Design
1 Codificação
2 Teste unitário
5 Teste de Aceitação
20 Manutenção

É melhor negócio investir na definição dos requisitos no início do processo de desenvolvimento. O custo para efetivar as mudanças no software nesta fase, em função da mudança de requisitos, pode chegar a 100 ou 200 vezes mais barato do que fazê-lo quando o sistema estiver implementado junto ao setor usuário (na fase de sua operação, quando das manutenções).

Requisito : uma condição ou capacidade que um sistema deve apresentar, sendo:

  • Funcionalidades
  • Qualidades

Necessária ao usuário do sistema, para resolver um problema e alcançar um objetivo.

Aquilo que deve ser definido antes de começar a construir um sistema.

Uma Breve História

Uma Breve História

A Situação abaixo ocorre muito:

A Situação Acontece

Levantamento dos Requisitos do Sistema

A respeito do levantamento dos requisitos podemos considerar:

  • Base do desenvolvimento do Sistema;
  • Solução de problemas existentes: começo da implementação de uma mudança na organização;
  • Complexa: Envolvimento de pessoas com pontos de vista conflitantes. Uso de novas tecnologias
  • Necessidade de uma linguagem comum aos envolvidos.

Análise de Requisitos um dos pontos a ser considerado pelo Capability Maturity Model Integration (CMMI)

Para que uma empresa seja classificada no nível inicial da evolução da qualidade de software, segundo o padrão do CMMI, ela deve demonstrar sua competência em termos de gerência de requisitos.

Nivéis CMMI e Áreas Chaves do Processo de Requisitos

Nivéis CMMI e Áreas Chaves do Processo de Requisitos

Tipos de Requisitos

Funcionais

o que o sistema faz para satisfazer as necessidades de seu usuário.

Não Funcionais

Atributos de qualidade que um sistema deve possuir para satisfazer as necessidades de seu usuário.

Restrições

Requisitos globais que o sistema deve satisfazer que servem para verificar a correção e a adequação dos demais requisitos (devem ser definidos no início do processo de levantamento de requisitos).

Posso incluir nas restrições as mensagens de alertas aos usuários no momento em que estiverem realizando uma operação?

Requisito não funcional pode a principio encaixar nas seguintes categorias:

  • Usabilidade (facilidade de uso pelos usuários)
  • Confiança (freqüência e resistência a falhas, capacidade de recuperação, predibilidade, precisão)
  • Desempenho (capacidade, taxas em relação ao tempo, de precisão:  velocidade, disponibilidade, tempo de resposta, uso de memória )
  • Suporte (capacidade manter o sistema atualizado, em termos de  testes, manutenção, versões )
  • Aparência (estética, visual, design gráfico)
  • Operacional (o ambiente no qual será usado; ambiente operacional, condições do usuário, sistemas relacionados)
  • Segurança (confidencialidade, integridade, disponibilidade)
  • Cultura e Política (costumes, preferências, hábitos dos usuários)
  • Legal (leis, regulamentações, normas existentes)

Requisitos x Objetivos x Especificações

Objetivos: Propriedade desejada do ambiente do sistema. (Ambiental)Tem a ver com o ambiente do sistema, com a organização, com o usuário e não com a tecnologia (hardware e software). Problemas de Análise
Requisitos: Objetivo que tem certas restrições no uso de valores a serem monitorados e controlados pelo sistema. (Requisitado)Já os requisitos têm a ver com o ambiente e com a tecnologia.Realização de um objetivo.Refere-se às propriedades do ambiente e do sistema. Problemas de AnáliseProblemas de Design
Especificações: Requisito que se refere somente a propriedades do sistema ( e não do domínio do sistema ) (Implementação)As especificações somente com a tecnologia (o usuário não influencia diretamente).Descreve como o sistema produz seu comportamento. Problemas de Design

Trabalhar com requisitos exige uma visão de análise (levantamento junto ao usuário) e uma visão de design (meios para a sua implementação com a tecnologia).

Os objetivos têm mais a ver com a intenção do usuário. Os requisitos com a ação do usuário usando os meios necessários para a realização do objetivo.

Podemos chegar aos requisitos através dos objetivos (e vice-versa).

As propriedades do domínio somente se referem às propriedade do ambiente.

Uma especificação do sistema somente se refere às propriedades do sistema.

Requisitos

É o que restringe o comportamento do sistema.

Propriedades:

É descrito em termos de valores monitorados pelo software (hardware)

Restringe somente valores controlados pelo software

Os valores controlados não são definidos em termos de valores monitorados futuros.

Ao definir um requisito você tem abordar as duas visões:

A intenção do usuário (imprimir uma página)

O que vai controlar monitorar esse objetivo (clicar no ícone da impressora)

Processo de definição de requisitos

Os objetivos são usados para definir se certa descrição é um requisito ou uma especificação

As especificações do sistema não devem ser definidas, enquanto a análise de requisitos não for considerada satisfatória.

O detalhamento de certo objetivo pode ser o início da fase de definição (iniciação) do sistema.

Como já falamos, existem métodos para o levantamento de requisitos a partir dos objetivos, através de casos de uso.

Esse é um:

Processo iterativo: onde se pode começar, por exemplo, por um objetivo, detalhá-lo para chegarmos às especificações (processo de cima para baixo).

Ou

Começar por um requisito, subir para objetivos (processo de abstração), completá-los e descer de novo derivando novos requisitos e especificações, consolidando os levantados anteriormente.

A UML não tem um padrão para a descrição de cada caso de uso.

Diagrama de casos de uso: modelo que descreve o relacionamento entre os atores do sistema e os seus casos de uso.

A descrição dos casos de uso é que contará os objetivos ou requisitos do sistema.

Diagrama de Casos de Uso = relacionamento entre atores do sistemas e seus casos de uso = objetivos ou requisitos do sistema.

Técnica: Descrição de Objetivos/Requisitos em Grupo (Caso de Uso)

Nome do Caso de Uso

Descrição

Atores

Objetivo

Fluxo de Eventos

Fluxo Básico

Sub-objetivo 1

Sub-objetivo 2

………….

Fluxo Alternativo

Pré-condições

Pós-condições

Uso de Framework no detalhamento de requisitos

Os autores do livro de S.Robertson, J.Robertson,  Mastering the Requirements Process, tem um site especializado em requisitos e entre outras técnicas propõe um framework para detalhamento de requisitos. O framework oferecido é baseado numa descrição atômica ou unitária de cada requisito, na forma de um formulário como mostrado acima. Nesse formulário descreve-se o requisito e seus atributos (tipo, evento ou caso de uso que é utlilizado, responsável por ele na organização e outros).

Hierarquia e Níveis de Objetivos e Requisitos

Atores – têm Objetivos.

Sistema – tem Objetivos correspondentes.

O uso do sistema faz com que os Objetivos possam  ser alcançados ou falhem.

Objetivos podem ser divididos em sub-objetivos ou agregados em objetivos de nível mais alto.

Normalmente existem hierarquias de objetivos, onde se vê Níveis dos Objetivos.

Classificamos tais níveis em:

Estratégicos (Negócios)

Base para os sub-objetivos;

Mostram: ciclo de vida da seqüência de objetivos relacionados;

contexto no qual os objetivos do usuário operam;

Abrangem vários sub-objetivos de usuário;

São alcançados em  horas, meses ou anos;

Tem a ver com a organização (as intenções, o problema) do usuário;

Pode ser um sub-objetivo de outro objetivo estratégico.

Exemplos:

Pesquisar o site de compras

Efetivar a compras online

Fechar as compras

Pagar pelas compras

Receber a mercadoria

Avaliar o processo de compras

Fazer nova compra

De Usuário

O que o ator primário tenta obter ao utilizar diretamente o sistema;

Correspondem a processos de negócios elementares ( workflows );

O nível mais importante na definição de requisitos do sistema são alcançados em horas ou dias;

Tendem a serem sub-objetivos de outros objetivos estratégicos;

Podem ser objetivos ou requisitos.

Cada um dos objetivos estratégicos  pode ser dividido em seus sub-objetivos (ou requisitos):

Efetivar a compra

Consultar catálogo de mercadorias

Escolher uma mercadoria

Colocar a mercadoria no carrinho de compras

Ao detalharmos os objetivos estratégicos , dependendo da complexidade do sistema, podemos começar a definir outro tipo de objetivo, mais distante das intenções do usuário e mais próximo de suas ações junto ao sistema.

De Detalhe

Necessários para efetivar os objetivos do usuário;

Correspondem a uma tarefa a nível operacional, de baixo nível;

São alcançados em minutos ou horas;

Tendem a ser sub-objetivos de outros sub-objetivos de usuário;

Podem ser objetivos ou requisitos;

O detalhamento dos objetivos ou requisitos de usuário leva aos objetivos ou requisitos de Detalhe. Uma vez que se trata de uma ação do usuário muito próxima da interface do sistema.

Fechar as compras

Definir o preço do frete

Achar o CEP da região de entrega

Totalizar a compra

Podemos representar os objetivos e requisitos de dois pontos de vista básicos:

do Ator (o usuário)

do próprio Sistema.

A recomendação mais comum é que a visão do ator deva prevalecer sobre a do sistema (aquela famosa frase: o cliente é que manda).

Objetivo do ator O usuário deve solicitar o pagamento da sua conta.
Requisito do Sistema O sistema verifica se existe saldo suficiente.
Especificação (do sistema) O sistema deve liberar pagamento mesmo com saldo insuficiente, utilizando o cheque especial.

Como vimos todo o requisito tem atributos, a sua definição e registro é essencial para a gerência dos mesmos.

Atributos de um requisito: tipo, nível, origem, responsabilidade.

Estes são essenciais na gerência de requisitos (Rastreamento).

Engenharia de Requisitos

A definição dos requisitos é um dos passos de uma área da Informática, que muitas pessoas se especializam cada vez mais. Esta pode ser dividida em duas áreas básicas:

O Desenvolvimento e a Gerência de Requisitos.

Engenharia de Requisitos

Maturidade na Gestão de Requisitos

RMM

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: