Requisitos 

Dec/10
19

Muito tempo sem publicar nada e as pessoas come√ßam a pensar o que estarei fazendo e porque n√£o escrevo mais… bom, n√£o √© porque n√£o queira, nem porque falte assunto, √© porque falta tempo. O assunto de hoje me √© muito querido e para quem sabe como gosto de scrum pode parecer at√© meio¬†contradit√≥rio¬†– levantamento de requisitos. ¬†Em scrum ha levantamento de requisitos ? Bom, n√£o especificamente, tal como n√£o ha pr√°ticas de desenvolvimento como repositorio partilhado. Contudo scrum levanta a bandeira da visibilidade bem alto, e requisitos s√£o uma forma de dar visibilidade ao projeto em tempos prim√°rios onde o c√≥digo ainda n√£o √© o artefato principal. Por outro lado, o que √© o Product Backlog sen√£o uma lista de requisitos ?

Se podessemos colocar apenas em uma frase o que nossa profiss√£o significa, seria algo como “Implementados¬†requisitos em c√≥digo”. Muitas escolas existem sobre o comportamento, as funcioanlidades, o codigo, mas poucas sobre requisitos. No seu livro Software Requirements, Karl Wiegers apresenta uma vis√£o, quanto a mim especialmente esclarecedora de como existem diferentes tipos de requisitos, e como eles s√£o influenciados por fatores externos. Al√©m disso estabelece tr√™s marcos essenciais num produto de software: documento de vis√£o, documento de casos de uso, e documento de especifica√ß√£o de software.

requisitosCome√ßamos com a¬†idealiza√ß√£o¬†do software. Isto significa dizer: para que servir√°, porque as pessoas o usaram, porque devemos investir nele, o que o¬†distingue¬†dos outros o que far√° dele um bom produto e o que far√° dele um mau produto. Estes pensamentos s√£o concentrados no documento de vis√£o e s√£o o estabelecimento de porque o software deve existir e qual √© a sua finalidade a curto, m√©dio e longo prazo. √Č um documento nada¬†t√©cnico, muito virado para potenciais utilizadores e investidores. ¬†Este passo √© normalmente esquecido para produtos “pequenos” cuja vida util √© menores que 2 anos, mas √© interessante para produtos de vida m√©dia (2 a 4 anos) e mandat√≥rio para produtos de vida long (5 anos ou mais).

Com base neste documento de vis√£o, que √© bem sucinto e ao ponto, √©¬†poss√≠vel¬†angariar¬†o interesse de utilizadores, ou patronos que estejam dispostos a investir neste produto em nome de outros utilizadores. Aqui a ideia original √© expandida e desenvolvida e¬†evolu√≠da¬†para algo mais pr√≥ximo ao que seria de esperar para algu√©m que utilizasse o software. A divis√£o de atores e o que cada um representa e como cada um¬†interagiria¬†com o software nos d√° mais detalhada informa√ß√£o. Esta informa√ß√£o √© registrada num documento de casos de uso. Tamb√©m neste documento s√£o descritas regras de¬†domino. Regras de¬†domino¬†s√£o regras do¬†√Ęmbito¬†do neg√≥cio em que o software √© usado ou no¬†√Ęmbito¬†do contexto em que √© usado. Estas regras s√£o normalmente gen√©ricas e aplic√°veis a software que ser√£o utilizados nos mesmos ambientes. Estas regras n√£o s√£o escolhas dos usu√°rios mas imposi√ß√Ķes que eles devem seguir ou pretendem que o software as ajude a seguir.

