Análise de requisitos

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Na engenharia de sistemas e engenharia de software , a análise de requisitos concentra-se nas tarefas que determinam as necessidades ou condições para atender o produto ou projeto novo ou alterado, levando em consideração os requisitos possivelmente conflitantes dos diversos stakeholders , analisando, documentando, validando e gerenciando software ou requisitos de sistema. [2]

A análise de requisitos é fundamental para o sucesso ou fracasso de um projeto de sistema ou software . [3] Os requisitos devem ser documentados, acionáveis, mensuráveis, testáveis, rastreáveis, relacionados às necessidades ou oportunidades de negócios identificadas e definidos com um nível de detalhe suficiente para o projeto do sistema.

Visão geral

Conceitualmente, a análise de requisitos inclui três tipos de atividades: [ citação necessária ]

  • Elicitação de requisitos : (por exemplo, o termo de abertura ou definição do projeto), documentação do processo de negócios e entrevistas com as partes interessadas. Isso às vezes também é chamado de coleta de requisitos ou descoberta de requisitos.
  • Requisitos de registro: Os requisitos podem ser documentados de várias formas, geralmente incluindo uma lista resumida e podem incluir documentos em linguagem natural, casos de uso , histórias de usuários , especificações de processos e uma variedade de modelos, incluindo modelos de dados.
  • Analisar requisitos: determinar se os requisitos declarados são claros, completos, não duplicados, concisos, válidos, consistentes e inequívocos e resolver quaisquer conflitos aparentes. A análise também pode incluir requisitos de dimensionamento.

A análise de requisitos pode ser um processo longo e cansativo durante o qual muitas habilidades psicológicas delicadas estão envolvidas. Novos sistemas mudam o ambiente e as relações entre as pessoas, por isso é importante identificar todas as partes interessadas, levar em conta todas as suas necessidades e garantir que eles entendam as implicações dos novos sistemas. Os analistas podem empregar várias técnicas para obter os requisitos do cliente. Isso pode incluir o desenvolvimento de cenários (representados como histórias de usuários em métodos ágeis ), a identificação de casos de uso , o uso de observação ou etnografia no local de trabalho , realização de entrevistas ou grupos focais.(mais apropriadamente chamado neste contexto como workshops de requisitos ou sessões de revisão de requisitos) e criação de listas de requisitos. A prototipagem pode ser usada para desenvolver um sistema de exemplo que pode ser demonstrado às partes interessadas. Quando necessário, o analista empregará uma combinação desses métodos para estabelecer os requisitos exatos das partes interessadas, de modo que seja produzido um sistema que atenda às necessidades do negócio. [ citação necessária ] A qualidade dos requisitos pode ser melhorada através destes e de outros métodos

  • Visualização. Utilizando ferramentas que promovam uma melhor compreensão do produto final desejado, como visualização e simulação.
  • Uso consistente de modelos. Produzir um conjunto consistente de modelos e templates para documentar os requisitos.
  • Documentando dependências . Documentar dependências e inter-relações entre requisitos, bem como quaisquer suposições e congregações.

Tópicos de análise de requisitos

Identificação das partes interessadas

Consulte Análise das partes interessadas para obter uma discussão sobre pessoas ou organizações (entidades legais, como empresas, órgãos de normalização) que têm um interesse válido no sistema. Eles podem ser afetados por ela direta ou indiretamente. Uma nova ênfase importante na década de 1990 foi o foco na identificação das partes interessadas . É cada vez mais reconhecido que os stakeholders não se limitam à organização que emprega o analista. Outras partes interessadas incluirão:

  • qualquer pessoa que opere o sistema (operadores normais e de manutenção)
  • qualquer pessoa que se beneficie do sistema (beneficiários funcionais, políticos, financeiros e sociais)
  • qualquer pessoa envolvida na compra ou aquisição do sistema. Em uma organização de produtos de mercado de massa, o gerenciamento de produtos, o marketing e, às vezes, as vendas atuam como consumidores substitutos (clientes do mercado de massa) para orientar o desenvolvimento do produto.
  • organizações que regulam aspectos do sistema (reguladores financeiros, de segurança e outros)
  • pessoas ou organizações que se opõem ao sistema (partes interessadas negativas; veja também Caso de uso indevido )
  • organizações responsáveis ​​por sistemas que fazem interface com o sistema em projeto.
  • aquelas organizações que se integram horizontalmente com a organização para a qual o analista está projetando o sistema.

Sessões de Desenvolvimento Conjunto de Requisitos (JRD)

