Gerenciamento de requisitos no SEI-CMM e ISO 9000

Gerenciamento de requisitos no SEI-CMM

Em novembro 1986, o Instituto de Engenharia de Software (SEI), de Carnegie-Mellon University, iniciou o desenvolvimento de um framework para acompanhar a maturidade do processo com a finalidade de ajudar aos desenvolvedores em seus projetos de software. Em setembro de 1987, o SEI realizou uma breve descrição do seu framework para o processo de maturidade após passar por ampliação de Watts Humprey’s – Managing the Software Process (1989). Em 1991, esse framework foi encapsulado naquilo que se denominou versão 1.0 do Capability Maturity Model, ou CMM. Em 1993 a versão 1.1 do CMM foi publicada (SEI 1993). A versão 1.1 define cinco níveis de maturidade de software para uma organização e provê um framework para condução de um nível para o nível seguinte, como ilustrado na figura 1. O CMM conduz o desenvolvedor através das suas atividades e ajuda a organização a acompanhar os seus processos de software, objetivando o reaproveitamento, controle e estimativa do processo.

Desconsiderando as controvérsias e discussões sobre as vantagens e desvantagens do CMM, a simples análise dos resultados comparativos mostram a aderência do CMM, pois confirmam o aumento significativo da qualidade de software e o baixo custo despendido pela adoção da metodologia por muitas empresas. O CMM tem sido adotado por muitas organizações do mundo todo e essas organizações, segundo os seus relatos estatísticos, têm obtido retorno positivo de investimento. O retorno aferido refere-se aos aumentos de produtividade e significante redução do tempo de construção dos produtos. Em uma época de progressivo aumento de ambientes competitivos, por mínimo que seja o ganho em produtividade não pode ser ignorado.
O CMM dispõe um framework para monitoramento em ‘áreas chaves do processo’, ou das atividades organizacionais que forem identificadas como as que influenciam em vários aspectos o processo de desenvolvimento e resulta na qualidade do software desenvolvido. A tabela 1 identifica as áreas chaves do processo de todos os cinco níveis do CMM.

O CMM sumariza a área do processo de gerenciamento de requisitos da seguinte forma: O propósito da gerencia de requisitos é o estabelecimento de um entendimento comum entre usuários e a equipe de software para as necessidades dos usuários.

O entendimento comum entre os clientes e a equipe de desenvolvimento serve como base para o acordo, que é documento central que define e controla as atividades seguintes. Requisitos são controlados para estabelecer a linha de base para o gerenciamento da engenharia de software utilizada. O CMM estabelece um guia específico para todas as atividades, planos, agendas. Os produtos de software são ajustados para serem desenvolvidos ou modificados quando necessário para se tornarem consistente com os requisitos alocados para o software. Desta maneira, o CMM promove a organização numa visão integrada consistente com o plano do projeto e as atividades. Para suportar esse processo, os requisitos do software devem ser documentados e revistos pelo gerente de software e grupos afetados, incluindo representantes dos clientes e comunidade de usuários.
A especificação de requisitos do software serve como o documento central do projeto, definindo o relacionamento entre outros elementos do plano do projeto. Os requisitos inclusos são os requisitos técnicos (relativos ao ambiente da aplicação) e os não-técnicos (outros requisitos do projeto, incluído cronograma entre outros). Adicionalmente, critérios de aceitação, que são os testes e estimativas que poderão ser utilizadas para a validação do software de encontro aos requisitos. Portanto, tudo deverá ser estabelecido formalmente e documentado.

Em suma, o CMM prover uma visão compreensiva das atividades que devem ser aplicadas para a qualidade de software e um aumento de produtividade. O eficiente gerenciamento de requisitos é a parte fundamental desse processo.

Gerenciamento de requisitos em ISO 9000:2000

Nas ultimas duas décadas passadas, um número significativo de organizações em torno do mundo, tem adotado uma série de padrões de gerenciamento de qualidade conhecidos como ISO 9000 para impor um meio mais produtivo em seus processos e reduzir custos. Em dezembro de 2000, esse documento foi revisado conforme as lições aprendidas nos últimos cinco anos, resultando no padrão denominado por ISO 9000:2000.

Atualmente, a ISO 9000 foi adaptada pela comunidade européia como EN29000 e foi um fator importante para o comércio internacional; organizações que desejavam ter negócios na Europa, freqüentemente apresentavam a certificação ISO 9000. Então, com a globalização da economia, muitas corporações americanas tem adotado a ISO 9000 para assegurar sua credibilidade no mundo dos negócios.

Análise de problemas em engenharia de software

A análise de problema

Nesse artigo, eu quero retomar a discussão sobre os caminhos que a equipe de desenvolvimento de software e usuários encontram para a construção de um novo sistema ou aplicação. Muitos sistemas são construídos para resolver um problema em particular, então, para isso usamos a técnica de análise de problema para estarmos seguros de que estamos, realmente, entendendo o problema.

Devemos também reconhecer que nem todo o desenvolvimento de aplicação visa a solução de um problema; algumas vezes, constrói-se sistemas para tirar proveito de situações e oportunidades que se fazem presentes, sem que necessariamente exista um problema a ser resolvido.
Concordamos, que problemas e oportunidades são apenas lados opostos de uma mesma moeda; seu problema é a minha oportunidade pregam os livros de auto-ajuda. Isso é, portanto, apenas um perspectiva diferente para se observar essa questão.

Podemos definir a análise de problemas como:

O processo de entendimento de problemas no mundo real, suas relações com as necessidades do usuário e a proposta de soluções que vão de encontro a essas necessidades.

Assim sendo, o domínio do problema deverá ser analisado, entendido e uma variedade de soluções para o problema deve ser explorada. Usualmente, uma variedade de soluções é possível e, dentre todas essas, pelo menos, uma solução será ótima para o problema a ser resolvido. Deve-se atentar para o fato de que, algumas vezes, a solução mais simples para o problema é uma simples revisão do processo de negócio ao invés da construção de um novo sistema.
O alvo principal da análise do problema é obter um melhor entendimento sobre o problema antes de iniciar-se, efetivamente, o desenvolvimento da solução. Desta forma, cinco passos devem ser cumpridos para a efetiva aplicação da análise do problema.