Sabido como o software dever√° interagir com o seu utilizador, √© necess√°rio definir detalhes mais minuciosos. Sabemos o que o software deve fazer e interagir com o¬†usu√°rio, mas n√£o que comportamento deve ter. Ou seja, que tipo de a√ß√Ķes o software tomar√° sozinho, quais ele necessitar√° da ajuda ou suporte do ser humano, se ser√° passivo ou ativo, se ser√° instrutivo. ¬†√Č claro que a forma como ele se ir√° comportar basicamente com base numa abstra√ß√£o como a todas as intera√ß√Ķes descritas nos casos de uso, mas al√©m disso existir√£o atributos de qualidade que tamb√©m afetar√£o o seu comportamento. ¬†Desde propriedades de ergonomia, design, facilidade de uso at√© propriedades como seguran√ßa, confiabilidade , resili√™ncia a falhas,¬†robustez¬† e durabilidade. Estas¬†propriedades¬†¬†desej√°veis pelo usu√°rio se tornaram depois guias fundamentais para a arquitetura final do software. Algumas regras de dominio que n√£o podem ser for√ßadas com base em intera√ß√£o, devem ser for√ßadas com comportamento, como regras de apresenta√ß√£o de informa√ß√£o, formata√ß√£o, internacionaliza√ß√£o, entre outras. Outros fatores que influenciam fortemente o comportamento do software s√£o requisitos de sistema, ou seja, regras que o sistema deve respeitar porque √© um software. Regras relacionadas ao uso de mem√≥ria, processador, placas gr√°ficas, ou ambientes como navegadores e sistemas operacionais. Um software baseado em internet utilizando HTML num browser tem, √† partida, um comportamento diferente de um sistema embarcado ou de um sistema desktop pela natruza do ambiente onde funcionar√°.

Alguns requisitos podem advir do¬†ecossistema¬† onde o software ir√° funcionar, ou com quem ir√° compartilhar informa√ß√Ķes. Documenta√ß√£o das interfaces externas que o software oferece e das que ele necessitam tamb√©m fazem parte do documentos de especifica√ß√£o de software.

Todos os requisitos de comportamento s√£o colocados num documento de especifica√ß√£o de software, juntamente com todos os atributos de qualidades relevantes. Mas nem tudo s√£o rosas. Muitas vezes, para que o software seja¬†poss√≠vel, ¬†funcione, ou at√© para que seja comercialmente interessante ele tem que respeitar um serie de “n√£o pode” conhecidos como¬†constrangimentos. ¬†Podem ser variados, desde tecnologia, a sistema operativos, ou qualquer outro detalhe¬†t√©cnico, a preocupa√ß√Ķes com o gasto de energia, a performance ou mesmo em rela√ß√£o √† apar√™ncia gr√°fica. Todas estas regras s√£o ent√£o compiladas num √ļltimo documento de especifica√ß√£o.

√Č de notar que existem fatores que podem modificar o como um documento de vis√£o √© transformado num documento de casos de uso, e posteriormente numa especifica√ß√£o. Um √ļnico documento de vis√£o, entregue a grupos diferentes de usu√°rios pode promover diferentes intera√ß√Ķes e casos de uso, e um mesmo documento de casos de uso, entregue a grupos diferentes, com constrangimentos diferentes pode , sem d√ļvida , levar a especifica√ß√Ķes diferentes. As possibilidades s√£o inumer√°veis. Ali√°s at√© o mesmo grupo de pessoas, em momentos diferentes do tempo podem obter resultados diferentes pegando a mesma fonte.¬†√Č por isto que em produ√ß√£o de software temos sempre a sensa√ß√£o de estarmos desenvolvendo sempre a mesma coisa, mas ligeiramente diferente.

Pode parecer daqui que o levantamento de requisitos segue uma ordem pr√©-determinada e bem definida. Na realidade n√£o √© bem assim. Ao conversar com um pessoas sobre um software que ela quer, ele ir√° misturar requisi√ß√Ķes de diferentes tipos, graus de¬†import√Ęncia, graus de relev√Ęncia e de especificidade. O papel do Analista √© reconhecer quais s√£o quais e coloc√°-los em seus respectivos “bal√Ķes”. Depois de ter um conjunto suficiente de informa√ß√Ķes contidas nos “bal√Ķes” ser√£o condensadas e depositadas nos¬†respectivos¬†documentos. Portanto, embora exista uma ordem l√≥gica para a leitura destes¬†documentos, na pr√°ticas eles podem, e devem, ser redigidos em paralelo.

