Ciclo de Vida de Requisitos

O ciclo de vida de requisitos ainda não é um conceito muito estudado, sendo assim, é difícil encontrar informação nesta matéria. Contudo, Carlshamre e Regnell (2000) identificam dois modelos para o ciclo de vida dos requisitos. São eles o RDEM (Requirement Driven Evolution Model) e o REPEAT (Requirements Engineering Process At Telelogic).

RDEM

O RDEM divide-se quatro fases (Carlshamre & Regnell, 2000): 1. Capturado: Nada é um requisito até ser capturado;

2. Especificado: Um requisito especificado contém toda a informação necessária para proceder com a implementação e verificação de um constituinte de um sistema. Nesta fase os requisitos estão agrupados em conjuntos denominados de deltas. Um delta contém um conjunto específico de atributos;

Ilustração 8: Modelo de ciclo de vida de software por versões, adaptado de (Rajlich & Bennett, 2000)

3. Planeado: Um delta para ser implementado ou verificado (realizado no RDEM) necessita de ser planeado;

4. Realizado: Este é o último estado do requisito na terminologia RDEM. Nesta fase o delta é transformado numa caraterística de um sistema.

REPEAT

O modelo do ciclo de vida REPEAT para os requisitos está dividido em 6 fases (Carlshamre & Regnell, 2000) (ver ilustração 9):

1. Novo: Este estado representa o estado inicial de um requisito;

2. Atribuído: Um requisito é elevado a atribuído quando um especialista foi atribuído para investigar o requisito;

3. Classificado: Um especialista atribui um valor aos atributos de um requisito;

4. Selecionado: Aqui os requisitos que refletem o produto são selecionados para a implementação; 5. Aplicado: O requisito está implementado;

6. Rejeitado: O requisito é rejeitado, e por isso não está implementado na solução final.

Tendo em conta que no âmbito desta dissertação de mestrado a gestão de requisitos será feita ao longo de diversos projetos, o modelo REPEAT é o mais adequado.

2.4.4 Sumário

Neste capítulo é referido que existem 3 tipos de ciclos de vida que podem estar relacionados com o conceito de requisito, são eles:

• Ciclo de vida do produto;

Ilustração 9: Modelo de ciclo de vida REPEAT, adaptado de (Carlshamre & Regnell, 2000)

• Ciclo de vida do sistema e software; • Ciclo de vida do requisito.

O ciclo de vida do produto compreende as seguintes fases: (1) introdução, (2) evolução, (3) maturidade e (4) declínio.

Genericamente, o ciclo de vida do sistema é constituído por: (1) ideia, (2) desenvolvimento, (3) produção, (4) utilização, (5) suporte e (6) aposento, já o ciclo de vida do software está organizado em: (1) desenvolvimento inicial, (2) evolução, (3) manutenção, (4) descontinuação e (5) encerramento.

Identificam-se 2 ciclos de vida (RDEM e REPEAT) do requisito e conclui-se que o REPEAT é o mais adequado no âmbito deste trabalho. Este é constituído pelas seguintes fases: (1) novo, (2) atribuído, (3) classificado, (4) selecionado, (5) aplicado e (6) rejeitado.

2.5 Conclusões

Esta revisão de literatura fornece reflexões sobre os elementos que constituem a finalidade desta dissertação de mestrado, dando ao leitor as bases necessárias para interpretar o restante conteúdo deste documento. Em adição, fornece ao autor desta dissertação de mestrado a matéria para a conceção do processo aplicável à Bosch, no capítulo 3, que resolve o problema estabelecido na introdução (capítulo 1).

Desta análise do “estado de arte” conclui-se que, um requisito é uma capacidade que um sistema deve possuir para satisfazer necessidades de utilizadores e pode ser classificado quanto ao nível, como quanto ao seu tipo. Os requisitos podem ser classificados como alto e baixo nível (se a escala for o nível), mas também podem ser classificados como requisitos de utilizador, requisitos de sistema, requisitos funcionais e requisitos não funcionais (se a categoria for o tipo).

A engenharia de requisitos é definida como uma disciplina transversal a diversas áreas, desde que estas tenham o propósito de desenvolver sistemas. Pode também ser considerado um processo que permite levantar, negociar, documentar e gerir requisitos ao longo do ciclo de vida do sistema. As seguintes atividades constituem o processo genérico de engenharia de requisitos: (1) início do processo, (2) levantamento de requisitos, (3) desenvolvimento de requisitos; (4) negociação de requisitos; (5) documentação de requisitos; (6) validação de requisitos; (7) gestão de requisitos.

