M2 #1 - Conhecer requisitos

Page 1

Objetivos de aprendizagem Ao final deste texto, você deve apresentar os seguintes aprendizados:

Listar as técnicas de coleta de dados.

Diferenciar requisitos funcionais e não funcionais.

Identificar as regras de negócio.

DESAFIO

Você deve listar e descrever, de forma clara, quais são os requisitos funcionais e não funcionais que este sistema pode ter (informe no mínimo 2 de cada tipo).

Padrão de resposta esperado

Os requisitos podem variar, dependendo da interpretação.

Os requisitos funcionais devem ser relacionados com o comportamento do sistema. Já os não funcionais, devem ser voltados para aspectos mensuráveis, técnicas e necessidades voltadas para a implementação (segurança, acessos, ferramentas, etc.).

Para este caso, os requisitos podem ser estes:

Requisitos funcionais:

RF 1. Os clientes poderão realizar compras e reservas de bilhetes pelo sistema.

RF 2. Os clientes poderão realizar o cancelamento de reservas de bilhetes.

Requisitos não funcionais:

RN 1. O sistema deve ser desenvolvido para Web.

RN 2. O sistema deve ter uma resposta rápida, para que os clientes não desistam da compra.

Page 2

Técnicas para coleta de dados

A complexidade de um software está associada a todas as suas particularidades, que vão desde as suas funcionalidades até os recursos que este necessita para desempenhar sua função com eficácia. O desenvolvimento de um sistema exige que algumas etapas sejam seguidas e executadas com lógica. Dessa forma, um planejamento de um software tem como uma de suas principais atividades a obtenção dos requisitos, ou seja, todas as funcionalidades do software.

Um fato importante, e que merece ser citado, é o de que nem sempre o cliente compreende o que é desenvolver um software, dessa forma, provavelmente ele não terá noção de como deve expor suas ideias, de forma organizada e coerente, e muito menos saberá relacionar o trabalho que será empenhado em seu projeto com os custos e os prazos finais. Para ele, é tudo muito simples, como inserir uma janela, mudar uma funcionalidade de um botão, ou até mesmo acrescentar uma lista de produtos, por exemplo. Mal sabe ele que, na verdade, tudo requer investimento de tempo e trabalho de uma equipe com diversas expertises diferentes.

Algumas técnicas acabaram sendo desenvolvidas para auxiliar a equipe de desenvolvimento neste processo.

As reuniões (reais ou virtuais) são conduzidas com a participação tanto dos Engenheiros de software quanto de outros envolvidos.

São estabelecidas regras para a preparação e a participação.

É sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes; porém, suficientemente informal para estimular o fluxo livre de ideias.

Um “facilitador” (pode ser um cliente, um desenvolvedor ou uma pessoa de fora) dirige a reunião.

É utilizado um “mecanismo de definições” (planilhas, flip charts, adesivos de parede ou um boletim eletrônico, salas de bate-papo ou fóruns virtuais).

O momento em que os requisitos estão sendo coletados é nomeado como descoberta de requisitos, Para isso, o autor lista algumas formas de executar tal ação:

1. Entrevistas. Podem ser de dois tipos:

■ Entrevistas fechadas, em que um conjunto predefinido de perguntas é respondido pelo cliente.

■ Entrevistas abertas, em que não existe uma agenda predefinida, e a equipe desenvolve uma série de questões com o intuito de compreender melhor as necessidades do cliente.

Page 3

2. Cenários. Podem ser úteis para a obtenção de mais detalhes na visão geral dos requisitos, em que cada cenário cobre determinados números de interações. Um cenário começa por meio de um esboço da interação. Durante o processo de elicitação, são adicionados detalhes ao esboço, para criar uma descrição completa dessa interação. Um cenário pode incluir:

■ Uma descrição do que o sistema e os usuários esperam quando o cenário se iniciar.

■ Uma descrição do fluxo normal de eventos no cenário.

■ Uma descrição do que pode dar errado e como isso é tratado.

■ Informações sobre outras atividades que podem acontecer ao mesmo tempo.

■ Uma descrição do estado do sistema quando o cenário acaba.

3. Casos de uso. Trazem definições estabelecidas pela linguagem de modelagem unificada (UML, do inglês Unified Modeling Language). São documentados por um diagrama de casos de uso de alto nível. Identificam as interações individuais entre o sistema e seus usuários ou outros sistemas.

4. Etnografia. É uma técnica de observação que pode ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de apoio para esses processos, em que um analista faz uma imersão no ambiente de trabalho em que o sistema será usado. O trabalho diário passa por diversas observações, nas quais contêm anotações sobre as tarefas em que os participantes estão envolvidos são realizadas.

Requisitos funcionais e não funcionais

Um software necessita de recursos computacionais para que possa desempenhar suas funções, ou seja, ele precisa de dispositivos físicos para operar. Para isso, precisamos definir quais restrições e qual poderá ser o limite de alcance que o software que está sendo desenvolvido poderá vir a ter. Um requisito não lista apenas uma funcionalidade, ele traz especificações também, de como deve agir para que o objetivo de sua função seja atingido.