O levantamento de requisitos √© ainda mais uma arte que a produ√ß√£o do pr√≥prio software. Pode ser feito por pessoas que n√£o conhecem das tecnologias envolvidas, mas, com certeza, n√£o pode ser feito por pessoas que ignoram as tecnologias envolvidas e/ou que n√£o dominam o plano¬†tecnol√≥gico¬†em causa. N√£o √© miss√£o de quem levanta requisitos impedir os interessados em fazer requisi√ß√Ķes e moldar requisitos mas √© miss√£o de quem levanta requisitos n√£o alimentar falsas expectativas ou fazer promessas de realiza√ß√£o se entendimento e/ou conhecimento da equipe ir√° realizar o software. Sim, eu n√£o acredito nesse neg√≥cio de uma equipe levantar requisitos e outra implementar.

Existem algumas diretrizes para o levantamento de requisitos que acho importantes. Primeiro a quest√£o da comunica√ß√£o. √Č importante que todos tenham bem claro os conceitos e que eles n√£o sejam¬†amb√≠guos. Um¬†gloss√°rio¬†e o uso de uma linguagem de¬†dom√≠nio¬†s√£o ferramentas essenciais. Segundo a aten√ß√£o ao que o cliente est√° tentando expressar e n√£o ao como est√° expressando. Nem todos s√£o¬†ex√≠mios¬†com as palavras ou¬†eloquentes. ¬†Use formas de¬†comunica√ß√£o¬†que sejam¬†adequadas¬†ao requisitante. Terceiro a analise. Levantar requisitos √© um processo¬†anal√≠tico e de alto risco para o projeto. Um levantamento mal feito pode ser desastroso para o resto do projeto. Portanto desconfie sempre que o requisitante usar as palavras “sempre” e “nunca”. Tente explorar cen√°rios alternativos com frase do tipo “E se acontecer ?”. Tenha a certeza que n√£o se est√° enganando a si mesmo por acreditar no requisitante e simplificar. Tente identificar o que s√£o regras e requisitos gerais do tipo de neg√≥cio do¬†requisitante¬†e quais s√£o¬†espec√≠ficos¬†√† forma como ele trabalha e ao seu neg√≥cio. Sempre tente entender o valor de negocio que o requisito tem e como ele, adicionado ao software, tornar√° a vida do requisitante melhor. Para o caso em que o requisitante √© desconhecido ou n√£o existe uma¬†√ļnica¬†pessoa que possas responder pelo processo de analise, utilize grupos de foco.

Levantamento de requisitos √© a tarefa mais importante no desenvolvimento de software. √Č onde existe mais risco de falha e onde se estabelecem os conceitos que ir√£o balizar a implementa√ß√£o.

Muitas pessoas acreditam, hoje em dia, que as metodologias ágeis são contrários ao levantamento de requisitos e/ou que elas ensinam que os requisitos devem ser obtidos on demand ou just-in-time apenas quando são necessários. Nada mais longe da verdade. Todas as metodologias começam com algum tipo de lista de histórias. Estas histórias não nasceram do nada e não nasceram sem um trabalho de analise. A montagem de dita lista ocorre sempre pre-linarmente ao desenvolvimento, mesmo quando ela é alterada durante o desenvolvimento. Scrum, por exemplo, aconselha que se estabeleça um documento de visão e o Product Backlog antes de mais nada. Sendo que os passos seguintes são a estimativa do backlog e o planejamento e só depois a execução.

Espero que as pessoas parem de menosprezar o levantamento de requisitos e o levem a s√©rio. Sen√£o continuaremos a n√£o acertar no que o cliente quer e a produzir software que ser√° abandonado. ¬†Com √Āgil, ou sem √Āgil, o levantamento de requisitos tem que ser feito, e tem que ser bem feito.

Comente

Artigos