Modelos de engenharia de requisitos

Segundo Wiegers (2003, p. 4), muitos dos problemas encontrados nos soft- wares advêm da deficiência no modo como as pessoas adquirem, documentam, a- cordam e modificam requisitos do produto. Paula Filho (2009, p. 165) faz três distin- ções sobre o significado de requisitos de software:

− Condição ou potencialidade de que o usuário necessita para um usuário

resolver um problema ou atingir um objetivo.

− Condição ou potencialidade que um sistema, componente ou produto

deve possuir para que seja aceito (isto é, satisfaça a um contrato, pa- drão, especificação ou outro documento formalmente imposto).

− Expressão documentada dessa característica.

Sommervile (2003) divide a Engenharia de Requisitos em três etapas princi- pais:

1. Na definição de requisitos, a partir de informações do cliente, declara-se,

em linguagem natural e diagramas, os serviços que o software deve pro- ver e as restrições nas quais ele deve operar.

2. A especificação de requisitos é um documento estruturado que detalha o

conjunto de serviços do software. Esse documento, às vezes chamado de especificação de função, deve ser preciso e serve como um acordo entre o cliente e o desenvolvedor de software.

3. Uma especificação de software é uma descrição abstrata do software

que servirá de base para o projeto e a implementação do software. Wiegers (2003, p. 47) divide as atividades relacionadas aos requisitos em (i) elicitação, (ii) análise, (iii) especificação, (iv) validação e (v) gerenciamento de requi- sitos.

Na Elicitação de Requisitos, o desenvolvedor do software procura entender o problema e propor soluções ao cliente. São também definidos a visão e o escopo do projeto.

A Análise de Requisitos envolve o refinamento dos requisitos para assegurar que todos os envolvidos os entendam e sejam capazes de identificar erros, omis- sões ou outras deficiências. A análise consiste em decompor os requisitos de alto nível em detalhes, de forma a subsidiar a construção de protótipos, avaliando-se sua viabilidade e prioridades.

A Especificação de Requisitos produz um documento com a representação dos requisitos funcionais e não funcionais. Os requisitos podem ser representados por meio de caso de uso ou de forma descritiva. A norma IEEE 830-1998 busca ga- rantir que esse documento seja correto, não ambíguo, completo, consistente, classi- ficável por importância, verificável, modificável e rastreável.

A Validação dos Requisitos busca a conformidade ente a Especificação de Requisitos e o desejo do cliente. Nesse contexto, casos de testes são uma das for- mas de se identificar ambigüidades e inconsistências.

O Gerenciamento de Requisitos tem como função acompanhar as mudanças propostas pelo cliente e seus impactos na execução do projeto.

A elaboração de requisitos é tratada sob diferentes abordagens. Algumas são mais formais enquanto outras são mais pragmáticas. A seguir, são apresentados os modelos de elaboração de requisitos no CMMI, na ISO 12207, na ISO 15504 e na Programação Extrema.

Chrissis, Konrad e Shrum (2003) afirmam que CMMI consiste nas melhores práticas no desenvolvimento e produção de software. O CMMI aborda práticas que cobrem todo o ciclo de vida do produto de software desde a concepção até a entre- ga e a manutenção. O CMMI possui duas áreas de processos que trabalham com requisitos: a gerência e o desenvolvimento de requisitos.

A ISO 15504 é uma norma para avaliação de processos de software com ob- jetivos de sua melhoria e determinação da capacidade. Ela pode ser utilizada tanto por organizações desenvolvedoras como por contratantes de serviços de software (ANACLETO et al, 2003). Segundo o Software Quality Institute (2009, p. 25), o pro- cesso para o desenvolvimento de requisitos da ISO 15504 (o ENG 2.1 Desenvolver os Requisitos de Software) busca estabelecer, analisar e refinar requisitos de soft-

ware. Ele sugere que: (i) o desenvolvimento de requisitos possua uma especificação de requisitos de software; (ii) os requisitos sejam analisados quanto sua completude, entendimento, viabilidade, consistência e adequação ao contexto; (iii) seja determi- nado o impacto do software no ambiente operacional; (iv) exista revisão dos requisi- tos com o cliente; (v) a cada interação de desenvolvimento, seja possível modifi- car/preparar os requisitos para uma próximo lançamento.