A gestão de requisitos é frequentemente desprezada na maioria das organizações, porém diversos autores reconhecem grande potencial nesta atividade para aumentar a eficácia e eficiência do processo de engenharia de requisitos. Um grande catalisador para esta atividade ter este potencial é a reutilização de

Dentre os ciclo de vida existentes o ciclo de vida do produto, o ciclo de vida do sistema e software, e o ciclo de vida do requisito são os conciliáveis com a objetividade deste documento. Genericamente, o ciclo de vida do produto compreende as fases de: (1) introdução, (2) evolução, (3) maturidade e (4) declínio. O ciclo de vida do sistema é dividido em: (1) ideia, (2) desenvolvimento, (3) produção, (4) utilização, (5) suporte e (6) aposento, porém o ciclo de vida de um software está organizado em: (1) desenvolvimento inicial, (2) evolução, (3) manutenção, (4) descontinuação e (5) encerramento. O ciclo de vida adequando na abordagem desta dissertação de mestrado é constituído por: (1) novo, (2) atribuído, (3) classificado, (4) selecionado, (5) aplicado e (6) rejeitado.

REQUISITOS

3.1 Introdução

Embora na Bosch worldwide já sejam utilizadas algumas ferramentas para o propósito de gestão de requisitos, como é o caso da aplicação DOORS o u Requisite Pro da IBM, no departamento de CI-CWR1 ainda não se faz qualquer esforço para gerir requisitos. Em adição, as ferramentas referenciadas no parágrafo ainda não oferecem funcionalidades que sustentem a gestão do ciclo de vida de requisitos, que é necessária para resolver o problema desta dissertação de mestrado.

Como está esplícito no capítulo 1, a abordagem metodológica utilizada nesta dissertação é a Design Science Research. Este método científico sugere a criação de um artefacto, ou seja algum objeto com a contribuição da investigação para a sua conceção (Peffers et al., 2007). Esta contribuição da investigação é frequentemente especificada através de uma revisão de literatura, que nesta dissertação é referente ao anterior capítulo (capítulo 2, os requisitos, engenharia de requisitos e ciclos de vida).

Atendendo que a organização Bosch usa processos para delimitar as funções estabelecidas em cada departamento, o artefacto resultante desta conceção é um processo. Justifica-se esta escolha com a facilidade de alinhar as funcionalidades estipuladas nesta dissertação de mestrado, para resolver o problema, com as atividades já definidas no domínio aplicacional.

Segundo Davenport (1993) um processo pode ser definido como uma ordenação específica de atividades de trabalho ao longo do tempo e espaço, com um início, um fim, e as entradas e saídas claramente identificadas. De modo a complementar esta definição, Møller e Ph (2012) afirmam que um processo pode assumir uma vertente mais administrativa. Por exemplo, certas entidades governamentais podem utilizar um processo para servir as necessidades dos colaboradores de uma determinada organização. As incidências discutidas neste parágrafo sustentam a escolha para o artefacto resultante deste objeto de investigação.

Segundo Browning (2002), uma forma de visualizar processos é através da modelação de processos de negócio. Para modelar processos de negócio, Dufresne e Martin (2003) sugerem diversas metodologias:

1. Flow Charts;

2. Data Flow Diagrams; 3. Control Flow Diagrams;

5. Gantt/PERT Diagrams;

6. Unified Modeling Language (UML);

7. Business Process Modeling Notation (BPMN).

Visto que no departamento de CI-CWR1, da Bosch Car Multimédia Portugal S.A., constata-se uma grande tendência para uso de UML na atividade de modelação, o autor deste documento opta por utilizar os diagramas de atividade desta notação, numa variante potencializada para os Work Flow Diagrams (Chonoles & Schardt, 2003). Esta abordagem deve facilitar a compreensão do processo aplicável à Bosch por parte dos potenciais utilizadores.

Um processo pode ser constituído por (1) atividades, (2) papeis e (3) artefactos (Ramzan & Ikram, 2006). Com base neste facto cria-se a estrutura deste capítulo (os artefactos são remetidos para anexo/apêndice).

No sub-capítulo 3.2, a sequência das atividades, que alinham no processo aplicável à Bosch, é apresentada. Aqui as atividades são divididas em duas componentes do processo: (1) requirements development e (2) requirements management. Posteriormente, cada atividade é detalhada em tarefas, enquanto se faz uma explicação mais aprofundada. Por fim, a inclusão das atividades (e tarefas adjacentes) é devidamente justificada.

No sub-capítulo 3.3, os papeis necessários à concretização das atividades determinadas no sub- capítulo 3.2 são selecionados. Segue-se uma elucidação destes papeis para se determinem os seus requisitos.