Os requisitos geralmente têm implicações multifuncionais que são desconhecidas pelas partes interessadas individuais e muitas vezes perdidas ou definidas de forma incompleta durante as entrevistas com as partes interessadas. Essas implicações interfuncionais podem ser obtidas por meio da realização de sessões JRD em um ambiente controlado, facilitado por um facilitador treinado (Analista de Negócios), em que as partes interessadas participam de discussões para elicitar requisitos, analisar seus detalhes e descobrir implicações interfuncionais. Um escriba dedicado deve estar presente para documentar a discussão, liberando o Analista de Negócios para conduzir a discussão em uma direção que gere requisitos apropriados que atendam ao objetivo da sessão.

As sessões JRD são análogas às sessões conjuntas de design de aplicativos . Na primeira, as sessões eliciam os requisitos que orientam o projeto, enquanto a segunda elicia os recursos de projeto específicos a serem implementados para satisfazer os requisitos elicitados.

Listas de requisitos de estilo de contrato

Uma maneira tradicional de documentar requisitos são as listas de requisitos de estilo de contrato. Em um sistema complexo, essas listas de requisitos podem chegar a centenas de páginas.

Uma metáfora apropriada seria uma lista de compras extremamente longa. Essas listas estão muito em desuso na análise moderna; como eles se mostraram espetacularmente malsucedidos em alcançar seus objetivos [ carece de fontes ] ; mas eles ainda são vistos até hoje.

Pontos fortes

  • Fornece uma lista de verificação de requisitos.
  • Forneça um contrato entre o(s) patrocinador(es) do projeto e os desenvolvedores.
  • Para um sistema grande pode fornecer uma descrição de alto nível a partir da qual os requisitos de nível inferior podem ser derivados.

Fraquezas

  • Essas listas podem chegar a centenas de páginas. Eles não se destinam a servir como uma descrição de fácil leitura da aplicação desejada.
  • Essas listas de requisitos abstraem todos os requisitos e, portanto, há pouco contexto. O Analista de Negócios pode incluir o contexto dos requisitos na documentação do projeto que o acompanha.
    • Esta abstração não pretende descrever como os requisitos se encaixam ou funcionam juntos.
    • A lista pode não refletir relacionamentos e dependências entre requisitos. Embora uma lista facilite a priorização de cada item individual, a remoção de um item fora do contexto pode tornar inútil um caso de uso inteiro ou um requisito de negócios.
    • A lista não suplanta a necessidade de revisar os requisitos cuidadosamente com as partes interessadas para obter um melhor entendimento compartilhado das implicações para o projeto do sistema/aplicativo desejado.
  • A simples criação de uma lista não garante sua completude. O Analista de Negócios deve fazer um esforço de boa fé para descobrir e coletar uma lista substancialmente abrangente e confiar nas partes interessadas para apontar os requisitos ausentes.
  • Essas listas podem criar uma falsa sensação de entendimento mútuo entre as partes interessadas e os desenvolvedores; Os analistas de negócios são essenciais para o processo de tradução.
  • É quase impossível descobrir todos os requisitos funcionais antes do início do processo de desenvolvimento e teste. Se essas listas forem tratadas como um contrato imutável, os requisitos que surgirem no processo de Desenvolvimento poderão gerar uma solicitação de mudança controversa.

Alternativa para listas de requisitos

Como alternativa às listas de requisitos, o Agile Software Development usa histórias de usuários para sugerir requisitos em linguagem cotidiana.

Metas mensuráveis

As melhores práticas tomam a lista composta de requisitos meramente como dicas e repetidamente perguntam "por quê?" até que os propósitos comerciais reais sejam descobertos. As partes interessadas e os desenvolvedores podem, então, elaborar testes para medir o nível de cada objetivo que foi alcançado até agora. Esses objetivos mudam mais lentamente do que a longa lista de requisitos específicos, mas não medidos. Uma vez que um pequeno conjunto de objetivos críticos e medidos tenha sido estabelecido, a prototipagem rápida e as fases de desenvolvimento iterativo curtas podem prosseguir para entregar o valor real das partes interessadas muito antes de o projeto estar na metade.

Protótipos

Um protótipo é um programa de computador que exibe uma parte das propriedades de outro programa de computador, permitindo que os usuários visualizem um aplicativo que ainda não foi construído. Uma forma popular de protótipo é uma maquete , que ajuda os futuros usuários e outras partes interessadas a ter uma ideia de como será o sistema. Os protótipos facilitam a tomada de decisões de design, pois os aspectos do aplicativo podem ser vistos e compartilhados antes da criação do aplicativo. Grandes melhorias na comunicação entre usuários e desenvolvedores foram muitas vezes vistas com a introdução de protótipos. As primeiras visualizações de aplicativos levaram a menos alterações posteriormente e, portanto, reduziram consideravelmente os custos gerais. [ citação necessária ]

