5. Tipos de Requisitos, Restrições e Premissas

5. Tipos de Requisitos, Restrições e Premissas

1. 5.1. Domínio do problema O domínio do problema é onde surge o motivo para a mudança facilitada pela Engenharia de Requisitos. É a partir desse ponto que se deve buscar entendimento antes de desenvolver uma solução, sob o risco de ter a solução perfeita para o problema errado.

   • 5.1.1. Qual é a sua importância? O domínio do problema delimita o escopo inicial de uma solução em termos de áreas funcionais ou processos de negócios. É nele que estão as partes interessadas chave, que são o ponto de partida para toda a atividade da Engenharia de Requisitos.

2. 5.2. Requisitos (ou necessidades) de negócio Requisitos (ou necessidades) de negócio são declarações de mais alto nível de objetivos, metas ou necessidades da organização. Eles descrevem as razões pelas quais um projeto foi iniciado, as metas que o projeto deve atingir e as métricas que serão utilizadas para aferir o seu sucesso.

   • 5.2.1. O que são?
     • O objetivo de resolver problemas ou aproveitar oportunidades é manter as condições atuais ou alterá-las para um novo cenário em que se deseja operar.
     • 5.2.2. Qual é a sua importância?
       • Com o conhecimento das necessidades de negócio, há mais liberdade para imaginar possíveis soluções
       • Conhecer de forma clara as necessidades de negócio fornece importantes referências sobre o valor para o negócio das solicitações recebidas e, com isso, é possível mais facilmente estabelecer prioridades.
       • Iniciativas mais longas podem envolver o esforço de trabalho de muitas pessoas ao longo de meses ou anos.
       • Revisitar as necessidades de negócio e os objetivos associados em marcos de validação intermediária permite avaliar se o caminho percorrido não se desviou do alvo e se ele representa a melhor solução.
       • 5.2.5. Papel do analista de requisitosQuando há atividades sérias de planejamento prévio, as intenções iniciais já são desenvolvidas em necessidades de negócio que observam as metas definidas pelo SMART. Porém, frequentemente é difícil encontrar as intenções iniciais observando naturalmente essas metas.
         • 5.2.6. Onde ficam registrados? Os requisitos de negócio costumam estar presentes em documentos que justifiquem o projeto e são originalmente elaborados pelas partes patrocinadoras da iniciativa em solicitações informais ou formais, como, por exemplo: Casos de negócio (business case). Estudos de viabilidade. Anteprojetos. Termos de abertura de projetos.

3. 5.3. Restrições e premissas O objetivo deste tópico é definir e exemplificar restrições e premissas de forma que possam ser identificadas e tratadas de maneira adequada ao longo do desenvolvimento dos requisitos. Ambas são informações relevantes para o sucesso do desenvolvimento do projeto e que devem ser descobertas, analisadas e tratadas ao estudar o domínio do problema. Elas são requisitos? Não, mas afetam diretamente a sua definição.

   • 5.3.1. Restrições
     • 5.3.1.1. Papel do analista de requisitos
     • 5.3.1.2. Qual é a sua importância?
     • 5.3.1.3. Restrição de negócio
       • Recursos orçamentários ou de tempo:
       • Disponibilidade dos envolvidos no projeto
       • Restrições baseadas nas habilidades da equipe de projeto e das partes interessadas
       • Outras restrições organizacionais
     • 5.3.1.4. Restrição técnica
       • Linguagem de programação.
       • Plataformas e produtos específicos de software e hardware
       • Tamanho de mensagens
       • Espaço ocupado pelos componentes de software da solução.
   • 5.3.2. Premissas Premissas são suposições, informações que se acreditam como verdadeiras, mas que ainda não foram confirmadas. Muitas vezes essas premissas são criadas pelo próprio analista de requisitos, para que se possa seguir adiante com a elaboração dos requisitos.
     • 5.3.2.1. Qual é a sua importância? Caso as premissas não se confirmem, riscos irão se materializar para o projeto.
     • 5.3.2.2. Papel do analista de requisitos A gestão de riscos não é responsabilidade do analista de requisitos. Porém, durante o trabalho de requisitos, ele deve estar atento para a percepção de premissas como tal, ou mesmo o seu estabelecimento e obtenção de consenso sobre ela.

