Processo de especificação

A primeira etapa do processo de criação de sistemas computadorizados é a análise de requisitos – “uma tarefa da engenharia de software que efetua a ligação entre a alocação do

software em nível de sistema e o projeto de software” (PRESSMAN, 1995, p. 232). Para

Sommerville (2003, p. 46), as quatro principais fases do processo de engenharia de requisitos são: 1) Estudo de viabilidade; 2) Levantamento e análise de requisitos; 3) Especificação de requisitos; 4) Validação dos requisitos. Sommerville (2003) ainda acrescenta o processo de gerenciamento de requisitos, além destes quatro, realizado de maneira constante, inclusive quando o sistema já se encontra em operação.

O trabalho de especificação é considerado tarefa do analista – “conhecido com uma série de apelidos: analista de sistemas, engenheiro de sistemas, projetista de sistemas-chefe,

programador/analista” (PRESSMAN, 1995, p. 235). Este profissional deve ser capaz de fazer

a ponte entre o cliente e os desenvolvedores (podendo ser ele mesmo o desenvolvedor do

sistema). O analista de sistemas seria, então, responsável por “planejar e implementar

soluções de tecnologia da informação em organizações privadas e públicas” (NASCIMENTO, 2003, p.6), conhecendo bem os processos organizacionais e fluxos informacionais (neste papel ele também é conhecido como analista de negócios) e tecnologia da informação e redes telemáticas (neste papel a denominação corrente é analista de suporte).

É nesta fase de especificação do software que se concentra a maior parte dos problemas dos sistemas computadorizados, em especial porque a definição dos requisitos do sistema – ou as descrições de funções e restrições do sistema – requer intenso processo de comunicação do analista com os seus clientes e/ou usuários, sujeitos, segundo Pressman (1995) a todos os ruídos daí advindos. Sommerville (2003) também enfatiza, como Pressman (1995), a importância da boa especificação, pois os custos de manutenção de um sistema advindos de requisitos mal especificados é muitíssimo alto. Por sua vez, Preece, Rogers e Sharp (2005) citam uma pesquisa realizada no Reino Unido constatando que a maior causa de falhas em projetos de TI está ligada a requisitos mal definidos. Schilling et al. (2010) acreditam que a instabilidade dos requisitos, também apontada por Liu, Li e Peng (2010) como problemática, e o não envolvimento do usuário em sua elicitação comprometem a qualidade do produto de software, intrinsecamente relacionada à qualidade do processo que o gerou.

Dos processos da engenharia de requisitos, o primeiro é o estudo de viabilidade do sistema, que visa compreender qual a contribuição do sistema computadorizado para a organização, se há viabilidade de sua implementação com os recursos disponíveis e de que forma ele deve ser integrado a outros sistemas. Contribuem para a análise de viabilidade engenheiros de software, gerentes ou gestores do departamento/organização na qual o sistema deverá ser utilizado, peritos em tecnologia, usuários finais dos sistemas (SOMMERVILLE, 2003).

Após o estudo de viabilidade, inicia-se a fase de levantamento e análise de requisitos

na qual “os membros da equipe técnica de desenvolvimento de software trabalham com o

cliente e os usuários finais do sistema para descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, o desempenho exigido do sistema, as

restrições de hardware e assim por diante” (SOMMERVILLE, 2003, p. 104). São várias as

classificações para os requisitos de software, como os abaixo apresentados por Sommerville (2003):

 Requisitos de sistema: descrevem de forma detalhada as funções do sistema e podem

servir como contrato entre o comprador do sistema e o desenvolvedor do software. Desenvolvedores, arquitetos de sistemas, engenheiros do cliente e usuários finais devem ser capazes de compreendê-los. Tais requisitos podem ser funcionais ou não funcionais.

o Requisitos funcionais: “São declarações de funções que o sistema deve

fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve

fazer” (SOMMERVILLE, 2003, p. 83). Exemplo de requisito funcional para um sistema de bibliotecas seria “O usuário deverá ser capaz de pesquisar por um título presente no catálogo”.

 Requisitos de domínio: “são derivados do domínio da aplicação do

sistema, em vez de serem obtidos a partir de necessidades específicas

dos usuários”, restringindo os requisitos funcionais. Exemplo de

