requisitos de software professor márcio hunecke · os principais autores sobre engenharia de...

www.acasadoconcurseiro.com.br

Informática

Requisitos de Software

Professor Márcio Hunecke

www.acasadoconcurseiro.com.br 3

Informática

GERÊNCIA DE REQUISITOS DE SOFTWARE

Requisitos

As descrições das funções que um sistema deve incorporar e das restrições que devem ser sa-tisfeitas são os requisitos para o sistema. Isto é, os requisitos de um sistema definem o que o sistema deve fazer e as circunstâncias sob as quais deve operar. Em outras palavras, os requisi-tos definem os serviços que o sistema deve fornecer e dispõem sobre as restrições à operação do mesmo.

Os principais autores sobre Engenharia de Requisitos são: Ian Sommerville e Roger Pressman.

Engenharia de Requisitos

Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objeti-vos e requisitos para os quais foi construído. De forma geral, a Engenharia de Requisitos de Sof-tware é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de forma apropriada para análise, comunicação e posterior implementação.

A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.

www.acasadoconcurseiro.com.br4

Fases da Engenharia de Requisitos

1. Estudo de viabilidade

Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de viabilidade. Tal como o nome sugere, pretende-se com este estudo avaliar sob o ponto de vista tecnológico e organizacional se o projeto é viável.

Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com “as partes interessadas” (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões:

Será que o sistema contribui para os objetivos da organização?

Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado?

Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?

A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifi-ca. Apesar de parecer óbvia, são frequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização.

Deve, portanto, identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida à recolha de todos os dados disponí-veis para clarificar ao máximo o âmbito do projeto e avaliar a sua viabilidade.

Tipicamente, quem poderá fornecer esta informação serão os usuários dos sistemas atuais e do sis-tema a implementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existen-tes), responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados).

Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo:

Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?

Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?

De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?

É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológi-co)? Com que facilidade é que se consegue partilhar informação entre estes sistemas?

O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação ou não do desenvolvimento do projeto, tornando mais claras as restrições (econô-micas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível.

Caso se determine que o projeto é viável, o passo seguinte é a elicitação e análise dos requisitos.

Informática – Requisitos de Software – Prof. Márcio Hunecke


2. Identificação

Algumas das atividades envolvidas nesta fase incluem:

Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.

Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos usuários do sistema.

Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pre-tendidos para o sistema.

Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

Dificuldades

Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas:

O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo, mas não conse-guir articulá-lo (o que é bastante comum). Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo).

Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo ne-cessário – através de um bom conhecimento do domínio – identificar estas situações.

Técnicas para levantamento dos requisitos

Existem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situ-ações, entre as quais podemos citar:

Entrevistas e Questionários

Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns fatores:

Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.

Relação pessoal entre os intervenientes na entrevista.

Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação.


Capacidade de seguir um “plano” para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de “querer despachar” sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).

2.1.2. Workshops de requisitos

Também chamados de JAD (Joint Application Development), o Workshop de Requisitos con-siste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então obter um conjunto de re-quisitos bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os ele-mentos presentes no workshop fomentando momentos de descontração como forma de dina-mizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade de ideias) como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar.

2.1.3. Cenários (Série de Eventos Hipotéticos)

Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:

• estado do sistema no início do cenário;

• sequência de eventos esperada (na ausência de erros) no cenário;

• listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados;

• outras atividades que podem ser executadas ao mesmo tempo que as deste cenário;

• estado do sistema depois de o cenário terminar.

2.1.4. Prototipagem

O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, base-ada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abor-dagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do usuário e que lhe podem



trazer maior valor acrescentado (principalmente na prototipagem evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser conside-rado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico.

2.1.5. Estudo etnográfico

Os Estudos Etnográficos são uma análise de componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pes-soa, é de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o repre-sentante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.

3. Análise e negociação dos requisitos

Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação.

Atividades envolvidas

Algumas das atividades envolvidas na análise de requisitos incluem:

Classificação: agrupamento de requisitos em “módulos” para facilitar a visão global do funcio-namento pretendido para o sistema;

Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisi-tos identificados; é importante resolver estes conflitos o mais breve possível;

Priorização: consiste na atribuição de uma “prioridade” a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um fator gerador de conflitos;

Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua con-sistência e validade (de acordo com o que se pretende do sistema).

Estas fases não são independentes entre si, pois uma informação obtida numa delas pode ser-vir para as demais fases.

A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.


Dificuldades

As dificuldades encontradas na análise são de diversas naturezas:

Fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com po-der de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema);

O ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponí-veis).

Negociações

Na fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem pro-blemas, chegando-se logo a consensos. Algumas sugestões são:

Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolu-ção para mais tarde, fora de reunião), de preferência nunca tomando partidos;

Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação;

Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envol-vidos;

Relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.

4. Especificação e documentação

É nesta fase que se dá a produção propriamente dita do Documento de Especificação de Requisitos.

Em todos os tipos de especificação há 2 tipos de requisitos a considerar:

Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o usuário espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.

Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.

Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos usuários, podendo depois ser classificados como funcionais ou não-funcionais.

A documentação produzida poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir três tipos de especificação:



Especificação de requisitos do usuário ou usuário, Especificação de requisitos do sistema e Especificação do design da aplicação.

A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando “linguagens” que o usuário conheça). Por exemplo, enquanto que nos requisitos do usuário apenas é feita uma abordagem de alto nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficas como diagramas de casos de uso).

Requisito do usuário

Os requisitos do usuário destinam-se, portanto aos vários níveis hierárquicos da organização na qual o sistema será implementado (desde gestores a usuários), pelo que são descritos usando apenas (conforme já foi referido) linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem algumas dificuldades:

Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão.

Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil.

Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um.

Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do usuário:

Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos requisitos).

Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões como “O sistema permitirá criar (...)” ou “Deverá ser possível criar (...)” respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento.

Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo).

Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los.


Requisitos do sistema

Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do usuário correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e notações gráficas. Estes requisitos destinam-se ainda aos usuários do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do usuário, o uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente diferentes:

As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos diferentes.

O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando é que descrições diferentes se referem ou não a requisitos diferentes.

Design da aplicação

Por fim, a especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de “se situar” quando precisar de começar a codificar, compreendendo a forma como a implementação, em um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de implementação aprofundados. Não convém cair na tentação de deixar toda a implementação detalhada, uma vez que convém que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver problemas encontrados em sub-sistemas de formas que uma especificação inicial da arquitetura não consegue prever.

Documento de Especificação de Requisitos

Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especi-ficação que é a usada como declaração oficial dos requisitos do sistema.

Este documento, normalmente chamado de Documento de Especificação de Requisitos (Sof-tware Requirements Specification ou SRS) inclui uma combinação dos requisitos do usuário e do sistema e tem diferentes utilidades para diferentes pessoas.

• Clientes: confirmar a completude dos requisitos e propor alterações.

• Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.

• Engenheiros: compreender o sistema a desenvolver.

• Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.

• Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.

Existem diversos padrões para este documento, embora não se possa apontar nenhum como o "ideal". Uma estrutura proposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-19933.



4.1 Validação

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.

À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.

A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alte-rações no código ou design, este tipo de erro traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os se-guintes atributos dos requisitos:

• Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especifi-cação final obtida.

• Consistência: não devem existir conflitos entre os requisitos identificados.

• Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de for-ma inequívoca pelas partes interessadas.

• Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.

• Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.

• Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos re-quisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.

• Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos re-quisitos.

• Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua espe-cificação deve obedecer às normas usadas ao longo de todo o documento.

Técnicas de validação

Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregadas:

Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revi-sores pode simplesmente ter uma conversa, envolvendo o maior número possível de represen-


tantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos usuários finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capaci-dade de sofrer alterações sem produzir efeitos em todos os outros requisitos).

Prototipificação (ou prototipação) é a implementação de um protótipo (por exemplo, da inter-face do sistema) pode ser útil para os usuários finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacio-nal; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua imple-mentação pode não justificar o seu uso, pode enviesar os usuários (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).

Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respecti-vos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.

4.2. Análise de consistência automática

Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramen-tas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos mo-delos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complemen-tada com uma das outras técnicas referidas.

A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito impor-tante na engenharia de requisitos e da qual dependem elevados custos a médio e longo prazo.

Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em va-lidação de requisitos) é bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. Quando isto sucede, torna--se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado.

Requisitos Funcionais

Em engenharia de software, um requisito funcional define uma função de um sistema de sof-tware ou seu componente. O requisito funcional representa o que o software faz, em termos de tarefas e serviços. Uma função é descrita como um conjunto de entradas, seu comporta-mento e as saídas. Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipula-ção de dados e de processamento e outras funcionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar. Requisitos comportamentais, que descrevem todos os casos em que o sistema utiliza os requisitos funcionais, são extraídos dos casos de uso. Tam-bém, os requisitos funcionais são suportados por requisitos não-funcionais (também conheci-dos como requisitos de qualidade), que impõem restrições sobre o projeto ou execução (tais como requisitos de desempenho, segurança ou confiabilidade). O plano para a implementação