Os protótipos podem ser diagramas planos (geralmente chamados de wireframes ) ou aplicativos de trabalho usando funcionalidade sintetizada. Os wireframes são feitos em uma variedade de documentos de design gráfico e geralmente removem todas as cores do design (ou seja, use uma paleta de cores em escala de cinza) nos casos em que se espera que o software final tenha design gráfico aplicado a ele. Isso ajuda a evitar confusão sobre se o protótipo representa a aparência visual final do aplicativo. [ citação necessária ]

Casos de uso

Um caso de uso é uma estrutura para documentar os requisitos funcionais de um sistema, geralmente envolvendo software, seja ele novo ou em mudança. Cada caso de uso fornece um conjunto de cenários que transmitem como o sistema deve interagir com um usuário humano ou outro sistema, para atingir uma meta de negócios específica. Os casos de uso geralmente evitam o jargão técnico, preferindo a linguagem do usuário final ou do especialista do domínio . Os casos de uso geralmente são coautoriados por engenheiros de requisitos e partes interessadas.

Os casos de uso são ferramentas enganosamente simples para descrever o comportamento de software ou sistemas. Um caso de uso contém uma descrição textual das maneiras pelas quais os usuários devem trabalhar com o software ou sistema. Os casos de uso não devem descrever o funcionamento interno do sistema, nem devem explicar como esse sistema será implementado. Em vez disso, eles mostram as etapas necessárias para executar uma tarefa sem suposições sequenciais.

Especificação de requisitos

A especificação de requisitos é a síntese das descobertas da descoberta sobre as necessidades de negócios do estado atual e a avaliação dessas necessidades para determinar e especificar o que é necessário para atender às necessidades dentro do escopo da solução em foco. Descoberta, análise e especificação movem a compreensão de um estado atual para um estado futuro. A especificação de requisitos pode abranger toda a amplitude e profundidade do estado futuro a ser realizado, ou pode visar lacunas específicas a serem preenchidas, como erros de sistema de software prioritários a serem corrigidos e aprimoramentos a serem feitos. Dado que qualquer grande processo de negócios quase sempre emprega software e sistemas de dados e tecnologia, a especificação de requisitos é frequentemente associada a construções de sistemas de software, compras, estratégias de computação em nuvem, software incorporado em produtos ou dispositivos ou outras tecnologias.

Tipos de requisitos

Os requisitos são categorizados de várias maneiras. A seguir estão categorizações comuns de requisitos relacionados ao gerenciamento técnico: [1]

Requisitos de negócio
Declarações de metas de nível de negócios, sem referência à funcionalidade detalhada. Geralmente, são recursos de alto nível (software e/ou hardware) necessários para alcançar um resultado comercial.
Requisitos do cliente
Declarações de fatos e suposições que definem as expectativas do sistema em termos de objetivos da missão, ambiente, restrições e medidas de eficácia e adequação (MOE/MOS). Os clientes são aqueles que executam as oito funções primárias da engenharia de sistemas, com especial ênfase no operador como cliente chave. Os requisitos operacionais definirão a necessidade básica e, no mínimo, responderão às questões colocadas na listagem a seguir: [1]
  • Distribuição operacional ou implantação : Onde o sistema será usado?
  • Perfil ou cenário da missão : Como o sistema cumprirá seu objetivo de missão?
  • Desempenho e parâmetros relacionados : Quais são os parâmetros críticos do sistema para cumprir a missão?
  • Ambientes de utilização : Como os vários componentes do sistema devem ser usados?
  • Requisitos de eficácia : Quão eficaz ou eficiente o sistema deve ser no desempenho de sua missão?
  • Ciclo de vida operacional : Por quanto tempo o sistema estará em uso pelo usuário?
  • Ambiente : Em quais ambientes se espera que o sistema opere de maneira eficaz?
Requisitos arquitetônicos
Os requisitos de arquitetura explicam o que deve ser feito identificando a arquitetura de sistemas necessária de um sistema .
Requisitos estruturais
Os requisitos estruturais explicam o que deve ser feito, identificando a estrutura necessária de um sistema.
Requisitos comportamentais
Os requisitos comportamentais explicam o que deve ser feito, identificando o comportamento necessário de um sistema.
Requisitos funcionais
Os requisitos funcionais explicam o que deve ser feito, identificando a tarefa, ação ou atividade necessária que deve ser realizada. A análise de requisitos funcionais será usada como as funções de nível superior para análise funcional. [1]
requisitos não Funcionais
Requisitos não funcionais são requisitos que especificam critérios que podem ser usados ​​para julgar a operação de um sistema, em vez de comportamentos específicos.
Requisitos de desempenho
A extensão em que uma missão ou função deve ser executada; geralmente medido em termos de quantidade, qualidade, cobertura, pontualidade ou prontidão. Durante a análise de requisitos, os requisitos de desempenho (quão bem deve ser feito) serão desenvolvidos interativamente em todas as funções identificadas com base nos fatores do ciclo de vida do sistema; e caracterizados em termos do grau de certeza em sua estimativa, o grau de criticidade para o sucesso do sistema e sua relação com outros requisitos. [1]
Requisitos de concepção
Os requisitos "construir para", "código para" e "comprar para" para produtos e requisitos de "como executar" para processos expressos em pacotes de dados técnicos e manuais técnicos. [1]
Requisitos derivados
Requisitos que estão implícitos ou transformados de requisitos de nível superior. Por exemplo, um requisito de longo alcance ou alta velocidade pode resultar em um requisito de projeto para baixo peso. [1]
Requisitos alocados
Um requisito que é estabelecido pela divisão ou alocação de um requisito de alto nível em vários requisitos de nível inferior. Exemplo: Um item de 100 libras que consiste em dois subsistemas pode resultar em requisitos de peso de 70 libras e 30 libras para os dois itens de nível inferior. [1]