requisito de domínio para um sistema de bibliotecas (de acordo com SOMMERVILLE, 2003, p. 88): “Deve haver uma interface-padrão com o usuário para todos os bancos de dados, que terá como base o

difícil compreensão para o analista de sistemas e considerados óbvios para os especialistas naquele tipo de domínio da aplicação. Neste caso, por exemplo, os bibliotecários compreenderiam muito bem o padrão Z39.50, mas os analistas de sistemas, não.

o Requisitos não-funcionais: não dizem respeito aos processamentos/funções específicas do sistema, podendo estar relacionados às “propriedades de sistema emergentes, como confiabilidade, tempo de resposta e espaço em disco”

(SOMMERVILLE, 2003, p. 85). Tais requisitos podem ser de produto (como os requisitos de desempenho, confiabilidade, portabilidade, facilidade de uso, tolerância a falhas); organizacionais (como os padrões de processo da organização do cliente e do desenvolvedor, por exemplo, a linguagem de programação na qual o sistema será desenvolvido) e externos (como os requisitos de interoperabilidade, os requisitos legais e os requisitos éticos). É preciso atenção a estes requisitos, pois todo o software pode ser tornar inútil, como é o caso de problemas de confiabilidade em sistemas computadorizados em uso por instituições financeiras. Exemplo de um requisito não-funcional de produto seria, para o caso de um sistema de bibliotecas: “A velocidade de realização de uma operação de consulta ao catálogo não deve exceder 10

mseg” (SOMMERVILLE, 2003, p. 85).

 Requisitos de usuário: descrevem “os requisitos funcionais e não funcionais de modo

compreensível para todos os usuários do sistema que não têm conhecimentos técnicos

detalhados” (SOMMERVILLE, 2003, p. 89).

Os requisitos para construção dos sistemas, no contexto dos métodos ágeis, têm sido construídos por meio de user stories, no processo de “user story mapping”40. Uma user story apresenta-se, na visão de Drummond e Alves (2010, p. 244), na forma de texto com vistas a

“descrever uma funcionalidade como uma necessidade do usuário, uma tarefa, seguindo o formato: ‘Eu como [usuário] preciso de [tarefa]’ (‘Eu como professor preciso lançar as notas dos meus alunos’)”. As user stories formarão o backlog do produto – lista de requisitos de alto

40

Para Drummond e Alves (2010), a técnica de user story mapping é método aplicado “nas fases iniciais de desenvolvimento de um produto, na etapa de concepção e estratégia do produto, onde serão mapeadas as necessidades dos

usuários e as funcionalidades do produto”, por meio da execução de seis etapas: “1. Listar user stories (funcionalidades); 2.

Escrever as user stories em cartões; 3. Ordená-las em um fluxo; 4. Priorizar; 5. Agrupar por atividades macros; 6. Marcar o

primeiro release”. A priorização leva em conta o valor para o negócio e a frequencia/utilidade para o usuário, sendo discutida,

nível priorizados para serem trabalhados pela equipe de desenvolvimento – no contexto do SCRUM.

As principais técnicas de extração de requisitos são entrevistas, cenários, realização de brainstorming, observação e análise, grupos de foco, reuso de requisitos, prototipação, soft system methodology (SSM)41, JAD (Joint Application Development)42 e QFD (Quality Function Deployment)43 (ATTARHA; MODIRI, 2011, p. 182).

Para auxiliar no entendimento das necessidades dos usuários para elicitação e especificação de requisitos, é recomendada a técnica de prototipação (PRESSMAN, 1995; SOMMERVILLE, 2003), no âmbito da engenharia de software. Segundo Sommerville (2003, p. 146), os objetivos dos protótipos podem ser: “desenvolver um projeto de interface com o usuário, desenvolver um sistema para validar os requisitos funcionais do sistema ou desenvolver um sistema para mostrar a validade da aplicação para a gerência”.

Os protótipos podem ser descartáveis ou evolucionários. Os protótipos evolucionários fazem parte dos estágios de desenvolvimento do sistema, a idéia é desenvolver uma implementação inicial e evoluí-la até a entrega do sistema, em um desenvolvimento por estágios, como no modelo de processo RAD44, com os usuários e stakeholders envolvidos no projeto e avaliação de cada estágio. Já os protótipos descartáveis visam esclarecer os requisitos e os riscos do sistema, não sendo aproveitados no processo de desenvolvimento do aplicativo (exceto para o caso de criação de componentes reutilizáveis). Ferramentas CASE – Computer-Aided Software Engineering, ferramentas “de apoio ao processo de software pela

