Requisitos de Software

Para Fernandes (2005) os requisitos de software definem propriedades que devem ser executadas pelo sistema, expressam características e restrições do ponto de vista da satisfação das necessidades do usuário, a fim de fornecer controle e suporte a uma tarefa específica.

Filho (2001 apud QUIRINO, 2005), afirma que os critérios de aceitação de um produto estão ligados aos requisitos funcionais do sistema, pois definem as diversas propriedades e funções realizadas pelo mesmo.

A necessidade de especificar os requisitos é proporcional ao tamanho do sistema, ou seja, quanto maior à complexidade envolvida, maior a necessidade de realizar uma especificação mais detalhada, aumentando a dificuldade do processo.

Através dos requisitos, toda funcionalidade comportamental e não comportamental pode ser descrita e avaliada. Muitas das etapas e técnicas envolvidas são abordadas pela engenharia de requisitos, onde diversos paradigma e arquiteturas são apresentados a fim de realizar um

planejamento minucioso e completo para melhorar o desempenho de um projeto (PETERS;

PEDRYCZ, 2001).

Sommerville (2007) aponta duas formas de especificar requisitos. Diferenciadas pelo nível de abstração de sua descrição, permite abranger diversos tipos de leitores e assim facilitar a comunicação em grupo:

• Requisitos de usuário: Utilizam linguagem mais clara e diagramas, exprimindo as idéias das funcionalidades, restrições a serem desempenhadas e os serviços que serão executadas pelo software; e

• Requisitos de sistema: São mais formais e possuem menor abstração, descritos através de uma linguagem mais precisa e com maior detalhamento. São utilizados principalmente por engenheiros de software, arquitetos de sistema e desenvolvedores de software.

Entre os principais desafios envolvidos no trabalho de determinar os requisitos, estão os de encontrar, comunicar e documentar de forma clara, os aspectos necessários às capacidades e condições do sistema, tanto para o cliente como a equipe envolvida no projeto (LARMAN, 2004).

De forma resumida os requisitos de software podem ser divididos em requisitos funcionais, não-funcionais e regras de negócio (requisitos de domínio) (CYSNEIROS, 2008).

A distinção entre um requisito funcional e um requisito não-funcional pode não ser simples, onde um requisito funcional está relacionado a algum tipo de transformação a ser realizada internamente no software, enquanto que um requisito não-funcional está relacionado à como esta transformação irá se comportar ou que qualidade deverá possuir (EAGLE, 1995; CHUNG, 2000 apud CYSNEIROS 2008).

Qualquer que seja a classificação, os requisitos são formados por um conjunto de atributos que definem suas características principais (e.g., prioridade, status, descrição) e demais informações que possam vir a ser necessárias (SANTOS; VARGAS; ABREU, 2004).

2.2.1.1 Requisitos Funcionais

Os requisitos funcionais (RF) descrevem através de uma linguagem clara e escrita às funções que o sistema deverá realizar, geralmente são específicos a cada software projetado (SOMMERVILLE, 2007).

Já para Pfleeger (2004) um requisito funcional é responsável por descrever a interação e comportamento existente entre o sistema e o ambiente, levando em consideração a ocorrência de uma ação ou estímulo.

Quirino (2005) define um requisito funcional como uma descrição das atividades executadas de acordo com as entradas e saídas executadas em resposta a uma ação externa ao sistema.

2.2.1.2 Requisitos Não-funcionais

Ao contrário dos requisitos funcionais os requisitos não-funcionais (RNF) estão relacionados às propriedades de funcionamento (e.g. confiabilidade, tempo de resposta, portabilidade, desempenho) e não as funções específicas do sistema. A importância de um RNF é oposta à de um RF onde muitas vezes existe uma maneira alternativa de se executar determinada tarefa. Já a omissão ou falha de um RNF pode comprometer o funcionamento e tornar o sistema inútil. (SOMMERVILLE, 2007).

Outros fatores relacionados aos requisitos não-funcionais são as necessidades de software, hardware, linguagens de programação utilizadas, recursos financeiros e demais características que não estão relacionadas às funcionalidades do software (ibidem).

Para Pfleeger (2004) um requisito não-funcional representa limitações e restrições que possam existir e que possam interferir na solução final do sistema. Entre os tipos de RNF propostos por Sommerville (2007) estão:

• Requisitos de produto: Ligados ao comportamento, geralmente são relacionados ao desempenho, poder de processamento, confiabilidade, tolerância à falhas, portabilidade e usabilidade;

• Requisitos organizacionais: Relacionados às políticas impostas pela organização do cliente, alguns exemplos incluem linguagem de programação e sistema operacional; e

• Requisitos externos: Requisitos voltados aos fatores externos do software, como a interoperabilidade com softwares de outras organizações e interfaces de comunicação.

Com a existência de diversas categorias de RNF, Conallen (2003 apud Quirino, 2005), classifica os requisitos não-funcionais em:

• Usabilidade: Relacionados principalmente a interação software x usuário. Permite que sejam definidos, como por exemplo, as telas do sistema que devem ser projetadas a fim de facilitar sua utilização;

• Desempenho: Descrevem os fatores relacionados ao tempo de resposta do software.

Abrangem tanto a parte de sistemas operacionais, quanto à parte de hardware utilizada pelo software;

• Confiabilidade: Em sistemas críticos esta é uma característica essencial, define restrições quanto ao seu total funcionamento e tolerância à falhas, além de definir questões relacionadas à recuperação de informações;

• Segurança: Definem aspectos necessários à proteção das informações do software como níveis e políticas internas da empresa para acesso aos dados;

• Hardware: Apontam os requisitos e especificações de hardware, necessários ao funcionamento do software; e

• Implantação: Definem aspectos a serem verificados durante a instalação e treinamento do sistema, a fim de garantir seu correto funcionamento.

2.2.1.3 Regras de Negócio

Para a execução de tarefas por um software, é necessário que normas e restrições sejam definidas para atender corretamente a determinadas necessidades do negócio. Para Sommerville (2007) as regras de negócio (RN), ou requisitos de domínio, são restrições ou especificações que serão executados por uma tarefa e não como ela será executada.

Já para Ross (2003 apud BUGHI, 2007) as regras de negócio são como diretivas que influenciam ou guiam o comportamento dos negócios em um sistema e são formalizadas através de

Apesar da importância de definir corretamente as regras de negócio, sua compreensão pode ser acompanhada de diversos conflitos originados dos processos envolvidos na gerência de negócio e de sistemas de informação de suporte, principalmente com as mudanças dos processos ao longo dos anos (ALENQUER, 2002 apud QUIRINO, 2005).

Quirino (2005) aponta o processo de definição das regras de negócio como uma atividade realizada por um analista de negócios e não pelos responsáveis em mapear os requisitos do sistema devido ao maior entendimento nos processos envolvidos.