dos requisitos funcionais é detalhado no projeto do sistema. Já o plano para a implementação de requisitos não funcionais é detalhado na arquitetura do sistema.

Tal como definido na engenharia de requisitos, os requisitos funcionais especificam resultados particulares de um sistema. Isto deve ser contrastado com requisitos não-funcionais, os quais especificam características gerais, tais como custo e confiabilidade. Os requisitos funcionais fa-zem parte da arquitetura do aplicativo de um sistema, enquanto os requisitos não funcionais denotam a arquitetura técnica de um sistema.

Em alguns casos, um analista de requisitos gera casos de uso após a coleta e validação de um conjunto de requisitos funcionais. A hierarquia de requisitos funcionais é: usuário / pedido das partes interessadas – característica -> requisitos funcionais/requisitos não funcionais/regras de negócio -> caso de uso. Cada caso de uso ilustra cenários de comportamento através de um ou mais requisitos funcionais. Muitas vezes, porém, um analista começará por evocar um conjunto de casos de uso, a partir do qual o analista pode derivar os requisitos funcionais, que devem ser implementados para permitir que um usuário possa realizar cada caso de uso.

Requisitos Não-Funcionais

Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de de-sempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas. Estes requisitos dizem respeito a como as funcionalidades serão entregues ao usu-ário do software.

Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: tem-po, o processo de desenvolvimento, padrões, etc.

Surgem conforme a necessidade dos usuários, em razão de orçamento e outros fatores.

Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de armaze-namento disponíveis.

Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar todo o siste-ma ineficaz. Ex.: requisito confiabilidade em um sistema de controle de voos.

Classificação dos Requisitos Não Funcionais

Requisitos de produtos: Requisitos que especificam o comportamento do produto. Ex. portabi-lidade; tempo na execução; confiabilidade, mobilidade, etc.

• Requisitos de usabilidade (facilidade de uso). Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.

• Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo.

• Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, exemplo, 99% do tempo.

• Requisitos de portabilidade. Ex.: o sistema deverá executar em qualquer plataforma.


Requisitos organizacionais: Requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões, infraestrutura, etc.

• Requisitos de entrega. Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.

• Requisitos de implementação. Ex.: o sistema deverá ser desenvolvido na linguagem Java.

• Requisitos de padrões. Ex.: uso de programação orientada a objeto sob a plataforma A.

Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, legislação, localização geográfica etc.

• Requisitos de interoperabilidade. Ex.: o sistema deverá se comunicar com o banco SQL Server.

• Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.

• Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.

FURPS

FURPS é um acrónimo que representa um modelo para classificação de atributos de qualidade de software (conhecidos como requisitos funcionais e não-funcionais):

Funcionalidade – Especifica as funcionalidades que não se relacionam com os casos de uso, nomeadamente: auditoria, reporte, interoperabilidade e segurança.

Usabilidade – Avalia a interface com o usuário. Possui diversas subcategorias, entre elasː pre-venção de erros, estética e design, ajudas, documentação, consistência e padrões.

Reliabilidade (Confiabilidade) – Refere-se à integridade, conformidade e interoperabilidade do software. Os requisitos a serem considerados são: frequência e gravidade de falhas, possibili-dade de recuperação, extensão e duração da falha (valorização/sobrevivência) e previsibilidade (estabilidade).



Performance (Desempenho) – Avalia os requisitos de desempenho do software, nomeadamenteː tempo de resposta, consumo de recursos (energia, RAM, CPU, cache, etc.), capacidade e escalabilidade.

Suportabilidade – Os requisitos de suportabilidade agrupam várias características, tais comoː testabilidade, adaptabilidade, manutenibilidade, compatibilidade, configurabilidade, instalabi-lidade, escalabilidade entre outros.

O modelo, desenvolvido na Hewlett-Packard, foi pela primeira vez publicamente elaborado por Grady e Caswell. FURPS+ agora é amplamente utilizado na indústria de software. O símbolo "+" foi posteriormente adicionado ao modelo após várias campanhas da HP para estender a sigla, de forma a enfatizar vários atributos.

O FURPS+ é uma evolução do FURPS. Este contém mais categorias para classificar os atributos de qualidade de software, sendo estas:

