Requerimento

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

No desenvolvimento de produtos e otimização de processos , um requisito é uma necessidade física ou funcional documentada singular que um projeto, produto ou processo específico visa satisfazer. É comumente usado em um sentido formal em projeto de engenharia , incluindo, por exemplo, engenharia de sistemas, engenharia de software ou engenharia empresarial.. É um conceito amplo que pode se referir a qualquer função, atributo, capacidade, característica ou qualidade necessária (ou às vezes desejada) de um sistema para que ele tenha valor e utilidade para um cliente, organização, usuário interno ou outra parte interessada. Os requisitos podem vir com diferentes níveis de especificidade; por exemplo, uma especificação de requisito ou "especificação" de requisito (frequentemente referida de forma imprecisa como "a" especificação/especificações, mas na verdade existem diferentes tipos de especificações) refere-se a um requisito explícito, altamente objetivo/claro (e muitas vezes quantitativo) (ou às vezes, um conjunto de requisitos) a ser satisfeito por um material, projeto, produto ou serviço. [1]

Um conjunto de requisitos é usado como entrada nos estágios de design do desenvolvimento do produto . Os requisitos também são uma entrada importante no processo de verificação, uma vez que os testes devem remontar a requisitos específicos. Os requisitos mostram quais elementos e funções são necessários para o projeto em particular. Quando métodos iterativos de desenvolvimento de software ou métodos ágeis são usados, os requisitos do sistema são desenvolvidos incrementalmente em paralelo com o projeto e a implementação. Com o modelo em cascata os requisitos são desenvolvidos antes do projeto e implementação.

Origens do termo

O termo requisito está em uso na comunidade de engenharia de software desde pelo menos a década de 1960. [2]

De acordo com o Guide to the Business Analysis Body of Knowledge® versão 2 do IIBA ( BABOK ), [3] um requisito é:

  1. Uma condição ou capacidade necessária por uma parte interessada para resolver um problema ou atingir um objetivo.
  2. Uma condição ou capacidade que deve ser atendida ou possuída por uma solução ou componente de solução para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos.
  3. Uma representação documentada de uma condição ou capacidade como em (1) ou (2).

Esta definição é baseada no IEEE 610.12-1990: Glossário Padrão IEEE de Terminologia de Engenharia de Software. [4]

Requisitos de produto versus processo

Pode-se dizer que os requisitos estão relacionados a dois campos:

  • Os requisitos do produto prescrevem as propriedades de um sistema ou produto.
  • Os requisitos de processo prescrevem atividades a serem executadas pela organização em desenvolvimento. Por exemplo, os requisitos do processo podem especificar as metodologias que devem ser seguidas e as restrições que a organização deve obedecer.

Os requisitos do produto e do processo estão intimamente ligados; pode-se dizer que um requisito de produto especifica a automação necessária para dar suporte a um requisito de processo, enquanto um requisito de processo especifica as atividades necessárias para dar suporte a um requisito de produto. Por exemplo, um requisito de custo máximo de desenvolvimento (um requisito de processo) pode ser imposto para ajudar a atingir um requisito máximo de preço de venda (um requisito de produto); um requisito de que o produto seja passível de manutenção (um requisito do produto) geralmente é abordado pela imposição de requisitos para seguir estilos de desenvolvimento específicos (por exemplo, programação orientada a objetos ), guias de estilo ou um processo de revisão/inspeção (requisitos de processo).

Tipos de requisitos

Os requisitos são normalmente classificados em tipos produzidos em diferentes estágios de uma progressão de desenvolvimento, com a taxonomia dependendo do modelo geral que está sendo usado. Por exemplo, o esquema a seguir foi desenvolvido pelo International Institute of Business Analysis em seu Business Analysis Body of Knowledge [5] (veja também FURPS e Tipos de requisitos ).

