[faceturbo]Olá, tudo bem?

Vamos falar um pouco sobre requisitos, recentemente observei um grupo de analista de negócios debatendo sobre a definição de requisitos e em que documentos eles deveriam aparecer. Sem dúvida que todos são muito preparados, porém não se atentaram para um questão simples, requisitos possuem uma classificação, são distintos, podem estar sem identificação ainda e de forma alguma requisitos são o objetivo do negócio.

Então como entender e “dissecar” os requisitos do “negócio” claramente? Vamos lá! **Baseado no Blog do Caminao, livre adaptação e tradução do texto.

Primeiro, vamos iniciar tentando, a partir de uma proposta metafórica, classificar os requisitos através da famosa enciclopédia chinesa inventada por Jorge Luis de Borges intitulada  Empório Celestial de conhecimentos Benévolos,  que divide os animais em catorze categorias. O desafio é compreender e tentar obter algo de coerente e útil nesta comparação.

Categorias:

1. pertencentes ao Imperador:  “Os Objetivos do Negócios” – DE ACORDO?
2. embalsamados: requisitos “não aplicáveis ou abandonados”, tornaram-se obsoletos devido as mudanças no contexto da empresa ou questões técnicas.
3. amestrados: Requisitos adicionais para os aplicativos existentes. os Pacotes, os sistemas externos, o sistema legado, etc… Esse tem bastante o tempo todo não é mesmo?
4. leitões: Requisitos adicionais para projetos ainda em desenvolvimento. Muito cuidado, nem terminou o projeto e já está sendo adicionado requisitos, imagina como a cara do GP fica nesse momento? :0.
5. sereias: Requisitos sem propósito claro ou apenas com função seduzir a parte interessada. Uau, que perigo!
6. fabulosos: São aquelas super exigências para um avanço tecnológico ambicioso ou quem sabe uma equipe perfeita.
7. cães vira-latas: Famoso cão sem dono, requisitos com propósitos bem claros e sem nenhuma parte interessada identificada.
8. os que estão incluídos nesta classificação: São todos os requisitos incluídos nesta classificação. O tudo do todo, hã?
9. os que se agitam feito loucos: Requisitos que mudam quando revisados, constantemente…
10. inumeráveis:  São os requisitos que se multiplicam quando revistos.
11. desenhados com um pincel finíssimo de pêlo de camelo: rsrsr… São requisitos definidos e modelados graficamente.
12. et cetera/outros: Todos os outros requisitos que não podem ser expressos simbolicamente.
13. os que acabaram de quebrar o vaso: Requisitos associados a falhas recentes. Xii, quem sustenta isso?
14. os que de longe parecem moscas: Requisitos não classificados que retornam pra lá e cá de forma irritante e  incômoda.

De todas listagens classificatórias, essa lista me parece ser a melhor do ponto de vista metafórico, pois denuncia sua arbitrariedade, afinal não há classificação neste imenso universo que não seja arbitrária ou há?

Voltando ao nosso mundo, o objetivo deve ser o de esclarecer o que está em jogo e identificar a natureza do problema a ser resolvido. Daí a busca de uma taxonomia/classificação para o requisito que seja abrangente, fundamentada e inequívoca. Ufa, será possível executar essa tarefa com excelência? Sim, claro.

Exceto para os itens 11 e 12, os resultados da classificação inicial podem ser agrupados em cinco categorias distintas e que não se sobrepõem:

1. Os objetivos de negócio (não confundir com os requisitos de negócios) que podem ser suportados por requisitos funcionais (pertencentes ao Imperador).
2. Requisitos sob a autoridade de um único dono ou parte interessada (cães vira-latas)
3. Requisitos que afetam os aplicativos em desenvolvimento ou já implantado (amestrados, leitões).
4. Requisitos “não aplicáveis ou abandonados” (embalsamados, sereias, fabulosos)
5. Requisitos em vias de classificação (os que se agitam feito loucos, inumeráveis, os que acabaram de quebrar o vaso, os que de longe parecem moscas)

Excetuando os objetivos de negócios, para evitar considerá-los como requisitos, temos os requisitos já atribuídos (supostamente com a classificação adequada), os não aplicáveis (sem necessidade de classificação), e os pendentes (para serem classificados mais tarde), critérios simbólicos podem ser utilizados para que seja descoberta a classificação:

1. Requisitos Técnicos com conteúdo simbólico (conhecido como requisitos funcionais *-*). Dado que as expressões simbólicas podem ser reformuladas, a granularidade dessas exigências sempre pode ser ajustadas de acordo com necessidades individuais e, portanto, sob a autoridade de um único dono ou parte interessada.
2. Requisitos não técnicos com conteúdo simbólico (conhecido como requisito não-funcional *-*) . Visto que não podem ser exclusivamente vinculados aos fluxos simbólicos entre sistemas e domínios, logo não pode ser relacionado ao conjunto de partes interessadas. Contudo, como eles têm como alvo características e comportamentos de sistemas, podem ser associados com  níveis de arquitetura: a empresa, funcional, técnica.

