Nível de detalhe: A melhor especificação é a que atende aos seus propósitos by Carlos Eduardo

Engenharia de Requisitos Nível de Detalhe: A melhor especificação é a que atende aos seus propósitos

FATTO Consultoria e Sistemas ˜ Estimativas e Requisitos de Software Medic¸ao,

˜ e´ a que N´ıvel de detalhe: A melhor especificaçao ´ atende aos seus propositos ˜ 2 Carlos Eduardo Vazquez1 , Guilherme Siqueira Simoes Resumo ´ um equivoco avaliar que quanto maior o n´ıvel de detalhe em uma especificaçao, ˜ melhor ela seja. As consequencias ˆ E ˜ desde fomentar o retrabalho a incorrer em erros graves como tomar no ambito ˆ desse equivoco vao da engenharia de ˜ de projeto (design) ou implementaçao. ˜ Este documento caracteriza o que seja n´ıvel de detalhe para requisitos decisoes ˜ de requisitos, apresenta uma serie ´ uma especificaçao de fatores de riscos que promovem um maior ou menor n´ıvel de ˜ do n´ıvel de detalhe que melhor alinha a especificaçao ˜ detalhe e explica como utilizar esses fatores de risco na avaliaçao ´ aos seus propositos. Keywords ˜ de requisitos; gestao ˜ do conhecimento; elicitaçao ˜ de requisitos; analise ´ ˜ de requisiespecificaçao de requisitos; gestao tos;n´ıvel de detalhe; escopo 1 FATTO

2 FATTO

Consultoria e Sistemas, carlos.vazquez@fattocs.com Consultoria e Sistemas, guilherme.simoes@fattocs.com

Conteudo ´ 1 1.1 1.2 1.3

Significado de n´ıvel de detalhe Delimitar o escopo . . . . . . . . . . . . . . . . . . . . . Descrever um item no escopo . . . . . . . . . . . . . . ˜ Mapear os requisitos no design ou implementac¸ao

1 1 2 3

Equivoco comum

´ 3 Criterios para o n´ıvel de detalhe 3.1 Desenvolvimento interno ou externo . . . . . . . . 3.2 Equipe dispersa ou agrupada geograficamente . 3.3 Casos de testes baseados nos requisitos . . . . 3.4 Incerteza das estimativas . . . . . . . . . . . . . . . 3.5 Rastreabilidade aos requisitos . . . . . . . . . . . . 3.6 Envolvimento dos clientes . . . . . . . . . . . . . . 3.7 Conhecimento da equipe no dom´ınio . . . . . . . ˆ 3.8 Experiencia trabalhando com software afim . . . 3.9 Desenvolvimento concorrente de procedimentos ˜ usara´ pacote . . . . . . . . . . . . . . . . . 3.10Soluc¸ao ˜ de obra . . . . 3.11Potencial de rotatividade de mao

. . . . . . . . . . .

4 4 4 4 5 5 5 5 5 6 6 6

˜ Conclusao

ˆ ´ Referencias Bibliograficas

1. Significado de n´ıvel de detalhe ˜ sobre o n´ıvel de detalhe na especificac¸ao ˜ de A discussao requisitos deve ser precedida por qual o significado que se pretende dar ao termo. Os n´ıveis de detalhe podem ser ˆ objetivos diferentes: subdivididos conforme tres •

Delimitar o escopo preliminar e definir o ˜ escopo final da soluc¸ao;

•

˜ Descrever o funcionamento e restric¸oes de um item no escopo;

•

Mapear os requisitos para design ou ˜ implementac¸ao.