Cinco passos para a análise do problema:

Passo 1: Obtenção sobre a definição do problema

O primeiro passo no caminho mais simples para a obtenção das definições sobre um problema a ser solucionado é, simplesmente, registrá-lo. O simples ato de registrar um problema já nos permite vislumbrar soluções.
Como parte desse processo, esse registro freqüentemente traz benefícios para o entendimento e alguns benefícios para a fixação da solução proposta. Devemos ser cuidadosos para fazer com esses benefícios sejam claramente descritos em termos dominados também pelos stakeholders. Tendo o usuário descrito os benefícios advindos do contexto do problema no mundo real e ao verificar os benefícios, também, do ponto de vista dos usuários, também se obterá um melhor entendimento dos pontos de vista do stakeholder sobre os seus problemas.

O registro do problema

A tabela 1 ajudará a registrar o seu problema em um formato padrão. A simples utilização de um registro padronizado fará com que você esteja seguro de que todos os stakeholder estejam focados nos mesmos problemas.

Passo 2: Entendendo as causas raízes – por dentro do problema

Sua equipe pode utilizar-se de uma variedade de técnicas para obtenção de entendimento sobre um problema real e suas causas reais. Uma técnica utilizada para isso e a análise “causas raízes”, que é uma sistemática para desvendar a raiz, ou identificar o sintoma provocado por um problema.
O próximo passo para identificar as causas raízes de um problema é determinar quais os fatores contribuem para a presença do problema. O Gerenciamento Total de Qualidade (TQM – Total Quality Management) nos ensina a usar o diagrama espinha de peixe (veja na Figura 1) para identificar o problema em seu âmago. Em nossa análise específica, a companhia identifica vários recursos que contribuem para a existência do problema. Toda a fonte do problema deverá ser listada com uma das “espinhas” do diagrama.

Se o problema é mais sério, a simples indagação sobre o que é afetado por este não cria uma sensação de conforto, isto pode ser necessário para uma investigação mais detalhada de toda a contribuição do problema e da dimensão do ser impacto individual. Esta investigação pode variar de um simples brainstorm cujos participantes tenham conhecimento sobre os pontos afetados do projeto ou, potencialmente, para uma investigação científica mais rigorosa. Nesse caso, o alvo é a quantidade com que cada causa raiz contribui para o problema.

Passo 3: Identificando os stakeholders e os usuários

Efetivamente a solução de um problema complexo, tipicamente, envolve satisfazer as necessidades de um grupo diverso de stakeholders. Stakeholders têm tipicamente uma perspectiva variada do problema e uma diversidade de necessidades que devem ser satisfeitas pela solução. Define-se stakeholder como:

Alguém que pode ser materialmente afetado pela implementação de um novo sistema ou aplicação.

Muitos stakeholders são usuários do sistema e suas necessidades são facilmente fixadas, pois estão diretamente envolvidos na definição e uso do sistema. De outra forma, alguns stakeholders são apenas usuários indiretos do sistema ou são afetados, tão somente, pelos resultados do negócio que o sistema influencia. Esse stakeholders pode ser membros de Conselhos, Agências reguladoras, enfim, agentes internos ou externos ao ambiente de desenvolvimento do sistema e que, não são afetados diretamente por esse, mas sim pelos resultados gerados sob sua influência. As necessidades dos stakeholders não-usuários também devem ser identificadas e apontadas. Um entendimento de quem são os stakeholders e quais são suas necessidades, esse é um importante fator para o desenvolvimento de uma solução efetiva. A relação dos stakeholders deve seguir o formato demonstrado na tabela 2.

Outros stakeholders, como os vendedores e o supervisor são diretamente afetados pelo sistema, mas acessam o sistema por intermédio de diferentes interfaces de usuário e relatórios. De outro modo, o Chefe do departamento financeiro da empresa são stakeholders que podem sofrer influência no aumento da produtividade, qualidade e rendimento da empresa. Assim, se espera que o diretor de TI e os membros da equipe de desenvolvimento sejam também classificados como stakeholders, pois, esses serão os responsáveis diretos pelo desenvolvimento e manutenção do sistema.

Passo 4: Define a fronteira para a solução

Uma atividade super importante com relação ao desenvolvimento de softwares reside na delimitação do que está no interior da fronteira do sistema e do que reside fora desta. Ou seja, a delimitação clara das responsabilidades do sistema. A fronteira do sistema define a borda entre a solução e o mundo real em torno da solução (Figura 2). Em outras palavras, a fronteira do sistema descreve um cenário em que a solução do sistema está contida.

Passo 5: Identificar os constrangimentos impostos pela solução

Antes de despender milhares de reais em busca de uma solução revolucionária, o verdadeiro estado da arte em termos de comércio, por exemplo. Deveremos parar e considerar os constrangimentos que serão impostos pela solução. Definimos constrangimentos como:

A restrição sobre os graus de liberdade que será imposto sobre uma aplicação.

Todo constrangimento ocasiona uma severa e potencial restrição para o desenvolvimento de uma solução. Dessa forma, todo constrangimento deve ser cuidadosamente considerado como parte do planejamento de processo e, muitas vezes, esse constrangimento poderá fazer com que sejam reconsideradas abordagens tecnológicas que foram inicialmente consideradas.

Várias fontes de constrangimentos deve ser consideradas. Essas incluem agendas, retornos e investimentos, custo de produção e equipamentos, ambiente, sistemas operacionais, bancos de dados, servidores e sistemas clientes, insumos técnicos, política organizacional, licenças de software, procedimentos e recursos da empresa, ferramentas e linguagens, pessoal e outros recursos. Esses constrangimentos devem ser mapeados antes de darmos de tomarmos uma decisão. A lista apresentada na tabela 3 apresenta os potenciais recursos de constrangimento de um sistema.

Tentou-se com esse artigo dar uma idéia geral sobre a análise de risco e problemas com relação ao desenvolvimento de software. Apresentamos os tópicos principais que devem ser monitorados quando da elicitação de requisitos para a construção de um produto de software.

Sobre protótipos em projetos de software