Requisitos arquitetônicos
Os requisitos de arquitetura explicam o que deve ser feito, identificando a integração necessária da estrutura do sistema e do comportamento do sistema , ou seja, a arquitetura do sistema de um sistema.
Na engenharia de software , eles são chamados de requisitos arquitetonicamente significativos , que são definidos como os requisitos que têm um impacto mensurável na arquitetura de um sistema de software . [6]
Requisitos de negócio
Declarações de alto nível das metas, objetivos ou necessidades de uma organização. Eles geralmente descrevem oportunidades que uma organização deseja realizar ou problemas que desejam resolver. Muitas vezes declarado em um caso de negócios .
Requisitos do usuário (parte interessada)
Declarações de nível médio das necessidades de uma determinada parte interessada ou grupo de partes interessadas. Eles geralmente descrevem como alguém deseja interagir com a solução pretendida. Frequentemente atuando como um ponto intermediário entre os requisitos de negócios de alto nível e os requisitos de solução mais detalhados.
Requisitos funcionais (solução)
Geralmente declarações detalhadas de recursos, comportamento e informações que a solução precisará. Exemplos incluem formatação de texto, cálculo de um número, modulação de um sinal. Eles também são conhecidos como capacidades .
Requisitos de qualidade de serviço (não funcionais)
Geralmente declarações detalhadas das condições sob as quais a solução deve permanecer eficaz, qualidades que a solução deve ter ou restrições dentro das quais ela deve operar. [7] Exemplos incluem: confiabilidade, testabilidade, manutenibilidade, disponibilidade. Eles também são conhecidos como características , restrições ou ilities .
Requisitos de implementação (transição)
Normalmente, declarações detalhadas de capacidades ou comportamento são necessárias apenas para permitir a transição do estado atual da empresa para o estado futuro desejado, mas isso não será mais necessário. Os exemplos incluem recrutamento, mudanças de função, educação, migração de dados de um sistema para outro.
Requisitos regulamentares
Requisitos definidos por leis (Federais, Estaduais, Municipais ou Regionais), contratos (termos e condições) ou políticas (em nível de empresa, departamento ou projeto).

Características dos bons requisitos

As características de bons requisitos são declaradas de forma variada por diferentes escritores, com cada escritor geralmente enfatizando as características mais apropriadas para sua discussão geral ou o domínio de tecnologia específico que está sendo abordado. No entanto, as seguintes características são geralmente reconhecidas. [8] [9]

Característica Explicação
Unitário (Coesivo) O requisito aborda uma e apenas uma coisa.
Completo O requisito é totalmente declarado em um só lugar, sem informações ausentes.
Consistente O requisito não contradiz nenhum outro requisito e é totalmente consistente com toda a documentação externa autorizada.
Não conjugado ( atômico ) O requisito é atômico , ou seja, não contém conjunções. Por exemplo, "O campo de código postal deve validar códigos postais americanos e canadenses" deve ser escrito como dois requisitos separados: (1) "O campo de código postal deve validar códigos postais americanos" e (2) "O campo de código postal deve validar códigos postais canadenses códigos".
Rastreável O requisito atende a toda ou parte de uma necessidade de negócios conforme declarado pelas partes interessadas e documentado com autoridade.
Atual O requisito não se tornou obsoleto com o passar do tempo.
Sem ambiguidade O requisito é declarado de forma concisa, sem recorrer a jargões técnicos , acrônimos (a menos que definido em outro lugar no documento de Requisitos) ou outro palavreado esotérico. Expressa fatos objetivos, não opiniões subjetivas. Está sujeito a uma e apenas uma interpretação. Sujeitos vagos, adjetivos, preposições, verbos e frases subjetivas são evitados. Declarações negativas e declarações compostas são evitadas.
Especificar importância Muitos requisitos representam uma característica definida pelas partes interessadas, cuja ausência resultará em uma deficiência importante ou mesmo fatal. Outros representam recursos que podem ser implementados se o tempo e o orçamento permitirem. O requisito deve especificar um nível de importância.
Verificável A implementação do requisito pode ser determinada através de métodos básicos possíveis: inspeção, demonstração, teste (instrumentado) ou análise (para incluir modelagem e simulação validadas).

Há muitos outros atributos a serem considerados que contribuem para a qualidade dos requisitos. Se os requisitos estão sujeitos a regras de integridade de dados (por exemplo), precisão/correção e validade/autorização também são atributos valiosos. A rastreabilidade confirma que o conjunto de requisitos atende à necessidade (não mais - e não menos do que o necessário).

