|
Análise de requisitos de software
Na sistematização e engenharia de software, análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte importante do processo de desenvolvimento de softwares, na qual o engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas estarão preparados para projetar a solução. A análise de requisitos é uma das primeiras atividades de desenvolvimento de software. O produto do seu trabalho é a especificação de requisitos, que é define o escopo do software em duas dimensões: Requisito funcional e Requisito não-funcional[1]. É nesta fase que o analista faz as primeiras reuniões com os clientes e/ou usuários do software para conhecer as funcionalidades do sistema que será desenvolvido. É nesta fase também que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ou usuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o software terá. As entrevistas estruturadas são um método utilizado para esta fase e que poderão ter um papel importante na ajuda à compreensão de todas as funcionalidades pretendidas pelo cliente. Outras denominaçõesA análise de requisitos é também conhecida por outros nomes:
Principais AtividadesConceitualmente, a análise de requisitos inclui três tipos de atividades:
ProcessoAnálise de requisitos 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 requisitos dos clientes. Historicamente, isto envolve coisas tais como organizar entrevistas ou grupos focais (workshops) e a criação de lista de requisitos. 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 requisitos exatos de seus stakeholders, tal que um sistema que atenda as necessidades do negócio seja produzido. Principais técnicasEntrevistas com stakeholderEntrevistas com stakeholder é um método comumente usado na análise de requisitos. Algumas decisões são usualmente necessárias, o custo inicial é um fator na decisão de quem será entrevistado. Estas entrevistas devem revelar requisitos ainda não precisamente delineados de acordo com o escopo do projeto, e requisitos que possam ser contraditórios. Workshops de requisitosEm alguns casos pode ser útil reunir os stakeholders em workshop de requisitos. Estes workshops são mais propriamente denominados como seção de Desenvolvimento de Requisitos Conjunta, onde os requisitos 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 para 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 requisitos propostos não deve ser demasiadamente dependente das personalidades daqueles envolvidos no processo! Lista de requisitos no estilo de contratoUma forma tradicional de documentar requisitos é a utilização de lista de requisitos no estilo de contrato. Em sistemas complexos tais listas de requisitos podem chegar a centenas de páginas. Objetivos MensuráveisAs melhores práticas consideram as listas de requisitos 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 requisitos 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 Ver artigo principal: PrototipaçãoEm meados dos anos 80, prototipação surgiu como a solução para o problema da análise de requisitos. 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 ideia de como o sistema irá parecer, e facilita a tomada de decisões no projeto sem esperar que o sistema seja construído. Melhorias na comunicação entre o usuário e desenvolvedores são frequentemente 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 requisitos:
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 frequentemente 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
Um 'Caso de Uso' é uma técnica para capturar os requisitos funcionais de um novo sistema ou manutenção de software. Cada caso de uso provê um ou mais cenários que 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 frequentemente de coautoria 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. ProblemasProblemas com StakeholderAlguns dos problemas que podem inibir a obtenção dos requisitos:
Isto deve levar a situações onde os requisitos do usuário continuam mudando mesmo quando o desenvolvimento do sistema ou produto já se iniciou. Problemas de Engenheiros/DesenvolvedoresPossíveis problemas causados por engenheiros e desenvolvedores durante a análise dos requisitos são:
Tentativas de soluçãoUma 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. Estas 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 é:
Ver também
Referências
Ligações externas
|
||||||||||||||||||||||
Portal di Ensiklopedia Dunia