Prototipação
Protótipo em termos de software é a materialização aproximada de um sistema e demonstra um conjunto de funcionalidades do novo sistema. A construção de um protótipo poderá ser efetiva para a elucidação de necessidades dos usuários. Os usuários poderão tocar, sentir e interagir com o protótipo fazendo com que sejam descobertas necessidades ocultas e, conseqüentemente haja, elucidação de possíveis dúvidas. A prototipação aliada com outras técnicas poderá prover a redução de retrabalho e minimização de riscos na implementação do projeto. A prototipação é muito eficiente na redução da síndrome do “Sim, mas”, “Não é exatamente isso que pensava” e a síndrome da “Ruínas ocultas” (“Só agora que percebemos isso, temos outros requisitos para adicionar”).

Tipo de protótipos

Protótipos podem ser categorizados de muitas formas. Por exemplo, Davis (1995a) categoriza protótipos como descartável verso evolucionário verso operacional, vertical verso horizontal, interface de usuários verso algoritmo e assim por diante. O tipo do protótipo depende do problema que você está tentando solucionar pela sua construção.

Por exemplo, se em seu projeto os risco estão baseados, principalmente, na viabilidade da abordagem tecnológica – essa solução nunca foi tentada antes e você está incerto quanto à aplicabilidade da tecnologia que pode afetar o desempenho ou desviar dos alvos (requisitos não funcionais de desempenho, por exemplo). Você pode decidir por realizar uma prova de conceito (que é o protótipo arquitetural) a fim de verificar a aderência da solução tecnológica. Um protótipo arquitetural pode ser descartável ou evolutivo (descartável é o protótipo que não será aproveitado no desenvolvimento. Sendo que, o termo evolutivo se refere ao protótipo que será aproveitado durante o processo de desenvolvimento). O protótipo descartável implica que o esforço empregado servirá, tão somente, para estabelecer a viabilidade, portanto, poder-se-á utilizar soluções restritas, tecnologias alternativas, simulações, cujo objetivo seja armazenar informações que o ajude na tomada de decisão. Quando a opção recai sobre a construção do protótipo descartável, os benefícios do exercício recaem sobre o aprendizado adquirido no exercício. O protótipo evolutivo implica que você implementou um protótipo com mesmos recursos e na mesma arquitetura em que será desenvolvido o sistema final e você estará habilitado a construir o sistema final a partir da evolução gradual do protótipo.

Se a área de risco primária do seu projeto reside na interface com o usuário, você deverá, então, desenvolver um protótipo de requisitos, usando tecnologias infinitas que possibilitam desenvolver de forma mais ágil o seu protótipo de interface. A figura 1, abaixo, mostra a árvore de decisão que pode ser utilizada para selecionar o modelo do protótipo que deverá ser desenvolvido, de acordo com as características do seu projeto.





Figura 1 – Árvore de decisão para seleção de protótipo: (a) protótipos para validação de requisitos; (b) protótipos para validação de arquitetura.

Protótipos para validação de requisitos

Para o propósito de elicitação de requisitos, deveremos nos fixar nos tipos de protótipos que estão representados na parte superior da árvore acima apresentada. Nós definimos um protótipo para validação de requisitos de software como:

Implementação parcial de um software cuja construção visa apoiar ao desenvolvedor, usuário e consumidores de software para melhor entender os requisitos de um sistema.

Para o processo de elicitação de requisitos, podemos construir uma interface de usuário, descartável e horizontal. “Horizontal” implica em, termos que, atentar para uma construção com ampla visão das funcionalidades do sistema; o protótipo vertical, pelo contrário, constrói apenas uns poucos requisitos, porém, atentando por implementá-los de forma qualificada. “Interface de usuários” implica que deverá ser construído mais detalhe da navegação da interface do sistema para os seus usuários diretos, do que a implementação de lógica e algoritmos que deverão residir no interior do software ou interfaces de outros módulos ou sistemas. Uma ferramenta de elicitação, como um servidor de protótipos pode conduzir aos seguintes caminhos:

· Construído pelo desenvolvedor - este pode ser utilizado para obter confirmação do usuário quanto ao entendimento sobre determinados requisitos;
· Construído pelo desenvolvedor – este pode ser usado como um catalisador para encorajar o usuário a fim de entender melhor os requisitos;
· Construído pelo usuário – este pode comunicar melhor os requisitos para o desenvolvedor.

Nesses três casos, o objetivo da construção do protótipo é construí-lo consumindo-se poucos recursos. Se for muito caro construí-lo, será melhor construir o próprio sistema!

Muitos protótipos de software tende a ser protótipos de requisitos e são usados primariamente para capturar aspectos das interfaces de usuários do sistema a ser construído. Existem, provavelmente, duas razões para isso:

1. A emergência de um projeto de baixo orçamento, sendo necessário a aplicação de ferramentas para construção de interfaces de usuário de baixo custo;
2. Para usuários de sistema com interação-intensiva, um protótipo de interface de usuários poderá revelar muitos outros requisitos ocultos inicialmente, com as funcionalidades que deverão ser providas aos usuários, onde todas as funções poderão ser avaliadas pelo usuário e que funções estão ocultas.

Na maioria das vezes, necessitamos de estar certos de que, não seremos influenciados a construir partes do sistema que não representam altos índices de risco para o projeto.

Artefatos fundamentais para registro de requisitos

1. Relação das necessidades dos stakeholders

O artefato, relação das necessidades dos stakeholders, é o documento em que se devem relacionar as necessidades dos usuários do software. Nesse artefato estarão identificadas todas as necessidades definidas pelos usuários, com indicação dos seus respectivos perfis e contatos. As necessidades devem se relacionadas já pré-classificadas como: necessidades funcionais, necessidades não-funcionais, necessidades negociais (regras de negócio). Além dessa classificação, deve ser informado qual são os usuários gestores da necessidade apontada. Necessidades afins devem ser apresentadas de forma agrupada. É importante indicar a referência sobre a identificação da necessidade, tais como, a ata e a reunião em que foi identificada, por exemplo.

2. Relação das funcionalidades do software

A partir da relação das necessidades dos stakeholders a equipe de analistas de requisitos responsáveis pela construção do software fará a identificação das funcionalidades (requisitos funcionais) a partir das necessidades classificadas como funcionais que foram definidas pelos usuários. A relação das funcionalidades deve conter, além da identificação da funcionalidade propriamente dita, as necessidades funcionais as quais estão relacionadas.