Essa distinção faz todo o sentido, porque, independentemente da sua utilização, os sistemas de software são dispositivos de computação dedicados ao processamento das representações simbólicas. Dado que as suas funcionalidades não surgem de um vácuo, mas de arquiteturas combinando agentes humanos, equipamentos físicos e outros sistemas de software, os requisitos devem fazer uma distinção clara entre (1) os objetivos de negócios, (2) que suportam funcionalidades de sistemas, (3) como os funcionalidades são implementadas, e (4) como elas são operadas.

Veja a relação intrínseca que existe entre as arquiteturas:

Essa forma de classificação é prática e útil:

Prática porque pode ser decidida através de quatro pontos e elimina ambiguidade:

• Existe um proprietário principal ou parte interessada com plena autoridade de validação dos requisitos? Single Owner
• Os requisitos possuem conteúdos simbólicos com fluxos específicos entre sistema e contexto? Content Symbolic
• Os requisitos são funcionalidade de apoio vinculados ao sistema? System Functional
• Os requisitos e sua validação estão diretamente vinculados com a experiência do usuário? User Experience

Útil porque suporta a separação das preocupações das responsabilidade e indica onde e como os requisitos devem ser geridos: carteira (objetivos de negócios), projetos (requisitos funcionais), ou arquitetura (requisitos não funcionais). Considero essa parte sensacional considerando o contexto em que vivo atualmente…

Objetivos e requisitos funcionais

Os objetivos de negócio

Os objetivos de negócio são definidos corporativamente e são expressado em realizações de negócios genéricos, quer sejam qualitativos (por exemplo, pessoas, regulamentos) ou quantitativo (por exemplo, espaço, tempo ou dinheiro). Contrariamente aos requisitos, objetivos de negócio não estão diretamente associadas à capacidade dos sistemas: eles não descrevem as regras de negócios (como domínios) ou fluxos simbólicos (como requisitos de usuários), nem eles abordam características técnicas ou qualidade do serviço. Como conseqüência, eles não podem ser diretamente associados com testes de aceitação.

Requisitos de domínio

Os requisitos de domínio lidam com a semântica e as regras dos objetivos de negócios e processos. Enquanto eles são geralmente expressos como requisitos funcionais de sistema, eles devem ser geridos por conta própria, para serem apoiados por funcionalidades do sistema independentemente da forma como eles são feitos .

Mais importante ainda, os requisitos de domínio deve cair de forma inequívoca sob a autoridade de um único proprietário e ser organizado em objetivos de negócios claramente identificados em cada processo. Quando isso não é possível, devem ser definidos como objetivos de negócio (se não forem relacionadas com as capacidades do sistema) ou como a qualidade do serviço (se forem relacionados com as capacidades do sistema).

Necessidades dos “usuários” (Utilizadores do Sistema)

Os sistemas de apoio desempenham o papel de atender às necessidades dos utilizadores do sistema, que descrevem os conteúdos simbólicos trocados entre sistemas de software, dispositivos e agentes. Na prática, combinar (1) o subconjunto de requisitos de domínio correspondente ao impacto do sistema e (2) estruturas organizacionais, regras e procedimentos estabelecidos ao nível da empresa.

Assumindo que a semântica e uso de fluxos simbólicos podem ser atribuídos exclusivamente a domínios de negócios, requisitos funcionais devem sempre ser gerido por uma única autoridade, geralmente mas não necessariamente o encarregado de requisitos de domínio.

Requisitos Não Funcionais

De um ponto de vista pragmático, são as exigências que não podem ser ancoradas a objetivos ou processos claramente identificados dentro de contextos empresariais, são normalmente reagrupados sob o rótulo “não funcional”, ou FURPS, por Funcionalidade (isso é confuso…), Usabilidade, Confiabilidade, Desempenho e Suportabilidade .

Mais formalmente, esses requisitos lidam com o apoio das interações entre sistemas e contextos, independentemente dos conteúdos específicos dos fluxos simbólicos. Como consequência, mesmo que alguns possam estar associados a processos operacionais específicos, tais requisitos devem ser mapeados e geridos em conformidade com recursos do sistemas:

• Qualidade do serviço refere-se a apoiar a capacidade dos sistemas de forma independente dos conteúdos funcionais.
• requisitos técnicos referem-se à implementação de recursos de sistemas, independentemente de seus conteúdos funcionais específicos.

Deve ser lembrado que a classificação não é sobre a natureza intrínseca dos requisitos, mas sobre a sua gestão. Como consequência, o mesmo tipo de requisitos (por exemplo, custos) pode aparecer separadamente como técnicas  (custos de desenvolvimento) e como uma qualidade de serviço (custo de propriedade).