4. 5.4. Partes interessadas O objetivo deste tópico é definir o que são as partes interessadas. Seu significado costuma ser de entendimento geral, mas formalismo, contudo, é necessário para os fins específicos da Engenharia de Requisitos.

   • 5.4.1. O caminho a partir dos requisitos de negócioUma vez entendidos o domínio do problema e as necessidades de negócio, há início a exploração do domínio da solução.
   • 5.4.2. O que são? As necessidades de negócio normalmente são fruto de uma resolução coletiva que reflete os desejos da área em análise como um todo.
   • 5.4.3. Clientes e usuários × partes interessadas Os termos “cliente” e “usuário” são muito comuns de usar para se referir aos indivíduos que deverão ser envolvidos no trabalho de requisitos comofontes de informação. E, de fato, clientes e usuários são casos específicos de partes interessadas.
   • 5.4.4. Autoridade e responsabilidade As partes interessadas – para os objetivos da Engenharia de Requisitos – são pessoas envolvidas no desenvolvimento dos requisitos.
   • 5.4.5. Qual é a sua importância? A identificação das partes interessadas é fator crítico de sucesso para o trabalho de requisitos.

5. 5.5. Requisitos das partes interessadas A função das partes interessadas no desenvolvimento dos requisitos é fornecer informações e feedback quanto à compreensão destes. A essas informações se dá o nome de requisitos das partes interessadas.

   • 5.5.1. Onde ficam registrados? Como resultado das atividades de levantamento de informações junto às partes interessadas e da volatilidade da memória humana, devem ser criados registros que documentem as informações levantadas e as decisões tomadas nas mais diferentes formas

6. 5.6. Requisitos da solução Os requisitos das partes interessadas originalmente contêm conflitos a resolver, lacunas de informação, oportunidades de racionalização, enfim, representam informações ainda não estruturadas e devem ser organizados em especificações antes de serem usados no desenvolvimento do software.

   • 5.6.1. Qual é a sua importância? As especificações com os requisitos da solução capturam todas as decisões tomadas sobre o escopo e o comportamento esperado para o software em desenvolvimento de tal forma que não se percam nem sejam esquecidas.
     • 5.6.2. Processo geral de desenvolvimento dos requisitos De maneira resumida, um processo para o desenvolvimento dos requisitos consiste em três passos
       • Organizar os requisitos das partes interessadas em um escopo da solução:
       • Desenvolver os requisitos das partes interessadas, resolver conflitos, eliminar redundâncias, superar lacunas de informação para rever o escopo e detalhar os requisitos da solução.
       • Fechar um pacote de requisitos com a profundidade suficiente para encaminhar um conjunto de especificações para atualizar a arquitetura;

7. 5.7. Requisitos de transição Imagine que na construção de um edifício seja necessário construir um vestiário e um refeitório para os operários. Ao final da obra, o vestiário e o refeitório serão desmontados, pois não farão parte do prédio propriamente dito – seu uso foi necessário apenas durante a construção.

   • 5.7.1. Qual é a sua importância? A motivação para haver um tipo de requisito para descrever a transição para a nova solução é propiciar a melhor organização das especificações na gestão de requisitos.
   • 5.7.2. Papel do analista de requisitos A identificação dos requisitos de transição deve ser precedida da avaliação de dois cenários: o cenário-alvo, necessário à nova solução em funcionamento (to-be), e o cenário atual, indicando a situação atual como está (as-is). A partir da comparação desses dois cenários, identificam-se itens de ação que devem ser atendidos (to-be) para que a solução entre em plena operação.

8. 5.8. Requisitos de software: solução + transição Os requisitos de software são compostos pelos requisitos da solução (o produto a ser entregue) e pelos requisitos da transição (se houver).

   • 5.8.1. Onde são armazenados? Os requisitos de software são mantidos em diversos tipos de artefatos, que variam conforme a metodologia de desenvolvimento de software usada pela organização. Por exemplo:  Documento de visão.  Lista de requisitos.  História de usuário