3. Relação dos requisitos não-funcionais

Da mesma forma que o procedimento anterior, deverá ser feito à identificação dos requisitos não-funcionais, a partir das necessidades classificadas como não-funcionais que, também, foram definidas pelos usuários. Os requisitos não-funcionais deverão ser classificados e agrupados por categoria, segundo a relação abaixo: Requisitos de sistemas, requisitos de desempenho, requisitos de ambiente, requisitos de usabilidade, requisitos de confiabilidade, requisitos de suportabilidade, requisitos de segurança, requisitos de documentação. Oportunamente, falaremos sobre cada uma dessas classificações.

4. Diagrama geral de relacionamento entre casos de uso

A UML (Unified Modeling Language) nos ajuda a descrever os relacionamentos entre os casos de usos envolvidos no desenho do software. Para se definir esse diagrama, inicialmente, é necessário definir cada um dos casos de uso do sistema. Um caso de uso se resume num conjunto (agrupamento) de funcionalidades que serão desenvolvidas no software para resolver cada uma das necessidades levantadas. Cada caso de uso, deve ser ater as suas responsabilidades específicas e, pelos relacionamentos com outros casos de uso, compor o conjunto de funcionalidades necessárias para o bom funcionamento do software. A boa arquitetura de cada um desses casos de uso desenhados definirá uma boa arquitetura final para o software em questão.
No diagrama de relacionamento entre os casos de usos deverão estar representados os relacionamentos entre os atores e os ‘seus’ casos de uso e entre os casos de usos relacionados.

5. Relação das regras gerais e específicas dos casos de uso

Um outro artefato muito importante no processo de gerenciamento de requisitos é a relação de regras gerais e específicas dos casos de uso para o software. É comum, encontrarmos as regras específicas para os casos de uso descritas na própria especificação de caso de uso. Pessoalmente, eu não gosto muito desse agrupamento, pois na minha visão pessoal a especificação de caso de uso não deve ser apenas um documento de negócio é sim, um documento fundamental para o processo de construção do software incluindo-se nesse artefato conceitos relacionados a navegabilidade quando necessário. Claro que, quando se trata de um projeto complexo, podemos optar por construir o artefato especificação geral de interfaces e, quando necessário, pode-se ter também a especificação de interface de um determinado caso de uso. Desta feita, o que deve ser validado pelo usuário, segundo o meu ponto de vista, são as regras de negócio, tanto as especificas (que dizem respeito a um caso de uso específico) quanto as gerais (que dizem respeito a mais de um caso de uso). Prefiro que a validação de navegabilidade seja feita diretamente por intermédio de um protótipo medianamente funcional. As regras gerais ou especificas devem ser listadas com seus respectivos identificadores (código, nome reduzido, nome completo), teor da regra (contendo inclusive as operações aritméticas quando necessário e, conseqüentemente, exemplos que esclareçam o texto), identificação do stakeholder responsável pela definição da regra.

6. Matriz de rastreabilidade entre funcionalidades x necessidades x regras gerais x casos de uso

A matriz de rastreabilidade é um artefato muito importante nesse processo e um dos mais trabalhosos, em razão, da exigência de atualizações a que estará submetido. Qualquer alteração deverá ser registrada assim que consolidada. As rasteabilidades fundamentais são as que relacionam funcionalidades com necessidades; regras com funcionalidades e necessidades; casos de uso com funcionalidades e necessidades e regras com casos de uso. Existem muitas formas de se manter esse relacionamento, sendo a mais simples o registro em células de planilhas eletrônicas.

7. Especificação de caso de uso

A especificação de caso de uso pode ser um documento muito importante e de muita utilização no processo de construção de software ou apenas um artefato alegórico e que não ‘serve pra nada’. Eu prefiro, trabalhar com especificações que documentem realmente o software que está sendo desenvolvido. Portanto, deve-se evitar construir um caso de uso puramente negocial para se validado pelo usuário como, normalmente, vemos. É comum, construir especificação de caso de uso com a finalidade de fixar os requisitos junto aos usuários. Porém, como a linguagem adequada ao artefato não é fácil ao usuário comum, muitas vezes obriga-se o mesmo a se qualificar na linguagem. Em minha experiência, alguns usuários perdem-se em discutir a forma do documento (o que é fluxo alternativo, fluxo de exceção, entre outros) e não discute o teor das informações que são importantes para a construção do aplicativo. Por isso, eu opto por registrar as regras em documentos próprios e na especificação teremos apenas a navegabilidade, que deverá ser empregada no sistema (desenho dos processos dos casos de uso de uma determinada interface). Portanto, meu conceito de caso de uso é o de caso de uso de implementação e não apenas um documento negocial.
Essa especificação pode ser classificada em caso de uso comum e caso de uso CRUD [agrupamento dos processos básicos: Create (Inserir), Retrieve (Consulta), Update (Atualização) e Delete (Exclusão)]. Pode-se definir no CRUD outros processos além dos acima citados.
Uma especificação deve apresentar os seguintes fluxos:
Fluxo básico;
Sub-fluxos;
Fluxo alternativo;
Fluxo de exceção.

8. Projeto de interfaces

Um projeto de interfaces bem elaborado pode facilitar o processo de construção, além de reduzir o próprio tempo, em termos de cronograma, nessa fase. Os usuários, muitas vezes têm dificuldade em validar texto, uma interface com navegação básica, facilitará sobremaneira essa processo. Eu sempre opto por construir protótipos medianamente funcionais utilizando-me de HTML (Hiper Text Markup Language), quando se desenvolve um aplicativo que deverá obedecer a um determinado padrão de interface, o melhor já será incorporar partes desses padrões ao projeto. O tempo consumido na construção de um bom projeto de interface reduzindo o retrabalho com testes funcionais e de navegabilidade e, também, o retrabalho.

Técnicas e eventos para elicitação de requisitos

O que é uma Entrevista

