• Fundamentos de Requisitos de Software
  • Processo de Requisitos
  • Levantamento de Requisitos
    • O levantamento de requisitos desempenha um papel importante no desenvolvimento de um software. É nesta etapa que o engenheiro de requisitos descobre as necessidades do cliente.
    • Se esta etapa não obter uma atenção especial, provavelmente obstáculos serão encontrados no caminho do desenvolvimento do produto, ou este não atenderá totalmente as necessidades.
    • Além disso, algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto: as vezes não é utilizada uma técnica adequada para extrair os requisitos do sistema ou há uma falha do engenheiro de requisitos e/ou usuário em não descrever os requisitos de modo claro, sem ambiguidades.
    • Entre as dificuldades encontradas na fase de levantamento de requisitos estão:
      • 1. Os usuários muitas vezes não sabem o que querem, a não ser em termos muito gerais: podem achar difícil articular o que desejam do sistema, fazendo pedidos não realistas.
      • 2. Os usuários expressam os requisitos em seus próprios termos e com conhecimento implícito de sua área de atuação.
      • 3. Diferentes usuários tem em mente diferentes requisitos e podem expressá-los de maneira distinta.
      • 4. O ambiente econômico e de negócios é dinâmico e se modifica durante o processo de análise (a importância dos requisitos pode mudar e novos requisitos podem surgir) .
    • As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto, caso seja necessário. A seguir serão apresentadas de forma resumida algumas dessas técnicas.
      • Entrevista: é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
      • Questionário: elaboram-se pesquisas específicas de acompanhamento com um grande número de usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais. Na fase de preparação, deve ser indicado o tipo de informação que se deseja obter com o questionário. As questões devem possuir forma simples, clara e concisa e estarem organizadas de forma a minimizar o tempo gasto na resposta.
      • Brainstorming: é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias. Essa técnica contém duas fases - a fase de geração, onde as ideias são coletadas, e a fase de avaliação, onde as ideias coletadas são discutidas. Na fase de geração, as ideias não devem ser criticadas nem avaliadas. Cada ideia pode levar a novas ideias.
      • JAD (Joint Application Design): é uma técnica para promover cooperação, entendimento e trabalho em grupo entre os desenvolvedores. A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos).
      • Prototipagem: Protótipo de um sistema é uma versão inicial do sistema que está disponível no início do processo de desenvolvimento. Protótipos de sistemas de software são frequentemente utilizados para ajudar a obter e validar requisitos do sistema. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho.
  • Análise de Requisitos
    • A Análise de Requisitos de software é um aspecto importante no gerenciamento de projetos, é a parte responsável por coletar dados indispensáveis e exigências de que o usuário necessite para solucionar um problema e alcançar seus objetivos. Assim como determinar as suas expectativas de um usuário para determinado produto. Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessidades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito de software, essa análise de requisitos é essencial para o desenvolvimento do sistema, ela vai determinar o sucesso ou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos, detalhados e relevantes para o projeto, pois eles fornecerão a referência para validar o produto final, estabelecerão o acordo entre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos de desenvolvimento, pois requisitos mal definidos implicam num trabalho maior.
    • Passos de Análise de Requisitos:
      • Reconhecer o problema – nesta fase encontra-se a especificação do sistema, o planejamento, o contato do analista com o cliente com a intenção de entender a visão do cliente com relação ao problema.
      • Avaliar o problema e a síntese da solução – tem-se o entendimento do problema, e faz-se a identificação das informações que serão necessárias ao usuário, identificação das informações que serão necessárias ao sistema e a seleção da melhor solução possível dentro das soluções propostas.
      • Modelar – é um recurso usado para o suporte da síntese da solução, o modelo vai apresentar ferramentas que facilitarão o entendimento do sistema, como as funcionalidades, informações e comportamento do sistema.
      • Especificar os requisitos – consolida funções, interfaces, desempenho, o contexto e as restrições do sistema.
      • Revisar – Juntos, cliente e analista, avaliarão o objetivo do projeto com o intuito de eliminar possíveis redundâncias, inconsistências e omissões do sistema, obtendo uma mesma visão.
  • Especificação de Requisitos
    • A especificação de Requisitos deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Erros nesse estágio produzem problemas posteriores no projeto e na implementação do sistema. E esses requisitos são classificados em Funcionais e Não-Funcionais.
      • Requisitos Funcionais: São as funções que se espera que o software faça pode ser também as funções que se espera que o software não faça.
      • Requisitos Não-Funcionais: São as qualidade e restrições relacionadas com o desenvolvimento, manutenção, custo, uso, entre outros.
  • Validação de Requisitos
    • A validação de requisitos consiste em verificar se os requisitos definidos no documento realmente define o que o cliente deseja, ou seja, garantir que o software em questão cumpre as especificações do mesmo. Dentre as verificações necessárias a se fazer, destacam-se:
      • Verificação de validade: Garantir que o sistema possua funções que supra as necessidades de todos os clientes. Deve-se ratificar que os mesmo verifiquem e aprovem as mesmas.
      • Verificação de consistência: Os requisitos presentes no documento não podem ser conflitantes.
      • Verificação de completeza: Todas as funcionalidades, exceções, restrições exigidas pelo cliente devem estar presentes e claras no documento.
      • Verificação de realismo: Dadas as funcionalidades do projeto, o mesmo deve ser implementável, isto é, tecnologicamente, financeiramente e temporalmente viável.
      • Conformidade com normas: Todo as especificações e o próprio documento devem obedecer às normas da empresa (cliente e/ou fornecedor).
    • Com o intuito de facilitar a verificação e deixá-la mais eficaz, é possível utilizar algumas técnicas, como:
      • Revisão dos requisitos: Os requisitos são analisados sistematicamente por uma equipe de revisores. A mesma pode ser informal, sendo através de uma conversa ou conferência envolvendo um número maior de representantes do(s) cliente(s) ou formal, onde a equipe se reúne junto ao(s) cliente(s) para confirmar se o documento e os requisitos cumprem os critérios de verificação (validade, consistência, completeza...).
      • Prototipificação: Implementação de um protótipo, como a interface ou um executável, que ao ser mostrada ao(s) cliente(s) seja possível verificar se o programa atenderá todas as necessidades.
      • Geração de casos de teste: Tomando-se a base de que todos os requisitos devem ser testados, deveria ser possível desenhar os mesmos e, caso não seja possível realizar o desenho, é sinal que o requisito deve ser reconsiderado.
      • Análise de consistência automática: Se os requisitos forem expressos em uma linguagem formal, pode-se usar ferramentas automatizadas para verificar os requisitos e encontrar inconsistências.