AULA 0 ATE 10

Prévia do material em texto

- -1
REQUISITOS DE SISTEMAS
APRESENTAÇÃO
- -2
BEM VINDO (A) Á DISCIPLINA: REQUISITOS DE SISTEMA
Brooks Jr., em um antigo artigo publicado pela IEEE Computer, entitulado como No Silver Bullet: Essence and
Accidents in Software Engineering (IEEE Computer, abril 1987), define: “A parte mais árdua na construção de
um sistema de software é decidir o que construir. Nenhuma outra parte do trabalho compromete mais o sistema
se for feito de forma imprópria. Nenhuma outra parte é mais difícil de corrigir a posteriori.”
Para os mais tecnicistas (e até muitos analistas), certamente existe uma grande dificuldade em compreender a
veracidade desta mensagem. É comum nos preocupamos bastante é com a linguagem de programação, base de
dados ou quaisquer outros recursos no tocante a base tecnológica. Contudo, cometemos uma grave e custosa
infração: definir o que realmente o sistema deve fazer; quais são as entradas disponíveis e as saídas esperadas
para o sistema.
Nesta disciplina, teremos a oportunidade de compreender a importância na definição dos requisitos de software,
identificando como ela contribui para o desenvolvimento de um sistema de qualidade, ou seja, que os objetivos
estão alinhados com a necessidade, evitando surpresas ou pouco entendimento sobre o que realmente se deseja.
O término do estudo dessa disciplina propiciará uma visão sobre os benefícios de se conhecer bem os requisitos
desejados, e como estes irão proporcionar um sucesso no que diz respeito a assertividade do produto de
desenvolvimento de software, ou seja, em um sistema que realmente satisfação as necessidades dos usuários.
Aula 1: Introdução a Requisitos de Sistemas
Conceito de qualidade. Garantia de qualidade de software. Levantar e documentar bem requisitos de projetos
(principalmente de projetos de software). Importância de requisitos bem especificados e documentados
comentando sobre erros de sistemas, funcionalidades, que não atendem ao negócio suporte pelo software e os
sistemas que sofrem manutenção por erros de especificação ou sistemas que são abandonados durante o
desenvolvimento ou já depois de implementados por não atenderem de forma correta o negócio.
Aula 2: Níveis de Requisitos: Requisitos de Usuários e Requisitos de Sistemas.
Identificar e diferenciar as especificidades e diferenças entre os requisitos. Os requisitos de domínio são
derivados do domínio da aplicação do sistema. Os requisitos de usuário englobam funcionais e não funcionais de
forma que eles sejam entendidos por usuários do sistema mesmo que não possuam conhecimento técnico
detalhado. Apresentar alguns exemplos de documentação de requisitos e os problemas gerados por utilizar
técnicas não específicas para a documentação, por exemplo, a linguagem natural (problemas relacionados a falta
de clareza, confusão de requisitos, fusão de requisitos, erros de interpretação por usuários e desenvolvedores,
etc.), exemplificar os requisitos obrigatórios e requisitos desejáveis e qual a forma correta de documentação.
Aula 3: Tipos de Requisitos: Funcionais, Não Funcionais e Regras de Negócios
- -3
Apresentar os conceitos e a diferença entre os requisitos funcionais e não-funcionais. Destaque a importância
das métricas para especificar os requisitos não funcionais. Conceito completeza (todos os serviços exigidos pelo
usuário devem ser definidos.) e consistência (os requisitos não devem ter definições contraditórias).
Aula 4: Identificação de stakeholders
Técnicas de levantamento de requisitos. Apresentar o de stakeholders. Características dos stakeholders.
Métodos para boa interação com stakeholders. Conhecer técnicas para levantamento de requisitos. Identificar as
melhoras técnicas para cenários diferentes.
Aula 5: Documentação de Requisitos de Software
Capítulo introdutório. Itens do documento de requisitos: (1) os serviços e funções que o sistema deve
proporcionar; (2) os constrangimentos sob os quais o sistema deve operar; (3) propriedades genéricas e
constrangimentos relativos às propriedades emergentes do sistema; (4) definições de outros sistemas com os
quais o sistema deverá ficar integrado; (5) informação acerca do domínio de aplicação do sistema; (6)
constrangimentos do processo utilizado para desenvolver o sistema; (7) descrições do hardware no qual correrá
o sistema. Utilidade de um documento de requisitos: aquisição de software pronto. Metodologias ágeis no
levantamento de requisitos em diferentes abordagens no desenvolvimento de software.
Aula 6: Engenharia de Requisitos e Estudos de Viabilidade
Nessa etapa iremos imergir detalhar nos conteúdos sobre a engenharia de requisitos, inclusive nossa aula de
hoje iniciar pelos fundamentos dessa área, destacando a importância no resultado de um software que atenda as
necessidades dos usuários.
Aula 7: Elicitação de Requisitos
Segunda etapa das nossas aulas sobre as atividades da área de requisitos.
Continuaremos imersos nos conteúdos sobre a engenharia de requisitos; nossa aula de hoje trabalhar sobre a
elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos
usuários.
Aula 8: Validação de Requisitos
Identificar mais uma atividade da engenharia de requisitos. Reconhecer o processo de validação de requisitos. 
Verificar o motivo e a importância da validação de requisitos.
Aula 9: Gerenciamento de Requisitos
Conhecer mais uma atividade da engenharia de requisitos. Identificar a função da atividade de gerenciamento de
requisitos. Reconhecer a importância do controle de mudanças.
Aula 10: Casos de Uso
- -4
Identificar a utilidade de casos de uso para a engenharia de software. Reconhecer como o caso de uso contribuiu
para a área de requisitos de sistemas. Conhecer a estrutura dos casos de usos. Obter uma introdução sobre a
linguagem UML.
Bibliografia
SOMMERVILLE, I., , 9ª Edição. Pearson, 2011.Engenharia de Software
PRESSMAN, R., 6ª Edição. McGraw-Hill, 2006.Engenharia de Software,
NOGUEIRA, Marcelo. , 1ª Edição. Ciência Moderna, 2009.Engenharia de Software
Avaliação
A avaliação é continua, integradora, com ênfase nos aspectos colaborativos, incluindo tarefas coletivas, e
contempla o diagnóstico, o processo e os resultados alcançados por intermédio de avaliações diagnósticas,
formativas e somativas, considerando os aspectos da autoavaliação.
A avaliação somativa da aprendizagem é realizada presencialmente pelo aluno no IES e segue a normativa da
Universidade. A(s) prova(s) presencial(is) segue(m) o calendário acadêmico divulgado para o aluno.
Durante o Curso, os alunos realizam atividades propostas, compostas de questões objetivas e discursivas
referentes ao conteúdo estudado, podendo ser elas de autodiagnóstico ou de discussão.
Ao final dessa disciplina você será capaz de:
• Apresentar os conceitos fundamentais e importância dos requisitos no processo de desenvolvimento de 
software.
• Compreender o que vem a ser qualidade, e como podemos desenvolver um sistema com qualidade.
• Apresentar as atividades envolvidas para elicitação e validação dos requisitos, evidenciando a 
importância de cada uma delas e as diferentes técnicas utilizadas, bem como o relacionamento entre elas.
• Ter uma visão sobre a engenharia de requisitos de software.
• Desenvolver senso crítico do aluno mostrando a necessidade do gerenciamento de requisitos para 
apoiar cada atividade do ciclo de vida de software.
Fique atento (a) e bons estudos!
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
INTRODUÇÃO A REQUISITOS DE SISTEMAS
- -2
Olá!
Nesta aula, você irá: 1 - Identificar o conceito de requisitos.
2 - O que é qualidade de software.
3 - Relacionar a importância dos requisitos para o desenvolvimento de software com qualidade.
1 Introdução
Certamente que você deve está familiarizado sobre o conceito da palavra “sistema”, onde este representa um
tipo de rotina; ou seja, quando estamos construindo um software, na realidade estamos transferindo uma
sequenciada operação definida e sequencial,incoerências e inconformidades no desenvolvimento de um produto de
software. Perceba que também o contexto da validação nos permite a identificação destas mesmas incoerências
na fase anterior à versão final do relatório de requisitos, o que proporciona um nível de acerto maior, e minimiza
consideravelmente uma detecção vindoura destas incoerências numa fase posterior, ou, pior ainda, até mesmo
na finalização do sistema.
Sommerville (Engenharia de Software, 2009) enfatiza ser possível afirmar que o processo de validação de
requisitos está para o documento de requisitos assim como a fase de testes unitários e de sistema está para a
fase de desenvolvimento de um projeto de software.
É encontrado e provado pela literatura que detectar um erro em fases finalistas de um projeto, pode chegar a ser
danoso a ponto de incompatibilizar a continuidade, visto que pode ser tão custosa que não existe recursos para
comportá-la. Por isso, a atenção deve ser constante e minuciosa.
São exemplos dos problemas que o processo de validação pode solucionar:
• Não conforme as normas de qualidade do
projeto e da empresa;
• Descrição pouco clara dos requisitos;
• Ambiguidade entre requisitos;
• Falhas na modelagem dos requisitos;
• Conflitos entre requisitos;
• Requisitos não realistas;
• Ausência de informação.
3 Insumos e produtos gerados pela atividade da validação 
de requisitos
Na figura abaixo, segue uma síntese no tocante aos insumos e produtos gerados pela atividade da validação de
requisitos.
- -4
A partir da compreensão do que na figura anterior, claramente conseguimos ter a percepção de um sistema da
informação, contendo: entrada, processamento e saída. Com base nesse modelo, então define-se que o processo
de validação de requisitos têm como entrada o arcabouço oriundo dos processo de:
(a) análise e elicitação de requisitos;
(b) das normas de qualidade da organização;
(c) conhecimento empírico obtido contido na empresa,
principalmente vindo de outros projetos ou de skateholders
experientes no assunto. Na etapa de processamento temos a
validação dos requisitos, que gera como saída uma lista de
problemas que devem ser resolvidos e ações que
 são combinadas.
