Bosch (quando se trata de um projeto onde se pretende desenvolver mais do que um sistema de informação, o software requirements engineer de criar um LHPH para cada sistema de informação). O LHPH tem uma estrutura que não obriga o software requirements engineer a ser estritamente fiel a esta. Há pontos no documento que podem não corresponder às necessidades da documentação de requisitos para o projeto em questão, sendo assim, o software requirements engineer deve apenas mencionar, que o ponto em questão, não se aplica nestas circunstâncias. Contudo, este artefacto apresenta uma estrutura projetada por pessoas especializadas na área, não são aconselhadas mudanças de grandes proporções.
Justificação
Como está exposto anteriormente, o artifact of requirements handling (ver apêndice I, artifact of requirements handling), fortemente utilizado nas atividades de levantamento e desenvolvimento de requisitos, contém os requisitos levantados e desenvolvidos, no âmbito da atual iteração do processo aplicável à bosch car multimédia portugal s.a. No entanto, este artefacto para além de ser concebido com o propósito de suportar exclusivamente o trabalho do software requirements engineer, contém os requisitos que são selecionados e os que são rejeitados na atividade de prioritização de requisitos. Qualquer processo de engenharia de requisitos contém a atividade de documentação de requisitos, devido à necessidade de formalizar os requisitos que constituem o(s) sistema(s) de informação, documentando-os (Pandey et al., 2010). Ao documentar estes requisitos no documento formal, o software requirements engineer está a abrir uma janela para comunicar o seu trabalho a outras entidades.
Os requisitos que possuem o estado “selecionado”, são aqueles que pertencem ao subconjunto dos requisitos fundamentais para o(s) sistema(s) de informação. Naturalmente, os software requirements engineers necessitam de recolher estes requisitos de forma a poderem formalizar-los.
Pressman (2005) sugere que os software requirements engineers devem seguir um padrão, no que toca à documentação de requisitos. Internamente à Bosch, há um artefacto, de carácter obrigatório, e por consequência já utilizado em projetos de engenharia de software da organização, ao qual se deu o nome de LHPH. Como este artefacto é obrigatório para a especificação de requisitos, o software requirements engineer tem a obrigação de o desenvolver.
De modo a desambiguar algumas questões, o LHPH compreende pontos onde sugere descrições, do problema, ou de alguma componente do problema. Com isto, recolher as descrições de onde são originados os requisitos torna-se útil.
g) Validation
Explicação
O objetivo desta atividade é assegurar que os requisitos definem o(s) sistema(s) desejado(s) pelo client (Fernandes & Machado, 2015). Para isto alguma tarefas devem ser efetuadas por diferentes atores (ver ilustração 17):
1. Verify if requirements are according to the required solution(s): O client (ver capítulo 3.3, atores do processo) analisa o(s) LHPH(s) (ver anexo I, LHPH) resultante(s) da atividade de documentation com detalhe, e verifica se os requisitos que estão neste especificados, correspondem as características do(s) sistema(s) de informação desejado(s);
Se os requisitos corresponderem à(s) solução(ões) pretendida(s) pelo client, a tarefa sign the LHPH é executada. Todavia, se o client sentir que os requisitos especificados não correspondem à(s) solução(ões) desejada(s), a tarefa adjust requirements or cut them from the LHPH é desempenhada.
2. Adjust requirements or cut them from the LHPH: Um software requirements engineer (ver capítulo 3.3, atores do processo) verifica que requisitos o client considera desajustados. De seguida, deve perceber com este, como resolver este desajuste. Se o client entender que algum requisito está completamente desenquadrado daquilo que pretende, retirar o requisito do LHPH resolve o desajuste. Porém, se o client entender que o requisito foi mal percebido, ou está incompleto, o software requirements engineer tem de alterar este (a versão deste, ao nível do requisito) no artifact of requirements handling (ver apêndice I, artifact of requirements handling) e no LHPH. No fim desta tarefa, o client volta a verificar se os requisitos que constituem o(s) LHPH(s) correspondem à(s) solução(ões) pretendida(s);
3. Sign the LHPH: O project manager (ver capítulo 3.3, atores do processo) e o client assinam o LHPH e assinam também um acordo que dá garantias ao fornecedor do(s) sistema(s) de informação que a partir deste momento, os requisitos que constituem o(s) LHPH(s) serão os requisitos que constituirão o(s) sistema(s) de informação resultante(s) do projeto. Mudar os requisitos a partir desta fase, resulta numa ação mais ponderada e custosa, já que pode resultar
em mudanças em SLOs (Software Lifecycle Objects) (Aurum & Wohlin, 2005), de fases avançadas, do processo de engenharia de software. Esta tarefa dita o fim da iteração atual da componente de requirements development.
Justificação
A satisfação do client, é um aspeto que tem de ser considerado crítico, pelo project manager. O(s) sistema(s) de informação até pode(m) estar bem desenvolvido(s), no entanto, se o client quando recebe o(s) sistema(s) sente que este(s) não resolve(m) o seu problema, o seu nível de insatisfação será elevado.
Para dar garantias ao project manager de que do projeto resultará(ão) o(s) sistema(s) desejado(s), o client deve analisar o(s) LHPH(s), documento(s) onde constam os requisitos que irão definir exatamente o(s) sistema(s) que será(ão) posteriormente desenvolvido(s), de forma a comparar o seu desejo com o que está especificado no artefacto.
Da análise feita pelo client a um LHPH, podem ocorrer dois desfechos. O client concorda com a especificação feita pelo software requirements engineer e as duas partes assinam um acordo, ou discorda e obriga o software requirements engineer a proceder a algumas alterações, motivando assim nova iteração da atividade. Isto acontece pois é menos custoso mudar apenas requisitos do que mudar estes e as suas derivações em fases posteriores do processo de engenharia de software (Aurum & Wohlin, 2005).
Os requisitos especificados no(s) LHPH(s), não podem ser diferentes dos requisitos incluídos no(s) artifact(s) of requirements handling, logo as alterações sugeridas pelo client, devem resultar em mudanças nos artefactos criados até então (na componente de requirements development).
Sign the LHPH, é uma tarefa que distribui responsabilidades pelo client e pelo project manager, relativamente ao que está escrito no documento, pois há entendimento comum em relação ao seu conteúdo. Isto dá segurança ao project manager, na medida em que o client quando recebe o(s) sistema(s) de informação, perde poder de argumentação, se este(s) não corresponder(em) às suas expetativas.
3.2.2 Descrição de Atividades da Gestão de Requisitos
a) Lifecycle Management
Explicação
Esta atividade tem o propósito de auxiliar o software requirements engineer (ver capítulo 3.3, atores do processo) a gerir o ciclo de vida dos requisitos no processo aplicável à Bosch.
Três tarefas compõe esta atividade (ver ilustração 18):
1. Elicitate all requirements: Um software requirements engineer recolhe todos os requisitos, nas diversas versões (e informação adjacente), do(s) artifact(s) of requirements handling (ver apêndice I, artifact of requirements handling) desenvolvido(s), no âmbito do processo aplicável à Bosch, com vista a preencher os artefactos state table (ver apêndice II, state table) e table of horizontal traceability (ver apêndice V, table of horizontal traceability);
2. Create/update state table: Um software requirements engineer deve colocar o ID do requisito (sem a versão, usar o seguinte padrão: [Cust.Req.X] ou [Prod.Req.X]) na coluna adequada (sempre que o estado do requisito é novo, surge um novo ID de Requisito). Quando as diversas versões dos requisitos são manuseadas, em atividades do processo para a gestão de requisitos ao longo do ciclo de vida de sistemas de informação, o seu estado muda, o que resulta na execução da atividade de lifecycle management (ver ilustração 10). Isto implica que um requisito (ou uma versão deste) pode ter mais do que um estado em diferentes sistemas de informação. Para garantir esta funcionalidade, o software requirements engineer deve usar o padrão [nome_do_sistema_de_informação-VX] (onde VX é a versão do requisito e X є N*), na coluna da state table que corresponde ao estado da versão do requisito no sistema de informação coincidente, para identificar o estado das diferentes instâncias. Isto resulta também na
possibilidade de uma coluna correspondente a um estado, ter associado o mesmo requisito em diversas versões, ou até a mesma versão do requisito em diferentes sistemas de informação. O nome do sistema de informação deve ser retirado do artifact of requirements handling, onde estão incluídas as versões dos requisitos. Wiegers e Beatty (2013) afirmam que é necessário definir os estados possíveis dos requisitos no rastreio de estados de requisitos. Estes são os estados que um requisito pode possuir:
• Novo: O requisito é recente no sistema (novo ID);
• Reutilizado: O requisito é reaproveitado do repositório sem sofrer qualquer alteração;
• Mudado: O requisito está associado a uma decisão de mudança na atividade de change management (implica nova versão do requisito);
• Selecionado: O requisito pertence ao sub-grupo dos requisitos fundamentais de um sistema de informação resultante da atual iteração, estabelecido na atividade de prioritisation;
• Rejeitado: O requisito não pertence ao sub-grupo dos requisitos fundamentais de um sistema de informação resultante da atual iteração, estabelecido na atividade de prioritisation;
• Documentado: O requisito encontra-se especificado em um LHPH (ver anexo I, LHPH); • Validado: O project manager e o client (ver capítulo 3.3, atores do processo) estão de acordo
relativamente à validade do requisito para um sistema de informação resultante da atual iteração;
• Implementado: O requisito é rastreável até um SLO proveniente da fase de implementação do processo de engenharia de software;
• Para mudança: Associado a uma futura mudança num sistema de informação, presente na wainting list of changes (ver apêndice I, wainting list of changes).
3. Create/update table of horizontal traceability: Um software requirements engineer deve colocar o ID do requisito (sem a versão, usar o seguinte padrão: [Cust.Req.X] ou [Prod.Req.X]) na coluna adequada (sempre que o estado do requisito é novo, surge um novo ID de Requisito) da table of horizontal traceability. Isto resulta na criação ou atualização da table of horizontal traceability. Uma atualização na table of horizontal traceability é efetuada através de:
• O aparecimento de um novo requisito no sistema (exige um novo ID de requisito, uma nova descrição e eventualmente uma observação);
• A mudança de um requisito (estado = mudado), resultando no aparecimento de uma nova versão de um requisito (exige uma nova descrição e eventual observação);
• Uma alteração na descrição e/ou observação de uma versão de um requisito.
Justificação
A necessidade de gerir os requisitos independentemente de um projeto ou de um sistema de informação, para potenciar a reutilização de requisitos, resulta na necessidade da inclusão desta atividade no processo para a gestão de requisitos ao longo do ciclo de vida de sistemas de informação.
O ID do requisito, nesta atividade tem especial relevância, porque é a única maneira de identificar um requisito, neste nível holístico, onde os sistemas de informação são só referenciados, e onde se trabalha ao nível dos requisitos ao invés do nível da necessidade do sistema de informação, daí o ID do requisito ser independente da versão, ao contrário do que se sucede em todas as outras atividade do processo aplicável à Bosch.
Segundo Carlshamre e Regnell (2000), o modelo de ciclo de vida de requisitos REPEAT é baseado em transições de estados, resultantes do produto das atividades da engenharia de requisitos. Wiegers & Beatty (2013) também alertam para a necessidade de gerir o ciclo vida dos requisitos por estados. Com base nestes
factos, a tarefa create/update state table constitui a atividade com o propósito de ajudar o software requirements engineer a gerir o ciclo de vida dos requisitos, ou seja, a identificar qual foi a última atividade do processo aplicável à Bosch (com o apoio do processo de engenharia de software, devido ao estado “implementado”), onde o requisito foi manuseado.
Os estados que um requisito pode ter atribuído, nascem das atividades incluídas (e como estas influenciam cada instância) no processo para a gestão de requisitos ao longo do ciclo de vida de sistemas de informação e no processo de engenharia de software. Na seguinte tabela pode consultar as atividades que originaram os estados no âmbito desta dissertação de mestrado (ver tabela 3).
Tabela 3: Origem dos estados de requisitos
Atividade Estado
Elaboration Novo, Reutilizado e Mudado Prioritisation Selecionado e Rejeitado
Documentation Documentado
Validation Validado
Implementation (processo de engenharia de software) Implementado
Change Management Para mudança
Wiegers & Beatty (2013) afirmam que controlar as versões draft de um requisito ou de um documento ajuda o software requirements engineer a reter um histórico de mudanças. Por outro lado, a rastreabilidade horizontal relaciona versões ou variantes do mesmo tipo de informação (Campos, 2013), ou seja, a rastreabilidade horizontal de requisitos precede de um mecanismo que permita a retenção do histórico de mudanças em requisitos. Assim nasce a gestão do ciclo de vida dos requisitos por versões.
Um documento que permita guardar todas as variantes ou versões dos requisitos, torna-se numa tecnologia viável para alocar os requisitos num repositório para reutilização ou mudança destes (Wiegers & Beatty, 2013).
Wiegers & Beatty (2013) referem ainda que para gerir o ciclo de vida dos requisitos por versões é fundamental definir um esquema de identificação de versões. No âmbito desta dissertação entende-se que a geração de uma versão de um requisito, quando este está associado a uma decisão de mudança num sistema de informação (estado = mudado), resulta num esquema de identificação de versões suficiente.
A tarefa de create/update table of horizontal traceability envolve características que poderiam ser adaptáveis na próxima atividade, traceability. Porém, como aborda o requisitos holisticamente foi inserida
b) Traceability
Explicação
Como já está referenciado na análise do “estado de arte” a definição mais usada para rastreabilidade de requisitos é “habilidade de descrever e seguir o ciclo de vida de um requisito, para à frente e para trás, idealmente ao longo do todo o ciclo de vida do sistema” (Aurum & Wohlin, 2005; Fernandes & Machado, 2015; Gotel & Finkelstein, 1993). A atividade de rastreabilidade de requisitos no âmbito desta dissertação de mestrado pode ser dividida em (1) requirements relations (Aurum & Wohlin, 2005) e (2) vertical traceability (Campos, 2013). As seguintes atividades constituem a atividade traceability (ver ilustração 20):
1. Elicitate requirements (and additional information) inherent to the information system: Um software requirements engineer (ver capítulo 3.3, atores do processo), deve levantar os requisitos peculiares ao sistema de informação ao qual se aplica esta gestão de requisitos. A informações relativas aos requisitos podem ser retiradas do artifact of requirements handling (ver apêndice I, artifact of requirements handling), para garantir que os artefactos provenientes desta atividade, possuem as informações dos requisitos que foram selecionados e rejeitados, para o sistema de informação e da state table (ver apêndice II, state table) para se levantarem os estados e eventuais observações dos requisitos;
A componente da identificação de relações de requisitos da atividade de traceability divide-se nas seguintes tarefas:
2. Create/update matrix of requirements relations (user - user): Um software requirements engineer procede ao preenchimento da matrix of requirements relations (ver apêndice IV, matrix of requirements relations), com o ID do requisito e a sua descrição escrita em linguagem natural, dos requisitos de utilizador, nas colunas (referentes aos requisitos afetantes) e nas linhas (referentes ao requisitos afetados) desta (pode ser a origem ou uma atualização do artefacto). A célula que corresponde a um “match”, entre o requisito afetante e o requisito afetado, reflete uma relação entre os requisitos. Numa célula que se denote uma relação, deve ser colocado o tipo de relação correspondente com o seguinte formato “<<tipo_de_relação>>”. Os tipo de relações utilizador – utilizador, podem ser representados nas seguintes interdependências (ver tabela 4): (1) <<e>>; (2) <<é_pré-requisito_de>>; (Carlshamre et al., 2001) (3) <<aumenta_valor_de>>; (4) <<diminui_valor_de>>; (5) <<aumenta_custo_de>> e (6) <<diminui_custo_de>> (Aurum &
Wohlin, 2005). Estas relações são impostas por stakeholders na atividade de elicitation, logo o software requirements engineer não pode criar relações nos requisitos (utilizador – utilizador); 3. Create/update matrix of requirements relations (user - system): Um software requirements
engineer preenche a matrix of requirements relations, com o identificador e descrição dos requisitos de utilizador, nas colunas reservadas para as informações dos requisitos afetantes, e com o identificador e descrição dos requisitos de sistema, nas linhas reservadas para as informações relativas aos requisitos afetados (resulta na geração do documento ou na sua atualização). Na célula que corresponde ao “match”, o software requirements engineer deve colocar simplesmente um “x”;
4. Create/update matrix of requirements relations (system - system): Um software requirements engineer preenche a matrix of requirements relations, com o identificador e descrição escrita em linguagem natural, dos requisitos de sistema, nas colunas (referentes aos requisitos afetantes) e linhas (referentes aos requisitos afetados) para o efeito. Assim como nas matrizes previamente desenvolvidas, a célula que corresponde a um “match” entre o requisito afetante e o requisito afetado, reflete uma relação entre os requisitos. Numa célula onde se observe uma relação, deve ser colocado o tipo de relação correspondente com o seguinte formato “<<tipo_de_relação>>”. As relações sistema – sistema podem ser representadas nas seguintes interdependências (ver tabela 4): (1) <<e>>; (2) <<é_pré-requisito_de>>; (Carlshamre et al., 2001) (3) <<aumenta_valor_de>>; (4) <<diminui_valor_de>>; (5) <<aumenta_custo_de>>, (6) <<diminui_custo_de>> e (7) <<mudou_para>> (Aurum & Wohlin, 2005). Estas relações são identificadas por um software requirements engineer, ou são derivadas das relações de requisitos utilizador – utilizador. São estas relações que fornecem a informação necessária aos software requirements engineers que medem o impacto de mudança de requisitos na atividade de gestão de mudança de requisitos (Aurum & Wohlin, 2005);
5. Create/update graph (system - system): Um software requirements engineer cria ou atualiza um grafo, que represente visualmente as relações de requisitos sistema – sistema, com o auxílio da informação resultante da matrix of requirements relations (system – system), e de uma ferramenta que permita criar diagramas. Sugere-se o “yEd Graph Editor”, ferramenta multi- plataforma e de código aberto (consultar a hiperligação https://www.yworks.com/products/yed
setas representam as relações (nas setas tem de adicionar uma descrição com o tipo de interdependência, com o formato exposto na tarefa anterior) (Carlshamre et al., 2001);
6. Create/update tables of requirements relations: Um software requirements engineer preenche as tables of requirements relations (ver apêndice III, tables of requirements relations) com as informações dos requisitos, referentes às colunas coincidentes (ID requisito, descrição, observações e estado). Isto pode ser o início do documento, ou uma atualização deste. As relações de requisitos devem ser extraídas das matrizes de relações de requisitos, com a intenção de preencher as colunas para esse propósito. O software requirements engineer, deve utilizar o seguinte formato “<<tipo_de_relação>>_[Cust.Req.X.VX]” se estiver a tratar relações utilizador – utilizador, ou “<<tipo_de_relação>>_[Prod.Req.X.VX]” se estiver a abordar relações sistema – sistema. Se estiver a referir-se a relações utilizador – sistema, o identificador do requisito serve para o efeito;
Tabela 4: Inferência de interdependências
Interdependência Descrição Em conflito com
<<e>> R1de R1 para ambos funcionarem13 precisa de R214 e R2 precisa <<é_pré_requisito_de>> <<é_pré_requisito_de>> R2 precisa de R1 para funcionar,mas não se verifica o vice-versa <<e>>
<<aumenta_valor_de>> R1 afeta o valor de R2 para ocliente positivamente <<diminui_valor_de>> <<diminui_valor_de>> R1 afeta o valor de R2 para ocliente negativamente <<aumenta_valor_de>> <<aumenta_custo_de>> R1 afeta o custo de implementaçãode R2 positivamente <<diminui_custo_de>>
<<diminui_custo_de>> R1 afeta o custo de implementaçãode R2 negativamente <<aumenta_custo_de>> <<mudou_para>> R2 é uma nova versão de R1 -
A componente de vertical treceability, nesta dissertação de mestrado, tem o desígnio de descobrir que instâncias são derivações dos requisitos associados ao sistema de informação. Esta começa com uma verificação, por parte do software requirements engineer, na busca da realização de fases posteriores à engenharia de requisitos, no processo de engenharia de software.
Se já foram realizadas fases avançadas do processo de engenharia de requisitos, a seguinte tarefa é efetuada, se não, a atividade de traceability é terminada:
7. Elicitate SLOs of advanced phases matching the requirements: os software requirements engineers reúnem com o development team spokesman (ver capítulo 3.3, atores do processo), de modo a levantar SLOs provenientes das fases de análise, conceção, desenvolvimento e fase de teste do processo de engenharia de software. Todos os SLOs levantados, no decorrer desta atividade, devem ser derivações de requisitos intrínsecos ao sistema de informação. Uma abordagem alternativa pode ser a rastreabilidade baseada em eventos (Campos, 2013; Cleland- Huang, Chang, & Christensen, 2003), onde o development team spokesman notifica o software requirements engineer quando terminar a sua contribuição para o projeto;
Há a hipótese, de mesmo sendo realizadas fases avançadas do processo de engenharia de software, não serem disponibilizados SLOs, por restrições impostas pela organização, ou por outras questões, então, se
o software requirements engineer encontrou SLOs, na tarefa anterior, a seguinte tarefa é efetuada, se não, a atividade de traceability termina:
8. Create/update table of vertical traceability: Um software requirements engineer deve primeiramente preencher o artefacto table of vertical traceability (ver apêndice VI, table of vertical traceability) com a informação dos requisitos de sistema recolhida na tarefa de elicitate requirements (and additional information) ihnerent to the information system desta atividade (isto pode consistir em criar ou atualizar o artefacto). De seguida, o software requirements engineer deve preencher as colunas referentes aos SLOs correspondentes aos requisitos expressos com as instâncias levantadas (ou referência destas) na tarefa de elicitate SLOs of advanced phases matching the requirements.
Justificação
A gestão de requisitos precede claramente da rastreabilidade de requisitos, uma vez que os requisitos estão sempre em constantes mudanças, e são precisos mecanismos para gerir estes contextos de
instabilidade, a fim de avaliar o impacto que estas mudanças nos requisitos podem ter no projeto (Fernandes & Machado, 2015).
A necessidade de rastrear sempre os requisitos que representem o sistema de informação, exige a