Entrevista é um evento em que o analista de requisitos aborda diretamente os stakeholders, isoladamente ou em grupo, para extrair-lhes informações sobre os processos do negócio que será alvo de sistematização. Quanto menor o número de elementos presentes no evento melhor será o aproveitamento. Os fatores limitantes da entrevista é a duração, para um melhor aproveitamento do evento esta não deve se estender em termos de tempo e pelo limitado número de participantes, pois o analista deverá manter o controle da situação, o que acontecerá com um número pequeno de participantes (recomenda-se até 8 pessoas, no máximo). Os stakeholders adequados para esse tipo de evento, bem como, qualquer outro tipo de evento de elicitação de requisitos, são os que são diretamente afetados pelos processos de negócio em questão e, também, os que sofrem as conseqüências diretas desses processos. Nesse caso, é melhor que o grupo dos que sofrem as conseqüências estejam em outro evento e não no mesmo evento dos primeiros. Logicamente, em um momento posterior deverá haver um encontro entre os dois grupos para equalizações nos processos. Nesses eventos são identificadas as Necessidades funcionais (NF), regras de negócio (RN), Restrições funcionais (RF) dos usuários do software.

O que é um workshop

Workshop é um evento em que o analista de requisitos, assessorado por moderadores neutros, submete questões sobre o software ou problemas específicos a um grupo de stakeholder. As vantagens do workshop é que o analista de requisitos estando assessorado e havendo a sua disposição uma certa infra-estrutura operacional, poder-se-á trabalhar em vários turnos, dividindo-se o trabalho em grupo quando necessário. O workshop pode ser utilizado tanto para apresentação de produtos, resultados, como para elicitar requisitos.

O que JAD

JAD é um ciclo programado de reuniões nas quais analistas de requisitos confrontam usuários com objetivo de definir necessidades que nortearão a construção de um sistema. Em JAD há uma atenção especial dirigida ao assunto Condução de Reuniões. Pois a reunião é o elemento constituinte fundamental do JAD.
Por definição, JAD é uma entidade abstrata. Para que esse evento se realize, para que se concretize, a implementação se dá através de uma reunião. O JAD corre o mesmo risco das reuniões, caso haja, um abuso em se resolver qualquer assunto utilizando essa técnica.

O que é um brainstorming

Brainstorming, segundo a análise de requisitos, é uma técnica em que os participantes de um evento para elicitação de requisitos se reúnem em grupo e cada um dos membros desse grupo expõe a sua idéia e expectativa sobre o projeto como um todo ou em pontos determinados. Um moderador neutro deve registrar todas as idéias apresentadas e coordenar a participação e interação de todos os participantes, sem censuras prévias às lucubrações expostas. O tempo de considerações livres (brainstorming) deve ser em média de 15 minutos, sendo que, após esse período deverá se iniciar uma discussão sobre cada um dos pontos levantados visando a sua consolidação. O moderador não deve nunca tentar fazer prevalecer o seu ponto de vista, nem interferir nas considerações de qualquer um dos participantes. Todas idéias deverão, a princípio, serem consideradas. O brainstorming pode ser uma das técnicas empregadas em workshop ou entrevistas.

Concluindo projetos

Não há nada mais gratificante do que vivenciar a conclusão de um projeto. Esse momento nos remete às sensações similares ao nascimento de um filho. É uma sensação satisfatória de dever cumprido, de metas alcançadas. Porém, não é fácil alcançar esse momento de satisfação, sem contar que existem projetos que jamais poderão ser finalizados.

Um projeto é construído a partir de sua base e sua estrutura fundamental estará assentada sobre esses fundamentos que permitirão a sustentação das demais estruturas que serão construídas ao longo do ciclo de vida do projeto. Caso essa fundação não seja bem alicerçada o projeto poderá ser lançado ao fracasso.

Pois bem, a primeira etapa na construção de um projeto que seja passível de conclusão é, que este, tenha seus marcos bem delimitados; suas metas devem ser claras e objetivas. A premissa principal para se alcançar um objetivo é saber qual é, exatamente, esse objetivo.

A elicitação de requisitos dentro da engenharia de software deve ser tratada como um fundamento básico para constituição de base sólida sobre a qual serão erigidos os pilares de sustentação de um projeto.

Os pilares de um projeto são os sub-projetos e processos que o complementam. A maioria desses sub-projetos e processos são intercalados e dependentes e a execução plena de cada um deles influenciará radicalmente na qualidade final do produto que está sendo desenvolvido. Por isso, devemos encarar esses elementos com todo cuidado e acompanhar a sua construção com a seriedade com que é executado o projeto em seu todo. Cada um desses elementos serão fundamentos básicos para que o todo esteja harmonizado, volto a lembrar! Dito isso, é bom ressaltar que em cada um desses elementos devemos atentar para a elicitação de requisitos e determinação das responsabilidades associadas a cada um desses elementos. Esse procedimento é fundamental para a determinação das fronteiras de cada um dos elementos que compõem um projeto.

A determinação de responsabilidades concernentes aos elementos do projeto é uma tarefa árdua, algumas vezes, fica difícil definir com precisão as fronteiras de ação de cada um desses elementos e tendemos a repetir responsabilidades ao logo de um processo de definição de fronteiras para a construção de um elemento.

Quando delimitamos mal essas fronteiras, caímos na armadilha da repetição desnecessária, da indefinição de responsabilidades e da imprecisão de conceitos.

Devemos ter o cuidado de fazer o usuário enxergar também essas responsabilidades e perceber que cada coisa nesse cenário deve ter o seu lugar. Na maioria das vezes, o usuário só consegue perceber o todo e, confusamente, tenta resolver todo o seu problema num processo só e no mesmo momento.

Com habilidade o analista de requisito deve fazê-lo entender que cada processo é um processo ‘limpo’ e objetivo. Sendo que seus objetivos e responsabilidades devem estar claramente definidos. Se essa premissa for negligenciada esse projeto estará fadado ao fracasso.

O zen e a arte de elicitar requisitos