1.1 Delimitar o escopo O n´ıvel de detalhe em que o escopo esta´ especificado pode ˆ pontos, ser descrito em uma escala onde se destacam tres conforme o momento em que o projeto se encontra. No ˜ de requisitos define o primeiro momento, a especificaçao ´ escopo relacionando os processos de negocio impactados ˜ e o seu posicionamento no ambiente indicando pela soluçao ˜ de requisitos e´ o que sera´ externo a ela. A especificaçao ´ ˜ assim elaborada, porque varias decisoes sobre o escopo ainda devem ser resolvidas. ˜ se sabe exatamente quais atividades - parte daqueles Nao ˜ inicialmente destacaprocessos impactados pela soluçao ˜ especificamente inclu´ıdas parcialmente ou em dos - serao ˜ Imagine que a soluçao ˜ sua totalidade no escopo da soluçao. ˜ urbana de determinadas localiseja reformular a sinalizaçao ˜ metropolitana de Sao ˜ Paulo com o objetivo dades na regiao ´ ˜ de melhorar o fluxo de automoveis. Descrito nesse n´ıvel nao se consegue observar especificamente quais trechos de rua ˜ objeto deste trabalho. Observando o em especial serao ´ mapa (figura 1), pode-se depreender uma area de interesse; contudo, os requisitos devem ser desenvolvidos para que se consiga definir um escopo final. ˜ Em um segundo momento, conforme as decisoes sobre ˜ tomadas, as especificaçoes ˜ o escopo sao descrevendo o ˜ apenas os processos de escopo evoluem relacionando nao ´ tarefas do usuario ´ mais alto n´ıvel, mas tambem que devem ser informatizadas total ou parcialmente. ˆ Dando sequencia ao mesmo exemplo para reformular a

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificaçao — 2/7 ˜ de sua extensao, ˜ mas nao ˜ se de sua preender a visao profundidade; o mesmo acontece com os requisitos que podem estar detalhados quanto ao seu escopo no n´ıvel ˜ de de atividade (ou de trechos de rua para reformulaçao ˜ urbana); contudo, sem explicar do que se espera sinalizaçao ˜ no que se refere a uma atividade em particular da soluçao (ou o que deve ser feito em um trecho de rua em particular).

Figura 1. Visão da região metropolitana de São Paulo (Google Maps). ˜ urbana, uma serie ´ ˜ ˜ tomadas sinalizaçao de decisoes sao ˜ com maior potencial para que priorizando aquelas regioes ´ se atinja o objetivo de melhorar o fluxo de automoveis. Uma ˜ dessas regioes, presente no escopo inicialmente definido ˜ que permite em termos mais gerais, ja´ possui informaçao discernir os trechos de rua relevantes (figura 2). Com isso, permite-se aumentar o n´ıvel de detalhe o escopo.

Figura 3. Vista da extens˜ao de um lago.

1.2 Descrever um item no escopo ´ indicar o grau O conceito de n´ıvel de detalhe pode tambem ˜ e as restriçoes ˜ em que o comportamento da soluçao que ˜ descritos para cada tarefa individualmente. se aplicam estao ˜ pode variar desde o ponto Nesse sentido, a especificaçao ˜ ha´ nada descrito (apenas se sabe o que faz em que nao ˜ completa com todos parte do escopo), ate´ uma descriçao ˜ do usuario ´ os passos que descrevem a interaçao com a ˜ o armazenamento e recuperaçao ˜ de dados; as soluçao; ˜ que se aplicam. regras e restriçoes ˜ refere-se a` explorar a N´ıvel de detalhe nesta acepçao ˜ e as restriçoes ˜ ˆ soluçao a que esta´ sujeita no ambito de uma tarefa em particular. Comparando a imagem com a ˆ abrangencia do lago, agora o interesse esta´ em entender a sua profundidade. O mesmo lago usado no exemplo anterior esta´ agora ilustrado (figura 4) com uma perspectiva ´ de sua profundidade. tambem

Figura 2. Vis˜ao detalhada de parte da regi˜ao metropolitana

de S˜ao Paulo (Google Maps).

˜ em Finalmente em um terceiro momento, a especificaçao ˜ descreve todo o escopo no n´ıvel de desua ultima versao ´ ´ ˜ talhe das tarefas do usuario. Todas as decisoes sobre o ˜ tomadas e sabe-se com precisao ˜ quais ativiescopo estao ˜ inclu´ıdas dades daquele processo mais abrangente serao ˜ como parte da soluçao. ˜ com o uso dos mapas, decidemConcluindo a comparaçao ˜ Em se se quais trechos de rua devem sofrer intervençao. ˜ metropolitana de Sao ˜ Paulo, o escopo tratando da regiao ˜ caberia nesta pagina ´ nao nesse n´ıvel de detalhe. O n´ıvel de detalhe, no sentido de qualificar o escopo de uma maneira mais geral ou mais espec´ıfica, busca explorar a ˆ ˜ Para realizar a transiçao ˜ para outro abrangencia da soluçao. ´ tipo de n´ıvel de detalhe, e´ melhor usar uma outra metafora. ˜ do lago (figura 3). Ela permite deObserve a ilustraçao

Figura 4. Visão também da profundidade de um lago. Em resumo, a Engenharia de Requisitos utiliza-se inicialmente de um escopo descrito de uma maneira geral. Isso ˜ do n´ıvel de incerteza associado a` soluçao, ˜ que da´ em funçao ˜ sobre a consolidaçao ˜ espaço ainda para diversas decisoes ˜ afetadas pela soluçao ˜ desse escopo (quais tarefas serao ˜ de cada informatizada, por exemplo) e sobre a descriçao item nesse escopo (qual o comportamento que se espera ˜ ao interagir com seus usuarios, ´ da soluçao por exemplo). A ˆ ˜ e´ representada na figura 5. dinamica desta evoluçao

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificac¸ao — 3/7