A norma ISO 9000-3 busca apoiar organizações desenvolvedoras de software a implantar o padrão de qualidade preconizado pela norma ISO 9001:2000 (SPINO- LA, 2003, p. 43). Para isto, ela define diretrizes para o desenvolvimento, fornecimen- to e manutenção de software. Quanto ao desenvolvimento de requisitos a ISO 9000- 3 sugere:

1. Estabelecer o seguinte para o desenvolvimento de requisitos:

I - Métodos para acordo de requisitos e autorização e acompanhamento de mudanças, especialmente durante desenvolvimento iterativo. II- Métodos para avaliação de protótipos ou demonstrações

III- Métodos para registro e revisão de resultados de discussão de todas as partes envolvidas

2. Desenvolver requisitos em estreita cooperação com o cliente ou usuários e fazer esforços para prevenir entendimentos divergentes, por exemplo, provisão de definição de termo, explanação de background de requisitos 3. Obter aprovação dos requisitos

4. Estabelecer um método de rastreabilidade dos requisitos para o produto final (tais como matriz de rastreabilidade de requisitos)

Segundo Machado (2003, p. 17), a norma ISO 12207 é dirigida para a indús- tria de software. A norma defende uma estrutura comum para processos de ciclo de vida de software, com uma terminologia bem definida (atividades, tarefas, propósi- tos, resultados) para a aquisição desenvolvimento, operação e manutenção de sis- temas, produtos ou serviços de software.

Um dos subprocessos da ISO 12207 relativa ao desenvolvimento define uma fase de requisitos organizada em duas etapas: elicitação e análise dos requisitos do sistema. A primeira é responsável pelo entendimento do problema, entendimento das expectativas do cliente, acordo dos requisitos, definição dos requisitos. A análise de requisitos trata da definição, análise, avaliação e comunicação dos requisitos.

Soares (2004b) chama os processos até agora definidos como processos ori- entados a documentação ou processos pesados. Em contraponto aos modelos cita- dos, em 2001 apareceram as chamadas metodologias ágeis, que abordaram a cons- trução de sistemas de forma menos burocrática e documentada.

As metodologias pesadas devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsí- veis. Estas situações são difíceis de serem atingidas, uma vez que os requi- sitos para o desenvolvimento de um software são mutáveis. Dentre os fato- res responsáveis por alterações nos requisitos estão a dinâmica das organi- zações, as alterações nas leis e as mudanças pedidas pelos stakeholders, que geralmente têm dificuldades em definir o escopo do futuro software. (SOARES, 2004a)

Processos orientados a documentação para o desenvolvimento de software, como o modelo em Cascata, são de certa forma fatores limitadores aos de- senvolvedores. Além disso, muitas organizações não possuem recursos ou inclinação para processos pesados de produção de software. Por esta ra- zão, muitas organizações, particularmente as pequenas, acabam por não usar nenhum processo, o que pode levar a efeitos desastrosos em termos de qualidade de software. Torna-se necessário, então, utilizar metodologias ágeis, que não são orientadas à documentação nem tampouco se preocu- pam apenas com a codificação. (SOARES, 2004b)

Metodologias ágeis, segundo Soares (2004b), não se baseiam em documen- tação e processos bem definidos, mas em princípios e formas de trabalho. Entre os princípios desta metodologia estão: (i) indivíduos e interações ao invés de processos e ferramentas; (ii) software executável ao invés de documentação; (iii) colaboração com o cliente ao invés de negociação de contrato; (iv) respostas rápidas as mudan- ças ao invés de seguir planos.

Programação Extrema – Extreme Programming (XP) é uma metodologia ágil (SOARES, 2004) baseada em doze práticas, entre as quais duas se relacionam mais diretamente com elaboração de requisitos: Planejamento e Metáfora. O plane- jamento visa à construção de um software, e conforme os requisitos surgem, há atu- alização no código fonte. Cada versão entregue deve ter o menor tamanho possível e com os requisitos de maior prioridade implantados. Metáfora é uma técnica para descrição do sistema segundo a qual ele deve ser descrito pelos usuários sem ter- mos técnicos e analisado pela equipe de desenvolvimento.