Você está na página 1de 3

O artigo trata de metodologia direcionada a requisitos de desenvolvimento de

software para pequenas empresas. A engenharia de requisitos oferece


ferramentas que sejam possveis documentar as necessidades do cliente,
negociar solues e descrever de forma clara o que o cliente espera da empresa.
Esse processo de documentar os requisitos pode ser dividido em 5 etapas.
Levantamento (ou elicitao) de requisitos, que envolve a coleta de informaes
do negcio.
Anlise e negociao dos requisitos, para que seja possvel estabelecer prazos,
catalogar e classificar requisitos. Especificao de metas, e restries que iro
servir de base para o processo de desenvolvimento do software. Verificao dos
requisitos, verificar se os requisitos no foram declarados de forma ambgua, e
focado nas necessidades do cliente. Gesto dos requisitos que ir controlar,
identificar, e rastrear as modificaes dos requisitos a qualquer momento do ciclo
de vida do software.
A Fase crtica de um desenvolvimento de software quando verificado a
engenharia de requisitos, normalmente nessa fase so apontados vrios defeitos
identificados no software, o que faz com que seu custo aumente at 100 vezes
da implementao at a entrega final para o cliente. Os principais problemas
identificados no comeo so: problemas de escopo, problemas de entendimento,
problemas de instabilidade, problemas de rastreamento. Esses problemas
poderiam ser resolvidos de forma simples se a empresa implementasse a
engenharia de requisitos. Possibilitaria ento a delimitao clara do escopo,
compreenso dos requisitos, rastreamento dos requisitos, estabelecimento de
relaes de dependncias, mtodo quantitativo dos requisitos, validao dos
requisitos.
A metodologia descrita no artigo tido como objeto de estudo trata de uma
simplificao do processo de engenharia de requisitos, o que facilita o seu uso
por pequenas equipes, levando em considerao algumas diretrizes da
programao como pequenas liberaes, alta disponibilidade do cliente,
planejamento das liberaes em conjunto do mesmo. Essas premissas tm por
objetivo reduzir o volume de documentao ao mnimo necessrio a um bom
entendimento dos requisitos do sistema.
Determinao do objetivo do sistema: serve para alinhar o objetivo do negcio
com o propsito do sistema, alinha as necessidades do cliente. Deve ser descrito
de forma sucinta e clara.
Elicitao dos requisitos do negcio: os requisitos do negcio determinam as
necessidades de informao do cliente, em relao ao produto, neste caso o
software a ser desenvolvido. O desenvolvedor deve ater-se as necessidades do
sistema com o foco voltado aos objetivos do negcio.
Determinao dos requisitos de software: os requisitos de software especificam
as funcionalidades e demais caractersticas que o software dever desempenhar
para atender os requisitos de negcio.

Classificao dos requisitos do negcio: nessa atividade os requisitos so


classificados de acordo com sua importncia para o usurio. Concentra-se nos
benefcios que o software trar com sua implementao. A metodologia para a
classificao dos requisitos baseia-se num diagrama utilizado pela primeira vez
pela General Eletric, em 40. Esse mtodo era utilizado por uma avaliao
numrica funcional, conhecida como Diagrama de Mudge, que determina uma
hierarquia entre as funes. Esse Diagrama preenchido atravs de uma Matriz
de Mudge preenchida com os requisitos de negcio.
Aps associar os pesos dos requisitos hora de realizar uma classificao, e
calcula-se o percentual de importncia de cada um.

Montagem de matriz de dependncia dos requisitos:


Permite o rastreamento de cada um dos requisitos em relao aos requisitos de
negcio e vice-versa. A matriz montada, primeiramente com os requisitos do
negcio, e em seguida os requisitos funcionais.

Planejamento das liberaes:


A partir da Matriz de Mudge e da matriz de dependncia possvel determinar
um planejamento de liberaes, analisando os dados, pode-se determinar
algumas estratgias mais viveis: implementar os trs requisitos de negcio em
uma nica liberao; implementar requisitos RN01 e RN02, que so os mais
importantes, segundo a matriz de Mudge, na primeira liberao e o requisito
RN03, em uma segunda liberao; implementar cada requisito em uma liberao
separada, iniciando-se pelo requisito RN03.
Especificao dos requisitos: comea com um diagrama de contexto,
contendo uso de sistema. Um caso de uso modela uma interao completa entre
um ator e o sistema. Deve-se tomar cuidado para detalhar excessivamente, pois
aumenta o gasto de tempo na modelagem, sem gerar contribuio para a
qualidade do produto final. Deve ser desprovida de termos tcnicos, evitando
termos que o usurio no se sente familiarizado. Na metodologia proposta, casos
de uso devem ser descritos em conjunto com o cliente e de maneira simplificada.
Em boa parte dos casos de uso, apenas uma descrio sucinta basta para o
caso de uso.

Modelo de classes conceitual


O modelo conceitual uma descrio de coisas do mundo real que fazem parte
do domnio do problema, ele no descreve artefatos de software, tais como
janelas ou banco de dados. A utilidade desse modelo fazer com que o
alinhamento de informaes com o cliente fique claro, e que no haja dvidas no
entendimento.

Validao dos requisitos


Por fim a validao dos requisitos serve para corrigir os erros da fase de
requisitos. O processo de validao dos requisitos visa assegurar que os
requisitos sejam consistentes e completos em relao ao objetivo do sistema. A
matriz permite verificar se os requisitos esto sendo atendidos. O importante
nesta fase realizar testes sejam em planilhas eletrnicas ou papel.

Concluso
Levando em considerao o uso dessa metodologia para auxiliar o
desenvolvimento de pequenas equipes, ela possibilita que sejam desenhados os
requisitos de cada etapa, proporcionando uma clareza nas informaes e nas
reais necessidades do cliente.

Você também pode gostar