Figura 5. Evoluça˜ o dos n´ıveis de detalhe conforme evolui o desenvolvimento dos requisitos. ˜ 1.3 Mapear os requisitos no design ou implementaçao ´ Ainda que seja um significado valido para n´ıvel de detalhe ´ ˆ para outros propositos, no ambito da engenharia de requisitos o mapeamento dos requisitos para uma determinada ˜ em uma linguagem de arquitetura ou sua implementaçao ˜ deve ser evitado. Fazer isso significa sair do programaçao escopo da disciplina de requisitos e entrar no escopo de outra disciplina. Um exemplo e´ alocar o comportamento descrito nos requisitos em um: •

Componente de software na camada de ˜ ˆ apresentac¸ao, o intercambio de dados ´ com o usuario;

•

Componente de software na camada ˆ de persistencia, o armazenamento e ˜ de dados; recuperac¸ao

•

´ Sistema gerenciador de regras de negocio (Business Rule Management System BRMS), as regras.

2. Equivoco comum E´ um equ´ıvoco comum pensar que quanto mais detalhada a ˜ de requisitos, melhor ela e. ´ Ela e´ um contrato especificaçao entre cliente e desenvolvedores e o n´ıvel de detalhe deve ˜ e ser aquele que melhor consiga promover a comunicaçao ˜ de ambas as partes. compreensao Se voceˆ observar os contratos que firmou - muitos sem nem ´ mesmo perceber - percebera´ varios bem enxutos, ocupando somente uma folha, e outros bem extensos, de dezenas ou mesmo centenas de folhas. Ha´ contratos que representam ´ negocios de pouco valor (ingresso de cinema) e outros de ˜ quanto muito valor (financiamento de uma casa). Entao, mais significativo o valor envolvido, mais detalhado tende a ˜ o unico ser o contrato. Mas este nao fator a influenciar no ´ detalhamento. ˜ de ir a uma loja e Quando se compra um carro, ha´ opçao ´ ´ ´ financia-lo. Isto ira´ gerar um contrato com varias paginas. No entanto, se o dono da loja e´ um amigo de longa data, e´ ˜ aconteça baseada somente em poss´ıvel que a transaçao ˜ deixa de ser um contrato). O um acordo verbal (que nao ˜ valor do item e´ o mesmo nas duas situaçoes.

Sendo relacionamentos pessoais, o que determina o maior ou menor detalhamento do contrato e´ o grau de confiança entre as duas partes. A engenharia de requisitos e´ aplicada em ambientes corporativos que transcendem interesses de ˜ deveriam ter suas decisoes ˜ baseadas um indiv´ıduo e nao somente em termos de confiança e desconfiança. Ima˜ de contas de um executivo ao conselho gine a prestaçao ˜ sobre o fracasso de um projeto apresende administraçao ˜ que a empresa contratada traiu sua tando como explicaçao confiança. Nesse paralelo feito entre os contratos por indiv´ıduos e os ˜ contratos no plano de corporaçoes, confiança surge como ˜ de risco. Logo, quanto menor o risco uma representaçao ˜ entre cliente e desenvolvedores, menor avaliado na relaçao ˜ de requia necessidade de detalhamento da especificaçao ˜ entre as sitos. Quanto maior o risco avaliado na relaçao partes, maior a necessidade de detalhamento. ´ ˜ com o cliente mais O Manifesto Agil prega: “Colaboraçao ˜ de contratos” e no seu Princ´ıpio 4: “Pessoas que negociaçao ´ de negocio e desenvolvedores devem trabalhar diariamente ˜ em conjunto por todo o projeto.“ [Agile Manifesto, 2001]. Sao ˜ de confiança entre diretrizes que favorecem a construçao as partes, e com isso reduz a necessidade de detalhamento ˜ da especificaçao. Um documento que melhor permite depreender a imˆ ˜ de confiança em um plano pessoal portancia da traduçao ˆ ˆ para riscos em ambiente com exigencias de transparencia ´ ao ˜ No 2314/2013 do e governança corporativa e´ o Acord ´ ˜ [TCU, 2013]. Ele plenario do Tribunal de Contas da Uniao ˆ grupos distintos: proreune os riscos elencados em tres ´ ˜ se limita aos riscos cuja cessos, produtos e pessoas e nao ˜ foi verificada nas auditorias como, por exemmaterializaçao plo, o da rotatividade de pessoal verificado em um ambiente que fomenta a pessoalidade. ´ importante que se reflita quao ˜ detalhada sera´ a E ˜ de requisitos pois ha´ custo e tempo envolespecificaçao vidos nisso. Detalhar desnecessariamente significa desˆ perd´ıcio de recursos no projeto. Ausencia de detalhes pode ˜ de atividades seguintes do projeto, significar interrupçao ˜ de erros por falta de informaçao, ˜ enfim, retrabaintroduçao lho.

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificac¸ao — 4/7

´ 3. Criterios para o n´ıvel de detalhe ˜ cr´ıtico que deve ser pensado em uma Esse e´ um assunto tao ˆ ˜ so´ do projeto em questao, ˜ mas dos procesabrangencia nao sos; seja em pol´ıticas de qualidade para o desenvolvimento ˜ de ´ interno, seja em modelos de negocio para a contrataçao serviços no mercado (desenvolvimento externo). ˜ haja uma definiçao ˜ previa ´ Caso nao do n´ıvel de detalhe nos processos, o gerente de projeto deve estabelecer essa pol´ıtica para o projeto a partir de potenciais elementos de ˜ forem especirisco. Se os detalhes sobre os requisitos nao ficados pelos analistas de requisitos, em algum momento ˜ definidos por outros. Em ultima ˆ serao instancia os desen´ ˜ estas decisoes, ˜ ˜ volvedores tomarao porque o software nao admite ambiguidade. Quanto menos detalhes, maior a auto˜ e vice-versa. nomia dos desenvolvedores nessas decisoes Por isso, ha´ que se balancear o custo e riscos. ˜ ordenada) de fatoA seguir apresenta-se uma lista (nao res que podem influenciar na escolha do n´ıvel de detalhe adequado. Tabela 1. Fatores para maior ou menor detalhamento das

especificac¸o˜ es de requisitos No

Menos detalhe na especificac¸a˜ o

Mais detalhe na especificac¸a˜ o

01.

Desenvolvimento interno

Desenvolvimento externo

02.

Equipe agrupada

Equipe dispersa

03.

N˜ao elabora casos de testes ou a elaborac¸a˜ o ocorre em paralelo aos requisitos

Casos de testes elaborados a partir da especificac¸a˜ o

04.

Estimativas menos precisas

Estimativas mais precisas

05.

Baixa rastreabilidade de requisitos

Alta rastreabilidade de requisitos

06.

Alto envolvimento dos clientes

Baixo envolvimento dos clientes

07.

Alto conhecimento da equipe no neg´ocio

Baixo conhecimento da equipe no neg´ocio

08.

Precedentes existentes

Sem precedentes

09.

Desenvolvimento concorrente de procedimentos operacionais

Desenvolvimento com procedimentos operacionais j´a definidos e maduros

10.

Uso de pacotes na soluc¸a˜ o

Soluça˜ o não adotará pacote

11.

Baixo potencial de rotatividade de pessoal

Alto potencial de rotatividade de pessoal

3.1 Desenvolvimento interno ou externo Quando o desenvolvimento do projeto e´ realizado interna˜ mente na empresa, a equipe do projeto e os clientes sao

colegas de trabalho e compartilham interesses comuns. Em geral, muitos ja´ se conhecem antes do projeto e podem ˜ proxima. ´ ´ do que normalmente ter ate´ uma relaçao Alem trabalham muitas vezes no mesmo espaço f´ısico, o que facilita o encontro e diminui a necessidade de formalismo ˜ ˜ face a face e´ mais facil ´ nas interaçoes. Ou seja, a interaçao e frequente. Para o desenvolvimento externo do projeto, a equipe do pro˜ de empresas distintas e tem interesses jeto e os clientes sao ˜ sao ˜ colegas de trabalho. Se o desenvolvidistintos. Nao ´ mento ocorre no regime de fabrica de software, boa parte da equipe do projeto tem contato limitado com os clientes. ˜ longe fisicamente. DeClientes e equipe do projeto estarao ´ pendendo da fabrica de software, boa parte da equipe do projeto pode estar localizada em outra cidade, outro pa´ıs ou outro continente (a Índia com sua presença forte em ´ serviços de outsourcing e´ o exemplo classico). Com me˜ face a face, e´ necessario ´ nos possibilidade de interaçao mais detalhamento dos requisitos para minimizar eventuais ˜ problemas de comunicaçao. 3.2 Equipe dispersa ou agrupada geograficamente ˜ com o anterior. So´ que De certa forma este item tem relaçao ˆ no caso anterior a enfase foi no desenvolvimento interno ou ˜ a` proximidade externo como fator que pode favorecer ou nao entre clientes e desenvolvedores. ˜ enNo entanto, neste item o que se considera e´ a dispersao tre os membros da equipe do projeto. Hoje o trabalho remoto ´ e´ uma realidade comum em muitas empresas. Varias trabalham seus projetos com times virtuais. Ha´ vantagens na abordagem do trabalho remoto, por exemplo, mais facilidade de obter as pessoas mais competentes para a equipe. No ˆ entanto a convivencia distante entre os membros da equipe ˜ do senso de equipe entre e´ um dificultador para a formaçao ˜ em potencial. as pessoas e uma barreira de comunicaçao O [PMI, 2013] apresenta o agrupamento dos membros da ´ equipe num mesmo espaço f´ısico como uma estrategia de ˜ como equipe. aprimoramento de sua capacidade de atuaçao ˜ face a face, que dispensa Isso promove a comunicaçao ˜ Em caso de duvida, tanto detalhamento na especificaçao. ´ basta perguntar ao colega do lado. [Agile Manifesto, 2001] ´ reforça isso no seu princ´ıpio 06: “O metodo ´ tambem mais ˜ para e entre uma eficiente e eficaz de transmitir informaçoes ´ de conversa face a equipe de desenvolvimento e´ atraves face.” 3.3 Casos de testes baseados nos requisitos A princ´ıpio soa estranho este item. Normalmente, o que ˜ os casos de testes sendo elaborados a se imagina sao ˜ de requisitos. Nem sempre essa e´ partir da especificaçao ´ a estrategia adotada no desenvolvimento do projeto. Ha´ ´ ˜ ja´ estao ˜ definidos e casos onde os criterios de aceitaçao ˜ orientar os testes. Neste caso, o trabalho de requisitos vao ˜ ´ e´ que usa estas informaçoes como materia prima do seu trabalho. ´ onde a equipe de testes participa do Ha´ casos tambem ˜ dos casos de testes. trabalho de requisitos para a elaboraçao Nestes casos tanto o analista de testes quanto o analista ˜ usando a mesma fonte de informaçao; ˜ de requisitos estao so´ que, enquanto o primeiro elabora os casos de testes,

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificaçao — 5/7 ˜ de requisitos. Nao ˜ ha´ o segundo elabora a especificaçao ˆ ordem de precedencia entre os dois trabalhos. ˜ de requisitos e´ materia ´ Quando a especificaçao prima para a equipe de testes elaborar seus casos de testes e depois ´ executa-los, certamente ha´ mais necessidade de detalhes ˜ A elaboraçao ˜ dos casos de testes a parna especificaçao. ˜ e´ uma ferramenta muito poderosa de tir da especificaçao ˜ de requisitos, ajudando a melhorar a sua qualiverificaçao dade. Os autores ja´ presenciaram o desenvolvimento do software ˜ de suas especificaçoes ˜ de requidescolado da elaboraçao ´ aos ˜ do governo. Enquanto o fornecedor mobilisitos em org ˜ (em tese, a zava uma equipe para produzir documentaçao ˜ de requisitos) para atender as ` exigencias ˆ especificaçao de entrega do contrato, outros desenvolvedores concomitante´ mente atuavam diretamente com os usuarios para obter as ˜ para a construçao ˜ do software. informaçoes ˜ produzida nao ˜ agregava valor Neste caso, a documentaçao ´ da conformidade as ` exigencias ˆ algum alem do contrato. O ˜ era meramente burocratico ´ trabalho em sua elaboraçao por˜ necessariamente ha´ nexo entre as especificaçoes ˜ que nao de requisitos e o produto propriamente dito. O verdadeiro trabalho de requisitos acontecia na equipe que atuava dire´ tamente com os usuarios. 3.4 Incerteza das estimativas ˜ Toda estimativa envolve um grau de incerteza por definiçao. A incerteza nas estimativas esta´ diretamente relacionada ao grau de maturidade e estabilidade dos requisitos. A ma˜ entre decisoes ˜ sobre requisitos turidade refere-se a` relaçao pendentes e que ja´ foram tomadas; estabilidade refere-se a` probabilidade de mudanças em requisitos ja´ definidos. Quanto mais cedo se necessita de uma estimativa, me´ nor a chance dos requisitos estarem maduros ou estaveis. ´ Quando um projeto esta´ em analise de viabilidade, e´ pouco ´ ˜ de reprovavel que haja espaço para uma especificaçao ´ quisitos detalhada. Para esses propositos, normalmente trabalha-se com uma estimativa de ordem de grandeza baseada nos requisitos existentes cujo n´ıvel de detalhe em ˜ de escopo preliminar. geral e´ associada a uma declaraçao No entanto se ha´ a necessidade de se obter uma estimaˆ ˜ tiva definitiva, havera´ a exigencia de mais informaçoes e ˜ de requisitos. detalhes na especificaçao 3.5 Rastreabilidade aos requisitos Alguns tipos de projeto implicam em um alto grau de ˆ evidencias relacionando os requisitos entre si e entre artefatos de outras disciplinas na engenharia de software; por ˜ cr´ıtica. Para a industria exemplo, sistemas de missao ae´ ´ ˜ ˜ ronautica, existem certificaçoes para software de missao ˜ DO-178C , que exige rastrecr´ıtica. Um caso e´ o padrao ´ abilidade ao ponto que cada linha de codigo fonte esteja diretamente rastreada para um requisito e um caso de teste. Logo, nestes casos ha´ a necessidade de requisitos mais detalhados. 3.6 Envolvimento dos clientes O grau de envolvimento dos clientes no projeto e´ um fator ´ influencia no n´ıvel de cr´ıtico para seu sucesso. E tambem

detalhe dos requisitos. Para o cliente que esta´ altamente envolvido e participativo no desenvolvimento do projeto, ˆ ˜ de uma relaçao ˜ uma consequencia natural e´ a construçao de confiança mais forte com a equipe de desenvolvimento. ´ a comunicaçao ˜ face a face entre Nesse ambiente, tambem as duas partes sera´ mais frequente. Tudo isso favorece para ˜ seja necessaria ´ ˜ tao ˜ detalhada. que nao uma especificaçao 3.7 Conhecimento da equipe no dom´ınio ´ O proverbio “para bom entendedor, meia palavra basta” encaixa-se bem aqui. Quando a equipe do projeto tem ˆ ´ experiencia de outros projetos no negocio do cliente, mui˜ desnecessarios ´ tos detalhes sao de se especificar. O que ˜ pode ocorrer (mas infelizmente ocorre com frequencia), ˆ nao ˜ e´ a equipe do projeto pensar que ja´ tem toda a soluçao para o cliente, sem antes ouvi-lo atentamente sobre suas ´ necessidades e de seu negocio. No desenvolvimento interno, e´ comum que a mesma equipe ´ ´ ´ execute varios projetos para uma mesma area de negocio. ˜ com o passar do tempo essa equipe acumula conheEntao, cimento sobre este dom´ınio, podendo conversar no mesmo n´ıvel com os clientes. Ha´ profissionais que passam a conhe´ ˜ cer tanto do negocio do cliente que deixam suas posiçoes ´ em projetos e passam a atuar como gestores no negocio. No desenvolvimento externo, ha´ fornecedores que atuam ´ ´ exclusivamente com projetos em areas de negocio muito ´ ˜ espec´ıficas: bancaria, telecomunicaçoes, energia. Isto ´ favorece que mantenham uma equipe com extambem ˆ ´ ˜ com os periencia no negocio, facilitando a comunicaçao clientes. ´ Ha´ tambem fornecedores que atuam sem tanta ˜ especializaçao, desenvolvendo projetos para qual´ ´ quer area de negocio em que surgir uma oportunidade. Neste caso, hoje uma equipe pode estar atuando num ´ projeto da area de saude, mas depois seus membros ´ ´ ˜ os podem ser alocados em projetos de outras areas. Entao, ´ responsaveis pelo trabalho de requisitos nessas equipes ´ devem estudar previamente o negocio do cliente para ˜ conseguir um nivelamento m´ınimo para a comunicaçao ´ ˜ eficaz. Ainda assim, sera´ necessaria uma especificaçao mais detalhada para que toda equipe consiga compreender bem o que deve ser constru´ıdo e entregue. ˆ O COCOMOII [Boehm, 2000] coloca que a experiencia do ˜ e o dom´ınio em que ela se insere analista com a aplicaçao tem efeitos multiplicativos na produtividade que pode impli˜ na produtividade em 22% ao seu car desde uma reduçao ˜ a` uma experiencia ˆ aumento em 19% em relaçao de um ano ˜ Ainda que o estudo nao ˜ entre no merito ´ com a aplicaçao. ˜ pode-se atribuir das causas subjacentes dessa constataçao, esses ganhos de produtividade a` maior agilidade associada ˜ dos requisitos. ao desenvolvimento e gestao ˆ 3.8 Experiencia trabalhando com software afim ˜ Nas situaçoes em que ha´ precedentes existentes ao projeto que sera´ desenvolvido, a necessidade de detalhamento torna-se menor. Precedentes podem ser projetos muito similares que ja´ foram desenvolvidos e que podem servir como ˜ para o projeto que sera´ desenvolvido. fonte de informaçao Exemplos:

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificac¸ao — 6/7 •

Reengenharia de um sistema existente: Desenvolver novamente um sistema legado em uma nova tecnologia. Neste caso ´ ˜ o proprio legado ou sua documentac¸ao pode suprir muito dos detalhes ne´ cessarios dos requisitos para novo projeto.

•

˜ Manutençoes similares em sistemas distintos: Um caso e´ de um projeto para adequar o sistema de Poupança de um ˜ do Banco banco para uma determinaçao ´ ja´ se sabe que a mesma Central, porem ˜ ja´ foi feita para o sistema de manutençao Contas Correntes. Assim, muitas das de˜ adotadas na primeira manutençao ˜ cisoes podem servir para o novo projeto.

3.9 Desenvolvimento concorrente de procedimentos Ha´ casos em que o desenvolvimento dos requisitos esta´ ´ do software, ha´ inserido em um ambiente em que, alem o desenvolvimento de novos procedimentos operacionais. ˜ que o proNesses casos, e´ poss´ıvel perceber de antemao ˜ jeto estara´ sujeito a uma grande quantidade de solicitaçoes ˜ ha´ ainda um de mudança em requisitos. Isso porque nao ´ ˜ ainda nao ˜ processo de negocio definido ou a sua definiçao ´ ˜ a serem tomadas e as esta´ madura; restam varias decisoes ˜ em discussao ˜ junto aos gestores das mesmas ainda estao ´ areas envolvidas.

Figura 6. Vis˜ao geral do posicionamento dos requisitos na

avaliac¸a˜ o de pacotes.

˜ mais detaNeste casos, tentar produzir uma especificaçao ˜ detalhada sera´ um desafio. Manter essa documentaçao ´ cada mudança implica lhada atualizada e consistente apos ˜ cabe a pergunta: Para que detalhar em retrabalho. Entao, ´ que sofrera´ mudanças pouco depois? Se algo ainda volatil ˜ houver razao ˜ forte o suficiente para isso, busque uma nao ˜ menos detalhada. especificaçao Figura 7. Tipos de aça˜ o relacionados a` adequaça˜ o do ˜ usara´ pacote 3.10 Soluçao ˜ Se o projeto tem por objetivo oferecer como parte da soluçao ˜ de um pacote de software dispon´ıvel no mercado a adoçao ˜ precisa se aprofundar (COTS), o trabalho de requisitos nao em tantos detalhes quanto a` profundidade e deve colocar ˜ faz o seu foco no escopo. Se o produto ja´ existe, nao sentido especificar detalhes de suas caracter´ısticas, porque o que se espera e´ que eles ja´ estejam presentes em sua ˜ para avaliaçao. ˜ documentaçao ˜ de um pacote deOs requisitos referentes a` avaliaçao ˜ do pavem permitir avaliar as necessidade de adequaçao ` necessidades do cliente e o grau de manutençao ˜ cote as que o mesmo deve sofrer [SEI:2010]. A figura 6 ilustra a ˜ entre os requisitos do produto e do negocio ´ comparaçao ˜ entre os dois conjuntos. indicando a intercessao ´ Quanto a` lacuna existentes entre os requisitos do negocio ˜ e do pacote, ha´ diferentes soluçoes que podem mudar a ˜ para se adequar as ` melhores praticas ´ organizaçao presentes no pacote e fazer com que o pacote se adeque ˜ Para este ultimo a` organizaçao. item, ele consiste de (vide ´ figura 7): •

˜ do pacote ˜ E´ a adequac¸ao Configurac¸ao: por meio de instrumentos nativos que permitem adequar o funcionamento ao requi-

pacote a` organizac¸a˜ o.

sito do cliente sem necessidade de desen˜ adicional. volvimento ou codificac¸ao •

˜ ˜ Customizaçao: Sao mudanças em ´ codigo para adequar funcionalidade ˜ esta´ dispon´ıvel por meio de que nao ˜ configuraçao.

•

˜ ˜ na base instalada: Sao Manutençao ˜ nos sistemas existentes para adaptaçoes ˆ acomodar o intercambio de dados com o ˜ pacote em avaliaçao.

[Dubey:2009] recomenda que cerca de 80% da funcionalidade do pacote devem estar aderente aos procedimentos ˜ ou pela sua adequaçao ˜ operacionais atuais na organizaçao ` melhores praticas ´ ´ coas embarcadas no software. Tambem ˜ mais que 15% sejam objeto de customizaçao. ˜ loca que nao ˜ de pacotes devem estar em Os requisitos para avaliaçao ˜ como um n´ıvel de detalhe suficiente para suportar decisoes essas. ˜ de obra 3.11 Potencial de rotatividade de mao ˜ de obra e´ um grande desafio para a Rotatividade de mao ˜ do conhecimento nas empresas. Sempre que uma gestao

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificaçao — 7/7 pessoa da equipe sai, algum conhecimento se perde, em ˜ de requisitos tornamaior ou menor grau. A documentaçao ˜ uma ferramenta importante para a retençao ˜ desse se entao conhecimento. Considerando que ha´ empresas que vivenciam a rotatividade de pessoal com mais intensidade que outras, cabe ao ˆ gerente de projetos em ultima instancia avaliar a probabili´ dade deste risco de perda ou troca de pessoal na equipe do ´ do lado do cliente, para definir um n´ıvel projeto e tambem ˜ que consiga ajudar a mitigar de detalhe na documentaçao este risco. Como regra geral, maior rotatividade de pessoal, maior detalhamento. Menos rotatividade, menos necessidade de detalhes.

˜ 4. Conclusao Antes de definir qual o n´ıvel de detalhe em que a ˜ de requisitos deve ser elaborada, deve-se: especificac¸ao •

Definir com clareza o ambiente em que ela estara´ inserida;

•

Avaliar os riscos conforme o elenco apresentado neste texto e outros particulares que se identificar;

•

˜ Decidir por quais tipos de informac¸ao devem estar presentes naquela ˜ especificac¸ao.

´ ˜ Esta e´ uma atividade valida para definir pol´ıticas de gestao ˜ como um todo. Caso de requisitos para a organizac¸ao ˜ tenha acontecido nesse n´ıvel ou nao ˜ haja disela nao pon´ıveis registros de seus resultados, o assunto deve ser pensado no n´ıvel do projeto considerando os marcos em ˜ sobre os requisitos sao ˜ necessarias ´ que as informac¸oes e ´ os propositos associados em cada um desses marcos.

ˆ ´ 5. Referencias Bibliograficas [Agile Manifesto, 2001]. http://agilemanifesto.org/

Agile

Manifesto.

[Boehm, 2000] Boehm, Barry et al (2000). “Software Cost Estimation With COCOMO II”, Prentice Hall, 2000. [Dubey, 2009] Sanjiva Shankar Dubey (2009). IT Strategy And Manage- ment. Editora PHI Learning Pvt. Ltd [PMI, 2013] PMI - Project Management Institute (2013). A Guide to the Project Management Body of Knowledge ˜ (PMBOK R Guide). 5a. Edic¸ao. [SEI,2010] Software Engineering Process Management Program(2010). CMMI for Acquisition, Version 1.3, 2010 ´ do Tribunal de Contas da Uniao ˜ (2013), [TCU,2013] Plenario ´ ao ˜ No 2314/2013 – TCU – Plenario”. ´ ”Acord [Wiegers, 2006]. Wiegers, Karl E. More About Software Requirements: Thorny Issues and Practical Advice.

c FATTO Consultoria e Sistemas - www.fattocs.com Cópia licenciada para: issuu Proibida a reproduça˜ o total ou parcial sem a permissão dos autores por escrito.