Restrições de Design – Especifica ou restringe o processo de design do sistema. Exemplos po-dem incluir:

• Padrões de Design;

• Processo de Desenvolvimento de Software;

• Uso de Ferramentas de Desenvolvimento;

• Biblioteca de Classes;

Requisitos de Implementação – Especifica ou restringe o código ou a construção de um siste-ma, através de restrições comoː

• Limites de Recursos;

• Sistema Operacionais;

Requisitos de Interface – Especifica ou restringe as funcionalidades inerentes às interfaces de diferentes componentes. A utilização de módulos externos é comum e as restrições a ela asso-ciada devem ser contempladas nesta secção.

Requisitos Físicos – Especifica uma restrição física imposta pelo hardware usado para implan-tar o sistema.


Questões

1. (2018 – FUMARC – COPASA – Agente de Saneamento – Desenvolvedor Sistemas Informação)

De acordo com Sommerville (2011), Requisitos de Interoperabilidade, Requisitos Éticos e Requisitos Legais são

a) Requisitos de Produto. b) Requisitos Externos. c) Requisitos Funcionais. d) Requisitos Organizacionais.

2. (2017 – CESPE – TRE-PE – Analista Judiciá-rio – Análise de Sistemas)

No contexto da análise de requisitos, con-fiabilidade e usabilidade são atributos de qualidade classificados como

a) requisitos funcionais. b) requisitos de domínio. c) requisitos não funcionais. d) dependências. e) regras de negócio.

3. (2018 – FAURGS – BANRISUL – Desenvolvi-mento de Sistemas)

_____________ são declarações de serviços que o sistema deve fornecer, ou seja, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, também podem explicitar o que o sistema não deve fazer. Assinale a alternativa que completa corretamente a lacuna do texto acima.

a) Requisitos funcionais b) Padrões de análise c) Requisitos não funcionais d) Padrões de projeto e) Padrões de arquitetura

4. (2018 – CESPE – STJ – Técnico Judiciário – Desenvolvimento de Sistemas)

Julgue o próximo item, a respeito de enge-nharia de software e análise de requisitos. Os requisitos funcionais especificam o que o software deverá fazer. Esses requisitos in-cluem tempo de resposta, utilização de vo-lumetria estática, escalabilidade, disponibi-lidade, segurança e usabilidade.

( ) Certo ( ) Errado

5. (2018 – CESGRANRIO – Banco da Amazônia – Técnico Científico – Tecnologia da Infor-mação)

Requisitos existem em vários níveis de abs-tração. Um desses níveis é conhecido como “requisitos de negócio”, os quais

a) definem a visão e o escopo que influen-ciam os requisitos de usuário.

b) são dependentes dos requisitos funcio-nais para serem levantados.

c) são descobertos depois e a partir dos requisitos de usuário.

d) são registrados na forma da Especifica-ção de Requisitos de Software.

e) influenciam e são registrados na forma de regras de negócio.

6. (2017 – IF-CE – IF-CE – Técnico de Laborató-rio – Informática)

Requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas res-trições operacionais. Com relação aos requisi-tos de software, é verdadeiro dizer-se que

a) os requisitos funcionais são declarações de serviços que o sistema deve forne-cer, como o sistema deve reagir e se comportar para determinadas entradas e situações.


b) o documento de requisito de software (SRS, do inglês Software Requirements Specification) é um documento restrito à equipe de desenvolvimento de sof-tware.

c) as necessidades do usuário são infor-mações que substituem os requisitos do software.

d) os requisitos de produto, os organiza-cionais e os externos são tipos de requi-sitos funcionais.

e) os requisitos não funcionais são aqueles diretamente relacionados às funções específicas fornecidas pelo sistema, ou seja, referem-se diretamente às carac-terísticas do software.

7. (2014 – FUNDATEC – SEFAZ-RS – Auditor Fiscal da Receita Estadual – Bloco 1)

Em um software, existem requisitos que po-dem ser categorizados segundo o modelo FURPS, onde cada letra provém de uma pa-lavra em inglês (acrônimo). Sobre esse mo-delo, considere as seguintes assertivas:

I – O modelo FURPS pode ser utilizado para categorizar os requisitos não funcionais de um software.

II – No acrônimo FURPS, a letra “R” significa “Reliability”, ou seja, “Consistência”. Em um software, um requisito de consistência diz respeito, por exemplo, à consistência que deve existir, em um banco de dados, ao se concluir uma transação.