41 _{Para Mead (2008), a SSM é uma metodologia para elicitar requisitos de sistemas para problemas “soft” ou menos}

orientados à tecnologia – como o problema de gerenciamento de desastres, melhoria nos cuidados de saúde e de sem-teto, entre outros – composta de sete passos: reconhecer a situação problemática; expressar o problema; definir a visão da situação e os conceitos associados; construir modelos conceituais do mundo; comparar os modelos com a realidade; identificar mudanças viáveis e desejáveis; fazer recomendações para melhorar o problema.

42 _{Mead (2008) caracteriza o JAD – Joint Application Development – como uma técnica a ser empregada em sistemas}

grandes de maneira a envolver todos os stakeholders em reuniões com a presença de um facilitador, usuários finais, desenvolvedores e observadores para elicitação e definição de requisitos.

43

QDF é uma abordagem do processo de elicitação e avaliação de requisitos em relação às funcionalidades e características do sistema. Suas etapas envolvem: identificação dos stakeholders; coleta de requisitos de alto nível junto a eles; construção de um conjunto de características que satisfaçam às necessidades dos clientes e criação de uma matriz de avaliação das características e funcionalidades do sistema de acordo com as necessidades dos clientes.

44

Segundo Preece, Rogers e Sharp (2005), nos anos 1990, surgiram abordagens de desenvolvimento com foco voltado aos usuários, como a abordagem RAD (Rapid Applications Development), de maneira a minimizar os riscos associados às mudanças de requisitos. O RAD conta com ciclos de desenvolvimento rápido (cerca de seis meses), de projetos menores/módulos de um sistema maior, os requisitos são levantados através do envolvimento de todos os stakeholders em workshops conhecidos como JAD (Joint Application Development). O modelo de processo conhecido como SCRUM pode ser considerado semelhante ao RAD, por ser um processo iterativo e incremental com uma abordagem ágil para o ciclo de desenvolvimento do software.Segundo Preece, Rogers e Sharp (2005), o processo de design de um produto para internet de uma empresa denominada Netpliance foi baseado no RAD e caracterizado pelo ciclo de vida em espiral, pois os produtos para internet sofreriam evoluções constantes. Produtos como softwares de prateleira podem requerer ciclos de vida diferentes. Mas, para qualquer aplicativo, o ciclo de vida em cascata para o processo de desenvolvimento de sistemas não beneficiaria a constante discussão dos requisitos do sistema.

automação de algumas atividades de processo e pelo fornecimento de informações sobre o software que está sendo desenvolvido” (SOMMERVILLE, 2003, p.53) – podem auxiliar muito na produção de protótipos e algumas delas cumprem exatamente esta função.

Liu, Li e Peng (2010) em survey realizado sobre as práticas para elicitação de requisitos comentam que as mais utilizadas são a entrevista face a face e a prototipação, além da pesquisa em sistemas similares. Schwiderski (2011) aponta a entrevista como técnica mais utilizada, mas há problemas em sua aplicação, pois os usuários podem resistir em fornecer informações, por medo de serem demitidos ou rebaixados ou por não revelarem as táticas que usam para contornar problemas com sistemas para executarem melhor seu trabalho e outras técnicas, como questionário; investigação contextual (observar como os usuários trabalham) e engenharia reversa de sistemas aparecem em sua revisão bibliográfica.

Segundo Evans (1989), os processos da engenharia de software, em cada uma das suas fases, deveria produzir modelos documentados (dados gerados na engenharia de software) que permitem controle, gerenciamento de qualidade e redução do retrabalho. Os modelos propostos por Evans (1989, p.87-95) são: modelo do usuário da aplicação (User Application Model); modelo de gerenciamento de projeto; modelo de requisitos de suporte; modelo de desenvolvimento de software; modelo físico. Destaca-se, para este momento, o modelo do usuário da aplicação:

A definição inicial dos requisitos do sistema e seu software inclui as necessidades, expectativas e requisitos que suportam a aplicação. A agregação destes requisitos é o modelo de aplicação do usuário. Este modelo é a base da implementação. Ele deve ser completo e não ambíguo e deve prover a base para o desenvolvimento. O modelo descreve o ambiente no qual o sistema deve operar. Ele documenta operacionalmente como o sistema deve atender às necessidades do usuário (EVANS, 1989, p. 87)45