A elicitação de requisitos é uma arte complexa. Desta feita, por estar sujeita aos humores do detentor das ‘Necessidades’ que muitas vezes não sabe exatamente o que quer, torna a fixação dessa informação, um processo complicado. É comum, depararmos com analistas de requisitos desesperados com a falta de definição por parte de quem deveria definir. Não é incomum, também, um stakeholder (usuário) que não tenha noção exata do que está acontecendo ao seu redor e que, simplesmente, caiu de pára-quedas num projeto e ainda não tem domínio dos processos ao seu redor. Outro problema envolvido nesse espectro é a quantidade de processos e artefatos que os processos obrigam, ao analista de requisitos, construir.
Pare, respire e analise...
O usuário – operador de ferramentas, só consegue enxergar as suas necessidades objetivamente a partir de uma visão objetiva. Com isso quero dizer que, na maioria das vezes nos basta construir os seguintes artefatos:
Relação das necessidades do stakeholders;
Relação das funcionalidades do software;
Relação dos requisitos não funcionais;
Diagrama geral de relacionamento entre casos de uso;
Relação das regras gerais e especificas dos casos de uso;
Matriz de rastreabilidade entre funcionalidades x necessidades x regras gerais x casos de uso;
Especificação de caso de uso;
Projeto de interfaces.
Em minha visão, esses artefatos são fundamentais para a construção de um software e para a fixação de necessidades de usuários são essenciais o documento de regras gerais e específicas e o projeto de interfaces.
Ultimamente, tenho tentado em meus projetos com essa seqüência de atividades:
1º ciclo:
Brainstorm e reuniões para levantamento das necessidades fundamentais dos usuários;
Levantamento de necessidade, regras do negócio;
Identificação de funcionalidades (requisitos funcionais) e requisitos não funcionais;
Organização das regras de negócio;
Construção dos casos de uso;
Construção das especificações de caso de uso;
Projeto de interfaces
2º ciclo:
Workshop para validação dos requisitos, utilizando-se como insumos as regras gerais e regras específicas para os casos de uso e projeto de interface.
O fato de o usuário validar as suas necessidades a partir de um projeto de interfaces (protótipo mediamente funcional), faz com que ele tenha mais clareza e objetividade em suas funções. Se Ganha em termos de tempo e precisão. O profissional de requisitos, por alcançar mais agilmente os seus objetivos e concluir suas tarefas de uma forma mais precisa minimizando o retrabalho fará com que esse profissional esteja mais relaxado e, conseqüentemente, mais produtivo. Tudo isso, por uma rápida reorganização no processo de trabalho.

O que a Engenharia de Requisitos tem a ver com a qualidade do software

Bem... O que é qualidade em software?

A qualidade de um software está relacionada com a precisão a qual as necessidades de seus usuários são atendidas.

Como essa qualidade pode ser avaliada?

A única forma de se avaliar a qualidade de um software é testá-lo, de preferência, exaustivamente!

Estou afirmando que a única disciplina que poderá aferir a qualidade em software é a disciplina de testes e para testar é necessário que exista uma documentação atualizada, clara e fiel às necessidades dos usuários desse software. Por isso, existe uma dependência clara entre essas duas disciplinas (requisitos e testes).

Existem representantes de organizações que declaram que a disciplina de teste não faz parte do Controle de Gestão de Qualidade (CGQ) de software, estão profundamente enganados. Sem um teste minucioso que se inicia com a análise e revisão cuidadosa da documentação e prossegue com a análise cuidadosa das funcionalidades em contraposição com as necessidades não serão alcançadas as metas de qualidade em software que se desejam. Desenvolver aplicativos úteis, esse deve ser o objetivos das boas fábricas de software - o produto deve ser a meta. A remuneração econômica 'deveria' ser conseqüência dos produtos de qualidade. Mas esta última colocação é apenas uma reflexão íntima.

Um bom padrão de desenvolvimento ajuda em muito tanto a disciplina de requisitos quanto todas as outras disciplinas envolvidas no processo de desenvolvimento de sistemas. Porém os padrões devem ser flexíveis o suficiente para não engessar o processo e rígidos o suficiente para não serem diluídos - esse equilíbrio é díficil de ser alcançado sem traumas. Um problema é que, normalmente, o 'burocrata' que impõe o padrão não o utiliza no seu dia-dia. Por isso, proponho que os padrões surjam do amadurecimento natural dos processos com a avaliação dos profissionais envolvidos e que, definitivamente, (esses padrões) não sejam impostos por 'burocratas' insensíveis ao meio de produção.

Sobre 'Especificações de Caso de Uso'

Na minha modesta opinião esse artefato é de fundamental importância ao bom desenvolvimento do software.

Após extrairmos, dos stakeholders (usuários) as necessidades do software, determinaremos quais serão as funcionalidades que comporão o aplicativo que estamos concebendo. Em seguida, organizaremos essas funcionalidades em seus cenários comuns, os quais denominamos, casos de uso. Isto feito, e após concebermos a inter-relação entre os diversos casos de uso que compõem o nosso sistema, iniciaremos a construção do artefato que representará a navegabilidade do sistema, do ponto de vista do usuário. Bem como, as regras que regulam o funcionamento do negócio.
Esse artefato se compõe basicamente de fluxos de navegação e regras de negócio específicas para o caso de uso em questão; além de algumas informações complementares que informam sobre as características específicas das informações contidas nesse caso de uso. Os elementos fundamentais da Especificação de caso de uso, são os seguintes:

1. Fluxo Básico - representa o fluxo fundamental (caminho feliz) do caso de uso. Ele define, inicialmente, o que determina o início do processo operacional do caso de uso em seu passo inicial e encerra o processo em seu último passo;
2. Subfluxo - representa uma seqüência de passos que se repetem durante o caso de uso. A característica fundamental dos subfluxos é que quando invocados de qualquer ponto do caso de uso, executa os seus passos seqüencialmente e, após, a conclusão da execução devolve, ao passo seguinte ao que o invocou, a sua execução. Esse tipo de elemento é fundamental para indicar o reuso de uma instrução;
3. Fluxo Alternativo - esse elemento representa toda a navegação que é alternativa àquilo que está proposto no passo ou fluxo antecedente. Quando invocamos um fluxo alternativo, estamos determinando um caminho opcional ao que está proposto antecedentemente;
4. Fluxo de Exceção - esse elemento tem alguma similaridade com o fluxo alternativo. Porém, trata de uma execução alternativa em função da violação de uma Regra de Negócio. Quando temos a vinculação de uma regra de negócio ao um passo, obrigatoriamente, deveremos tratar a exceção correspondente. Obviamente, existirão outras exceções que não serão tratadas em nosso aplicativo. O elemento, em questão, dispõe sobre aquelas exceções que conseguimos prever, a priori;
5. Regras de Negócio Específicas - esses elementos são fundamentais para a especificação de caso de uso, são através da determinação desses fatores que delimitamos operacionalmente o sistema que estamos a construir.