Passaremos então a estudar sobre as técnicas existentes para o processo de validação.
4 Revisão dos Requisitos
É uma técnica, como o nome já sugere, a qual são analisados e revisados sistematicamente todos os requisitos
elicitados, executando um checagem no tocante a erros e inconsistências.
- -5
É uma boa prática para esta técnica uma reunião formal com representantes ou especialistas de todas as áreas,
tanto do contratante como do contratado. Portanto, todas as equipes deverão ter representação. São
recomendadas as seguintes providências:
• Planejamento do que será revisado.
• Estabelecer e convidar os envolvidos.
• Definir local e tempo para a reunião.
• Escolher para condução alguém “livre de vícios”, ou seja, que não estava integrado à equipe
desenvolveu o documento de requisito.
• Realizar procedimento de checklists para os requisitos e nas relações entre eles.
• Distribuir previamente todos os documentos a serem utilizados na reunião.
• Apresentar cada requisitos individualmente.
• Discutir e anotar comentários para cada requisito que apresenta erro ou inconsistência.
• Estabelecer um período de soluções após todo o término dos relatos apurados nas análises.
• Apurar a qualidade final do documento de requisitos.
No tocante ao item 10, segue na tabela abaixo questões e respectivos atributos de qualidade que devem ser
considerados na apuração:
5 Prototipagem
A fim de estabelecer uma demonstração mais didática sobre o projeto, desenvolve-se um protótipo para que os
stakeholders possam compreender de maneira mais exata o funcionamento do sistema. “Nessa abordagem para
- -6
avaliação, um modelo executável do sistema é demonstrado para os usuários finais e clientes.” (Sommerville,
2009). O objetivo é tornar mais fácil a fase de validação de requisitos, visto que, através da demonstração visual,
tornar-se mais intuitivo detectar inconsistências e problemas nos requisitos.
Experientes nessa técnica evidenciam algumas preocupações para sua adoção:
A qualidade do protótipo poderá levar a desilusões para os utilizadores finais, visto do ambiente projetado para
os testes não ser aprazível aos usuários, principalmente no tocante as telas do sistema (as interfaces).
Mediante a anuência do que foi apresentado com teste, incentivar os programadores a uma baixa qualidade nas
interfaces.
O tempo gasto no desenvolvimento do protótipo em detrimento dos prazos estabelecidos para o projeto.
6 Testes de Requisitos
Uma propriedade importante para cada requisito é o de ser testável. Para cada requisito funcional deve ser
possível definir um ou mais testes a serem realizados no sistema final para ser possível verificar se o sistema
cumpre o requisito na integra. Caso tal propriedade não esteja presente, ou até mesmo se for muito difícil testá-
lo; tal circunstância indica a necessidade de uma retificação.
A realidade implica em uma probabilidade considerável para que todo o requisito que não pode ser
testado muito provavelmente será instituidor de problemas. Deve-se então reconsiderar a presença
deste, buscando por alternativas testáveis.
Então quando da realização dos testes, deve-se tomar nota das características observadas quanto ao requisitos
em si (identificador, requisitos relacionados), como aqueles relacionados aos testes (descrição, problemas,
comentários, recomendações, etc.).
O que vem na próxima aula
•
Gerenciamento de Requisitos
CONCLUSÃO
Nesta aula, você:
• Aprendeu sobre mais uma atividade da engenharia de requisitos.
• Analisou o processo de validação de requisitos.
• Compreendeu a importância da validação de requisitos para o documento de requisitos de software.
•
•
•
•
- -7
• Compreendeu a importância da validação de requisitos para o documento de requisitos de software.•
- -1
REQUISITOS DE SISTEMAS
GERENCIAMENTO DE REQUISITOS
- -2
Olá!
Nesta aula, você irá: 1. Conhecer mais uma atividade da engenharia de requisitos.
2. Identificar a função da atividade de gerenciamento de requisitos.
3. Reconhecer a importância do controle de mudanças.
1 Introdução
Seja bem-vindo a última etapa das nossas aulas sobre as atividades da área de requisitos.
Encerramos hoje os conteúdos sobre a engenharia de requisitos; nossa aula trabalhará assunto sobre o
gerenciamento de requisitos, destacando a importância no resultado de um software que atenda as necessidades
dos usuários.
Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa revisar
algum assunto), veja ordem abaixo:
• Aula 6 - Viabilidade;
• Aula 7 – Elicitação;
• Aula 8 – Validação;
• Aula 9 – Gerenciamento.
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não
temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema,
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os
sistemas os requisitos mudam.” (Sommerville, 2009).
Com base nesse cenário, tornar-se necessária então a padronização o procedimento, para ter maior convicção da
acertabilidade do que está sendo desenvolvido.
Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre
as atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo
em mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto.
Faça um bom proveito!
- -3
2 Evolução dos Requisito
Apesar de toda preocupação no cumprimento das atividades referente à engenharia de requisitos, tem-
se como verdade que uma incômoda realidade: não importa o quão cauteloso seja sobre a definição dos
seus requisitos, sempre haverá mudanças. Mas nãoprecisa então achar de tudo o que aprendemos deve
ser desconsiderado, porque, sem ele, o prejuízo poderá ser muito maior.
Sommerville (2011) destaca: Os requisitos para sistemas de software de grande porte estão sempre mudando.
Uma razão para isso é que esses sistemas geralmente são desenvolvidos para enfrentar os problemas “maus”
(problemas que não podem ser definidos). Porque os problemas não podem ser definidos, os requisitos de
software são obrigados a ser incompletos. Durante o processo de software, o entendimento dos stakeholders a
respeito do problema está em constante mutação. “Logo, os requisitos de sistema devem evoluir para refletir
essas novas percepções do problema.”
Conforme disposto na figura abaixo, o stakeholder, por exemplo, aponta uma determinada direção para
a problemática e suas compreensões iniciais.
A partir desse cenário são elicitados os requisitos que serão a Bse para a resolução.
Na medida em que o tempo vai passando, é normal um amadurecimento do que fora proposta e novas
compreensões são visualizadas, fazendo com que os requisitos tenham que então suprir uma nova ou
mais acertada concepção, portanto, alterando-os.
- -4
E toda alteração em um ambiente aonde os recursos utilizados são alterados, requer uma análise geral
dos impactos a serem gerados pela alteração a ser aplicada.
E justamente nesse escopo é que temos as maiores dificuldades. Portanto, o que torna complexo o
gerenciamento dos requisitos variáveis não se trata especificamente na circunstância que um requisito
mudado provocará mais ou menos tempo gasto na aplicação no sistema de um atributo novo, mas
também que a mudança em um requisito propiciará impacto em outros requisitos, gerando uma cadeia
de acontecimentos que devem ser avaliados.
3 Mudanças de Requisitos
1 - Uma realidade muito comum também é uma vez que o sistema venha a ser implantado, sua utilização regular
proporciona levantamento de novos requisitos. Humanamente é difícil que usuários e clientes do sistema
consigam antecipar todos os efeitos que o novo sistema terá sobre seus processos de negócio e sobre a forma que
o trabalho é realizado.
2 - Quando os usuários finais tiverem experiência de um sistema, descobrirão novas necessidades e prioridades.
São fusões entre empresas, mudanças no negócio, questões técnicas (utilização de software livre, por exemplo),
- -5
novo hardware que deve ser introduzido, interoperabilidade, as prioridades do negócio podem mudar (com
consequentes alterações necessárias no apoio do sistema), novas legislações e regulamentos os quais o sistema
deve necessariamente respeitar, dentre outros.
3 - Então, é fato que no tocante a engenharia de software, é preciso ter a preocupação de compor uma estrutura
de requisitos que tenha adaptabilidade a mudanças, além de usar vínculos de rastreabilidade que possam
representar as dependências existentes entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento.
• Estabelecer uma linha de base (baseline), aonde seja registrado aquele estado atual dos requisitos, 
principalmente se houverem mudanças. Costumamos dizer que é como tirar uma foto; ou seja, saberemos 
quais as características dos requisitos de acordo com alguma escala de tempo.
• Determinar quais dependências são importantes de serem rastreadas, entendendo os requisitos mais 
importantes e suas ligações.
• Estabelecer a rastreabilidade entre itens correlatos, trata-se de definir os “link” entre os requisitos, 
permitindo saber as ligações entre eles.
• Controle de mudança. É necessário manter a informação do requisito original, ou seja, antes da 
mudança; o que foi mudado; as alterações estabelecidas e os requisitos alterados.
“O gerenciamento de requisitos é o processo de compreensão e controle das mudanças nos
requisitos do sistema.
Você precisa se manter a par das necessidades individuais e manter as ligações entre as
necessidades dependentes para conseguir avaliar o impacto das mudanças nos requisitos. Você
precisa estabelecer um processo formal para fazer propostas de mudanças e a ligação destas às
exigências do sistema.
O processo formal de gerenciamento de requisitos deve começar assim que uma versão preliminar
do documento de requisitos estiver disponível.
No entanto, você deve começar a planejar como gerenciar mudanças de requisitos durante o
processo de elicitação de requisitos.” Sommerville (2011, pag. 76).
4 Planejamento de gerenciamento de requisitos
Nosso passo inicial está em planejar e definir bem qual será o nível do detalhamento pretendido no
gerenciamento de requisitos.
São exemplos de atributos que devem ser avaliados:
• 1. Identificação de requisitos
•
•
•
•
•
- -6
Cada requisito deve possuir um identificador, ou melhor, pode ser definida uma política para compor
cada identificação. Ela precisa ser única e mesmo que o requisito deixe de ser utilizado, deve mantê-la
para fins de histórico.
• 2. Processo de gerenciamento de mudanças
Política que define conjunto de atividades cujo objetivo está em avaliar o impacto causado e o
referenciar o(s) custo(s) inerente(s) a(s) mudança(s).
• 3. Políticas de rastreabilidade
Definem os relacionamentos entre cada requisito e o projeto de sistema que deve ser registrado. A
política de rastreabilidade também deve definir como esses registros serão mantidos.
• 4. Ferramenta de apoio
Não existe implicação direta em fazer o controle via formulários, contudo, gerenciar requisito abarca
sempre grandes volumes de informações. É uma boa prática a utilização de ferramentas tecnológicas,
que podem ser desde sistemas especializados em gerenciamento de requisitos até planilhas e sistemas
de banco de dados simples.
Sommervile (2011) é bem incisivo no tocante ao desenvolvimento da atividade de gerenciamento de requisitos.
Ele afirma que “o gerenciamento de requisitos precisa de apoio automatizado, e as ferramentas de software para
esse gerenciamento devem ser escolhidas durante a fase de planejamento.” Ele dispor de três necessidades
macros para apoiar sua afirmação.
São elas:
Armazenamento de requisitos - Os requisitos devem ser mantidos em um repositório de dados gerenciado e
seguro, acessível a todos os envolvidos no processo de engenharia de requisitos.
Gerenciamento de rastreabilidade - Como discutido anteriormente, as ferramentas de apoio para
rastreabilidade permitem descobrir requisitos relacionados. Algumas ferramentas estão disponíveis , as quais
técnicas possíveisusam de processamento de linguagem natural para ajudar a descobrir as relações entre os
requisitos
Gerenciamento de mudanças - O processo de gerenciamento de mudanças (figura 2) é simplificado quando as
ferramentas ativas de apoio estão disponíveis.
•
•
•
- -7
 Contudo, é preciso contemplar o tamanho da empresa, porque tais ferramentas não podem ser maisAtenção:
