Fala, pessoal!

Há muito tempo não tinha feito uma prova tão bem feita como foi a prova da ANTAQ. Foi bem elaborada. Que pena que as questões de Direito me tiraram do páreo, entretanto é isso mesmo. É estudar o que erramos e melhorar!

Bom, o motivo do post é mostrar um possível texto para a redação exigida para o cargo 9 (Analista de Informática).

Antes de mostrar o texto, acredito que é interessante revisar os itens exigidos no comando da redação que está assim definido:

O MPS.BR, programa para melhoria de processo do software brasileiro, desenvolvido desde dezembro de 2003, é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX) e conta com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).

Considerando a caracterização do MPS.BR apresentada acima, redija um texto dissertativo acerca da importância de requisitos no MPS.BR. Ao elaborar seu texto, aborde, necessariamente, a gerência de requisitos (GRE) e o desenvolvimento de requisitos (DRE), apresentando exemplos de requisitos funcionais e não funcionais.

Com isso, podemos revisar os seguintes itens:

  • Gerência de Requisitos (GRE) do MPS.BR [1];
  • Desenvolvimento de Requisitos (DRE) do MPS.BR; e
  • Requisitos funcionais e não funcionais.

Gerência de Requisitos (GRE)

  • Nível MR-MPS:
  1. G – Parcialmente Gerenciado
  • Propósito:
  1. Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
  • Resultados esperados:
  1. GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;
  2. GRE 2. Os requisitos de software são aprovados utilizando critérios objetivos;
  3. GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
  4. GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos;
  5. GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
  • Equivalência CMMI:
  1. Gerência de Requisitos

Encontrei um resumo que resume bem a GRE [2]:

O principal objetivo da Gerência de Requisitos é controlar a evolução dos requisitos. O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos impostos ao projeto pela organização. Para assegurar que o conjunto de requisitos acordados é gerenciado e fornece suporte às necessidades de planejamento e execução do projeto, a organização deve executar um conjunto de passos definidos e apropriados. Quando um projeto recebe requisitos de um fornecedor de requisitos – pessoa autorizada a participar de sua definição e a solicitar modificação –, estes devem ser revisados para resolver questões e prevenir o mau entendimento, antes que os requisitos sejam incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a organização chegam a um acordo, é obtido um compromisso das demais partes interessadas sobre os requisitos. Outras atribuições do processo Gerência de Requisitos são documentar as mudanças nos requisitos e suas justificativas, bem como manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.

Outra fonte interessante sobre esse processo é o artigo Desmistificando o MPS.BR – Gerência de Requisitos (GRE) [3] do blog do Samuel Luiz [4].

Desenvolvimento de Requisitos (DRE)

  • Nível MR-MPS:
  1. D – Largamente Definido
  • Propósito:
  1. Estabelecer os requisitos dos componentes do produto, do produto e do cliente.
  • Resultados esperados:
  1. DRE 1. As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas;
  2. DRE 2. Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas;
  3. DRE 3. Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente;
  4. DRE 4. Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados;
  5. DRE 5. Interfaces internas e externas do produto e de cada componente do produto são definidas;
  6. DRE 6. Conceitos operacionais e cenários são desenvolvidos;
  7. DRE 7. Os requisitos são analisados para assegurar que sejam necessários, corretos, testáveis e suficientes e para balancear as necessidades dos interessados com as restrições existentes;
  8. DRE 8. Os requisitos são validados.
  • Equivalência CMMI:
  1. Desenvolvimento de Requisitos

Diferença entre os processos

A principal diferença dos processos é que o primeiro, Gerência de Requisitos (GRE), trata somente do gerenciamento e evolução dos requisitos dos produtos e componentes do produto do projeto e identifica inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Não foca o levantamento e especificação dos requisitos ou como eles serão validados. São essas lacunas que o processo Desenvolvimento de Requisitos (DRE) vem para fechar.

