---

Análise de requerimento de software

Na engenharia de sistemas e engenharia de software , análise de requerimento engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requerimento é uma parte importante do processo de projeto de sistemas , na qual o engenheiro de requerimento e o analista de negócio , juntamente com engenheiro de sistema ou desenvolvedor de software ,
identificam as necessidades ou requerimentos de um cliente. Uma vez que
os requerimentos do sistema tenha sido identificados, os projetistas de
sistemas estarão preparados para projetar a solução.

Outras denominações

A análise de requerimento é também conhecida por outros nomes:

Engenharia requerimento

Levantamento de requerimento

Captura de requerimento

Análise de sistema

Especificação de requerimento

Principais Atividades

Conceitualmente, a análise de requerimento inclui três tipos de atividades:

Elicitação dos requisitos: é a tarefa de comunicar-se com os usuários e clientes pra determinar quais são os requisitos.

Análise de requerimento: determina se o estado do requerimento é obscuro, incompleto, ambíguo , ou contraditório e resolve estes problemas.

Registros dos requerimentos: os requerimentos devem ser
documentados de várias formas, tais como documentos de linguagem
natural, casos de uso , ou processo de especificação.

Processo

Análise de requerimento pode ser um processo longo e árduo. Novos
sistemas mudam o ambiente e a relação entre as pessoas, então é
importante identificar todos os envolvidos, levando em conta todas as
suas necessidades e assegurando que eles compreenderam as implicações
dos novos sistemas. Os analistas
podem empregar várias técnicas para elicitar os requerimentos dos
clientes. Historicamente, isto envolve coisas tais como organizar entrevistas ou grupos focais ( workshops ) e a criação de lista de requerimentos. Técnicas mais modernas incluem prototipação , e casos de uso , onde o analista irá aplicar uma combinação de métodos para estabelecer os requerimentos exatos de seus stakeholders , tal que um sistema que atenda as necessidades do negócio seja produzido.

Principais técnicas

Entrevistas com stakeholder

Entrevistas com stakeholder
é um método comumente usado na análise de requerimento. Algumas
decisões são usualmente necessárias, o custo inicial é um fator na
decisão de quem será entrevistado .
Estas entrevistas devem revelar requerimentos ainda não precisamente
delineados de acordo com o escopo do projeto, e requerimentos possam
ser contraditórios.

Workshops de requerimento

Em alguns casos pode ser útil reunir os stakeholders em workshop de requerimentos.
Estes workshops são mais propriamente denominados como seção de
Desenvolvimento Requerimento Conjunta, onde os requerimentos são
identificados conjuntamente e definidos pelos stakeholders.

Pode ser útil realizar tais workshops fora em ambientes controlados, tais que os stakeholders
não sejam distraídos. Um facilitador que pode ser usado pra manter o
processo focado e beneficiar esta sessão seria o fato de haver um redator dedicado a documentar a discussão. Facilitadores
devem fazer uso de um projetor e diagramas de software ou devem usar um
suporte tão simples como papel e marcadores. Uma regra para os
facilitadores deve assegurar que o peso associado ao requerimentos
propostos não deve demasiadamente dependente da personalidades daqueles
envolvidos no processo.

Lista de requerimento no estilo de contrato

Uma forma tradicional de documentar requerimentos é a utilização de lista de requerimento no estilo de contrato . Em sistemas complexos tais listas de requerimentos podem chegar a centenas de páginas.

Objetivos Mensuráveis

As melhores práticas consideram as listas de requerimentos compostas
como meras dicas e respostas, até que o real propósito do negócio seja
descoberto. Então os stakeholders e desenvolvedores poderão planejar
testes para medir em qual nível cada objetivo será atingido. Estes
objetivos mudam mais lentamente do que a longa lista de especificação
de requerimentos não mensuráveis. Uma vez que este pequeno grupo de
objetivos críticos e mensuráveis for estabelecido, prototipação rápida
e fases de desenvolvimento interativas e rápidas convergirão para
atendimento dos fundamentais objetivos dos stakeholder antes que tenha
decorrido metade do projeto.

Protótipos

Artigo Principal: Prototipação

Em meados dos anos 80, prototipação surgiu como a solução
para o problema da análise de requerimentos. Prototipação é uma
simulação das telas de uma aplicação a qual permite ao usuário
visualizar a aplicação
que ainda não foi produzida. Protótipos ajudam o usuário a ter uma
idéia de como o sistema irá parecer, e facilita a tomada de decisãoes
no projeto sem esperar que o sistema seja construído. Melhorias na
comunicação entre o usuário e desenvolvedores são freqüentemente vistas
com a implantação da prototipação. A visualização antecipada das telas leva a poucas mudanças posteriores e, por conseguinte reduz o custo total consideravelmente.

