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

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

© FATTO Consultoria e Sistemas - www.fattocs.com

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

˜ e´ a que N´ıvel de detalhe: A melhor especificac¸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 especificac¸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 implementac¸ao. ˜ Este documento caracteriza o que seja n´ıvel de detalhe para requisitos decisoes ˜ de requisitos, apresenta uma serie ´ uma especificac¸ao de fatores de riscos que promovem um maior ou menor n´ıvel de ˜ do n´ıvel de detalhe que melhor alinha a especificac¸ao ˜ detalhe e explica como utilizar esses fatores de risco na avaliac¸ao ´ aos seus propositos.

Keywords ˜ de requisitos; gestao ˜ do conhecimento; elicitac¸ao ˜ de requisitos; analise ´ ˜ de requisiespecificac¸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

2

Equivoco comum

3

´ 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

4

˜ Conclusao

7

5

ˆ ´ Referencias Bibliograficas

7

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 especificac¸ao ´ escopo relacionando os processos de negocio impactados ˜ e o seu posicionamento no ambiente indicando pela soluc¸ao ˜ de requisitos e´ o que sera´ externo a ela. A especificac¸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 soluc¸ao ˜ especificamente inclu´ıdas parcialmente ou em dos - serao ˜ Imagine que a soluc¸ao ˜ sua totalidade no escopo da soluc¸ao. ˜ urbana de determinadas localiseja reformular a sinalizac¸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 especificac¸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 especificac¸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 reformulac¸ao ˜ urbana); contudo, sem explicar do que se espera sinalizac¸ao ˜ no que se refere a uma atividade em particular da soluc¸ao (ou o que deve ser feito em um trecho de rua em particular).

Figura 1. Vis˜ao da regi˜ao metropolitana de S˜ao Paulo (Google Maps). ˜ urbana, uma serie ´ ˜ ˜ tomadas sinalizac¸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 informac¸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 restric¸oes ˜ em que o comportamento da soluc¸ao que ˜ descritos para cada tarefa individualmente. se aplicam estao ˜ pode variar desde o ponto Nesse sentido, a especificac¸ao ˜ ha´ nada descrito (apenas se sabe o que faz em que nao ˜ completa com todos parte do escopo), ate´ uma descric¸ao ˜ do usuario ´ os passos que descrevem a interac¸ao com a ˜ o armazenamento e recuperac¸ao ˜ de dados; as soluc¸ao; ˜ que se aplicam. regras e restric¸oes ˜ refere-se a` explorar a N´ıvel de detalhe nesta acepc¸ao ˜ e as restric¸oes ˜ ˆ soluc¸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 especificac¸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 soluc¸ao. ˜ com o uso dos mapas, decidemConcluindo a comparac¸ao ˜ Em se se quais trechos de rua devem sofrer intervenc¸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 transic¸ao ˜ para outro abrangencia da soluc¸ao. ´ tipo de n´ıvel de detalhe, e´ melhor usar uma outra metafora. ˜ do lago (figura 3). Ela permite deObserve a ilustrac¸ao

Figura 4. Vis˜ao tamb´em 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` soluc¸ao, ˜ que da´ em func¸ao ˜ sobre a consolidac¸ao ˜ espac¸o ainda para diversas decisoes ˜ afetadas pela soluc¸ao ˜ desse escopo (quais tarefas serao ˜ de cada informatizada, por exemplo) e sobre a descric¸ao item nesse escopo (qual o comportamento que se espera ˜ ao interagir com seus usuarios, ´ da soluc¸ao por exemplo). A ˆ ˜ e´ representada na figura 5. dinamica desta evoluc¸ao

c FATTO Consultoria e Sistemas - www.fattocs.com C´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao dos autores por escrito.

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