Evans (1989) apresenta os cinco quesitos que devem fazer parte do modelo do usuário: requisitos de suporte operacionais (o que o software deve fazer para dar suporte ao sistema); requisitos de entrega (documentação, revisões, packaging); requisitos de definição de interface de usuário (aspectos da interação homem-máquina, treinamento, ajuda do sistema), requisitos de ambiente (ambiente em que o sistema deve ser instalado) e interface de definição de dados externos (dados que se conectam a outros sistemas).

45

Tradução livre de “The initial definition of a system requirement and its software includes the needs, expectations,

and support requirements of the application. The aggregation of these requirements is the user application model. This model is the basis of implementation. It must be complete and unambiguous, and must provide a testable basis for development. The model describes the environment in which the system must perform. It documents operationally how the system must meet

Os requisitos de sistema podem ser escritos com linguagem natural, o que traz flexibilidade e, ao mesmo tempo, está sujeito a ambiguidades, em especial porque há diversos pontos de vista e conceitos que nem sempre são igualmente compreensíveis por usuários e analistas. É possível a adoção de formulários ou templates para expressar a definição de requisitos de forma a melhorar a legibilidade e compreensão do documento de requisitos. É importante considerar, ainda, que os requisitos devem ser passíveis de serem rastreados ao longo de todo o ciclo de vida do sistema.

Outras abordagens à linguagem natural para a escrita de requisitos são a utilização da linguagem de programação (ou algoritmos) para a definição de modelo operacional do sistema; o uso de notações gráficas (como o diagramas de caso de uso) e as especificações matemáticas. Destas abordagens, um dos diagramas da UML (Unified Modeling Language), se destaca – o diagrama de casos de uso, que são representações gráficas de interações do usuário com o sistema baseados em cenários (SOMMERVILLE, 2003). Além do diagrama de caso de uso, também são utilizados os diagramas de sequência que “mostram os agentes da interação, os objetos dentro de sistema com os quais eles interagem e as operações associadas

a estes objetos” (SOMMERVILLE, 2003, p. 113). Liu, Li e Peng (2010), em pesquisa

realizada sobre a prática de escrita dos requisitos na China constataram que diagrama de fluxos de dados, uso de formulários, diagramas da UML, escrita de narrativas e uso de linguagem natural, nesta ordem, são usados para descrever os requisitos.

Segundo Sommerville (2003), muitos problemas nos softwares têm origem na falta de precisão e clareza na definição dos requisitos, faltando completude e consistência, especialmente em sistemas grandes. O levantamento e análise de requisitos do sistema podem envolver diversas pessoas conhecidas como stakeholders (SOMMERVILLE, 2003; PREECE, ROGERS e SHARP, 2005), os quais podem ou não ser usuários. Segundo Kujala e Kaupinen (2004), a própria identificação dos usuários - “aqueles indivíduos que interagem diretamente com o produto a fim de realizar uma tarefa” (PREECE, ROGERS, SHARP, 2005, p. 191) - e o contato com eles em si são problemáticos. Para estes autores, pode existir tensão entre as necessidades dos usuários e dos clientes contratantes da construção do sistema, ou tensão entre as diferentes necessidades dos diversos perfis de usuários que interagem com o sistema.

No projeto de um produto, como o produto de software, o grupo de stakeholders deve ser levado em consideração, aumentando a complexidade do levantamento dos requisitos, já que tal grupo pode ser maior que o grupo de usuários e, inclusive, ter interesses conflitantes entre si e com os usuários. Segundo Yourdon (1992, p.52), o analista de sistemas deve se

envolver com várias pessoas, como os usuários, gerentes, auditores, projetistas de sistemas, programadores, pessoal operativo. Os operadores são vistos como aqueles responsáveis pelo centro de processamento de dados, pela segurança do sistema, pelas redes, entre outras funções que hoje poderiam ser denominadas de funções de suporte.