Contudo, no decorrer da década seguinte, embora provasse ser uma
técnica útil, ela não resolvia estes problemas dos requerimentos:

Gerente uma vez que o protótipo fique pronto gasta um grande tempo
para entender que o projeto final não irá ser produzido ao mesmo tempo.

Projetistas freqüentemente sentem-se compelidos a usar o atalho de
utilizar o protótipo no sistema real, porque eles têm medo do `grande
tempo` para iniciar de novo.

Projetistas e usuários finais podem focar-se demais no projeto da
interface e pouco na produção de um sistema que atenda as necessidades
do processo de negócio.

Protótipos podem ser exibidos em diagramas (denominados como wireframes ) ou utilizando aplicações que sintetizem as funcionalidades. Wireframes
são exibidos em documentos com várias apresentações gráficas, e
freqüentemente removem-se as cores do projeto gráfico (isto é, usa-se
uma paleta de tons de cinza) em casos onde existe uma expectativa a respeito do projeto gráfico do software final. Isto ajuda a prevenir a confusão a respeito da experiência final a respeito da aparência da aplicação.

Casos de Uso

Artigo Principal: Caso de uso

Um ` Caso de Uso` é uma técnica para capturar os requerimentos
em potencial de um novo sistema ou manutenção de software. Cada caso de
uso prove um ou mais cenários
de indicam como o sistema deve interagir com o usuário final ou outro
sistema para atingir um objetivo de negócio específico. Casos de uso
tipicamente evitam o jargão técnico, preferindo ao invés disto a
linguagem do usuário final ou de um expert no domínio . Os casos de uso são freqüentemente de co-autoria dos desenvolvedores de software e usuários.

Casos de usos são ferramentas enganosamente simples para descrever o
comportamento de um software. Um caso de uso deve conter uma descrição
textual de todos os passos que o usuário futuramente poderá vir a
utilizar no software através de sua interface .
Casos de uso não descrevem nenhum comportamento interno do software,
nem fazem explanações de como o software será implementado. Eles
simplesmente mostram os passos que o usuário deve seguir para usar o
software no seu trabalho. Todas as formas com que o usuário irá
interagir com o software deverão ser descritas por este meio.

Problemas

Problemas com Stakeholder

Alguns dos problemas que podem inibir a obtenção dos requerimentos:

Usuários não sabem o que eles querem.

Usuários que não querem concluir a escrita do conjunto de requerimentos.

Comunicação com o usuário é lenta

Os usuários freqüentemente não participam nas revisões ou são incapazes de fazer isto.

Os usuários são tecnicamente poucos sofisticados.

Os usuários não entendem do desenvolvimento de processo.

Isto deve levar a situações onde os requerimentos do usuário
continuam mudando mesmo quando o desenvolvimento do sistema ou produto
já se iniciou.

Problemas de Engenheiros/Desenvolvedores

Possíveis problemas causados por engenheiros e desenvolvedores durante a análise dos requerimentos são:

Pessoal técnico e usuários finais têm vocabulários diferentes.
Conseqüentemente, eles podem acreditar que estão em perfeito acordo até
que o produto final seja entregue.

Engenheiros e desenvolvedores tentam ajustar os requerimentos para
um sistema existente ou modelo, em vez de desenvolver um sistema
específico que atenda as necessidades do cliente.

A análise é freqüentemente conduzida por engenheiros ou
programadores, ao invés de pessoal com habilidade e domínio do
conhecimento para compreender as necessidades dos clientes.

Tentativas de solução

Uma tentativa para solucionar os problemas de comunicação vem sendo
o emprego de especialistas em negócios ou analistas de sistema.

As técnicas introduzidas em 1990 como Prototipação , UML , Casos de Uso , e Desenvolvimento ágil de software foram também introduzidas como soluções para os problemas apresentados.

Também surgiu no mercado uma nova classe de ferramentas de simulação
de aplicação ou definição de aplicação. Esta ferramentas foram
projetadas como uma ponte para transpor a lacuna de comunicação
existente entre o usuário e a equipe de TI
– e também permitir que aplicações tenham `testes de mercado` antes que
qualquer código seja produzido. O melhor que estas ferramentas tem a
oferecer é:

Quadro eletrônico para marcar o fluxo das aplicações e testar alternativas.

habilidade de capturar a lógica do negócio e informações necessárias.

interatividade

capacidade de adicionar requerimentos contextuais e outros comentários.

habilidade para uso remoto e distribuído para permitir o uso e interação como as simulações

Ver também

Reengenharia

Analise de sistema

Analise de negócio

Caso de uso

Arquitetura de processo

Modelagem de processo

Modelagem de dados

Requerimento funcional

Requerimento não-funcional