Figura 5. Evoluc¸a˜ o dos n´ıveis de detalhe conforme evolui o desenvolvimento dos requisitos. ˜ 1.3 Mapear os requisitos no design ou implementac¸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 implementac¸ao ˜ deve ser evitado. Fazer isso significa sair do programac¸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 especificac¸ao entre cliente e desenvolvedores e o n´ıvel de detalhe deve ˜ e ser aquele que melhor consiga promover a comunicac¸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´ opc¸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´ ˜ acontec¸a baseada somente em poss´ıvel que a transac¸ao ˜ deixa de ser um contrato). O um acordo verbal (que nao ˜ valor do item e´ o mesmo nas duas situac¸oes.

Sendo relacionamentos pessoais, o que determina o maior ou menor detalhamento do contrato e´ o grau de confianc¸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 confianc¸a e desconfianc¸a. Ima˜ de contas de um executivo ao conselho gine a prestac¸ao ˜ sobre o fracasso de um projeto apresende administrac¸ao ˜ que a empresa contratada traiu sua tando como explicac¸ao confianc¸a.

Nesse paralelo feito entre os contratos por indiv´ıduos e os ˜ contratos no plano de corporac¸oes, confianc¸a surge como ˜ de risco. Logo, quanto menor o risco uma representac¸ao ˜ entre cliente e desenvolvedores, menor avaliado na relac¸ao ˜ de requia necessidade de detalhamento da especificac¸ao ˜ entre as sitos. Quanto maior o risco avaliado na relac¸ao partes, maior a necessidade de detalhamento. ´ ˜ com o cliente mais O Manifesto Agil prega: “Colaborac¸ao ˜ de contratos” e no seu Princ´ıpio 4: “Pessoas que negociac¸ao ´ de negocio e desenvolvedores devem trabalhar diariamente ˜ em conjunto por todo o projeto.“ [Agile Manifesto, 2001]. Sao ˜ de confianc¸a entre diretrizes que favorecem a construc¸ao as partes, e com isso reduz a necessidade de detalhamento ˜ da especificac¸ao.

Um documento que melhor permite depreender a imˆ ˜ de confianc¸a em um plano pessoal portancia da traduc¸ao ˆ ˆ para riscos em ambiente com exigencias de transparencia ´ ao ˜ No 2314/2013 do e governanc¸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 exemmaterializac¸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 envolespecificac¸ao vidos nisso. Detalhar desnecessariamente significa desˆ perd´ıcio de recursos no projeto. Ausencia de detalhes pode ˜ de atividades seguintes do projeto, significar interrupc¸ao ˜ de erros por falta de informac¸ao, ˜ enfim, retrabaintroduc¸ao lho.

c FATTO Consultoria e Sistemas - www.fattocs.com C´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao 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 contratac¸ao servic¸os no mercado (desenvolvimento externo). ˜ haja uma definic¸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

Soluc¸a˜ o n˜ao adotar´a 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 relac¸ao Alem trabalham muitas vezes no mesmo espac¸o f´ısico, o que facilita o encontro e diminui a necessidade de formalismo ˜ ˜ face a face e´ mais facil ´ nas interac¸oes.

Ou seja, a interac¸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 ´India com sua presenc¸a forte em ´ servic¸os de outsourcing e´ o exemplo classico).

Com me˜ face a face, e´ necessario ´ nos possibilidade de interac¸ao mais detalhamento dos requisitos para minimizar eventuais ˜ problemas de comunicac¸ao.

3.2 Equipe dispersa ou agrupada geograficamente ˜ com o anterior. So´ que De certa forma este item tem relac¸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 formac¸ao ˜ em potencial. as pessoas e uma barreira de comunicac¸ao O [PMI, 2013] apresenta o agrupamento dos membros da ´ equipe num mesmo espac¸o f´ısico como uma estrategia de ˜ como equipe. aprimoramento de sua capacidade de atuac¸ao ˜ face a face, que dispensa Isso promove a comunicac¸ao ˜ Em caso de duvida, tanto detalhamento na especificac¸ao. ´ basta perguntar ao colega do lado. [Agile Manifesto, 2001] ´ reforc¸a isso no seu princ´ıpio 06: “O metodo ´ tambem mais ˜ para e entre uma eficiente e eficaz de transmitir informac¸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 especificac¸ao ´ a estrategia adotada no desenvolvimento do projeto. Ha´ ´ ˜ ja´ estao ˜ definidos e casos onde os criterios de aceitac¸ao ˜ orientar os testes. Neste caso, o trabalho de requisitos vao ˜ ´ e´ que usa estas informac¸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 elaborac¸ao Nestes casos tanto o analista de testes quanto o analista ˜ usando a mesma fonte de informac¸ao; ˜ de requisitos estao so´ que, enquanto o primeiro elabora os casos de testes,

c FATTO Consultoria e Sistemas - www.fattocs.com C´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificac¸ao — 5/7 ˜ de requisitos. Nao ˜ ha´ o segundo elabora a especificac¸ao ˆ ordem de precedencia entre os dois trabalhos. ˜ de requisitos e´ materia ´ Quando a especificac¸ao prima para a equipe de testes elaborar seus casos de testes e depois ´ executa-los, certamente ha´ mais necessidade de detalhes ˜ A elaborac¸ao ˜ dos casos de testes a parna especificac¸ao. ˜ e´ uma ferramenta muito poderosa de tir da especificac¸ao ˜ de requisitos, ajudando a melhorar a sua qualiverificac¸ao dade.