Para o acima, alguns adicionam Externamente Observável, ou seja, o requisito especifica uma característica do produto que é externamente observável ou experimentada pelo usuário. Esses defensores argumentam que os requisitos que especificam a arquitetura interna, design, implementação ou decisões de teste são provavelmente restrições e devem ser claramente articulados na seção Restrições do documento Requisitos. A visão contrastante é que essa perspectiva falha em dois pontos. Primeiro, a perspectiva não reconhece que a experiência do usuário pode ser suportada por requisitos não perceptíveis pelo usuário. Por exemplo, um requisito para apresentar dados geocodificadosinformações para o usuário podem ser suportadas por um requisito para uma interface com um parceiro de negócios externo. A interface será imperceptível para o usuário, embora a apresentação das informações obtidas através da interface certamente não o seja. Em segundo lugar, uma restrição limita as alternativas de projeto, enquanto um requisito especifica as características do projeto. Para continuar o exemplo, um requisito de seleção de uma interface de serviço da Web é diferente de uma restrição que limita as alternativas de design a métodos compatíveis com uma arquitetura Single Sign-On.

Verificação

Todos os requisitos devem ser verificáveis. O método mais comum é por teste. Se este não for o caso, outro método de verificação deve ser usado (por exemplo, análise, demonstração, inspeção ou revisão do projeto).

Certos requisitos, pela sua própria estrutura, não são verificáveis. Isso inclui requisitos que dizem que o sistema nunca ou sempre deve exibir uma propriedade específica. O teste adequado desses requisitos exigiria um ciclo de teste infinito. Tais requisitos devem ser reescritos para serem verificáveis. Como dito acima, todos os requisitos devem ser verificáveis.

Os requisitos não funcionais, que não são verificáveis ​​no nível do software, ainda devem ser mantidos como documentação da intenção do cliente. No entanto, eles podem ser rastreados para requisitos de processo que são determinados como uma maneira prática de atendê-los. Por exemplo, um requisito não funcional para estar livre de backdoors pode ser satisfeito substituindo-o por um requisito de processo para usar programação em par . Outros requisitos não funcionais serão rastreados para outros componentes do sistema e serão verificados nesse nível. Por exemplo, a confiabilidade do sistema é frequentemente verificada por análise no nível do sistema. O software aviônico com seus complicados requisitos de segurança deve seguir o processo de desenvolvimento do DO-178B .

Atividades que levam à derivação do sistema ou requisitos de software. A engenharia de requisitos pode envolver um estudo de viabilidade ou uma fase de análise conceitual do projeto e levantamento de requisitos (coletar, entender, revisar e articular as necessidades das partes interessadas ) e análise de requisitos , [10] análise (verificação de consistência e integridade), especificação (documentar os requisitos) e validação (certificando-se de que os requisitos especificados estão corretos). [11] [12]

Os requisitos são propensos a questões de ambiguidade, incompletude e inconsistência. Técnicas como inspeção rigorosa foram mostradas para ajudar a lidar com esses problemas. Ambiguidades, incompletude e inconsistências que podem ser resolvidas na fase de requisitos normalmente custam ordens de magnitude menos para corrigir do que quando esses mesmos problemas são encontrados em estágios posteriores do desenvolvimento do produto. A análise de requisitos se esforça para resolver esses problemas.

Há uma troca de engenharia a ser considerada entre requisitos que são muito vagos e aqueles que são tão detalhados que

  1. levar muito tempo para produzir - às vezes a ponto de ficar obsoleto uma vez concluído
  2. limitar as opções de implementação disponíveis
  3. são caros para produzir

As abordagens ágeis evoluíram como uma forma de superar esses problemas, baseando os requisitos em alto nível e elaborando detalhes just-in-time ou no último momento responsável .

Requisitos de documentação

Os requisitos são geralmente escritos como um meio de comunicação entre as diferentes partes interessadas. Isso significa que os requisitos devem ser fáceis de entender tanto para usuários normais quanto para desenvolvedores. Uma maneira comum de documentar um requisito é declarar o que o sistema deve fazer. Exemplo: 'O contratante deve entregar o produto até a data xyz.' Outros métodos incluem casos de uso e histórias de usuários .

Mudanças nos requisitos

Os requisitos geralmente mudam com o tempo. Uma vez definidos e aprovados, os requisitos devem estar sob controle de mudanças . Para muitos projetos, os requisitos são alterados antes que o sistema seja concluído. Isso se deve em parte à complexidade do software de computador e ao fato de que os usuários não sabem o que querem antes de vê-lo. Essa característica dos requisitos levou a estudos e práticas de gerenciamento de requisitos.

Problemas

Padrões concorrentes