caras do que o próprio sistema. Portanto, para sistemas de menor porte, outras alternativas podem (e devem)
ser avaliadas, podendo não apenas ser necessárias ferramentas especializadas no gerenciamento de requisitos.
Bancos de dados ou planilhas elaboradas em softwares comuns podem gerar um ótimo resultado, apoiando o
processo de gerenciamento de requisitos.
Existem três estágios principais em um processo de gerenciamento de mudanças (Sommerville, 2011):
1. Análise de problema e especificação de mudanças.
Tudo começa com a identificação de um problema de requisitos. Uma segunda necessidade também pode ser
com uma proposta específica de mudança. Nessa etapa, é realizada a análise do problema ou a proposta de
mudança a fim de se verificar sua validade. Como boa prática, o resultado dessa análise é transmitido àquele que
propôs mudança, a fim de definir: maiores detalhes ou retirar a solicitação.
2. Análise de mudança de requisitos.
O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade e conhecimentos gerais dos
requisitos do sistema. O custo de ser fazer a mudança é estimado em termos de modificaçõesno documento de
requisito e, se apropriado, no projeto e implementação do sistema. Uma vez que essa análise é concluída, decide-
se prosseguir ou não com a mudança de requisitos.
3. Implementação de mudanças.
Deve ocorrer tanto no documento de requisitos e, se necessário, no projeto e, por último, na atualização do
sistema, pelo resultado da implementação da modificação. Você deve organizar o documento de requisitos para
poder fazer alterações sem ampla reformulação ou reorganização.
- -8
Uma vez que houve a aprovação do documento de requisitos, o gerenciamento de mudanças de requisitos (figura
abaixo) deve ser aplicado a todas as mudanças propostas aos requisitos de um sistema. A importância no
gerenciamento de mudanças é fundamental, pois é necessário decidir se os benefícios da implementação de
novos requisitos justificam os custos de implementação, ou seja, “os fins justificam os meios”.
Sommerville (2011) destaca: “a vantagem de se usar um processo formal de gerenciamento de mudanças é que
todas as propostas de mudanças são tratadas de forma consistente, e as alterações nos documentos de requisitos
são feitas de forma controlada.”
E quando da ocorrência de casos de urgência, há sempre a tentação de mudar o sistema e, em seguida,
retrospectivamente modificar o documento de requisitos.
Desnecessário afirmar que esse procedimento deve ser evitado, pois produz um cenário quase
inevitável: a especificação de requisitos e a implementação do sistema fiquem defasadas. Confiar na
mente humana e/ou no “bom senso” representa péssimo modelo de gerenciamento.
Quase que na maioria das vezes as mudanças no sistema são feitas, e é esquecido de incluir, acrescentar,
atualizar tais alterações no documento de requisitos.
O que vem na próxima aula
Na próxima aula, você estudará sobre os assuntos seguintes:
• Casos de Uso.
CONCLUSÃO
Nesta aula, você:
• Compreendeu a função da atividade de gerenciamento de requisitos.
• Aprendeu mais uma atividade da engenharia de requisitos.
• Analisou a importância do controle de mudanças.
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
CASOS DE USO
- -2
Olá!
Nesta aula, você irá: 1. Identificar a utilidade de casos de uso para a engenharia de software.
2. Reconhecer como o caso de uso contribuiu para a área de requisitos de sistemas.
3. Conhecer a estrutura dos casos de usos.
4. Obter uma introdução sobre a linguagem UML.
1 Introdução
Uma modelagem de um determinado sistema é um processo que consiste na representação de uma visão (ou
perspectiva) do que se espera do sistema, no tocante ao seu funcionamento e resultado(s). É um consenso que
ter uma representação visual de seu sistema antes que ele entre na etapa de implementação é de fundamental
importância.
Desde meados da década de 80, o CASO DE USO estabelece uma metodologia que institui regras para a
modelagem de sistemas. É como se fosse a planta baixa de uma residência. Antes que venhamos a construí-la,
precisamos observar o desenho e demais informações, para evitarmos desagradáveis surpresas no o produto
depois de terminado, ou seja, de nossa casa, por exemplo.
Representados por diagramas, os Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o
cliente. Ele então expõe uma espécie de cenário que mostra as funcionalidades do sistema do ponto de vista do
usuário. Enfim, o cliente deve ter acesso através do diagrama de Casos de Uso a identificação das principais
funcionalidades de seu sistema.
A partir dessa análise, conseguimos então perceber se estamos no caminho correto, portanto iremos atender os
requisitos do sistema. Isso porque não estamos falando de uma conversa técnica (“bits e bytes”), mas com uma
linguagem entendível por todos os integrantes da equipe, principalmente do solicitante, facilitando grandemente
a comunicação.
Podemos também citar sobre uma segunda característica dessa modelagem, é que ela independe do tipo de
plataforma tecnológica; ou seja, qual a linguagem de programação, qual o banco de dados etc. Lembra-se que
falamos sobre isso no início da disciplina. Pois então, o Caso de Uso é uma estratégia muito peculiar a engenharia
de requisitos.
Vamos agora aprender sobre sua estrutura.
O diagrama de Caso de Uso é compostos basicamente por 3 elementos. São eles:
- -3
• Atores; ( Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator identifica um
usuário do sistema, seja ele humano ou
outro sistema.)
• Casos de uso; ( Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator identifica um
usuário do sistema, seja ele humano ou
outro sistema.)
• Relacionamentos entre estes elementos.
Vamos a exemplos:
• Representação do requisito “CADASTRAR CLIENTE”:
Lembre-se que usamos a figura de “ator” para representar quaisquer entidades que interagem com o sistema.
Um ator representa um papel no sistema, mas um papel pode ser representando por vários atores.
Mediante o que sugere o diagrama, temos as seguintes ações do atores:
• Ator “Cliente” poderá executar os casos de uso
“realizar saque” e “consultar saldo”;
• Ator “Gerente” poderá executar os casos de uso
“abrir conta” e “vender seguro”.
- -4
2 Relacionamentos entre casos de uso
Mediante aspectos inerente a necessidade de fazer uso de casos de uso por outro caso de uso, estes podem se
relacionar de duas formas:
• Include
• Extends
Include
Quando um caso de uso “A” inclui (include) outro caso de uso “B”. Isto implica que ao executar o caso de uso “A”
executa-se também o caso de uso “B”.
Neste exemplo, o ator “Vendedor” pode executar o caso de uso “Processar Pedido”, e também o caso de uso
“Emitir nota Fiscal”, visto que os casos de uso possuem relacionamento. Contudo, o ator não pode executar o
caso de uso “Emitir nota Fiscal” sem executar “Processar Pedido”.
Extends
Quando um caso de uso “A” tem um relacionamento do tipo extends com outro caso de uso “B”. Implica que ao
executar o caso de uso “A” não necessariamente “B” será executado.
Neste cenário, o vendedor pode fazer uso de quaisquer um dos casos de uso de maneira independente. Ele
executa o caso de uso “Consultar Serasa” e/ou “Solicitar Entrega”.
•
•
- -5
Atenção: Portanto, a diferença é que no include existe uma dependência do uso do caso de uso, o que não
acontece quando o relacionamento é extend.
3 Relacionamento entre atores
O ator pode herdar as funcionalidades (casos de uso) de outro ator.
Aqui temos os Atores “usuário” e “Cliente.
Ao ator “usuário” está liberado o acesso ao caso de uso “Fazer Login”. No caso do ator “Cliente”, ele pode
executar o caso de uso “Realizar saque”, bem como “Fazer Login”, visto que ele possui também o privilégio de
executar todos os casos de uso disponíveis ao ator “usuário”.
Neste exemplo, é importante verificar o sentido da seta, a qual indica que o sentido é do ator “Cliente” para o ator
“usuário”.
- -6
4 Representação do sistema
No tocante ao sistema como um todo, ou seja, a representatividade global do funcionamento é feito através de
mais dois elementos:
Nome do sistema: Localizado dentro do retângulo.
Limites do sistema: representado por um retângulo envolvendo os casos de uso que compõem o sistema.
Acompanhe os dois exemplos a seguir (visto do conhecimento já adquirido, descreva sua interpretação para cada
cenário apresentado e remeta ao seu tutor).
Exemplo 1
Exemplo 2
- -7
Fonte: Fonte das imagens (todas): http://celodemelo.wordpress.com/2007/03/17/entendedo-o-diagrama-de-
casos-de-uso/
5 A UML – Unified Modeling Language
A UML surgiu a partir de um incentivo (inclusive financeiro) da Rational Software na união entre outras três
metodologias de modelagem. Foram eles: (a) o método do americano Grady Booch; (b) o método OMT (Object
Modeling Technique) do sueco Ivar Jacobson; e (c) o método OOSE (Object-Oriented Software Engineering) do
americano James Rumbaugh.
O esforço inicial do projeto começou com a união do método de Booch com o método OMT de Jacobson, o que
resultouno lançamento do Método Unificado no final de 1995. Logo em seguida, Rumbaugh juntou-se a Booch e
Jacobson na Rational Software e seu método OOSE começou a ser incorporado à nova metodologia. O trabalho de
Booch, Jacobson e Rumbaugh conhecidos popularmente como "Os Três Amigos", resultou no lançamento, em
1996, da primeira versão da UML propriamente dita.
Assim que a primeira versão foi lançada, diversas grandes empresas atuantes na área de software passaram a
contribuir com o projeto, fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente a UML foi
adotada pela OMG (Object Management Group) em 1997, como a linguagem padrão de modelagem. Hoje, em
2007, a UML está na versão 2.0.
- -8
Com uma modelagem, seu propósito é para permitir o entendimento e não para documentação. Ela então é parte
do processo do desenvolvimento do sistema. Portanto, podemos utilizar os Casos de Usos para disseminação do
conhecimento referente ao software a ser entregue.
Além do Caso de Uso que estudamos anteriormente, os seguintes tipos de diagramas são suportados pelo
Umbrello UML Modeller:
• Diagrama de Classe mostra classes e os relacionamentos entre elas
• Diagrama de Sequência mostra objetos e uma sequência das chamadas
do método feitas para outros objetos.
• Diagrama de Colaboração mostra objetos e seus relacionamentos,
colocando ênfase nos objetos que participam na troca de mensagens
• Diagrama de Estado mostra estados, mudanças de estado e eventos
num objeto ou uma parte do sistema
• Diagrama de Atividade mostra atividades e as mudanças de uma
atividade para outra com os eventos ocorridos em alguma parte do sistema
• Diagrama de Componente mostra os componentes de programação de
alto nível (como KParts ou Java Beans).
• Diagrama de Distribuição mostra as instâncias dos componentes e
seus relacionamentos.
• Os Diagramas de Entidade-Associação mostram os dados e as relações
e as restrições entre os dados.
Atenção: Vale uma consulta ao livro base dessa disciplina, e fazer uma verificação dos detalhes sobre cada um
deles, bem como identificar suas diferenças, principalmente no tocante ao Caso de Uso - o qual foi detalhado em
nossa aula de hoje.
CONCLUSÃO
Nesta aula, você:
• Compreendeu como os casos de uso contribuem para sucesso na identificação de requisitos.
• Aprendeu sobre a modelagem de sistemas através de casos de uso.
• Analisou o modelo para desenvolvimento de casos de uso.
•
•
•de acordo com o seu funcionamento. Por exemplo, uma grande
montadora de veículos encomenda um sistema para fazer com que “braços” mecânicos possam executar a tarefa
de alocar as peças para que o carro seja construído. Portanto, o software opera sobre o hardware para que o
computador possa desenvolver a determinada ação.
Portanto, antes de se pensar em ambiente de desenvolvimento, linguagem dequestões tecnológicas (
programação, banco de dados a ser utilizado etc.), é preciso ter a concepção correta do que se está sendo
solicitado. Se não conseguirmos compreender corretamente o que precisamos sistematizar, temos grande risco
de não entregarmos o que se desejava no referido software.
2 Análise de Dado
Não existe um bom projeto, uma boa linguagem de programação, um bom (Sistema Gerenciador de BancoSGBD
de Dados), se a análise dos requisitos foi mal elaborada. Analise esse dado:
“Numa recente pesquisa da indústria, as organizações avaliadas sofreram aumentos de até 60% no
tempo e no orçamento quando utilizaram más práticas de requisitos. As organizações com recursos
deficientes de análise de negócios tiveram três vezes mais falhas que sucessos nos projetos.”
IBM. Definição e Gerenciamento de Requisitos. Acessível em: http://www-01.ibm.com/software/br
/rational/offerings/irm/
Atenção: É preciso massificar a concepção nos profissionais e empresas que trabalham com software, a
necessidade de destinar investimentos para capacitação em análise e documentação, visto que vai agregar uma
- -3
rentabilidade melhor para o software, com maior grau de acerto do que será entregue para atender a requisição
do cliente. Sem um levantamento de requisitos adequado, certamente o desafio será muito maior!
3 Levantamento de Requisito
O processo de levantamento de requisito está vinculado para garantir qualidade no produto que vamos entregar.
Mas você sabe definir o que é qualidade?
Para qualquer empresa, ter qualidade nos seus processos é ter uma estratégia competitiva, principalmente para
aquela que desenvolve software. A muito tempo já deixamos de ter a visão que qualidade é algo voltado a classes
sociais mais ricas. É preciso definir ou escolher um determinado padrão de qualidade a ser seguido nas
atividades para o desenvolvimento do sistema, a fim de poder acompanhar em diferentes estágios se está tudo
em conformidade com as normas estabelecidas, e por fim garantir a qualidade do software.
É perceptível atualmente um significativo movimento em busca da qualidade. Adventos de várias
transformações no mundo, as organizações precisam produzir produtos e serviços de qualidade, não mais como
uma estratégia de diferenciação de mercado, mas como uma condição de subsistência.
Mas qual o caminho para um produto de qualidade? Como atingir a qualidade do produto de software? Variáveis
como: qualidade de software, garantia da qualidade e custo da qualidade também são assuntos que exigem
análise. Lembre-se que, qualquer empresa precisa ser rentável, e a qualidade tem seus custos.
4 Qualidade de Software
Para facilitar nossa compreensão na definição da palavra qualidade, Pressman (2006) atribuiu o alcance da
qualidade de software como uma consequência formal no desenvolvimento; para tanto, estima-se que seja
colocada em prática e não somente uma idéia ou desejo que uma organização venha a ter. Ele cita as seguintes
colocações sobre qualidade de software:
- -4
Definir explicitamente o termo qualidade de software, quando o mesmo é dito.
Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de
software exiba alta qualidade.
Realizar atividades de segurança da qualidade em cada projeto de software.
Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a
qualidade no produto final.
Sendo assim, qualidade se consegue nos fragmentos do processo, não apenas no começo do projeto ou no seu
final realizando testes, mas sim dentro do contexto visa abranger toda a engenharia de software, contando como
a colaboração de todos os envolvidos no projeto.
“Qualidade de software deve ser compreendido e empreendido como um processo sistêmico que precisa está
presente todas as etapas e artefatos produzidos, visando a garantia da conformidade de processos e produtos
mediante aos requisitos definidos.”
Portanto, isso consiste em realizar a qualidade tanto do processo quanto o produto.
PROCESSO
No processo, podemos quantificar a sua qualidade através de métricas para qualidade e no produto com as
técnicas de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO
9000, auditorias, inspeções formais, testes, revisões. Ainda no processo podemos usar os métodos de garantia da
qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e
análise estatística de controle do processo.
PRODUTO
No produto os métodos de garantia da qualidade são revisões, inspeção formal e testes, além de revisão dos
resultados do teste realizada por profissionais altamente capacitados, auditorias do produto e testes realizados
pelo cliente.
5 Controle da Qualidade e Garantia da Qualidade
Não podemos confundir os conceitos e a aplicação dos termos Controle da Qualidade e Garantia da Qualidade.
Para que possam utilizá-los adequadamente, acompanhe na tabela abaixo diferenças entre estas duas atividades:
Garantia de qualidade
- -5
Controle de qualidade
Teste de Software
Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de
software é orientado a produto e está dentro do domínio do controle da qualidade.
- -6
6 Gerenciamento da Qualidade
De acordo com o (Project Management Body Of Knowledge) do Project Management Institute) , na PMBOK PMI ( 
versão 2004, os processos de gerenciamento da qualidade do projeto detêm todas as atividades da organização
executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto
atenda às necessidades que motivaram sua realização. Eles desenvolvem o sistema de gerenciamento da
qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da
qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao
fim, conforme adequado.
Com isso os três principais processos são:
• Planejamento da Qualidade
Identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfaze-los.
• Garantia daQualidade:
Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega
todos os processos necessários para atender aos requisitos.
• Controle daQualidade:
Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os
padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho
insatisfatório.
Há diversas semelhanças entre os conceitos usados no PMBOK e os conceitos da própria ISSO. Com isso, é
possível ainda relacionar estes três processos do PMBOK com as definições de qualidade de processo, qualidade
de projeto, controle da qualidade e garantia da qualidade.
A norma ISO 9000 estabelece um padrão para a qualidade de software.
Ela aponta um conjunto de características de trata de um produto, processo ou sistema que está adequado os
requisitos inicialmente estipulados para estes. “A ISO 9001 é de longe a estrutura de qualidade melhor
estabelecida, sendo utilizada atualmente por mais de 750 mil organizações em 161 países, e define o padrão não
só para sistemas de gestão da qualidade, mas para sistemas de gestão em geral.”
Enfim, alcançar um produto de software de maneira mais assertiva, que consegue o problema de maneira
correta e que entrega dentro de um tempo e lugar que satisfazem ao cliente, inicia com a identificação dos
•
•
•
- -7
requisitos.Então devemos primeiramente levantamos as pessoas, os processos e recursos que estão envolvidos,
e buscar então evidenciar suas ações e documentá-las, da maneira mais detalhadamente necessária para que não
haja dúvidas do(s) respectivo(s) comportamento(s).
O que vem na próxima aula
Na próxima aula, você estudará sobre os assuntos seguintes:
• Classificação de requisitos;
• Conceito e exemplos de requisitos funcionais;
• Conceito e exemplos de requisitos não funcionais.
CONCLUSÃO
Nesta aula, você:
• Compreendeu sobre a definição de requisitos de sistemas.
• Aprendeu sobre os conceitos de qualidade no aspecto do desenvolvimento de software.
• Analisou que os requisitos representam o foco de deve receber muita importância, caso desejemos 
atingirmos um software com qualidade.
•
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
NÍVEIS DE REQUISITOS: REQUISITOS DE 
USUÁRIOS E REQUISITOS DE SISTEMAS
- -2
Olá!
Nesta aula, você irá: 1 - Aprender sobre a classificação dos requisitos de níveis.
2 - Identificar os níveis em nível de sistema.
3 - Identificar os níveis em nível de usuário.
4 - Reconhecer as características de requisitos de sistema e requisitos de usuário.
1 Introdução
Conforme estudamos na aula anterior, definir bem requisitos é um passo importante para alcançarmos o
desenvolvimento de um projeto de determinado software com qualidade. Independente das características que
defina maior ou menor, a primeira iniciativa será identificar o que se espera do sistema. Notadamente o sistema
a ser desenvolvido substituirá ou aperfeiçoará algum outro existente ou automatizar um processo que
atualmente não está sendo realizado por computador.
2 Requisitos
Quando falamos em requisitos, estamos identificando algo intrínseco ao sistema, ou seja, alguma característica
que deverá ser capaz de efetivamente realizar, visando assim atingir os objetivos macros que motivaram o início
do projeto. Podemos também dizer que requisitos apontam a conduta desejada de um sistema.
2.1 Requisitos classificados por níveis
Os requisitos classificados por níveis estão vinculado na linguagem ou ambiente do teor da especificação para
determinada finalidade, com o intuito de consegui ser entendível, evitando que qualquer anomalia na qualidade
da informação disposta imponha obstáculos para se alcançar plenamente o resultado esperado. E não adianta
apenas constar, mas a compreensão do que se preciso tem que ser clara.
Na figura abaixo (Sommerville, pág. 58), temos um exemplo descrito detalhadamente, que visam atender
diferentes necessidades de informações. Por exemplo, nele estão visíveis para o programador saber qual(ais) a
(s) regra(s) para se atingir o objetivo esperado, e o que o usuário deve efetivar no momento de obter o resultado
daquele processamento. Todos estes devem sempre fornecer a dimensão exata dentro da especificidade do
cenário, sendo claro e sem ambigüidades, para evitar desencontros e/ou desentendimentos.
- -3
Para então contemplar todos os envolvidos no processo de levantamento de requisitos, de maneira que
compreendam o cenário proposto para resolução de determinada necessidade que culminou na tarefa de
desenvolver um sistema, dividimos os requisitos em dois níveis:
• Sistema
• Usuário
2.2 Requisitos de usuário
1- Os definem em uma linguagem qualquer o que o sistema deve atender, sem serequisitos de usuário
preocupar como vai atender. O foco é apontar características que agregam o valor do software, sem apontar
como isso foi feito. É uma espécie de manual do sistema, que aponta suas funcionalidades para todos que o
venham a ler. Exemplos: clientes (contratantes) e usuários finais do sistema.
•
•
- -4
 Nesta etapa, por exemplo, o usuário define então a rotina de determinada atividade, expressando claramente2-
qual a necessidade, de forma que seja então criado todo o processo necessário para atender os anseios, e
consequentemente possa atingir plenamente os objetivos.
Notadamente neste caso não estão sendo levado em consideração quaisquer tecnologias a serem empregadas;3- 
pelo contrário, deve ser permissiva e sentida a flexibilidade, de modo que o usuário possa ter total liberdade
para sua explanação.
 O usuário realiza o seu pagamento independente da infraestrutura de rede, linguagem de programação, etc. O4-
que importa é que consiga interagir com o software e hardware, de forma a realizar a operação desejada. Como a
leitura de um código de barras realizado por uma máquina de autoatendimento de um banco.
- -5
2.3 Requisitos de sistema
No tocante aos , estes já são especificados para um grupo de leitores que detém de umarequisitos de sistema
experiência, seja no negócio como na área de tecnologia da informação, nas especificidades da empresa. Precisa
não necessariamente entender de detalhes tecnológicos, mas estima-se que ostente algum tipo de experiência,
dotando-o da capacidade de, por exemplo, identificar os insumos já presentes e aqueles também necessários,
mas que não estão sendo gerados, para se alcançar uma determinada informação e com base na regra do
negócio, aplicada e requerida pelo cliente.
Um exemplo que facilita a compreensão é vinculado a software de jogos eletrônicos. Sempre ao comprar
(recomenda-se) analisar quais são as características mínimas exigidas para que o jogo possa funcionar em um
determinado computador. As informações ali dispostas são consideradas, obrigatórias, pois define os
componentes e configurações para que seja possível usufruir das emoções dos jogos. Portanto, são requisitos do
sistema.
Observando a figura que detalha os requisitos mínimos de sistema, é possível concluir que nem todas as pessoas
terão capacidade de avaliar se realmente seu computador poderá fazer com que o jogo funcione. Mediante as
informações serem mais de ordem técnica, é necessário alguém que tenha alguma familiaridade para que tenha a
capacidade de avaliar e definir.
- -6
Importante destacar que nada impede que os requisitos de sistema e/ou de usuário estejam disponíveis, ou seja,
possam ser lidos por pessoas sem conhecimento apropriado (salvo por questões de confidencialidade); portanto,
o documento está sendo disponível a todos, contudo, o grau de a relevância está mais associados àqueles que
detém vínculo com determinado perfil de informação.
A seguir, veremos sobre mais dois tipos de requisitos, porém estes agora mais voltado para características mais
internas dos próprios requisitos, que apontam pela funcionalidade do requisito, o que justifica então a presença
dele, tanto de maneira mais direta (requisito funcional), como indireta (requisitos não funcional).
- -7
O que vem na próxima aula
Na próxima aula, você estudará sobre os assuntos seguintes:
• Classificação de requisitos por tipos;
• Requisitos Funcionais;
• Requisitos Não Funcionais.
CONCLUSÃO
Nesta aula, você:
• Compreendeu sobre a classificação dos requisitos;
• Aprendeu sobre requisitos de sistema e requisitos de usuário;
• Analisou a abrangência de cada nível de requisito.
•
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
TIPOS DE REQUISITOS: FUNCIONAIS, NÃO 
FUNCIONAIS E REGRAS DE NEGÓCIOS
- -2
Olá!
Nesta aula, você irá: 1 - Identificar o que é um requisito funcional e não-funcional.
2 - Quais as características de um requisito funcional.
3 - Quais as características de um requisito não-funcional.
4 - Compreender as diferenças entre os requisitos funcionais e não-funcionais.
1 Introdução
Antes de entrarmos nas características que definem a classificação de requisitos, é importante enfatizar que um
sistema não é concluído com apenas um tipo de requisito. E que também não existe algum que é mais ou menos
importante. Recapitulando o que já estudamos, requisitos definem o que o sistema deve fazer; portanto, quando
eles são evidenciados, entende-se que devem ser contemplados e inseridos no software.
Sommerville (2011, pág. 60), destaca que os requisitos devem especificar todos os intentos do cliente, e que
sejam de forma clara– os quais denominam pelo conceito de completude e consistência. Um fato que vamos
estudar na próxima aula: as pessoas que fazem parte da empresa cliente, nem sempre são precisos em identificar
corretamente um contexto.
2 Classificação dos Requisitos
De maneira geral, os requisitos são classificados em três tipos. São eles:
- -3
Vamos então analisar exemplos dessas classificações.
Exemplo Prático
Relativo ao sistema a ser desenvolvido, pede-se: deve disponibilizar um grid na tela, que permitirá a visualização
dos dados relativos a nossa conta bancária (saldo disponível para o saque). Essas informações poderão ser
acessadas apenas com o interesse do cliente. Portanto, o grid somente será ativado (e também pode ser
desativado) através do clique em um botão. Esse grid não poderá durar mais do que 3 segundos para aparecer
ao cliente.
Separando corretamente os requisitos especificados no exemplo acima, visto que não houve preocupação em de
distinguir – ou seja, temos uma aglutinação de requisitos, o resultado seria:
- -4
Muitas vezes é difícil discernir entre quais requisitos são funcionais e quais não são. Essa prática vem com o
tempo e com a experiência e, por isso, para quem não trabalha diretamente com análise, é sempre bom exercitar.
O processo de análise é uma das fases mais complexas do projeto de software. Vamos ainda continuar falando
sobre o processo de elicitação de requisitos e de análise em geral em próximas ocasiões.
2.1 Requisitos Funcionais
Os requisitos funcionais são aqueles que estabelecem e descrevem as funcionalidades do sistema desejadas
pelos clientes, ou seja, retratam “O QUE” se espera que o software faça. Então, por exemplo, uma empresa
determinada está com interesse em ter um sistema que gerencie o seu cadastro de fornecedor. Ela deseja acabar
com um cadastro de fornecedor atualmente realizado em fichas. Para tanto, encomendou um sistema que
possibilite cadastrar e armazenar todos os dados daqueles que lhe fornece produtos e/ou serviços.
Também foi solicitado que pudesse ser emitido um relatório de todos os fornecedores que não conseguiram
entregar no prazo estabelecido, citando o motivo e o número do pedido, além de outros relatórios que são
importantes para os gerentes da empresa. Todos estes são exemplos de requisitos funcionais. Mediante este
cenário, tudo que envolver funcionalidades ou serviços que se espera do sistema no tratamento para o controle
do fornecedor será um requisito funcional. Por exemplo: o sistema deve disponibilizar o cadastro dos campos
“A”, “B” e “C”.
2.2 Requisitos Não Funcionais
Os requisitos não funcionais envolvem fatores para o sucesso do produto a ser entregue porque atua
diretamente com a satisfação dos usuários na operação do software. São exemplos de características de
requisitos não funcionais que devem ser avaliadas:
- -5
Funcionalidade - Está vinculado a finalidade do produto. É preciso entender as características de quem e o que foi
pedido.
Usabilidade - Esforço para utilizar o sistema; aprendizagem do produto; acessibilidade, principalmente por
público de necessidades especiais.
Confiabilidade - Relacionado a frequência de falhas, e, quando ocorrerem, qual o tempo necessários para a
recuperação do ambiente, caso ocorra alguma indisponibilidade.
Eficiência - Característica relacionada ao desempenho do sistema relativo a quantidade da demanda gerada
quando ele estiver em atividade.
Manutenibilidade - Esforço necessário para modificar o sistema para possíveis cenários, sejam eles novos ou
resultado de ajustes para atender alguma nova característica. Portabilidade.
Portabilidade - Capacidade de transferir o produto para outros ambientes.
São exemplos de requisitos não-funcionais:
• Software deve ser operável por deficientes visuais.
• Tempo de resposta do sistema não deve ultrapassar 10 segundos.
• Software deve ter módulo de backup.
• A base de dados deve ser acessível apenas para autorizados.
Abaixo, temos uma abrangente descrição dos tipos de requisitos não funcionais, a qual nos permite ter uma
noção mais exata sobre as características necessárias para enquadrarmos um item como um requisito não
funcional.
Métricas para Especificar Requisitos Não Funcionais
•
•
•
•
- -6
Mediante o cenário muito intangível (mas que precisa obter um métrica), detalhamos na tabela abaixo, as
principais métricas para especificar requisitos não funcionais. Acompanhe então cada medida que pode ser
utilizada em relação a uma determinada propriedade do requisito.
Fonte: Sommerville 2011, pag 62
Atenção: Resumindo então a diferença entre os requisitos funcionais e não funcionais, podemos dizer que o
primeiro tem características tangíveis (é mais fácil observar), enquanto o outro trata de questões intangíveis, e
que podem obter diversas maneiras de ser avaliado, ou seja, vai depender diretamente do contexto
computacional e do tipo do sistema a ser produzido.
O que vem na próxima aula
Na próxima aula, você estudará sobre os assuntos seguintes:
• Definição de skateholders;
• Levantamento de requisitos;
• Técnicas para levantamento de requisitos.
•
•
•
- -7
CONCLUSÃO
Nesta aula, você:
• Aprendeu mais sobre a classificação de requisitos;
• Compreendeu o conceito de requisitos funcionais e não funcionais;
• Analisou as características que definem se um determinado requisito é funcional ou não funcional.
•
•
•
- -1
REQUISITOS DE SISTEMAS
IDENTIFICAÇÃO DE STAKEHOLDERS
- -2
Olá!
Nesta aula, você irá:
1 - Conhecer o conceito de stakeholders.
2 - Identificar características dos stakeholders.
3 - Conhecer técnicas de levantamento de requisitos.
4 - Relacionar cenários distintos e as melhores técnicas de levantamento de requisitos a serem aplicadas.
1 Introdução
Uma vez que já definimos uma estrutura e classificação para o desenvolvimento de um projeto de software com
controle e garantia da qualidade, vamos na aula de tratar de identificar e detalhar sobre as pessoas que tenham e
/ou sejam afetados por um software. Porque, também independente de tecnologia, certamente um projeto que
atua na área da engenharia de software, contemplará a participação direta ou indireta, ativa ou passiva, de
pessoas.
E justamente nesse perfil de um indivíduo que em algum momento influi algum tipo de interesse, participação,
etc., sobre um determinado software, a este caracterizamos como um stakeholder.
2 Stakeholder
Antes de levantarmos as considerações específicas da engenharia de software, vamos buscar um entendimento
mais amplo do que vem a ser um stakeholder, permitindo assim que possamos compreender, por exemplo, que
não é somente na Computação que existem, mas em todo em qualquer sistema (computacional ou não), sempre
teremos agentes diretos ou indiretos, que irão compor ou sofrer das suas características.
Atenção: Acompanhando ao abaixo, tente identificar a atividade da empresa que possa conter todos os usuários
com base nos “pensamentos” citados nas caixas. Também procure distinguir quais deles seriam colaboradores e
quais representam o(s) cliente(s), e, principalmente, sinalize quais serão os stakeholders desse cenário.
Deixe anotada a sua resposta para verificar se está correta ou completa.
- -3
Com foco então em um ciclo de vida do software é possível claramente saber que ele é composto por diversas e
distintas responsabilidades que estão vinculadas as pessoas, grupos e entidades. Dentre essas responsabilidades
que podemos aqui elucidar, são exemplos: o responsável pelo financiamento, o projeto, o desenvolvimento, o
teste, o uso e a manutenção do software. A todos estes chamamos de stakeholder.
A palavra vem de da seguinte composição:
Stake: interesse, participação, risco.
Holder: aquele que possui.
Atenção: Portanto, todos aqueles que de alguma maneira é afetado pelo software, é um stakeholder (reveja sua
resposta da questão vinculada ao questionamento da tela anterior). Então é correto afirmar que toda a
preocupação no tocante ao correto desenvolvimentode um sistema e demais recursos de infraestrutura, por sua
vez, tem o duplo objetivo de facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender às
suas (Voltando a ilustração temos: a urgência por desempenho, os aspectos de segurança enecessidades
usabilidade).
Segundo Summerville (2009), podemos definir da seguinte forma:
“Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou
preocupações sobre a realização da arquitetura.”
- -4
2.1 Exemplos de Stakeholders
Com base então no que já aprendemos, podemos então relacionar os seguintes exemplos e atribuições de
stakeholders no desenvolvimento de um projeto de software:
• Gerente de projeto
Responsável em organizar e conduzir as equipes em suas responsabilidades. Como gestor, precisa
manter harmonia no desenvolvimento do projeto, supervisionando a execução das tarefas, observar os
processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc.
• Analista de Sistema
Responsável em analisar quais as características o que deverá ter o produto a ser desenvolvido para
atingir o objetivo final, ou seja, o que o cliente espera. Para isso, busca analisar as especificidades
inerentes ao determinado software.
• Programador
São os responsável em efetivamente desenvolver do software. Cabe a ele a implementação das linhas de
códigos que construirão a identidade lógica do software.
• Patrocinador
Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto. Ele
será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de
software.
• Cliente (usuário)
É aquele que, a partir de uma necessidade, faz a encomenda de um software. Portanto, é quem vai
usufruir do produto a ser entregue. seja ele apenas um ou um grupo de usuários.
Contudo, além destes supracitados, podemos ter muitos outros stakeholders – que não são tão elementares, mas
possuem algum tipo de interesse. Por exemplo:
•
•
•
•
•
- -5
Para contextualizar melhor, acompanhe o exemplo abaixo:
No contexto do início dessa aula, podemos dizer que uma pessoa qualquer que ficou no carro aguardando o
amigo ou parente devolver um filme, tem grande interesse no desempenho do sistema utilizado pela locadora.
caso contrário, o tempo de espera será maior do que o previsto. Portanto, tanto que está no carro aguardando,
como quem está na locadora para devolver o filme, são stakeholders.
2.2 Características dos Stakeholders
São outras características dos stakeholders:
• São específicos para cada projeto.
• Possuem anseios e objetivos distintos em um projeto.
• São atores fundamentais para detalhamento do que deve ser desenvolvido.
Mediante então a todos esse envolvimento, fato que pode atrapalhar consideravelmente o êxito de um projeto de
software é a ocorrência de uma falha no levantamento dos stakeholders. Tal realidade pode representar que o
gerente de projeto não estará pensando nas necessidades de todos os envolvidos. como conseqüência, podemos
ter um software que não atende aquilo que o cliente esperava, e de que deverá ser revisto e ajustado
posteriormente. Portanto, gerará desgastes de recursos, além da insatisfação daquele que encomendou o sistema.
Entretanto, o gerente de projeto deve observar bem seus objetivos e não procurar stakeholders por todos lados,
o que culminará em um cenário difícil de gerenciar. Deve haver limitação no escopo daqueles que afetam e/ou
serão afetados pelo projeto. Caso contrário, com um pouco de imaginação, pode-se considerar stakeholder até a
mulher do gerente de projeto que deixará de sair com o marido no fim de semana porque ele terá que trabalhar!
Atenção: Concluindo essa primeira etapa de nossa aula, esperamos que você possa ter entendido toda o
envolvimento e influência dos stakeholders em um projeto de software, suas relações e inter-dependência na
concepção e uso de um determinado sistema.
3 Técnicas para levantamento de Requisitos
Diferentemente do que pode representar a melhor das iniciativas, acionar os programadores para começarem a
escrever linhas de códigos não deve ser o foco de atenção para o projeto de software, a abertura para toda a
atividade de desenvolvimento de software deve ser o levantamento de requisitos.
Como já sabemos, a fonte das informações inerentes ao que queremos automatizar está com os futuros usuários,
os quais atualmente já desenvolvem as mesmas tarefas, de forma manual ou automática. Além que o cliente não
estabelece claramente todas as regras relativas ao negócio. e quem está sendo contratado desconhece as
especificidades referente ao processo que atualmente está em execução.
•
•
•
- -6
Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as atividades que
veremos a seguir.
Apesar de aparentemente parecer elementar, o problema de não saber especificar corretamente o que o sistema
deverá fazer é muito rotineiro. Realidades como:
(a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer
transmitir para o analista. ou
(b) requisitos identificados, mas que não exprimem a realidade. e
(c) não estão em concordância com os requisitos informados por pessoas diferentes, são constantes na
elaboração dos requisitos.
Atenção: Um stakeholder ou informação errada afetará em perda de tempo e dinheiro para ambas as partes
envolvidas no desenvolvimento do sistema. É preciso aferir e revisar os requisitos.
No tocante ao do analista responsável pelo levantamento dos requisitos, dois fatores contribuem para o baixo
grau de satisfação dos usuários, o que aumenta consideravelmente a perspectiva do erro. São eles:
Não utiliza uma técnica adequada para extrair os requisitos do sistema.· 
Descrever os requisitos do sistema de modo pouco claro, com ambigüidades, sem consistência com todos os· 
aspectos significativos do sistema proposto.
Como contramedida para atacar primeiro item acima, vamos agora estudar sobre as técnicas de levantamento de
requisitos, detalhando seu conceito e suas respectivas vantagens e desvantagens, que podem ser utilizadas em
conjunto pelo analista.
Etnografia
- -7
A etnografia é caracterizada como uma técnica de observação, aonde o analista buscar uma familiarização do
cliente, seus valores, sua história. Ela pode ser utilizada para compreender os requisitos sociais e
organizacionais, que facilitem compreensão da política organizacional e da sua cultura.
Workshops
Entrevistas
A entrevista também é uma das técnicas de levantamento de requisitos. Tradicionalmente mais simples de
utilizar, produz bons resultados na fase inicial de obtenção de dados. Sobre a entrevista, deve-se considerar:
• O entrevistador dê margem ao entrevistado para expor as suas ideias.
• Ter um plano de entrevista para que seja mantido o foco no cerne do assunto principal.
• Evita que a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.
Questionários
Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha,
lista de verificação e questões com espaços em branco.
Um ambiente oportuno para o uso de questionário é quando há diversos grupos de usuários que podem estar em
diversos locais diferentes do país. Neste caso, elaboram-se pesquisas específicas de acompanhamento com
usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático
entrevistar todas as pessoas em todos os locais.
Questionários
• Identifique todos os destinatários que o receberão.
• Realize a distribuição junto com instruções detalhadas sobre seu preenchimento.
• Defina e informe o prazo para devolução do questionário.
• Documente o resultado da análise e consolidação das respostas dos participantes.
• Envie uma cópia com as informações levantadas para o participante, como sendo uma forma de 
agradecimento e consideração pelo tempo dedicado a pesquisa.•
•
•
•
•
•
•
•
- -8
Brainstorming
Brainstorming é uma técnica para geração de ideias. Uma ideia preliminar gerada serve como incentivo para que
outras apareçam, sejam concordantes ou não, propiciando um aprimoramento e compartilhamento de todos os
envolvidos. Pode ser estabelecida uma ou várias reuniões. O número de ideias geradas deve ser bem grande, pois
quanto mais ideias forem propostas, maior será a chance de aparecerem boas ideias. Os participantes também
devem ser encorajados a combinar ou enriquecer as ideias de outros e, para isso, é necessário que todas as ideias
permaneçam visíveis a todos os participantes.
Uma vez definido que esta é a técnica mais apropriada para determinada situação, as próximas etapas
necessárias para conduzir uma sessão de brainstorming estão elencadas nos balões em destaque.
• Conteúdo 1 - Seleção dos participantes ou grupo de trabalho
Estes devem ser selecionados em função direta com as contribuições que possam oferecer durante a
sessão. É aconselhável sempre a presença de pessoas que estejam sempre bem informadas, sejam de
diferentes grupos.
• Conteúdo 2 - Prepara a sessão
Duração e local do encontro, bem como o que será tratado.
• Conteúdo 3 - Explicar a técnica e as regras a serem seguidas
Definir os conceitos básicos de brainstorming e as regras a serem seguidas durante a sessão.
• Conteúdo 4 - Gerar ou produzir uma boa quantidade de ideias
Os participantes geram tantas ideias quantas forem exigidas pelos tópicos que estão sendo o objeto do
brainstorming. Os participantes são convidados, um por vez, a dar uma única ideia. Se alguém tiver
problema, passa a vez e espera a próxima rodada.
• Conteúdo 5 - Analisar as ideias
Revisar a produção de ideias, destacando as mais valiosas definidas pelo grupo e classificando-as com
prioridades.
Prototipagem
Protótipo tem por alvo explorar requisitos vinculados a um produto que possua aspectos críticos,
implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto. O protótipo
é aconselhado para:
•
•
•
•
•
- -9
As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios
gráficos, entre outras. Um dos principais benefícios que podemos relacionar são as reduções dos riscos na
construção do sistema, pois é possível detectar se o usuário chave já verificou o que o analista captou nos
requisitos do produto.
São elementos para o sucesso na elaboração dos protótipos:
• Seleção do ambiente de prototipagem.
• Compreender os objetivos do protótipo por parte de todos os interessados no projeto.
• Focar em áreas que estejam com maior dificuldade na compreensão.
• Rapidez na construção.
JAD
Por fim, não menos importante, vamos apresentar uma técnica de grande adesão pelos analistas a fim de realizar
o levantamento de requisitos: JAD (Joint Application Design). É uma técnica destinada a principalmente
promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores. Com a intenção de
facilitar a criação de uma visão compartilhada do que o produto de software deve ser, ela ajuda os usuários e
desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido. Tal fato
estabelece sentimento de envolvimento, posse e responsabilidade com o sucesso do produto.
Possui quatro princípios básicos:
Dinâmica de grupo: São realizadas reuniões com um líder experiente, analista, usuários e gerentes, para
despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e
requisitos do sistema.
Uso de técnicas visuais: Para aumentar a comunicação e o entendimento.
Manutenção do processo organizado e racional: O JAD emprega a análise top down e atividades bem
definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no
projeto e cada nível de detalhe recebe a devida atenção.
Utilização de documentação padrão: Preenchida e assinada por todos os participantes. Este documento
garante a qualidade esperada do projeto e promove a confiança dos participantes.
Possui um total de seis tipos de participantes – levando em consideração que nem todos participam de todas as
fases. São eles:
•
•
•
•
- -10
O que vem na próxima aula
• Documento de Requisitos de Software.
• Composição do Documento de Requisitos de Software.
• Utilidade e validade do Documento de Requisitos de Software.
CONCLUSÃO
Nesta aula, você:
• Compreendeu o que é um stakeholders.
• Aprendeu sobre técnicas para levantamento de requisitos.
• Analisou diferentes estratégicas para um bom levantamento de requisitos.
•
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
DOCUMENTAÇÃO DE REQUISITOS DE 
SOFTWARE
- -2
Olá!
Nesta aula, você irá: 1. Aprender sobre o documento de requisitos.
2. Reconhecer a importância da elaboração do documento de requisitos.
3. Verificar os pontos prioritários e a atenção na redação de um documento.
4. Compreender quem são os envolvidos no processo de criação de um documento de requisitos.
5. Verificar a composição de um documento de requisitos.
1 Introdução
Até essa etapa, conseguimos estabelecer uma boa perspectiva de todo o contexto que envolve um projeto
relacionado a desenvolvimento de software. Mesmo para aqueles que já atuam na área de desenvolvimento de
sistema, mas a cada aula vamos adicionando necessidades e entendendo que não basta codificar uma sequência
lógica de um procedimento em uma determinada linguagem de programação, mas que existem métodos que
auxiliam e estabelecem modelos para que possamos alcançar um resultado mais aderente e satisfatório junto ao
cliente.
Tudo que estamos estudando nessa disciplina é para fazer com que entendamos bem do problema, da
sistemática já ou se existente - quem está contratando, além de estabelecer um elo entre o que se espera e o que
será entregue.
Na aula de hoje, estaremos avançando no quesito de comunicação e documentação, mais especificamente no
aspecto do registro de todo o conteúdo extraído no levantamento de requisitos, ou seja, será um local cujo teor é
uma consignação que retrata as especificações a serem seguidas no desenvolvimento de software. Este é O que
denominamos que documento de requisitos de software.
2 Conceito
De acordo com Sommerville (2009):
“o documento de requisitos de software, às vezes chamado de Especificação de Requisitos de
Software (SRS – do inglês Software Requeriments Specification), é uma declaração oficial do que os
desenvolvedores do sistema devem implementar”.
- -3
Enfim, como sabemos que a área de requisitos de sistemas tem total ligação com o fator qualidade para o
desenvolvimento de software, o documento de requisitos trata então de indicar e detalhar sobre os componentes
a serem inseridos no sistema que está sendo construído. Uma vez concluído, se comportar como uma bússola
que detalha quais as ferramentas a serem estabelecidas ao término do projeto. Como tudo o que vimos até agora,
não seria diferente com este documento.
Objetivo
A primeira necessidade é ter em mente que este não é apenas um documento técnico, que será lido apenas pelos
analistas de sistemas e os programadores. Sommerville (2009) esclarece sobre tal realidade, tratando
claramente sobre a diversidade do perfil de usuários, que vão desde a cúpula organizacional até aqueles
vinculados à tecnologia da informação e comunicação. Ele então chama a atenção referenciando que “a
diversidade de possíveis usuários é um indicativo de que o documento de requisitos precisa ser um
compromisso com a comunicação dos requisitos para o cliente, a definição dos requisitos em detalhes precisos
para os desenvolvedores e testadores e a inclusão de informações sobre a possível evolução do sistema”.
Portanto, a premissa “compreensível” deve ser uma tônica para o grupo que está responsável por gerar o
documento de requisitos. Conforme mencionado, o documento é referência tanto no presente (quanto seestá em
pleno desenvolvimento), bem como no futuro, quando na fase de manutenção. No tocante a compreensão,
também deve-se observar o texto utilizado, o qual precisa organizado e com nível adequado aos respectivos
leitores.
Exemplo
- -4
Veja o exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de Software – Teoria e Prátíca – 2ª Edição,
pág. 140):
Em 1995, a Organização Australiana de Defesa e Tecnologia relatou os resultados de uma pesquisa sobre
problemas com especificação de requisitos na Marinha. Um dos problemas destacados foi a disparidade no nível
das especificações. Isto é, alguns requisitos foram especificados em um nível alto e outros em um nível muito
baixo. A disparidade era composta de diversas situações:
Exemplos de usuário
Conforme apontando em Sommerville (2009) na Figura 1, são estes exemplos de usuários de um documento de
requisitos de software:
Clientes do Sistema: Especificam e leem os requisitos para verificar se estes satisfazem suas necessidades. Os
clientes especificam as alterações nos requisitos.
Gerentes: Usam documentos de requisitos para planejar uma proposta para o sistema e para planejar o processo
de desenvolvimento do sistema.
Engenheiros de Sistemas: Usam os requisitos para entender o sistema que será desenvolvido.
Engenheiros de Testes de Sistemas: Usam os requisitos para desenvolver testes de validação de sistema.
Engenheiros de Manutenção de Sistema: Usam requisitos para entender o sistema e os relacionamentos entre
suas partes.
Da mesma particularidade que existe em um projeto de software, tornando-o único em algum(ns) ponto(s), toda
a informação a ser disposta no documento de requisitos tem total vínculo com o perfil do sistema a ser
- -5
desenvolvido. Portanto, podemos encontrar documentos com o foco será sobre a definição de requisitos de
usuários e os requisitos não funcionais, ou que envolva requisitos de sistemas e requisitos funcionais, bem como
outras combinações entre eles. Ainda sob o aspecto de fatos particulares, outro aspecto que deve também ser
definido é o nível de detalhamento a ser utilizado para descrição dos requisitos no documento.
3 Perfil de um Documento
Então agora, mais contextualizados sobre o perfil de um documento de requisitos, passaremos para uma nova
etapa, na qual iremos aprender detalhes sobre a sua estrutura, conhecendo o que pode ser considerado para a
sua criação.
Para tal finalidade, utilizaremos a composição definido por Sommerville (2009) – bibliografia básica de nossa
disciplina, a qual está disposta abaixo:
Prefácio - Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma
justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão.
Introdução- Deve descrever a necessidade para o sistema. Deve descrever brevemente as funções do sistema e
explicar como ele vai funciona com outros sistemas. Também deve descrever como o sistema atende aos
objetivos globais do negócio ou estratégicos da organização que encomendou o software.
Glossário - Deve definir os termos técnicos usados no documento. Não deve conter suposições sobre o
conhecimento ou experiência do leitor.
Definição de requisitos de usuário - USUÁRIO: Deve descrever os serviços oferecidos ao usuário. Os requisitos
não funcionais do sistema também devem ser descritos nessa seção. Essa descrição pode usar linguagem natural,
diagramas ou outras notações compreensíveis para os clientes. Normas produtos que devem ser seguidos devem
sem especificados.
Modelos do sistema - Pode incluir modelos gráficos do sistema que mostram relacionamentos entre os
componentes do sistema, o sistema e seu ambiente.
Evolução do sistema - Deve descrever os pressupostos fundamentais em que o sistema se baseia, bem como
quaisquer mudanças previstas, em decorrência da evolução do hardware, de mudanças nas necessidades do
usuário, etc. Essa seção é útil para projetistas de sistemas, pois pode ajudá-los a evitar decisões capazes de
restringir possíveis mudanças futuras no sistema.
- -6
Apêndices - Deve fornecer informações detalhadas e especificas em relação à aplicação em desenvolvimento,
além das descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as
configurações mínimas do sistema. Requisitos de banco de dados definem a organização lógica dos dados usados
pelo sistema e os relacionamentos entre esses dados.
Índice - Vários índices podem ser incluídos no documento. Pode haver, além de um índice alfabético normal, um
índice de diagramas, de funções, dentre outros que sejam pertinentes.
Atenção: Lembre-se que essa proposta não é única e definitiva, podendo sofrer adaptações, inclusões e
exclusões, a depender da necessidade do cliente dos responsáveis pela sua criação.
O que vem na próxima aula
• Analisar a viabilidade de projeto de software.
• Conhecer os processos da engenharia de requisitos.
CONCLUSÃO
Nesta aula, você:
• Compreendeu sobre a necessidade e importância da elaboração de um documento de requisitos de 
sistemas.
• Aprendeu a estrutura e componentes de um documento de requisito.
• Analisou uma proposta para elaboração de um documento de requisito.
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
ENGENHARIA DE REQUISITOS E ESTUDOS 
DE VIABILIDADE
- -2
Olá!
Nesta aula, você irá: 1. Identificar o conceito e os processos de engenharia de requisitos.
2. Identificar o conceito sobre viabilidade de requisitos.
3. Reconhecer a importância da atividade de análise de viabilidade.
4. Realizar a análise de viabilidade de um projeto de software.
1 Introdução
Nessa etapa iremos imergir detalhar nos conteúdos sobre a engenharia de requisitos, inclusive nossa aula de
hoje iniciar pelos fundamentos dessa área, destacando a importância no resultado de um software que atenda as
necessidades dos usuários.
Serão trabalhadas quatro atividades da área de requisitos, com base na seguinte ordem:
- -3
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não
temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema,
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os
sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a
padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido.
2 Engenharia de Requisitos
Engenharia é uma palavra que costuma sempre nos lembrar sobre processos relacionados a criação, ampliação e
/ou reforma. Também é comum pensarmos em criação – mediante a engenharia civil. Então, quando pensamos
em um engenheiro, estamos pensando em algum tipo de construção. Pois bem, existem várias variáveis que o
profissional da área de atentar-se antes de simplesmente, por exemplo, estudar as composições físicas ou
químicas mais apropriadas. Para isso, ele precisa averiguar!
Portanto, quando falamos em engenharia de requisitos, estamos a tratar de um processo que define atividades
para uma produção e (lembrando que esse documento serve para todos os envolvidos,manutenção adequada 
necessitando cobrir as necessidades tanto em termos técnicos como de áreas comum), do documento de
requisitos de software, o qual foi estudado na unidade anterior. Este importante documento para
direcionamento do sistema a ser desenvolvidos. Para atingir esse objetivo, temos uma sistematização de um
processo para definir o perfil do software.
A premissa básica então para a engenharia de requisitos de software é definir o que deve ser feito; ou seja, é um
trabalho de interpretação. Ela não se preocupa no como deve fazer feito. Com isso, questões tecnológicas como
linguagem de programação, sistema gerenciador de banco de dados, topologias de redes de computadores, não
representam o cerne a ser detalhado, mas sim todas as necessidades que os “humanos” esperam da “máquina”.Na figura 1, temos a definição do processo de engenharia de requisitos:
- -4
Conforme citado no início de nossa aula, teremos uma aula para tratar cada um dos componentes do processo.
Por enquanto, trataremos apenas de explicar o modelo de maneira geral.
O estudo de viabilidade aponta então se o projeto está adequado para responder a contento ao que a empresa
quer, e que esteja apoiado nas condições dos recursos disponíveis. Este gera então um relatório a qual aponta as
conclusões e devidas justificativas.
Ou seja, o projeto pode ser cancelado antes mesmo de qualquer digitação de linha de código.
Na análise de requisitos, segundo passo do processo, que busca identificar entre os stakeholders as
funcionalidades ideais e fundamentais para o software.
Definição dos requisitos, como o nome já sugere, é responsável em receber todas as informações referente a
análise de requisitos e promover então o que será especificado como requisito para o sistema que será definido.
Por fim, a fim de consolidar o processo com o nível de detalhe e especificidade necessários, são descritos todos
os requisitos que já estão definidos.
Importante observar que a partir do (análise de requisitos), temos setas bidirecionais, que estabelece2º passo
que possa haver um retorno dentre as atividades, principalmente mediante a identificação de um erro na fase
anterior àquela que está sendo executada no momento. Lembre-se que ao término do processo, tudo que estiver
contido no documento de requisito de software deve ser atendido plenamente; portanto, o lapso culminará em
um sistema sem qualidade.
No contexto Na figura 2 está disposta um modelo mais completo, em espiral, do processo de engenharia de
requisitos, segundo proposta por Sommerville (2011):
- -5
Fonte: Figura 2 - Processo de Engenharia de Software em Espiral (Sommerville, 2011)
 Cada uma das atividades será detalhada a partir dessa e nas próximas 3 aulas.Atenção:
3 Estudos de Viabilidade
Para todo projeto que estimamos realizar, seja ele para nós ou para a empresa a qual colaboramos, uma
pergunta muito básica e fundamental sempre deve ser respondida:
Será que contribui para meus objetivos?
Uma estimativa realizada para verificar se as necessidades do usuário podem ser satisfeitas usando correntes de
software e hardware, à custo e prazo efetivo.
A partir então do resultado alcançado da reflexão a partir desse questionamento, é que
No tocante a área da tecnologia da informação e que estamos estudando, vamos então adicionar os seguintes
questionamentos:
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
internação entre diferentes sistemas, será que esta é possível?
- -6
Conforme o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e
organizacional, se o projeto é viável e se representará uma solução capaz de ser executada e de agregar valor.
Portanto, muito antes de pensarmos em requisitos, temos que saber se o sistema pode ser concluído e/ou
mantido, por exemplo.
São outros exemplos de questões que devem ser avaliadas:
De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?
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?
É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)?
Com que facilidade é que se consegue partilhar informação entre estes sistemas?
 Atenção: Analisando dos itens supracitados, percebemos que 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 justifica. Apesar de parecer óbvio, frequentemente constata-se que um determinado