É bom lembrar, que esse artefato deve conter, ainda, a descrição precisa - do ponto de vista do negócio - das interfaces que compõem o caso de uso. Quando ressalto do 'ponto de vista do negócio', quero argumentar que somente aquelas definições de interface que advêm das necessidades do negócio é que devem ser documentadas. Neste momento, não deveremos focar conteúdo sobre os padrões de interfaces da corporação para qual estamos especificando, esse assunto deve ser tratado no artefato 'Documento Geral de Interfaces de Software'.

Os passos dos fluxos devem ser referenciados de forma clara e objetiva (recomenda-se que se utilize o tempo verbal presente do indicativo). É condenável passo de fluxo que contenha informação típica de regras de negócio. Essas informações devem estar contidas na própria regra de negócio que estará referenciada nos fluxos onde acontece. Essas regras devem ter redação clara e de fácil entendimento - mesmo por pessoas não afeitas ao negócio. Deve-se evitar que as regras de negócio contenham texto que conduzam a dupla interpretação ou a conclusões equivocadas. Quando necessário para aclarar a informações devemos apelar para diagramas, tabelas entre outros recursos. Assim como, devemos evitar termos específicos (jargões) que não estejam claramente explicados no artefato 'Glossário'.

Basicamente, a especificação é dividida em duas categorias:
Especificação comum - essa categoria é adequada para a descrição de casos de uso isolados, sejam autônomos ou que se mantenham relacionados a outros como 'include’, 'extends' ou ‘generalização’;
Especificação CRUD - Essa categoria refere-se aos agrupamentos de casos de uso com objetos comuns, ou seja, que contemplem as seguintes transações: consultar, excluir, incluir e alterar. Essas transações são estruturadas na forma de subfluxo, sendo que o fluxo básico do 'CRUD', normalmente, refere-se a seleção de uma dessas opções num menu.

"DICA" sobre especificações de casos de uso

Mediante algumas circunstâncias, quando estamos pensando em software é melhor pensarmos na melhor maneira de comunicar nossas idéias. Clareza e objetividade são fatores fundamentais para que não haja mal entendidos quando o assunto seja requisitos de software. As necessidades do usuário e as funcionalidades do software são os elementos fundamentais, esses 'que tais' que denominamos requisitos de software devem ser comunicados com precisão absoluta para a equipe de desenvolvimento. Uma especificação de caso de uso é um artefato que deve apresentar com clareza, do ponto de vista do negócio, todas as regras ressaltadas pelo usuário, além de indicar com precisão a navegabilidade que se deseja atribuir ao produto software. Para isso, a especificação, deve evitar termos que não denotem precisão e, sobretudo, evitar repetições desnecessárias - redundâncias. O bom software é aquele que tem, claramente, determinadas as responsabilidades de cada um dos seus casos de uso. Essa determinação será definida no momento em que o Analista de Requisitos define as relações entre seus casos de uso. Nesse momento, o profissional assume, realmente, o seu papel e não deixa a responsabilidade para outros, nesse caso, a equipe de desenvolvimento.

A relações entre casos de uso são definidas em três formas básicas, quais sejam:

1. Generalização - esse tipo de relacionamento deve ser utilizado com cuidado, pois que, representa relacionamentos de polimorfismo que se não forem bem definidos poderão levar a conclusões equivocadas e confusas. O princípio fundamental da generalização consiste em concluir que uma 'idéia' mais particular está contida em uma 'ideía' mais geral. Desta feita, podemos exemplificar usando a seguinte analogia: Esse tipo de conclusão se aplicada no sentido inverso poderá levá-lo a concluir que todos animais são felinos, o que é uma inverdade.
2. Inclusão (include) - esse tipo de de relacionamento faz com que um caso de uso encapsule funcionalidades que são complementares a ação de outros casos de uso. Por exemplo, para efetuar uma transação de inclusão ou exclusão, usualmente será necessário, primeiramente, executar-se uma pesquisa a fim de verificar a existência do registro que será alvo da ação. Desta feita, para que não repitamos ações, isolaremos a pesquisa em um caso de uso e faremos com que os casos de uso de inclusão e exclusão o acione como include. A particularidade, com relação ao include está relacionada a obrigatoriedade de execução, ou seja, todas as vezes que os casos de uso de inclusão ou exclusão de registros forem acionados, obrigatoriamente, o include também será executado.
3. Extensão (extends) - o relacionamento de extensão muito se assemelha ao de inclusão. Esse relacionamento também visa complementar alguma ação isolada de um caso de uso. Porém a diferença fundamental consiste em que a sua execução será opcional.

Os casos de uso que tem como alvo o mesmo objeto, normalmente são agrupados em um caso de uso que usualmente denominados 'Manter'. Esse tipo de caso de uso que é também conhecido pela sigla na lingua inglêsa 'CRUD', que representa: C - Create; R - Retrieve; U - Update e D - Delete, tem esse agrupamento justificado porquê para as transações de criação, atualização e exclusão dever-se-á ser executada a transação de recuperação ou pesquisa da informação. Na verdade propomos que esse tipo de caso de uso em português seja denominado por 'DICA' - Deleção, Inclusão, Consulta e Atualização. Tenho dito!

Desvendando os Casos de Uso

Casos de Uso dizem respeito a funcionalidades que estão agrupadas em cenários comuns. Essas funcionalidades, certamente, devem ter afinidades entre sí, além de convergirem para um objetivo comum. Um Caso de Uso deve ser 'enxuto', ou seja, deve fornercer aos operadores funcionalidades que estão estritamente relacionadas com os objetivos a que se propõe.

O diagrama de caso de uso é a representação em UML (Unified Modeling Language) - Linguagem de Modelagem Unificada - desses cenários afins, cuja representação sustenta-se em três elementos fundamentais.