Qualidade do serviço

Se a qualidade do serviço é para ser diretamente verificada a nível operacional os requisitos correspondentes devem ser associados a capacidade dos sistemas convencionais, em particular:

• Interações (OMS): simbólicas (papéis) e não simbólicas (dispositivos) interfaces.
• Domínios (O): persistência e acesso a representações simbólicas.
• Atividades (como): descrição da lógica de negócios
• Locais (Onde): distribuição de empregos e recursos.
• controle de processos (Quando): gestão de eventos e nível de serviço.

Qualidade de serviço e Arquitetura Capacidades

Dependendo da capacidade, os requisitos de qualidade do serviço podem tratar de:

• recursos de balanço / capacidades: tempo de resposta, volumes, etc.
• Nível de serviço: disponibilidade, manutenção.
• Confiabilidade: falhas e recuperação, tolerância a falhas.
• Segurança: confidencialidade, integridade.
• escalabilidade
• Interoperabilidade, compatibilidade, conformidade com os regulamentos.
• Usabilidade: facilidade de uso, a curva de aprendizagem, documentação, personalização.
• Custos: uso de propriedade.

Requerimentos técnicos

Considerando que podem vir a enfrentar as mesmas preocupações, exigências técnicas não deve ser confundidas com a qualidade do serviço. Contrariamente aos serviços, cuja qualidade é observável nos limites do sistema, requisitos técnicos são componentes do sistema ao longo dos diferentes níveis de arquitetura:

• componentes de negócios persistentes apoiam o acesso compartilhado.
• componentes de negócios transitórios apoiam o acesso compartilhado.
• componentes de negócios transitórios apoiam o acesso único.
• mecanismos de comunicação.

Dependendo das camadas, requisitos técnicos podem abordar:

• A natureza dos recursos a serem utilizados para implementar os componentes.
• Qualidades internas dos Componentes: rastreabilidade, a manutenção, reutilização, etc.
• Qualidades externas dos Componentes: portabilidade, de conformidade com as normas técnicas, etc.
• Custos: desenvolvimento de produtos.

Avaliação

Classificações são ferramentas feitas de propósito, e eles devem ser avaliados se estão em conformidade. Em uma base teórica a taxonomia proposta parece apoiar a separação de interesses, tanto para clientes (partes interessadas e usuários) e fornecedores (de desenvolvimento). Em termos práticos, deve também ser aplicada à uma amostragem de requisitos e testados para garantir praticidade, precisão e eficácia:

1. Praticidade e precisão, medida pela percentagem de requisitos que podem ser classificados de forma inequívoca.
2. Eficácia, medida pela percentagem de requisitos não classificados que podem ser reformulados e classificados de forma inequívoca.

Em uma perspectiva mais ampla, essa taxonomia pode ser especialmente útil para aplicações baseadas na nuvem, uma vez que distingue as exigências do que deve ser apoiado em cloud ou não.

Um estudo de caso simples para ilustrar a abordagem!

Estudo de caso: A Oficina-Garagem do Rai

Todos os requisitos podem estar inequivocamente classificados usando a tabela proposta, mesmo que algumas respostas continuem gerando dúvida.

1. O negócio da Oficina do Rai é servir aos veículos dos moradores da região.
2. A Oficina pode reparar veículos de clientes privados, visto que mais de 20% da equipe de mecânica está desempregada há mais de uma semana (6).
3. A Oficina pode estacionar veículos de clientes privados, se a taxa de ocupação é inferior a 75% (11).
4. A Oficina deve ser capaz de servir pelo menos 3 intervenções por dia (2).
5. As intervenções devem ser agendadas de acordo com o interesse dos Clientes VIP´s(12).
6. As intervenções devem dar prioridade aos Clientes oficiais  e aos VIP´s (12).
7. A posição dos caminhões de serviço devem ser verificados duas vezes por dia (1).
8. Um caminhão de serviço deve ficar no local do incidente o mais tardar no dia seguinte em que um pedido de intervenção for aceito (2).
9. Os pedidos de intervenção são imediatamente registrados e expedidos (3).
10. Equipe de mecânica são atribuídos com base na disponibilidade (4).
11. Equipe de Mecânica são atribuídos com base em habilidades como avaliado pelos gestores (4).
12. Pagamento por mão de obra avulsa são aceitos (5).
13. A oficina do Rai pode reparar veículos de clientes privados, se a taxa de ocupação é inferior a 70% (6).
14. Pagamento por mão de obra avulsa são aceitos até 100 libras (5).
15. documentação técnica usada pela equipe de mecânica deve estar pronta em menos de meio dia (4).
16. Detalhes de intervenção e o tempo gasto deve ser gravado imediatamente após a conclusão (6).
17. arquivos de intervenção devem ser colhidos em menos de cinco minutos (7).
18. Os clientes devem reconhecer o estado de seu veículo antes de verificar (8).
19. Os clientes devem ser identificados usando sua foto gravada (7);
20. As fotos dos clientes devem ser registradas por fotógrafos profissionais cadastrados/registrados(7);
21. Elevadores devem ser operado por voz e comandos de sinal (12).
22. Elevadores devem medir pelo menos 4 x 4m por padrão e suportar o peso de 15 homens (9)
23. Unidades de controle de elevação devem conhecer a última paragem do elevador e sua direção se ele estiver em movimento (10).
24. Pisos permaneceram bloqueados até que o elevador esteja parado e alinhado (11).
25. Cercas em pisos devem ser feitos de carvalho (11).
26. Bois puxando caminhões de serviço deve ser de pelo menos 4 côvados de alto padrão (2).
27. Passagem deve desbloquear-se quando o elevador está parado e alinhado (11).
28. Passagem deve bloquear-se quando o elevador deixa seu alinhamento (11).
29. Veículos em manutenção e reparo deverão ser recuperados em duas semanas, no máximo, após a conclusão (8).
30. Os proprietários de veículos reparados devem ser informados no prazo de dois dias após a conclusão (13).
31. O status de veículos no reparo será estabelecido diariamente (6).
32. O faturamento mensal da força de trabalho para processar o elevador deve ser inferior a 50% (9).