Existem várias visões concorrentes sobre o que são requisitos e como eles devem ser gerenciados e usados. Dois órgãos líderes na indústria são o IEEE e o IIBA. Ambos os grupos têm definições diferentes, mas semelhantes, do que é um requisito.

Disputas sobre a necessidade e os efeitos dos requisitos de software

Muitos projetos tiveram sucesso com pouco ou nenhum acordo sobre os requisitos. [13] Além disso, algumas evidências indicam que a especificação de requisitos pode diminuir a criatividade e o desempenho do design. [14] Os requisitos dificultam a criatividade e o design porque os designers ficam excessivamente preocupados com as informações fornecidas. [15] [16] [17] De forma mais geral, algumas pesquisas sugerem que os requisitos de software são uma ilusão criada pela deturpação das decisões de projeto como requisitos em situações em que não há requisitos reais evidentes. [18]

Enquanto isso, as metodologias de desenvolvimento de software mais ágeis questionam a necessidade de descrever rigorosamente os requisitos de software antecipadamente, o que eles consideram um alvo móvel. Em vez disso, a programação extrema , por exemplo, descreve requisitos informalmente usando histórias de usuários (resumos que cabem em um cartão explicando um aspecto do que o sistema deve fazer) e considera dever do desenvolvedor pedir esclarecimentos diretamente ao cliente. As metodologias ágeis tentam capturar os requisitos em uma série de testes de aceitação automatizados .

Crescente de requisitos

A fluência do escopo pode ocorrer a partir de requisitos que se movem ao longo do tempo. No gerenciamento de requisitos, a alteração de requisitos é permitida, mas se não for adequadamente rastreada ou etapas anteriores (objetivos de negócios e requisitos do usuário) não forem estranguladas por supervisão adicional ou tratadas como um custo e uma possível falha do programa, as alterações de requisitos são fáceis e prováveis ​​de acontecer. É fácil que as mudanças de requisitos ocorram mais rápido do que os desenvolvedores são capazes de produzir trabalho, e o esforço para retroceder como resultado.

Taxonomias de vários requisitos

Existem várias taxonomias para requisitos, dependendo de qual estrutura está operando. (Por exemplo, os padrões declarados das abordagens IEEE, vice IIBA ou US DoD). Linguagem e processos diferentes em locais diferentes ou discurso casual podem causar confusão e desvio do processo desejado.

Corrupções do processo

Um processo executado por humanos está sujeito a falhas humanas na governança, onde conveniências, desejos ou políticas podem levar a exceções ou subversão total do processo e desvios da maneira como o processo deveria prosseguir. Exemplos incluem:

  • Processo sem rigor não recebe respeito - Se exceções ou mudanças são comuns, como a organização que o administra ter pouca independência ou poder ou não ser confiável e transparente nos registros, isso pode levar a que todo o processo seja ignorado.
  • Novos atores querendo uma renovação - por exemplo, a tendência natural de novas pessoas quererem mudar o trabalho de seus antecessores para demonstrar seu poder ou alegações de valor, como um novo CEO querendo mudar o planejamento do CEO anterior, incluindo objetivos de negócios, de algo (como uma solução de software) já em desenvolvimento, ou um objeto de escritório recém-criado para o desenvolvimento atual de um projeto porque eles não existiam quando os requisitos do usuário foram criados, então eles começam um esforço para retroceder e redefinir o projeto.
  • Colorir fora das linhas - por exemplo, os usuários que desejam mais controle não apenas inserem coisas que atendem à definição de gerenciamento de requisitos de "requisito do usuário" ou nível de prioridade, mas inserem detalhes de design ou características do fornecedor favorito como requisitos do usuário ou tudo o que seu escritório diz como o mais alto possível prioridade.
  • Aparecer atrasado - por exemplo, fazer pouco ou nenhum esforço na elicitação de requisitos antes do desenvolvimento. Isso pode ser devido a pensar que eles terão o mesmo benefício independentemente da participação individual, ou que não adianta se eles podem apenas inserir demandas na fase de testes e próxima rodada, ou a preferência de estar sempre certo esperando o pós-trabalho crítica.