1. O caso de uso no estrito senso do termo, ou seja, o nome comum desse agrupamento de funcionalidades - cenários comuns;
2. Os atores - operadores do caso de uso, esses podem ser pessoas, outros sistemas (robôs etc.), outros casos de uso;
3. Indicador de interelacionamento - que índica a relação entre os atores e as funcionalidades do caso de uso.

Usamos denominar casos de uso segundo a seguinte forma: UC - mneumônico de Use Case - expressão que significa caso de uso na lingua inglesa e XX - numero seqüencial que indentifica o caso de uso, p ex.: UC01.

Freqüentemente, encontramos casos de uso cujos objetivos sejam 'Criar', 'Consultar', 'Editar' e 'Excluir' agrupados num único caso de uso, denominado 'Manter'. A esse agrupamento denominamos 'CRUD' - sigla a construída a partir das palavras da lingua inglesa: Create - Criar, Retrieve - Consultar, Update - Atualizar e Delete - Excluir. Esse agrupamento favorece a visão do contexto do sistema, necessitando que seja detalhado em nota explicativa específica. Abaixo vemos a representação de um diagrama de caso de uso.

De quê necessita o seu usuário

Quais são as necessidades dos stakeholders do software para o qual você está elicitando requisitos?

Muitas vezes, nem eles sabem!... E aí começam os problemas. Algumas vezes, as pessoas desejam realizar projetos e não têm a mínima idéia do quê e para o quê. E aí você, analista de requisitos, é convocado para levantar necessidades (NE) de não sei o quê, para não sei quem.

Como sobreviver nesse contexto?

Existe receita de bolo para esse problema?

Tenho que responder com um sonoro nãaaaaaao! Em algumas circustâncias você terá de se esforçar muito para sobreviver na função, na empresa etc.

Meu amigo, quando seu chefe mandar você elicitar requisitos com stakeholders que não sabem as necessidades dele em relação ao software, saiba que não haverá projeto. Pois que, tudo em software se resume numa palavra fundamental: Necessidade.

A pedra fundamental de um software se resume nisso, que chamamos necessidades dos usuários do software.

Em tempo: o termo Stakeholder diz respeito a todos envolvidos no projeto de software, desde de patrocinadores, usuários diretos, usuários indiretos, fornecedores, equipes de infra-estrutura, enfim todos aqueles que tem algum relacionamento direto ou indireto com o projeto.

O Que Seria Rastreabilidade 2ª parte

A relação entre os diferentes produtos e etapas da construção de um software, que aqui usamos denominar rastreabilidade, pode ser comparada a uma árvore em desenvolvimento. E no princípio era o verbo, ou seja, as Necessidades que os usuários expuseram à equipe de levantamento de requisitos, através de formulários, reuniões, workshopings, brainstorm etc. A partir dessas Necessidades, raízes fundamentais para a sustentação de nossa criação e que, estarão registradas em atas, derivarão os outros apêndices, quais sejam: Funcionalidades, Requisitos Funcionais, Requisitos não Funcionais, Regras de Negócios, enfim...

Essa interligação de fatores concluir-se-á com a construção do código - é claro que uma certa seqüência de código estará presente para resolver, em termos de Funcionalidade, uma certa Necessidade.

Finalmente, ao se objetar uma manutenção, seja evolutiva ou corretiva, todas as informações estarão interligadas facilitando a interpolação entre a documentação e o código do software.

A essência da reastreabilidade é percebida quando lidamos com o reuso de código, pois ficará claro onde ocorrerão impactos - efeitos colaterais - caso haja alteração em alguma parte desse código.

O Que Seria Rastreabilidade 1ª Parte

Rastreabilidade é a forma que o Analista de Requisitos (AR) tem para rastrear os seus elementos de trabalho, ou seja, Atas de Reuniões (AT), Necessidades dos usuário (NE), Funcionalidades do Sistema (FN), Requisitos Funcionais (RE), Requisitos Não Funcionais (RF), Regras de Negócio (RN) entre outros.

A Rastreabilidade começa a existir no momento em que obtemos as NE. Mediante os contatos com os usuários registramos o conteúdo desses eventos em documentos, os quais denominamos Atas de Reunião (AT). Nesses encontros são levantadas as necessidades do usuário em relação ao software que está sendo construido. Normalmente, num primeiro momento, essas necessidades estarão desorganizadas e não estarão agrupadas. São, na verdade, pontos relevantes apontados pelo usuário e que o sistema deverá, obviamente, atender. No exato momento, em que o AR, debruça-se sobre essas NE, ele procura desmembrá-las e complementá-las. Essas NE que chamaremos aqui de Necessidade Objetivas necessitarão de outras NE complementares que chamaremos de Necessidades Subjetivas. Esses elementos, normalmente, estarão além do entendimento do usuário, pois esses não deveriam se preocupar com a implementação em sí. De forma contrária, o AR já deve ter em foco as regras de implementação para software. Por exemplo, o usuário tem como necessidade objetiva uma consulta específica a uma informação qualquer. O AR, subjetivamente, entende que para se consultar uma informação é necessário que esta informação esteja disponibilizada em algum local do sistema.

O primeiro ponto de rastreabilidade do AR, consistem nas relações NE x AT --> ou seja, a relação entre a Necessidade dos usuários que o tenham definido, época em que foi definido, bem como o seu VORD (visão do usuário em relação à NE).

Técnica de Elicitação de Requisitos parte 2

A partir do cruzamento entre NE x FN, surgirão os Requisitos (RE). Esses "indivíduos" devem ser tratados como,verdadeiros, seres vivos. Pois que, evoluem e amadurecem ao longo do tempo e em relação ao seu "nicho". A nossa relação inicial, agora apresenta um terceiro elemento e temos então um triângulo relacional, tão "perigoso", quanto um triângulo amoroso:

Esse triângulo relacional representa a relação fundamental de nossa matriz de rastreabilidade, que será resolvida por três relações unívocas objetivas:

1. a primeira, já pre-existente: NE x FN;
2. uma segunda recente: FN x RE;
3. e uma terceira, também recente: FN x NE.