Classificando:

1 – Objetivos do Negócio:

1. O negócio da Oficina do Rai é servir aos veículos dos moradores da região.
2. A posição dos caminhões de serviço devem ser verificados duas vezes por dia (1).

2 – Requisitos sob a autoridade de um único dono ou parte interessada:

1. arquivos de intervenção devem ser colhidos em menos de cinco minutos (7).
2. Os clientes devem ser identificados usando sua foto gravada (7).
3. As fotos dos clientes devem ser registradas por fotógrafos profissionais cadastrados/registrados(7).

3 – Requisitos que afetam os aplicativos em desenvolvimento ou já implantado:

1. Os pedidos de intervenção são imediatamente registrados e expedidos (3).
2. Equipe de mecânica são atribuídos com base na disponibilidade (4).
3. Equipe de Mecânica são atribuídos com base em habilidades como avaliado pelos gestores (4).
4. documentação técnica usada pela equipe de mecânica deve estar pronta em menos de meio dia (4).

4 – Requisitos “não aplicáveis ou abandonados”:

1. A Oficina pode reparar veículos de clientes privados, visto que mais de 20% da equipe de mecânica está desempregada há mais de uma semana (6).
2. A Oficina deve ser capaz de servir pelo menos 3 intervenções por dia (2).
3. Um caminhão de serviço deve ficar no local do incidente o mais tardar no dia seguinte em que um pedido de intervenção for aceito (2).
4. Pagamento por mão de obra avulsa são aceitos (5).
5. A oficina do Rai pode reparar veículos de clientes privados, se a taxa de ocupação é inferior a 70% (6).
6. Pagamento por mão de obra avulsa são aceitos até 100 libras (5).
7. Detalhes de intervenção e o tempo gasto deve ser gravado imediatamente após a conclusão (6).
8. Bois puxando caminhões de serviço deve ser de pelo menos 4 côvados de alto padrão (2).
9. O status de veículos no reparo será estabelecido diariamente (6).

5 – Requisitos em vias de classificação:

1. Elevadores devem medir pelo menos 4 x 4m por padrão e suportar o peso de 15 homens (9)
2. Unidades de controle de elevação devem conhecer a última paragem do elevador e sua direção se ele estiver em movimento (10).
3. Os proprietários de veículos reparados devem ser informados no prazo de dois dias após a conclusão (13).

6 – Todos os outros:

1. A Oficina pode estacionar veículos de clientes privados, se a taxa de ocupação é inferior a 75% (11).
2. As intervenções devem ser agendadas de acordo com o interesse dos Clientes VIP´s(12).
3. As intervenções devem dar prioridade aos Clientes oficiais  e aos VIP´s (12).
4. Os clientes devem reconhecer o estado de seu veículo antes de verificar (8).
5. Elevadores devem ser operado por voz e comandos de sinal (12).
6. Pisos permaneceram bloqueados até que o elevador esteja parado e alinhado (11).
7. Cercas em pisos devem ser feitos de carvalho (11).
8. Passagem deve desbloquear-se quando o elevador está parado e alinhado (11).
9. Passagem deve bloquear-se quando o elevador deixa seu alinhamento (11).
10. Veículos em manutenção e reparo deverão ser recuperados em duas semanas, no máximo, após a conclusão (8).

Convido a todos a comentarem e compartilharem suas opiniões sugestões e críticas a cerca da classificação dos requisitos.

Obrigada.

[/faceturbo]