1. Requisitos funcionais (RF ou, em inglês, FR, de functional requirement): “São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de 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”

Page 4

2. Outros aspectos que norteiam os requisitos funcionais estão ligados à completude, ou seja, se todos as funcionalidades estão definidas, ao realismo quanto à definição das funcionalidades e à consistência, na qual os requisitos não devem trazer ambiguidade ao projeto.

3. Requisitos não funcionais (RNF ou, em inglês, NFR, de non functional requirement): “Pode ser descrito como um atributo de qualidade, de desempenho, de segurança ou como uma restrição geral em um sistema” Esses requisitos abrangem muito mais atributos, que podem estar associados a outras áreas do software.

4. Para Sommerville (2011, p. 60), esses requisitos podem “estar relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta, e ocupação de área. [...] Os requisitos não funcionais, como desempenho, proteção ou disponibilidade, normalmente especificam ou restringem as características do sistema como um todo. [...] Esses requisitos podem afetar a arquitetura geral de um sistema em vez de apenas componentes individuais”

Page 5

O diagrama desenvolvido por Sommerville (2011, p. 61) expõe requisitos não funcionais que podem ser provenientes das características requeridas para o software (requisitos do produto), da organização que desenvolve o software (requisitos organizacionais) ou de fontes externas:

Requisitos do produto: “Requisitos que especificam ou restringem o comportamento do software. Exemplos incluem os requisitos de desempenho quanto à rapidez com que o sistema deve executar e quanta memória ele requer, os requisitos de confiabilidade que estabelecem a taxa aceitável de falhas, os requisitos de proteção e os requisitos de usabilidade”.

Requisitos organizacionais: “São os requisitos gerais de sistemas derivados das políticas e procedimentos da organização do cliente e do desenvolvedor. Exemplos incluem requisitos do processo operacional, que definem como o sistema será utilizado, dentre outros”.

Requisitos externos: “Abrangem todos os requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento. Exemplos incluem requisitos reguladores, que definem o que deve ser feito para que o sistema seja aprovado para uso, dentre outros”.

O detalhamento e as demais especificações acerca de cada vertente de um requisito, seja ele funcional ou não funcional, são descritos em uma documentação, que deve ser bastante detalhada e concisa. É nessa documentação que todas as práticas de levantamento de requisitos que foram utilizadas irão mostrar presteza para todo o processo. Outro fator importante é o de conhecermos também as regras de negócio que devem ser inseridas no sistema.

Page 6

Identificação das regras de negócio

A identificação das regras de negócio que fazem parte do contexto do projeto compartilham das mesmas técnicas da coleta de dados, até mesmo porque é o momento em que os dados estão sendo coletados e as restrições do sistema estão sendo impostas, automaticamente, em que é necessário se ter conhecimento, também, das regras de negócio do cliente. O entendimento dessas regras deve ser exposto em um modelo de negócio, pois “é ele que gera um entendimento do negócio do cliente como um todo. Com esse conhecimento, os desenvolvedores poderão aconselhá-lo sobre quais partes de seu negócio eles deveriam informatizar. De modo alternativo, se a tarefa for estender um produto de software existente, os desenvolvedores terão de entender o negócio existente como um todo para determinar como incorporar a extensão e aprender quais partes, se realmente alguma, do produto existente precisam ser modificadas para acrescentar o novo trecho”. Ainda sob o ponto de vista de Schach (2010, p. 288), “para construir um modelo de negócio, o desenvolvedor precisa ter um entendimento detalhado dos diversos processos de negócio. Tais processos serão refinados, isto é, analisados de forma mais detalhada. Podem ser usadas várias técnicas diferentes para obter as informações necessárias para criar o modelo de negócio, principalmente entrevistas”.

De acordo com Morgan (2001 apud ALVARENGA, 2007), a definição de uma regra de negócio requer a especificação de alguns detalhes operacionais, dentre os quais podemos destacar:

Quem invoca uma regra: esta informação geralmente é descrita em um caso de uso ou em uma descrição de processo do negócio.

Quando a regra é executada: normalmente isto é descrito por um evento, caso de uso ou descrição de processo do negócio.

Onde a regra é executada: esta decisão é pertinente ao design do sistema e, mais especificamente, ao empacotamento do software.

Como a regra é implementada: também é uma decisão da fase de projeto.

Page 7

Conforme Alvarenga (2007, p.21), uma característica comum às regras de negócio é que elas fazem uso dos chamados “parâmetros do negócio”. Tais parâmetros podem ser definidos e gerenciados da mesma forma que as regras de negócio (MORGAN, 2001, apud ALVARENGA, 2007). O Quadro 1 traz características das Regras de Negócios encontradas na prática em muitas organizações, de acordo com Morgan (2001)

Podemos notar que cada detalhe é descrito juntamente com suas particularidades e pode ser inserida a documentação do projeto por um meio específico, seja por um diagrama, ou por uma descrição textual. As regras de negócio, assim como as demais informações de um software, visam a trazer o desenvolvimento correto de um sistema de informação

Page 8