12

III. Requisitos so Frases

Entendemos requisitos de software como sentenas que expressam as necessidades dos clientes e
que condicionam a qualidade do software. Em funo disso classificamos requisitos como
requisitos funcionais, requisitos no funcionais e requisitos inversos. O primeiro est diretamente
ligado a funcionalidade do software, enquanto o segundo reflete os requisitos que expressam
restries que o software deve atender ou qualidade especficas que o software deve ter, o terceiro
trata de situaes que no podem ocorrer.
III.I Representao
Requisitos Funcionais
Para os requisitos funcionais existem trs classes de sentenas: entrada, sada e mudana de
estado. Cada requisito tem que seguir uma das duas estruturas abaixo.
O sistema deve + [ verbo + objeto | frase verbal ]
+ [ complemento de agente | null ] + [ condio | null ].
O sistema deve + [ verbo + objeto | frase verbal ]
+ [ complemento de agente | null ] + { a) condio-1,
13
b) condio-2, .... condio-n}.
Definies
Verbo um verbo simples que expresse a funcionalidade daquele requisito. Dependendo
do tipo do verbo, objeto pode ser um objeto direto ou um objeto direto seguido de um
objeto indireto.
Frase verbal uma frase que expressa a funcionalidade do requisito.
Complemento de agente a identificao de um agente relacionado com o requisito.
Algumas vezes esse complemento pode ser descrito pelo objeto indireto. Um agente
pode ser uma pessoa, uma instituio, um grupo ou um dispositivo fsico externo ao
software.
Uma condio uma sub-sentena que reflete uma situao especfica.
Uma forma de adicionar mais estrutura, por exemplo no que diz respeito a conectivos
apresentada abaixo.
O sistema deve +verbo + objeto + "para"
+ complemento + ["quando" | "se" ] + condio.
Requisitos No-Funcionais
Os requisitos no-funcionais podem ser expressos de duas maneiras: independentes ou
associados a um requisito no funcional. No caso de um requisito no-funcional associado temse
a seguinte estrutura:
O sistema deve + [ verbo + objeto | frase verbal ]
+ [ complemento de agente | null ] + [condio | null] + [ restrio | null ].
Nesse caso restrio uma frase que qualifica a funcionalidade restringindo-a. uma frase no
verbal onde vezes o ncleo da frase um adjetivo.
Os requisitos no-funcionais independentes tm geralmente a seguintes estruturas:
O sistema deve + [ ter | manter | possuir | atender | fazer + objeto]
+ frase-adjetiva.
O sistema deve + [ ter | manter | possuir | atender | fazer + objeto]
+ [frase-adjetiva | null].
Condio + o sistema deve + [ ter | manter | possuir | atender + fazer + objeto]
+ [ complemento de agente | null ] + [frase-adjetiva | null].
14
Requisitos Inversos
Os requisitos inversos so situaes que no podem ocorrer em situao alguma. So de certa
maneira restries de alcance geral.
O sistema no pode + [ frase verbal ].
III.II Organizao
Os requisitos so um conjunto de sentenas numeradas e classificadas segundo seu tipo (RF e
NFR e RF 1 ) e sua classe (entrada, sada e mudana de estado) no caso de requisitos funcionais.
Em caso de listas muito grandes, uma boa poltica agrupar os requisitos com menor distncia
conceitual.
Abaixo listamos alguns exemplos.
Loja de Vdeo
Requisitos Funcionais:
1. O sistema deve cadastrar o cliente. (entrada)
2. O sistema deve emitir um recibo para o cliente. (sada)
3. O sistema deve transformar uma fita disponvel em fita emprestada, quando a fita for
alugada pelo cliente. (mudana de estado)
Requisitos No Funcionais:
4. O sistema deve cadastrar o cliente rapidamente, em menos de 2 minutos.
5. O sistema deve emitir um recibo para o cliente, com o tempo mximo de 8 segundos
aps a transao.
6. O sistema deve atender as normas do padro IEEE.
Requisitos Inversos:
7. O sistema no pode perder dados do cliente.
Biblioteca
Requisitos Funcionais:
1. O sistema deve cadastrar bibliotecrios. (entrada)
2. O sistema deve cadastrar os usurios. (entrada)
3. O sistema deve achar para os bibliotecrios, qual o usurio que est com um determinado
livro. (sada)
4. O sistema deve tornar um livro em livro emprestado, quando um usurio pegar este livro
emprestado. (mudana de estado)
Requisitos No-Funcionais:
5. Dependendo do tipo de usurio o sistema deve atender a completa revogao da multa.
6. O sistema deve cadastrar os usurios de maneira amigvel, por intermdio de uma
interface fcil de usar.
7. O sistema deve fazer o cadastramento rapidamente, em menos de 3 minutos.
8. O sistema deve ser portvel para plataformas Linux.
Requisitos Inversos:
9. O sistema no pode cobrar multa de professores em tempo integral.
Alm da organizao bsica vista acima, possvel que as listas de requisitos possam estar
ligadas a outros modelos de apoio ao esclarecimento ou a elicitao dos requisitos. Abaixo,
falamos sobre uma ligao desse tipo com um glossrio.
III.III Armazenamento
Como vimos anteriormente o armazenamento pressupe que tenhamos polticas para
classificao, indexao e apresentao dos requisitos.
Adotando-se a lista de requisitos, estes estaro classificados segundo o que vimos acima: por tipo
e por classe. Eventualmente, caso seja necessrio, um esquema de agrupamento segundo
conhecimento explcito do domnio pode juntar requisitos em grupos afins.
A indexao dos requisitos feita segundo o esquema de armazenamento, podendo
eventualmente estar disponvel acesso por palavras chave. Essas palavras chave ficam so
melhor definidas quando de utiliza um esquema de glossrio em conjunto com a lista de
requisitos [Leite 93]. Referncias cruzadas entre requisitos podem ser feitas por meio do glossrio
ou por ligaes diretas a numerao dos requisitos. Existe tambm a possibilidade de ligaes
com outros modelos, neste caso a organizao da lista deve prever explicitamente essas ligaes
dentro de sua poltica de rastreabilidade.
A apresentao dos requisitos principalmente em forma de lista. Eventualmente pode-se
apresent-los em forma de hipertexto, caso haja uma implementao das relaes com o glossrio
ou com outros requisitos da mesma lista, ou ainda com outros artefatos.
Alm dos aspectos de armazenamento sob a tica de reutilizao, como vimos acima, h que se
ressaltar o aspecto de evoluo dos requisitos. Nesse caso deve-se ter disponvel um esquema de
gerncia de configurao que torne possvel que os requisitos sejam uma baseline para o processo
de software e que alm disso esteja em constante evoluo. O conceito de requirements baseline
foi formulado por ns [Leite 97] e aplica-se a qualquer modelo de requisitos, obviamente
incluindo o modelo que enfatizamos aqui, o de sentenas de requisitos. A definio da baseline
de requisitos explica que essa evoluo se d em dois eixos, um no que diz respeito a pontos de
referncia do modelo de processo de software e outro eixo no que diz respeito a progresso do
processo de software no que se refere a mudana de nvel de abstrao.
Ou seja o baseline de requisitos muda tanto num mesmo nvel de abstrao como entre nveis de
abstrao. Portanto o armazenamento do modelo de requisitos deve levar em considerao que
esses requisitos evoluram e precisam ter um controle sobre possveis configuraes e verses.
claro que a complexidade de controlar essa baseline no trivial, no entanto uma maneira
integrada de tentarmos garantir que a alocao dos requisitos, tanto funcionais como no
funcionais seja registrada e rastrevel. Assim, possvel efetivamente gerenciar os requisitos,
principalmente num contexto voltil.