A maior rede de estudos do Brasil

Grátis
81 pág.
Apostila-UML

Pré-visualização | Página 6 de 18

 Reações iniciais do usuário: Como o usuário se sente em relação ao sistema em 
desenvolvimento? Reações ao protótipo podem ser obtidas através da observação, 
entrevistas, questionário ou relatório de avaliação. 
 Sugestões do usuário para refinar ou alterar o protótipo: guiam o analista na 
direção de melhor atender as necessidades dos usuários. 
 Inovações: novas capacidades, não imaginadas antes da interação com o protótipo. 
 Informações para revisão de planos: estabelecer prioridades e redirecionar planos. 
 Usuários são fundamentais na prototipação. Para capturar as reações dos usuários 
em relação ao protótipo, outras técnicas de levantamento de informação devem ser usadas 
em conjunto. Durante a experimentação do usuário com o protótipo, utiliza-se a 
observação. Para capturar opiniões e sugestões, podem ser empregados, além da 
observação, entrevistas e questionários. 
Especificação e documentação 
 É nesta fase que se dá a produção propriamente dita do documento de especificação 
de requisitos. 
 
 
 
18 
 
 Em todos os tipos de especificação há dois 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 utilizador 
espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será 
desenvolvido. 
Exemplos: 
o “O software deve possibilitar o cálculo dos gastos diários, semanais, 
mensais e anuais com pessoal”. 
o “O software deve emitir relatórios de compras”. 
o “Os usuários devem poder obter o número de aprovações, reprovações e 
trancamentos em todas as disciplinas”. 
 Os requisitos funcionais descrevem as funcionalidades e serviços que o 
sistema deve oferecer. Dependem do tipo do software, potenciais usuários e do tipo 
de sistema onde o software será utilizado. 
 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. 
Exemplos: 
o “O tempo de resposta do sistema deve ser inferior a 30 segundos”. 
o “O tempo de desenvolvimento não deve ultrapassar seis meses”. 
o “O software deve ser operacionalizado no sistema específico”. 
 Os requisitos não-funcionais definem as propriedades do sistema e suas 
restrições, isto é, confiabilidade, tempo de resposta. Restrições podem ser 
capacidade de dispositivos de I/O, representações gráficas, etc. 
 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 utilizadores, 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. 
 Especificação de requisitos do sistema. 
 Especificação do design da aplicação. 
 
 
 
19 
 
 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 utilizador conheça). Por 
exemplo, enquanto que nos requisitos do utilizador 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). 
 Requisitos do Usuário: Os requisitos do utilizador destinam-se, portanto, aos 
vários níveis hierárquicos da organização na qual o sistema será implementado 
(desde gestores a utilizadores), pelo que são descritos usando apenas linguagem 
natural, formulários e diagramas muito simples. Obviamente, neste nível de 
especificação surgem algumas dificuldades: 
o Ambigüidade: 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. 
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. 
o 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 utilizador: 
o Usar o mesmo formato em todos os requisitos (evitam-se omissões e 
facilita-se a verificação dos requisitos). 
o 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. 
 
 
 
20 
 
o Usar formatação de texto para salientar determinados aspectos do 
documento (usando negrito, por exemplo). 
o 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áter mais técnico, 
consistindo numa descrição detalhada dos requisitos do utilizador correspondentes 
recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e 
notações gráficas. Estes requisitos destinam-se ainda aos utilizadores 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 utilizador, o uso de linguagem natural 
levanta problemas, embora alguns deles sejam ligeiramente diferentes: 
o As mesmas palavras podem, de acordo com a interpretação de cada pessoa, 
designar conceitos diferentes. 
o 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 de 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, a 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 a meio do projeto deverá ser capaz de "se 
situar" quando precisar começar a codificar, compreendendo a forma como a 
implementação, a um nível global, está a ser feita, mas sem conhecer 
necessariamente os detalhes de implementação dos componentes menores. 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 subsistemas de 
forma que uma especificação inicial da arquitetura não consegue prever. 
 
Saídas de um bom processo – ajuda os usuários a explorarem e entenderem 
completamente seus requisitos, especialmente a separação entre o que eles querem e o que 
 
 
 
21 
 
realmente precisam. Suas interações com o engenheiro de software os ajudam a entender as 
restrições que podem ser impostas ao sistema pela tecnologia, pelas práticas da própria 
organização ou por regulamentações governamentais. Eles passam a entender as 
alternativas, tanto tecnológicas quanto procedimentais, as escolhas que podem ser 
necessárias