Preece, Rogers e Sharp (2005), citando Eason (1987)46, identificam três categorias de usuários – os diretos, que usam o sistema; os indiretos que usam através de um intermediário; os terciários que são afetados pelo sistema ou tem poder de compra. Dix et al.47 (2004) acrescenta a estas três categorias a categoria de usuários facilitadores, aqueles que são responsáveis pela manutenção técnica do sistema. Preece, Rogers e Sharp (2005) exemplificam os stakeholders de um produto como uma agenda eletrônica: os seus usuários diretos marcam compromissos nas interfaces do sistema, os indiretos são afetados pela pontualidade potencial que o seu usuário direto passa a ter, e os terciários podem ser as empresas que produzem agendas de papel.

Sommerville (2003) identifica, para um sistema de caixa automático de banco, os seguintes stakeholders:

1) clientes do banco que recebem os serviços do sistema;

2) representantes de outros bancos que têm acordos de reciprocidade que permitem o uso de ATMs uns dos outros;

3) gerentes de agências bancárias que obtêm informações do sistema;

4) equipes de atendimento de balcão em agências bancárias envolvidas na operação diária do sistema, que atendem às reclamações dos clientes;

5) administradores de bancos de dados que são responsáveis pela integração do sistema com o banco de dados do cliente do banco;

6) gerentes de segurança bancária que devem assegurar que o sistema não apresente nenhum tipo de falha de segurança;

7) departamento de marketing do banco que provavelmente estará interessado em utilizar o sistema como um instrumento de marketing do banco;

8) engenheiros de manutenção de hardware e software que têm a responsabilidade de fazer a manutenção e a atualização de hardware e software (SOMMERVILLE, 2003, p. 106, grifos do autor).

Conciliar, entender e elicitar todos os interesses e necessidades dos stakeholders não é tarefa simples, segundo Preece, Rogers e Sharp (2005); Kujala e Kaupinen (2004); Sommerville (2003), entre outros tantos autores. Há abordagens de processo de software – como o SCRUM – que procuram abarcar os stakeholders, usuários e a equipe de desenvolvimento de forma a acordar as características do sistema e a desenvolvê-lo de maneira incremental, contando também com o envolvimento e participação dos usuários. Em

46

EASON, K. Information technology and organizational change. London: Taylor and Francis, 1987.

47

Baseado no modelo USTM (User Skills and Task Matching) para projeto de sistemas interativos. Para maiores detalhes, consultar DIX et al. (2004).

tópico à parte será apresentada revisão bibliográfica referente aos processos de desenvolvimento centrados no usuário.

Com a rápida diferenciação entre stakeholders e usuários, é importante, todavia, considerar como os usuários diretos do sistema são estudados ou levados em conta no ciclo de vida dos sistemas computadorizados. Para Yourdon (1992) nem sempre o analista tem contato direto com o usuário direto e há dois modos de classificá-lo: por tipo de função exercida (operativos ou operacionais – tem visão local do sistema; supervisores ou responsáveis – chefiam os operadores e costumam ser aqueles com maior poder de definição dos requisitos; e executivos ou donos – tem visão global do sistema e são os que têm iniciativa em levar o projeto adiante) ou por nível de experiência com computadores. Rocha e Baranuaskas (2003), citando Nielsen (1993)48 ponderam a importância de saber, além da experiência com computadores do usuário também a sua experiência no domínio da aplicação. Conforme será detalhado mais adiante, a compreensão das características do usuário tornou-se objeto de estudo de disciplina à parte – a Interação Homem-Computador – à medida que a complexidade dos sistemas computadorizados cresceu.

É importante notar que tanto Yourdon (1992) quanto Pressman (1995) apontam as grandes dificuldades na relação com os usuários:

Clientes e engenheiros de software frequentemente têm uma mentalidade de “nós e eles”. Em vez de trabalhar como uma equipe para identificar e refinar as exigências, cada pessoa envolvida define seu próprio “território” e comunica-se por meio de memorandos, notas formais, documentos e sessões de pergunta e resposta. A história tem demonstrado que essa abordagem não funciona muito bem. Abundam mal-entendidos, informações importantes são omitidas e um relacionamento de trabalho bem-sucedido jamais é estabelecido (PRESSMAN, 1995, p. 240).

Nascimento (2003) comenta que a qualidade do sistema é proporcional à participação do usuário, de forma a ser necessário considerar todos os perfis de usuário por ele categorizados – usuário operacional, tático e estratégico (a mesma classificação de Yourdon, 1992) – e sua proficiência em informática – usuários amadores, novatos e peritos - classificação próxima da de Santaella (2004), com seus usuários errantes, detetives e