Síntese dos dois processos

SinteseProvaSubjetivaANTAQ

Requisitos funcionais e não funcionais

Usando as definições do Sommerville [5], temos

  • Requisitos funcionais: descrevem o que o sistema deve fazer. Eles dependem do tipo de software que está sendo desenvolvido, dos usuários a que o software se destina e da abordagem geral considerada pela organização ao redigir os requisitos. São declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas e como o sistema deve se comportar em determinadas situações. Em alguns casos, esses requisitos podem também estabelecer explicitamente o que o sistema não deve fazer.
  • Requisitos não funcionais: são restrições sobre os serviços ou as funções oferecidos pelo sistema. Eles não estão diretamente relacionados às funções específicas fornecidas pelo sistema. Podem estar relacionados a propriedades como confiabilidade, tempo de resposta e espaço de armazenamento.

A Redação

Vamos agora como seria um exemplo de redação que pudesse responder ao comando da prova:

Os requisitos de software são muitos importantes, pois eles irão oferecer ao software o porquê de sua existência. Um requisito mal identificado, validado ou gerenciado pode afetar significadamente o tempo e o custo do desenvolvimento de uma aplicação. Sendo assim, o programa MPS.BR (Melhoria de Processos do Software Brasileiro) reservou dois processos para tratar dos requisitos de software, sendo eles funcionais ou não funcionais: Gerência de Requisitos (GRE) no nível G (Parcialmente Gerenciado) e Desenvolvimento de Requisitos (DRE) no nível D (Largamente Definido).

Logo no primeiro em seu primeiro nível de maturidade, nível G, o MPS.BR define a GRE, pois a empresa que decidir seguir o MPS.BR precisa saber de imediato gerenciar os requisitos dos seus projetos de software. A GRE foca o gerenciamento e a evolução dos requisitos dos produtos e componentes do produto do projeto e identifica inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Não define o levantamento e especificação dos requisitos ou como eles serão validados, que é justamente os resultados esperados pelo processo DRE que possui o objetivo de estabelecer os requisitos dos componentes do produto, do produto e do cliente.

Tanto a GRE quanto o DRE tratam de requisitos funcionais ou não funcionais. Os primeiros são requisitos que descrevem o que sistema deve fazer e, em alguns casos, o que não deve fazer. São exemplos desse tipo de requisitos são: o sistema a ser desenvolvido deve possibilitar o cadastramento dos dados pessoais dos clientes; emitir relatórios gerenciais; e deve permitir a baixa automática do estoque quando da venda de um produto.

Já os requisitos não funcionais são restrições sobre os serviços ou as funções oferecidos pelo sistema e ão estão diretamente relacionados às funções específicas fornecidas pelo sistema. Como exemplos para esses requisitos temos: o software deve permitir um sistema de autenticação e permissão; o tempo de resposta não deve ultrapassar 15 segundos; o aplicativo será construído utilizando a linguagem de programação Java; e o banco de dados será Oracle.

[]s e até a próxima!

Rogério Araújo
Blog: https://rogerioaraujo.wordpress.com/
Gmail: rgildoaraujo@gmail.com

O trabalho árduo e a disciplina são os meios mais rápidos de alcançar meus objetivos!!!
Eu posso, eu consigo! Eu acredito em mim!

Referências

[1] MPS.BR: http://www.softex.br/mpsbr/

[2] mpsbr-gre Gerência de Requisitos do MPS.BR: http://code.google.com/p/mpsbr-gre/

[3] Desmistificando o MPS.BR – Gerência de Requisitos (GRE): http://blogdosamueldiniz.blogspot.com/2009/03/desmistificando-o-mpsbr-gerencia-de.html

[4] Blog do Samuel Diniz: http://blogdosamueldiniz.blogspot.com/

[5] SOMMERVILLE, Ian. Software Engineering, 8ª Edição, Addison-Wesley, 2007