Dentro do processo do Departamento de Defesa dos EUA, alguns exemplos históricos de questões de requisitos são

  • as questões M-2 Bradley do movimento de exigências casuais retratadas nas Guerras do Pentágono ;
  • o crescimento do F-16 a partir do conceito de caça leve da máfia Fighter , atribuído ao programa F-15 que tenta sabotar a competição ou escritórios individuais colocando em desejos locais erodindo o conceito de ser leve e de baixo custo.
  • entusiasmo ca. 1998 para 'Net-Ready' levou ao seu mandato como Parâmetro-Chave de Desempenho do escritório Net-Ready, fora do escritório, definindo o processo de requisitos e não consistente com o processo definido anteriormente daquele escritório, sua definição do que era um KPP ou que alguns esforços pode não ser apropriado ou capaz de definir o que constitui 'Net-Ready'.

Veja também

Referências

  1. ^ Forma e estilo dos padrões, ASTM Blue Book (PDF) . ASTM Internacional . 2012 . Recuperado em 5 de janeiro de 2013 .
  2. ^ Boehm, Barry (2006). "Uma visão da engenharia de software do século 20 e 21" . ICSE '06 Anais da 28ª Conferência Internacional de Engenharia de Software . University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, EUA. págs. 12–29. ISBN 1-59593-375-1. Recuperado em 2 de janeiro de 2013 .
  3. ^ "1.3 Conceitos-chave - IIBA | Instituto Internacional de Análise de Negócios" . www.iiba.org . Recuperado 2016-09-25 .
  4. ^ "IEEE SA - 610.12-1990 - Glossário padrão IEEE de terminologia de engenharia de software" .
  5. ^ Iiba; Análise, Instituto Internacional de Negócios (2009). A Guide to the Business Analysis Body of Knowledge® (Guia BABOK®) Versão 2.0 . ISBN 978-0-9811292-1-1.
  6. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Caracterizando Requisitos Arquitetonicamente Significativos". Software IEEE . 30 (2): 38–45. doi : 10.1109/MS.2012.174 . HD : 10344/3061 . S2CID 17399565 . 
  7. ^ Ralph, P., e Wand, Y. Uma proposta para uma definição formal do conceito de design. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J. e Robinson, W., (eds.), Engenharia de Requisitos de Projeto: Uma Perspectiva de Dez Anos: Springer-Verlag, 2009, pp. 103-136
  8. ^ Davis, Alan M. (1993). Requisitos de software: objetos, funções e estados, segunda edição . Prentice Hall. ISBN 978-0-13-805763-3.
  9. ^ Sociedade do computador de IEEE (1998). Prática Recomendada IEEE para Especificações de Requisitos de Software . Instituto de Engenheiros Elétricos e Eletrônicos, Inc. ISBN 978-0-7381-0332-7.
  10. ^ Stellman, André; Greene, Jennifer (2005). Gerenciamento de Projetos de Software Aplicado . Mídia O'Reilly. pág. 98. ISBN 978-0-596-00948-9. Arquivado a partir do original em 2015-02-09.
  11. ^ Wiegers, Karl E. (2003). Requisitos de software, segunda edição . Imprensa da Microsoft. ISBN 978-0-7356-1879-4.
  12. ^ Jovem, Ralph R. (2001). Práticas de Requisitos Eficazes . Addison-Wesley. ISBN 978-0-201-70912-4.
  13. ^ Checkland, Peter (1999). Pensamento Sistêmico, Prática Sistêmica . Chichester: Wiley.
  14. ^ Ralf, Paulo; Mohanani, Rahul (maio de 2015). "A Engenharia de Requisitos é inerentemente contraproducente?" . Anais do 5º Workshop Internacional sobre os Twin Peaks de Requisitos e Arquitetura . Florença, Itália: IEEE. págs. 20-23.
  15. ^ Jansson, D.; Smith, S. (1991). "Fixação de desenho". Estudos de Design . 12 (1): 3–11. doi : 10.1016/0142-694X(91)90003-F .
  16. ^ Purcell, A.; Gero, J. (1996). "Design e outros tipos de fixação". Estudos de Design . 17 (4): 363–383. doi : 10.1016/S0142-694X(96)00023-3 .
  17. ^ Mohanani, Rahul; Ralf, Paulo; Shreeve, Ben (maio de 2014). "Fixação de Requisitos" . Anais do Congresso Internacional de Engenharia de Software . Hyderabad, Índia: IEEE. págs. 895-906.
  18. ^ Ralph, Paul (2012). "A Ilusão de Requisitos no Desenvolvimento de Software". Engenharia de Requisitos . 18 (3): 293–296. arXiv : 1304.0116 . doi : 10.1007/s00766-012-0161-4 . S2CID 11499083 . 

Links externos