software não contribui 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, porém ele foi
desenvolvido ou até mesmo já adquirido.
3.1 Os Stakeholders no Estudo de Viabilidade
No estudo de viabilidade, é comum termos várias fontes de informações. Tipicamente, temos os seguintes
stakeholders:
- -7
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 a escolha de todos os dados disponíveis para permitir mais exatidão e
visões no âmbito do projeto, permitindo realmente avaliar a sua viabilidade.
A partir das conclusões obtidas, outra atividade no processo de estudo de viabilidade é a produção de um
relatório e deverá determinar a continuaçã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.
O que vem na próxima aula
Na próxima aula, abordaremos os seguintes assuntos:
• O conceito de estudos de elicitação de requisitos.
• O processo e as atividades da elicitação de requisitos.
• A contribuição da elicitação de requisitos na engenharia de software.
CONCLUSÃO
Nesta aula, você:
• Aprendeu o conceito de engenharia de requisitos.
• Compreendeu o conceito de estudos de viabilidade.
• Aprendeu a importância da atividade de estudos de viabilidade.
• Analisou o que deve ser tratado em um documento de estudos de viabilidade.
•
•
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
ELICITAÇÃO DE REQUISITOS
- -2
Olá!
Nesta aula, você irá: 1. Aprender sobre o conceito da elicitação de requisitos.
2. Compreender o processo de elicitar requisitos.
3. Reconhecer a importância da elicitação de requisitos para projetos.
1 Introdução
Seja bem-vindo a segunda etapa das nossas aulas sobre as atividades da área de requisitos.
Continuaremos imersos nos conteúdos sobre a engenharia de requisitos; nossa aula de hoje trabalhar sobre a
elicitação de requisitos, destacando a importância no resultado de um software que atenda as necessidades dos
usuários.
Revisando sobre as quatro atividades da área de engenharia de requisitos (principalmente se precisa revisar
algum assunto), veja ordem abaixo:
Aula 6 - Viabilidade.
Aula 7 – Elicitação.
Aula 8 – Validação.
Aula 9 – Gerenciamento.
Estas atividades fazem parte do que definimos como processo de engenharia de requisito. Lembre-se que não
temos um comportamento e necessidade uniforme na área de software. Quando decidimos construir um sistema,
certamente temos uma necessidade e um perfil que nos torna único, portanto, “em praticamente todos os
sistemas os requisitos mudam.” (Sommerville, 2009). Com base nesse cenário, tornar-se necessário então a
padronização o procedimento, para ter maior convicção da acertabilidade do que está sendo desenvolvido.
Portanto, caso tenha o desejo em atuar na área de projetos, certamente lhe será requerido conhecer bem sobre
as atividades inerentes a engenharia de requisitos, no tocante a entender o real problema do seu cliente. Tendo
em mãos essa importante informação, terás grandes possibilidades de um resultado mais apurado e correto.
Faça um bom proveito!
Vamos lá!
- -3
2 Finalidade de um Software
Conforme tratamos no início do estudo da disciplina, é preciso saber e fazer saber a(s) finalidade(s) de um
software. Portanto, um fundamental questionamento que precisa ficar bem esclarecido para todos os envolvidos
é:
O QUE REALMENTE QUEREMOS?
Exemplo
Fonte: Fonte: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/intro/processo.htm
Análise do Exemplo
A figura anterior demonstra um cenário que envolve dois fatores: céu com nuvens e uma grama verde. Apenas
estes são substancialmente suficientes para diferentes interpretações, sujeitando a diversas soluções que não
compreende a resolução efetivado que se queria. Importante ver que nem mesmo o próprio cliente soube
explicar com exatidão o que ele queria.
- -4
Podemos então rapidamente transferir ao cliente a responsabilidade pela não conformidade do produto
entregue; destituindo-nos de qualquer culpa, então friamente nos posicionamos: “lhe entregamos o que foi
pedido!”
Seria então esse o perfil mais adequado? Certamente que se queremos ser uma empresa de referência para
segmentos de software e/ou engenharia de requisitos, definitivamente, NÃO!
Então imagine um cenário em que o cliente esteja apresentando suas necessidades e seus objetivos para um
sistema computacional. Lá estão alguns diretores e representantes da empresa contratada:
Queremos que o sistema faça: isso, isso, aquilo, isso juntamente com aquilo...
Também podemos então adicionar aquilo outro que vi no do meu colega, que pertence aquela empresa (detalhe: a
empresa é de outro segmento comercial).
Então, quando do uso da palavra (de terno e gravata), fala de maneira convincente:
- Tudo anotado e esclarecido. Tenho certeza que ficará muito satisfeito com o que lhe entregaremos.
A diretoria reúne os usuários que serão “beneficiados” com o sistema; fala sobre como a vida deles mudará –
inclusive já está levantando quantos deverão permanecer na empresa.
Faz o convite para o representante da contratada para prestar esclarecimento.
Novamente, ele faz uma apresentação do seu currículo e em quer resultará o projeto. Detalhe: alguns
funcionários começam a especular perigo de demissão em massa.
Então soa a pergunta:
- Alguém tem alguma sugestão?
O genro de um dos diretores levanta-se na plateia e saúda a iniciativa como sendo de tempos modernos para a
organização, pedindo aos presentes uma salva de palmas.
Depois de algum tempo de espera eis que o documento de requisitos de software está pronto. E é remetido para
análise.
Depois de 18 meses de trabalho,eis então o feedback:
Após a analise de um documento que jugamos muito difícil, chegamos a conclusão que:
- -5
"A parte mais árdua na construção de um software consiste exatamente em identificar o que
construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado
de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções
posteriores." — Fred Brook
3 Elicitação
ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em
questão.
Sob o escopo do analista de negócios, a em inglês “Elicitation”) é a atividade responsável emelicitação (
compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou
operam. Portanto, é preciso saber que existe uma distinção entre “elicitar” e “levantar”, uma vez que o primeiro
termo é mais abrangente é o foco na extração das necessidades verdadeiras, que podem ou não estar explícitas.
A atividade da elicitação dos requisitos não é habitualmente desenvolvida forma isolada, visto que a
identificação de requisitos costuma aparecer de forma cíclica durante sessões tanto de levantamento quando de
- -6
validação, portanto requer uma combinação de técnicas para que seja completa. Conforme estudamos na
primeira unidade, as técnicas de levantamento de requisitos são: brainstorming, análise documental, entrevistas,
observação, prototipagem, workshops de requisitos e pesquisa/questionários.
No tocante as tarefas inerentes ao processo da elicitação dos requisitos, temos: a preparação, condução,
documentação e confirmação dos resultados da elicitação.
A elicitação de requisitos envolve o processo de identificar junto aos stakeholders, frente ao sistema ou produto,
os seguintes pontos:
1. Os alvos a serem alcançados;
2. Os pontos a serem acompanhados;
3. Como se encaixa no contexto das necessidades
do negócio;
4. O comportamento ou operacionalização da
solução rotina da solução na rotina da empresa.
Mas então porque se apresenta como um processo extremamente complexo?
Problemas de escopo excesso ou falta de detalhamento. Os clientes/usuários desconhecem o que é importante: 
(ou até mesmo quer ocultar), inibindo os limites do sistema, o que dificulta uma definição completa.
Problemas de compreensão omitem informações que julgam óbvias; clientes/usuários desconhecem ou estão:
em dúvidas sobre as necessidades e como seu papel é fundamental; é leigo ou limitado no conhecimento de seu
ambiente computacional ou do domínio do seu negócio e etc.
Problemas de volatilidade: mudanças constantes nos requisitos.
A partir deste cenário, algumas ações são sugeridas para superar estes problemas, a fim de uma abordagem
organizada para o processo da elicitação. São eles:
- -7
Independente do tamanho do que esteja sendo construídos, os produtos da utilização dos passos trabalho
incluem:
• Ter totalmente bem estruturadas as necessidades e viabilidade; bem como, a definição do limite de 
escopo do sistema ou produtos;
• A relação de clientes, usuários e outros stakeholders que participaram da atividade de elicitação de 
requisitos;
• Conhecimento descritivo do ambiente técnico do sistema;
• A lista de requisitos e suas respectivas aplicações regras de domínio.
• Cenários de uso que promovem uma concepção do uso do sistema sob diferentes condições de operação;
• Informação de um modelo que eventualmente tenha sido desenvolvido para melhor definir os requisitos
• Revisões realizadas por todas as pessoas que tenham participado da elicitação de requisitos.
O que vem na próxima aula
•
Validação de Requisitos
CONCLUSÃO
Nesta aula, você:
• Compreendeu a necessidade de processo de elicitação de requisitos.
• Perfil do analista de negócios, responsável na condução de elicitação de requisitos.
• Analisou que a elicitar requisitos faz parte de qualquer projeto.
•
•
•
•
•
•
•
•
•
•
•
- -1
REQUISITOS DE SISTEMAS
VALIDAÇÃO DE REQUISITOS
- -2
Olá!
Nesta aula, você irá: 1. Identificar mais uma atividade da engenharia de requisitos.
2. Reconhecer o processo de validação de requisitos.
3. Verificar o motivo e a importância da validação de requisitos.
1 Introdução
O processo de validação de requisitos é também uma fase importante na elaboração de um documento de
requisitos. Mesmo atendendo as etapas de elicitação, pode incorrer que erros passem despercebidos na etapa,
pode criar certos problemas quando esses erros forem detectados numa fase posterior, ou seja, o documento de
requisitos já terá sido validado pelo cliente.
Na etapa de elicitação aprendemos que vamos levantar e evidenciar o requisito. Agora, vamos DEMONSTRAR
que conseguimos compreender e definir bem as características a serem incorporadas no software. Para este
momento, o contatado é quem assume o papel principal, sendo o foco da comunicação; o contratante acompanha
e avalia.
Esse processo da engenharia de requisitos trata em especial dos critérios relacionados à consistência, precisão,
contextualização de requisitos levantados no processo de identificação e descoberta e de análise e negociação de
requisitos.
2 Documento de requisitos de software
Segue uma relação de propriedades que são avaliadas no tocante ao documento de requisitos de software pela
equipe responsável na validação:
Completude e consistência;
Conformidade com os padrões;
Conflitos de requisitos;
Erros técnicos;
Requisitos ambíguos.
- -3
Sommerville (Engenharia de software, 2009) destaca que “o custo para consertar um problema de requisitos por
meio de uma mudança no sistema é geralmente muito maior do que o custo para consertar erros de projetos ou
codificação. A razão para isso é que a ocorrência de mudança dos requisitos normalmente significa que o projeto
e a implementação do sistema devem ser alterados”.
Daí então a característica crítica nessa atividade, e o destaque como sendo um dos mais importantes na
engenharia de requisitos. Tendo em visto que um documento de requisitos bem definido permite aos envolvidos
atuar de maneira consistente nas