Modelos de categorização de requisitos bem conhecidos incluem FURPS e FURPS+, desenvolvidos na Hewlett-Packard .

Problemas de análise de requisitos

Problemas das partes interessadas

Steve McConnell, em seu livro Rapid Development , detalha várias maneiras pelas quais os usuários podem inibir a coleta de requisitos:

  • Os usuários não entendem o que querem ou não têm uma ideia clara de seus requisitos
  • Os usuários não se comprometerão com um conjunto de requisitos escritos
  • Os usuários insistem em novos requisitos depois que o custo e o cronograma foram corrigidos
  • A comunicação com os usuários é lenta
  • Os usuários geralmente não participam das revisões ou são incapazes de fazê-lo
  • Os usuários não são tecnicamente sofisticados
  • Os usuários não entendem o processo de desenvolvimento
  • Os usuários não sabem sobre a tecnologia atual

Isso pode levar à situação em que os requisitos do usuário continuam mudando, mesmo quando o desenvolvimento do sistema ou do produto foi iniciado.

Problemas de engenheiro/desenvolvedor

Possíveis problemas causados ​​por engenheiros e desenvolvedores durante a análise de requisitos são:

  • Uma inclinação natural para escrever código pode levar ao início da implementação antes que a análise de requisitos seja concluída, resultando potencialmente em alterações de código para atender aos requisitos reais assim que forem conhecidos.
  • O pessoal técnico e os usuários finais podem ter vocabulários diferentes. Consequentemente, eles podem erroneamente acreditar que estão em perfeito acordo até que o produto acabado seja fornecido.
  • Engenheiros e desenvolvedores podem tentar fazer com que os requisitos se ajustem a um sistema ou modelo existente, em vez de desenvolver um sistema específico para as necessidades do cliente.

Soluções tentadas

Uma tentativa de solução para os problemas de comunicação foi empregar especialistas em análise de negócios ou de sistemas.

Técnicas introduzidas na década de 1990, como prototipagem , Unified Modeling Language (UML), casos de uso e desenvolvimento ágil de software também se destinam a soluções para problemas encontrados com métodos anteriores.

Além disso, uma nova classe de ferramentas de simulação ou definição de aplicativos entrou no mercado. Essas ferramentas são projetadas para preencher a lacuna de comunicação entre os usuários de negócios e a organização de TI — e também para permitir que os aplicativos sejam 'testados no mercado' antes que qualquer código seja produzido. A melhor dessas ferramentas oferece:

  • quadros brancos eletrônicos para esboçar fluxos de aplicativos e testar alternativas
  • capacidade de capturar a lógica de negócios e as necessidades de dados
  • capacidade de gerar protótipos de alta fidelidade que imitam de perto a aplicação final
  • interatividade
  • capacidade de adicionar requisitos contextuais e outros comentários
  • capacidade para usuários remotos e distribuídos de executar e interagir com a simulação

Veja também

Referências

  1. ^ a b c d e f g h Fundamentos de Engenharia de Sistemas Arquivado em 22/07/2011 no Wayback Machine Defense Acquisition University Press, 2001
  2. ^ Kotonya, Gerald; Sommerville, Ian (1998). Engenharia de Requisitos: Processos e Técnicas . Chichester, Reino Unido: John Wiley and Sons. ISBN 9780471972082.
  3. ^ Alan Abram; James W. Moore; Pierre Bourque; Robert Dupuis, eds. (março de 2005). "Capítulo 2: Requisitos de Software" . Guia para o corpo de conhecimento de engenharia de software (2004 ed.). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Recuperado em 2007-02-08 . É amplamente reconhecido na indústria de software que os projetos de engenharia de software são criticamente vulneráveis ​​quando essas atividades são mal executadas.

Bibliografia

Links externos