III – Tempo de resposta e consumo de recur-sos, como memória RAM e processador, são características de requisitos de um softwa-re, relacionadas, no acrônimo FURPS, à letra “P”, que significa “Performance”.

Quais estão corretas?

a) Apenas I b) Apenas II. c) Apenas III. d) Apenas I e III e) I, II e III.


No processo de engenharia de requisitos, há uma de suas fases que tem a finalidade de verificar se os requisitos realmente definem o sistema que o cliente quer. Para isso, nessa fase, podem ser realizados diferentes tipos de verificações, tais como: (1) verificação de va-lidade dos requisitos; (2) verificação de com-pletude, para avaliar se os documentos in-cluem todos os requisitos e se definem todos os comportamentos e restrições definidas; (3) verificação do realismo, para assegurar que os requisitos podem ser implementados usando as tecnologias disponíveis; e (4) testes que demonstrem que o sistema entregue atende a cada requisito especificado. Portanto, na engenharia de requisitos, tais verificações são realizadas em uma fase chamada de:

a) Elicitação de requisitos. b) Especificação de requisitos. c) Documentação de requisitos. d) Validação de requisitos e) Classificação e organização de requisitos.


Na engenharia de requisitos, pode-se utili-zar a seguinte técnica para o levantamento de requisitos de um software:

I – Cenários.

II – Joint Application Development (JAD).

III – Prototipação.


a) Apenas I. b) Apenas III. c) Apenas I e II. d) Apenas II e III. e) I, II e III.


Considere as seguintes assertivas sobre a especificação de requisitos:



I – A especificação de requisitos é o proces-so de escrever os requisitos de usuário e de sistemas em um documento de requisitos.

II – No documento em que são especifica-dos os requisitos, devem ser detalhados os aspectos tecnológicos da arquitetura e as restrições do projeto.

III – Os requisitos podem ser especificados de diversas formas, como, por exemplo, por meio de escrita em linguagem natural ou através do preenchimento de um formulá-rio padrão, do tipo template.


a) Apenas I. b) Apenas II. c) Apenas I e II. d) Apenas I e III. e) I, II e III.

11. (2014 – FUNCAB – SEFAZ-BA – Auditor Fis-cal – Tecnologia da Informação – Tarde)

Um modelo genérico do processo de levan-tamento e análise de requisitos proposto por Sommerville (2004) é composto por seis ativi-dades, dispostas a seguir de forma aleatória: classificação, verificação de requisitos, reso-lução de conflitos, compreensão do domínio, coleta de requisitos e definição das prioridades. A primeira e a última atividade a ser realizada, seguindo esse modelo são, respectivamente:

a) resolução de conflitos e verificação de requisitos.

b) coleta de requisitos e classificação.

c) verificação de requisitos e resolução de conflitos.

d) compreensão do domínio e verificação de requisitos.

e) definição das prioridades e classificação.


As revisões de requisitos e a prototipação são as principais técnicas utilizadas para:

a) o gerenciamento de requisitos. b) a validação de requisitos. c) o levantamento e a análise de requisi-

tos. d) o estudo de viabilidade e para o desen-

volvimento do sistema. e) a especificação de requisitos.


Segundo Sommerville (2004), o processo de engenharia de requisitos de sistema deve--se iniciar como(a):

a) levantamento e análise de requisitos. b) especificação de requisitos. c) projeto de interface. d) análise de componentes. e) estudo de viabilidade.


Segundo Sommerville (2004), os requisitos são divididos em duas classes. São elas:

a) requisitos voláteis e requisitos funcionais. b) requisitos permanentes e requisitos vo-

láteis. c) requisitos de compatibilidade e requisi-

tos mutáveis. d) requisitos mutáveis e requisitos emer-

gentes. e) requisitos emergentes e requisitos con-

sequentes.


15. (2014 – FUNCAB – SEFAZ-BA – Prova: Audi-tor Fiscal – Tecnologia da Informação – Tar-de)

Na engenharia de software, a técnica de ob-servação que pode ser utilizada para com-preender os requisitos sociais e organizacio-nais é conhecida como:

a) brainstorming. b) casos de uso. c) etnografia. d) prototipação. e) delphi.

Gabarito: 1. B 2. C 3. A 4. E 5. A 6. A 7. D 8. D 9. E 10. D 11. D 12. B 13. E 14. B 15. C

requisitos de software professor márcio hunecke · os principais autores sobre engenharia de...

Documents