9. 5.9. Requisitos funcionais Os requisitos funcionais descrevem o comportamento que o software deve ter em termos das tarefas ou serviços do usuário. Isso se opõe à descrição do desenho da arquitetura da solução ou de sua implementação em uma plataforma tecnológica usando determinadas linguagens de programação.

   • 5.9.1. Onde são armazenados? Os requisitos funcionais podem estar presentes como parte de vários artefatos, como: documento de visão, listas de requisitos, histórias do usuário, especificações de casos de uso e modelos de processo.
   • 5.9.2. Papel do analista de requisitos São exemplos de requisitos em especificações funcionais descrições como: 1. Efetuar a gestão dos cursos. 2. Emitir o certificado de participação do aluno no curso.3. Garantir que somente alunos com frequência superior a 75% possam emitir seu certificado.
   • 5.9.3. Nível de granularidade O nível de granularidade é a maior ou menor abrangência na descrição do comportamento esperado para o software em uma especificação funcional. Essa abrangência está relacionada ao tipo de objetivo associado ao requisito presente nessa especificação.
   • 5.9.4. Requisitos funcionais com objetivo de usuário Se nada for dito ao contrário quando se refere a um requisito em uma especificação funcional, então se trata do próprio requisito funcional como descrito anteriormente. É o requisito funcional especificado:  no nível de uma única tarefa sob a responsabilidade de um único indivíduo;  em um determinado momento no qual o usuário tem tudo o que precisa para que a tarefa seja concluída até o limite de sua responsabilidade no fluxo operacional em que ela se insere.
     • 5.9.4.1. Qual é a sua importância? A importância de saber identificar um requisito funcional neste nível é poder delinear o escopo do software em desenvolvimento de maneira inequívoca; sem dúvidas quanto à sua abrangência. O escopo descrito por meio de requisitos funcionais neste nível pode mais facilmente ser validado e compreendido.
   • 5.9.5. Requisitos funcionais com objetivo agregador São requisitos que agregam vários objetivos de usuários individuais em uma única especificação de alto nível. Quanto maior o nível, mais gerais são seus objetivos – e para que um objetivo de maior nível seja alcançado, outros de menor nível devem ser alcançados.
     • 5.9.5.1. Qual é a sua importância? O propósito de descrever um requisito agregador é resumir um conjunto de tarefas do usuário em um único item quando ainda não se sabe exatamente quais delas existem, quais existirão ou quais delas serão objeto de informatização ou automação no escopo do projeto em desenvolvimento.
     • 5.9.5.2. Papel do analista de requisitos Em momentos preliminares do desenvolvimento, talvez boa parte dos requisitos identificados para compor a especificação funcional sejam requisitos agregadores.
     • 5.9.5.3. Requisitos de negócio × requisitos agregadores Um cuidado para o qual se deve atentar é diferenciar um requisito agregador de uma necessidade de negócio. Afinal, enquanto a necessidade de negócio está no domínio do problema com todo um universo de soluções em potencial, o requisito agregador tem o objetivo de descrever a solução escolhida.
   • 5.9.6. Requisitos funcionais com objetivo de subfunção Análogos aos requisitos agregadores, mas em sentido inverso, são fragmentos que compõem uma especificação funcional em um nível inferior ao nível dos objetivos do usuário: são passos e regras.
     • 5.9.6.1. Qual é a sua importância? No caso das regras de negócio, é comum que elas sejam compartilhadas entre diferentes requisitos funcionais, inclusive alocados a produtos de software diferentes.
     • 5.9.6.2. Papel do analista de requisitos O analista de requisitos, quando obtém a informação das partes interessadas como subfunções, deve saber identificá-las como tal para investigar em quais requisitos funcionais essas subfunções se inserem.

10. 5.10. Requisitos não funcionais Este tópico trata dos requisitos não funcionais que descrevem limitações de ordem geral aos requisitos funcionais e, nisso, complementam a especificação do software. Afinal, ele não deve apenas funcionar; deve funcionar bem.

    • 5.10.1. Diferença entre requisitos não funcionais e restrição técnica O requisito não funcional é o resultado de uma elaboração (de escolhas) para uma solução em particular dentre várias possíveis. As restrições técnicas são limitações impostas externamente às possíveis soluções; não é algo passível de mudança na esfera do projeto, não se negociam.
    • 5.10.2. Qual é a sua importância? Alguns requisitos não funcionais são óbvios, como haver mensagens que descrevam os erros em um vocabulário comum aos usuários do software especificado... mas será que Nelson Rodrigues estava certo e “só os profetas enxergam o óbvio”?
      • Com o objetivo de sistematizar a identificação, o desenvolvimento e a validação dos requisitos não funcionais, há alguns padrões de classificação de requisitos que podem ajudar. É possível encontrar na literatura várias formas distintas de classificação de requisitos não funcionais. Nos dois itens a seguir são apresentados dois destes casos.

11. 5.11. Requisitos inversos Um requisito inverso é uma declaração, como uma proposição negativa, indicando o que o sistema ou projeto não irá fazer ou entregar.

    • 5.11.1. Qual é a sua importância? A intenção de apresentar este tipo de requisito como parte da estrutura de tipos de requisitos neste livro é pela sua função na clarificação do escopo. Imagine a situação onde há um requisito agregador em que não se sabequais as tarefas que ele agrega; contudo, sabe-se que uma em particular estará fora.

12. 5.12. Requisitos de projeto e requisitos de qualidade A classificação de requisitos apresentada até este momento está de acordo com o proposto tanto pelo PMBOK ® Guide quanto pelo BABOK ® . Porém, vale comentar que o PMBOK ® Guide cita dois outros tipos de requisitos: requisitos de qualidade e requisitos de projeto. A definição apresentada para esses tipos é relevante apenas para o trabalho de gerência de projetos e não para o trabalho da Engenharia de Requisitos. No entanto, convém descrevê- los.