A Gestão de Requisitos


 

Conhecer e dominar uma linguagem de programação é bom mas não é tudo. Para criar sistemas robustos e que com qualidade é preciso mais do que uma boa linguagem e um bom programador.

 

A princípio todo o sistema tem um objetivo e uma necessidade de criação. Não se cria um sistema que não tem utilidade e que ninguém vai usar , não é mesmo. Assim, um sistema deve ser criado para atender as expectativas de um cliente.

 

A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um sistema de software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e restrições e a especificação precisa do software

 

A maior parte dos problemas no desenvolvimento de software são originados nas etapas iniciais do desenvolvimento justamente na etapa de levantamento e definição dos requisitos do sistema onde as principais atividades são :  elicitação, análise, especificação, gerenciamento e validação de requisitos.

 

Havendo falhas na realização das atividades acima citadas haverá inconsistência nos documentos de requisitos e o que acarretará um software de baixa qualidade com um custo elevado.

 

Mas o que é um requisito de software ?

Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário, e, em geral independem da tecnologia empregada na construção da solução sendo a parte mais crítica e propensa a erros no desenvolvimento de software.

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Os requisitos  de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessárias que o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais.

Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software faça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.

São exemplos de requisitos funcionais:

A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem.

Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente que segurança mas os usuários querem facilidade de uso) e são difíceis de validar.

São exemplos de requisitos não-funcionais:

A necessidade de se estabelecer os requisitos de maneira de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros. Por exemplo, o requisito de que o software de ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos).

Uma boa especificação de requisitos deve ser:

De acordo com Farley, um documento de especificação de requisitos deve possui as seguintes seções:

Construir um sistema de software com base em requisitos inconsistentes e mal definidos é como construir uma casa sem alicerce na areia...

Até o próximo artigo...

Referências :

http://www.dimap.ufrn.br/~jair/ES/es99c3.html - Jair C Leite, 1999


José Carlos Macoratti