Os autores ja´ presenciaram o desenvolvimento do software ˜ de suas especificac¸oes ˜ de requidescolado da elaborac¸ao ´ aos ˜ do governo. Enquanto o fornecedor mobilisitos em org ˜ (em tese, a zava uma equipe para produzir documentac¸ao ˜ de requisitos) para atender as ` exigencias ˆ especificac¸ao de entrega do contrato, outros desenvolvedores concomitante´ mente atuavam diretamente com os usuarios para obter as ˜ para a construc¸ao ˜ do software. informac¸oes ˜ produzida nao ˜ agregava valor Neste caso, a documentac¸ao ´ da conformidade as ` exigencias ˆ algum alem do contrato. O ˜ era meramente burocratico ´ trabalho em sua elaborac¸ao por˜ necessariamente ha´ nexo entre as especificac¸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 definic¸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` relac¸ao pendentes e que ja´ foram tomadas; estabilidade refere-se a` probabilidade de mudanc¸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 espac¸o para uma especificac¸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 declarac¸ao No entanto se ha´ a necessidade de se obter uma estimaˆ ˜ tiva definitiva, havera´ a exigencia de mais informac¸oes e ˜ de requisitos. detalhes na especificac¸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 certificac¸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 relac¸ao ˜ uma consequencia natural e´ a construc¸ao de confianc¸a mais forte com a equipe de desenvolvimento. ´ a comunicac¸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 especificac¸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 soluc¸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 posic¸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, telecomunicac¸oes, energia. Isto ´ favorece que mantenham uma equipe com extambem ˆ ´ ˜ com os periencia no negocio, facilitando a comunicac¸ao clientes. ´ Ha´ tambem fornecedores que atuam sem tanta ˜ especializac¸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 comunicac¸ao ´ ˜ eficaz. Ainda assim, sera´ necessaria uma especificac¸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 aplicac¸ao tem efeitos multiplicativos na produtividade que pode impli˜ na produtividade em 22% ao seu car desde uma reduc¸ao ˜ a` uma experiencia ˆ aumento em 19% em relac¸ao de um ano ˜ Ainda que o estudo nao ˜ entre no merito ´ com a aplicac¸ao. ˜ pode-se atribuir das causas subjacentes dessa constatac¸ao, esses ganhos de produtividade a` maior agilidade associada ˜ dos requisitos. ao desenvolvimento e gestao ˆ 3.8 Experiencia trabalhando com software afim ˜ Nas situac¸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 informac¸ao Exemplos:

c FATTO Consultoria e Sistemas - www.fattocs.com C´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao 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.

•

˜ Manutenc¸oes similares em sistemas distintos: Um caso e´ de um projeto para adequar o sistema de Poupanc¸a de um ˜ do Banco banco para uma determinac¸ao ´ ja´ se sabe que a mesma Central, porem ˜ ja´ foi feita para o sistema de manutenc¸ao Contas Correntes. Assim, muitas das de˜ adotadas na primeira manutenc¸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 solicitac¸oes ˜ ha´ ainda um de mudanc¸a em requisitos. Isso porque nao ´ ˜ ainda nao ˜ processo de negocio definido ou a sua definic¸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 especificac¸ao ˜ detalhada sera´ um desafio. Manter essa documentac¸ao ´ cada mudanc¸a implica lhada atualizada e consistente apos ˜ cabe a pergunta: Para que detalhar em retrabalho. Entao, ´ que sofrera´ mudanc¸as pouco depois? Se algo ainda volatil ˜ houver razao ˜ forte o suficiente para isso, busque uma nao ˜ menos detalhada. especificac¸ao Figura 7. Tipos de ac¸a˜ o relacionados a` adequac¸a˜ o do ˜ usara´ pacote 3.10 Soluc¸ao ˜ Se o projeto tem por objetivo oferecer como parte da soluc¸ao ˜ de um pacote de software dispon´ıvel no mercado a adoc¸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 avaliac¸ao. ˜ documentac¸ao ˜ de um pacote deOs requisitos referentes a` avaliac¸ao ˜ do pavem permitir avaliar as necessidade de adequac¸ao ` necessidades do cliente e o grau de manutenc¸ao ˜ cote as que o mesmo deve sofrer [SEI:2010]. A figura 6 ilustra a ˜ entre os requisitos do produto e do negocio ´ comparac¸ao ˜ entre os dois conjuntos. indicando a intercessao ´ Quanto a` lacuna existentes entre os requisitos do negocio ˜ e do pacote, ha´ diferentes soluc¸oes que podem mudar a ˜ para se adequar as ` melhores praticas ´ organizac¸ao presentes no pacote e fazer com que o pacote se adeque ˜ Para este ultimo a` organizac¸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 •

˜ ˜ Customizac¸ao: Sao mudanc¸as em ´ codigo para adequar funcionalidade ˜ esta´ dispon´ıvel por meio de que nao ˜ configurac¸ao.

•

˜ ˜ na base instalada: Sao Manutenc¸ao ˜ nos sistemas existentes para adaptac¸oes ˆ acomodar o intercambio de dados com o ˜ pacote em avaliac¸ao.

[Dubey:2009] recomenda que cerca de 80% da funcionalidade do pacote devem estar aderente aos procedimentos ˜ ou pela sua adequac¸ao ˜ operacionais atuais na organizac¸ao ` melhores praticas ´ ´ coas embarcadas no software. Tambem ˜ mais que 15% sejam objeto de customizac¸ao. ˜ loca que nao ˜ de pacotes devem estar em Os requisitos para avaliac¸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´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao dos autores por escrito.

˜ e´ a que atende aos seus propositos ´ N´ıvel de detalhe: A melhor especificac¸ao — 7/7 pessoa da equipe sai, algum conhecimento se perde, em ˜ de requisitos tornamaior ou menor grau. A documentac¸ao ˜ uma ferramenta importante para a retenc¸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 documentac¸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´opia licenciada para: issuu Proibida a reproduc¸a˜ o total ou parcial sem a permiss˜ao dos autores por escrito.