FACULDADE DO LITORAL SUL PAULISTA – FALS
CLAYTON DE SOUZA SILVA
REQUISITOS DE SOFTWARE
PRAIA GRANDE
2010
CLAYTON DE SOUZA SILVA
REQUISITOS DE SOFTWARE
Trabalho de conclusão de curso, Faculdade do
Litoral Sul Paulista, sob orientação do Prof.
Ana Lucia Pegetti.
PRAIA GRANDE
2010
CLAYTON DE SOUZA SILVA
REQUISITOS DE SOFTWARE
Trabalho de conclusão de curso, Faculdade do
Litoral Sul Paulista, sob orientação do Prof.
Ana Lucia Pegetti.
AVALIAÇÃO:_________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
NOTA: ____(____________)
________________, ___de____________de______.
Local
data
RESUMO
A Engenharia de Software é uma disciplina distinta que utiliza um conjunto de
métodos, técnicas e ferramentas para analisar, projetar e gerenciar desenvolvimento
e manutenção de software. O conjunto de técnicas de levantamento, documentação
e análise forma a engenharia de requisitos, que é uma das disciplinas da Engenharia
de Software, após ser estabelecido os requisitos teremos um projeto que definirá os
objetivos e necessidades que deverão ser alcançados, possibilitando a definição do
escopo do projeto com precisão, nesta fase é necessário detalhar todos os aspectos
funcionais e não-funcionais estabelecendo um conjunto de especificações com um
nível máximo de detalhamento, neste caso os requisitos de software é o processo de
identificação de todos os envolvidos onde é documentado para análise e posterior
implementação.
PALAVRAS CHAVES: Requisitos e projetos.
ABSTRACT
Software Engineering is a discipline that uses a distinct set of methods, techniques
and tools to analyze, design and manage development and maintenance of software.
The set of elicitation techniques, documentation and analysis as to requirements
engineering, which is one of the disciplines of Software Engineering, having been
established requirements will have a project that will define the goals and needs to
be achieved, allowing for the scoping project with precision at this stage is necessary
to detail all the functional and nonfunctional establishing a set of specifications with a
maximum level of detail, in this case the software requirements is the process of
identifying all those involved where it is documented for analysis and subsequent
implementation.
KEYWORDS TOOL: Requirements and projects.
SUMÁRIO
1.
INTRODUÇÃO ............................................................................................................................ 1
2.
JUSTIFICATIVA .......................................................................................................................... 2
3.
OBJETIVO DO TRABALHO ..................................................................................................... 3
4.
REFERENCIAL CONCEITUAL ................................................................................................. 4
4.1. Objetivos da Engenharia de Software............................................................................5
4.2. Princípios da Engenharia de Software...........................................................................6
4.3. Processos de Software...................................................................................................7
4.4. Tipos de Processos.........................................................................................................8
5.
ENGENHARIA DE REQUISITOS E SEUS PROCESSOS ................................................... 12
5.1 Ciclos de Vida do Software.........................................................................................13
5.2 Etapas do Projeto de elaboração de Software..............................................................17
5.3 Projetos e seus processos.............................................................................................18
6.
REQUISITOS DE SOFTWARE .............................................................................................. 21
6.1 Modelo do Problema....................................................................................................24
6.2 Modelo do Sistema......................................................................................................25
6.3 Modelagem do Processo, Caso de Uso e Qualidade de Software...............................26
7.
TIPOS DE REQUISITOS DE SOFTWARE .......................................................................... 30
7.1 Requisitos de Usuários.................................................................................................32
7.2 Especificação e Analise de requisitos de software......................................................34
7.3 Requisitos e interfaces externas...................................................................................35
8.
CONCLUSÃO............................................................................................................................. 36
9.
ANEXOS MODELOS DE DOCUMENTOS DE REQUISITOS............................................ 37
10. REFERENCIAS BIBLIOGRAFICAS ...................................................................................... 41
11. REFERENCIAS ELETRONICAS ............................................................................................ 42
SUMÁRIO DAS FÍGURAS
1.
FIGURA 1 (Processo de engenharia de software) ........................................... 7
2.
FIGURA 2 (Modelo Cascata) .............................................................................................. 8
3.
FIGURA 3 (Desenvolvimento de software)..................................................... 10
4.
FIGURA 4 (Espiral ............................................................................................ 10
5.
FIGURA 5 (Analíse de requisitos de software) .............................................. 13
6.
FIGURA 6 (Gerenciamento dos requisitos).................................................... 23
7.
FIGURA 7 (Processo interativo) ...................................................................... 27
8.
FIGURA 8 (As macro atividades da fase de RU) ........................................... 33
1.
INTRODUÇÃO
Nos projetos da engenharia de software evoluem da necessidade para a
idéia e desta para a realidade, a disciplina de requisitos de software auxiliará a reunir
as atividades que procuram obter o enunciado completo, claro e preciso dos
requisitos de um projeto de software. Requisitos são objetivos ou restrições estabelecidos
por clientes e usuários que definem as suas diversas propriedades do sistema. Os requisitos de
software são, obviamente, os requisitos de sistema que dizem respeito a propriedades do
software. Os requisitos de software de uma maneira objetiva é a base para a criação de um
sistema com a menor probabilidade de erro ou falha. Um sistema de software é caracterizado
por um conjunto de componentes abstratos como uma estrutura de dados e um algoritmo,
unidos como uma forma de procedimento, funções, módulos, objetos ou agentes que de certa
forma estão ligados compondo assim a Engenharia de Software, onde deverão ser executados
em sistemas computacionais. Os fundamentos da Engenharia de Software são os modelos
abstratos e preciosos, permitindo à especificação, o planejamento, a implementação e até
mesmo manter um sistema com uma avaliação continua, garantindo assim sua qualidade.
A importância da Engenharia de Software é que tem como objetivo principal o
melhoramento da qualidade do software e um aumento da produtividade, por este motivo é
fundamental ser bem estabelecido antecipadamente os requisitos de desenvolvimento de
software, estes requisitos auxiliarão tanto para o desenvolvimento quanto para diagnosticar
possíveis falhas no momento de implantação do sistema, isso ocorrera devido ao fato dos
requisitos terem como finalidade serem utilizados ate mesmo como base para um
desenvolvimento, sendo estabelecidos por pessoas ligadas diretamente ao produto final.
7
2.
JUSTIFICATIVA
A grande importância de se abordar os requisitos de software é chegar a um
alcance da qualidade e quando é possível se alcançar todos os requisitos pré
estabelecidos, antecipando e satisfazendo as necessidades do cliente, a qualidade é
escrever previamente tudo o que devera ser realizado e se cumprir este relatório pré
estabelecido, quanto maior a precisão e menor a margem de erro no
desenvolvimento e implantação do projeto, será mais fácil de obter o sucesso.
Por isso é fundamental constantes analises dos relatórios onde são
denominados de requisitos de software, normalmente estes requisitos são
estabelecidos antes do desenvolvimento de processos, onde esses requisitos
deverão ser levantados pela equipe do projeto juntamente com o representante do
cliente, usuário, e possivelmente, especialistas na área de aplicação.
A engenharia de requisitos é o principal passo para o desenvolvimento de um
bom produto em qualquer caso, os requisitos de alta qualidade são aqueles que
possuem uma linguagem clara, consistentes, completos e testáveis. A definição dos
requisitos consiste em uma lista em que são relatados todos os requisitos funcionais
e os principais requisitos não-funcionais, sendo fundamental a identificação dos
atores, dos casos de uso, dos relacionamentos entre atores, dos relacionamentos
entre atores e os casos de uso, dos diagramas de contexto, das restrições de
memória, dos modos de operação, dos requisitos de adaptação ao ambiente, das
restrições ao produto, das hipóteses de trabalho.
A principal função do analista de requisitos é auxiliar o gerente de projeto e
também do desenvolvedor, pois são lançados fundamentos das atividades de
análise. O principal resultado devera ser um pacote de descrição geral, da visão de
requisitos do modelo do problema.
8
3.
OBJETIVO DO TRABALHO
O principal objetivo desta monografia é abordar de uma forma mais detalhada as
principais restrições estabelecidas por clientes e usuários e apresentar as principais
dificuldades e falhas que ocorrem em um projeto de software na elaboração de seus
requisitos.
“Desenvolver software é uma atividade complexa por natureza. Uma
das razões para esta afirmação é que não existe uma única solução para
cada cenário de desenvolvimento. Além disso, lidamos o tempo todo com
pessoas, o que torna o sucesso do projeto bastante relacionado à
competência da equipe e à forma como trabalham, e, para dificultar ainda
mais, muitas vezes não fazemos uso de um processo bem definido para
apoiar as atividades do projeto”. (Artigo Engenharia de Software – Ana
Luiza Ávila – UNIFACS – 2008)
Conforme o artigo citado anteriormente, o que leva a uma motivação para
aprofundamento do estudo sobre requisitos de software, é a busca por um resultado
positivo no final da elaboração do projeto, para que isso ocorra é muito importante
que os requisitos sejam bem definidos.
Outro foco desta monografia é demonstrar com uma linguagem clara e objetiva
as definições e a importância de cada fase do desenvolvimento de um projeto, para
que se possa conquistar uma validação da empresa
9
4.
REFERENCIAL CONCEITUAL
Engenharia de Software – Fundamentos, métodos e padrões
Visando melhorar a qualidade dos produtos de software e aumentar a
produtividade no processo de desenvolvimento, surgiu a Engenharia de Software. A
Engenharia de Software trata de aspectos relacionados ao estabelecimento de
processos, técnicas, métodos, ambientes e ferramentas de suporte ao desenvolvimento
de software, os processos seguem os métodos e estes de utilizam de ferramentas
visando solucionar problemas referentes ao processo e ao produto, seu objetivo é
estabelecer uma abordagem de desenvolvimento, através de ferramentas e técnicas
apropriadas, considerando restrições e recursos disponíveis.
Os métodos utilizados na engenharia de software são abordagens estruturadas
para o desenvolvimento de software que também incluem os modelos de software,
notações, regras e maneiras de desenvolvimento.
Segundo MARTIN e McCLURE (1991) a engenharia de software é: “o estudo dos
princípios e sua aplicação no desenvolvimento e manutenção de sistemas de software...
tanto a engenharia de software como as técnicas estruturadas são coleções de
metodologias de software e ferramentas...”
Para MAFFEO (1992) a engenharia de software é: “a área interdisciplinar que
engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático
(modular), os processos de construção, implantação e manutenção de produtos de
software com qualidade assegurada por construção segundo cronogramas e custos
previamente definidos”.
Segundo SOMMERVILLE (1992) a engenharia de software envolve questões
técnicas e não-técnicas, tais como a especificação do conhecimento, técnicas de projeto
e implementação, conhecimentos dos fatores humanos pelo engenheiro de software e
ainda, gestão de projetos.
Para PAULA FILHO (2001) a engenharia de software é conexa. Porém distinta, e
envolve múltiplas variáveis, tais como arte, atendimento das necessidades humanas,
10
conhecimentos científicos, conhecimentos empíricos, habilidades especificas, recursos
naturais, formas adequadas, dispositivos, estruturas e processos. Não deve ser
confundida com a ciência e fornece problemas para seus estudos.
Segundo CARVALHO e CHIOSSI (2001) a engenharia de software é uma
disciplina que reúne metodologias, métodos e ferramentas a serem utilizados, desde a
percepção do problema até o momento que o sistema desenvolvido deixa de ser
operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao
produto de software.
Outras definições de engenharia de software costumam omitir a vertente gerencial.
Concentram-se apenas no aspecto tecnológico do problema. Os aspectos gerenciais do
desenvolvimento de software devem receber uma atenção cada vez maior nessa
disciplina (PRESSMAN, 1995).
Nesse sentido, a engenharia de software pode de caracterizar por um
desenvolvimento de software pratico, ordenado e medido para produzir sistemas
satisfatórios aos usuários e que respeitem prazos e orçamentos (PETERS; PEDRYCZ,
2001).
Os benefícios dos novos ambientes de desenvolvimento de software sejam
significativos, porém é importante ressaltar que os seus elementos básicos são as
pessoas. Desta forma é essencial estabelecer que seja feito um planejamento no
contexto de engenharia de software, para que assim suas necessidades sejam atendidas.
Ao englobar as duas vertentes, tecnológica e gerencial, a definição para Engenharia de
Software indica para a necessidade dos dois temas, desta forma ocorrera uma
aprimoramento dos conhecimentos e métodos dessa disciplina, além de colaborar para
os aspectos particulares de cada vertente.
4.1 - Objetivos da engenharia de software
A engenharia de software tem como objetivo sistematizar a produção, evolução, a
manutenção e a recuperação de produtos de software, de maneira que seja executado
dentro de prazos e custos estimados, sempre utilizando métodos, tecnologia e processos.
Os produtos que são desenvolvidos seguindo efetivamente esse processo e os preceitos
11
da Engenharia de Software tendem a atender uma qualidade satisfatória, deixando assim
os seus usuários satisfeitos com suas tarefas.
De modo geral, considera-se que os objetivos primários da Engenharia de
Software são o aprimoramento da qualidade dos produtos de software e o aumento da
produtividade dos engenheiros de software, além do atendimento aos requisitos de
eficácia e eficiência, ou seja, efetividade (MAFFEO, 1992)
Nesses casos de elaboração de produtos industriais e elaboração de sistemas de
software, é necessário que seja feita a analise e especificação dos requisitos de forma
rigorosa, à medida que seja considerado um produto que se deve haver manutenção
durante esse tempo, essa característica impõe ao software uma complexidade em
relação aos produtos tradicionais da engenharia, mas dificilmente modificam-se durante a
operação.
Associação a esses objetivos, o termo engenharia pretende indicar que o
desenvolvimento de software deve submeter-se a leis similares as que governam a
manufatura dos produtos industriais e engenharias tradicionais, pois ambos são
metodológicos (MAFFEO, 1992).
4.2 - Princípios da engenharia de software
Alguns princípios fundamentais deram inicio a engenharia de software, que devem
ser levadas em consideração nas aplicações dos softwares nas organizações, esses
elementos podem ser utilizados no processo em um produto final do software. O
relacionamento entre processo e produto são muito próximo, quando um está correto o
resultado do outro também estará.
Os princípios requerem metodologias pertinentes e adequadas aos métodos e
ferramentas que incorporam as propriedades desejadas aos processos e aos produtos do
software (CARVALHO; CHIOSSI, 2001).
Segundo (GUEZZU; JAZAYERI, 1991) alguns princípios podem ser destacados:
formalidade para evitar a dependência e determinadas pessoas ou processos; abstração
para identificar aspectos importantes de determinado fenômeno; decomposição para
12
subdividir problemas complexos; generalização para disseminar soluções semelhantes e
reutilizar resultados; e flexibilização para facilitar eventuais mudanças modulares.
4.3 - Processos de software
Os processos de software têm fundamentos e conceitos que equivalem a
metodologias de desenvolvimento e manutenção de software, ambos são bases para a
elaboração de software que contenham fases, subfases, produtos externados e pontos de
avaliação de qualidade.
Figura 1 - www.alexandrebartie.spaces.live.com
Conforme a demonstração anterior, um processo de engenharia de software pode
ser caracterizado por um tipo de modelo que estabeleça a forma de sistematização e que
consiga controlar todas as atividades relacionadas à construção de softwares. Um bom
processo deve ser estruturado em disciplinas que possibilitem o gerenciamento dos
aspectos que estejam em um nível mais critico. Cada disciplina tem um determinado foco
dentro do processo e define de que forma irá se organizar, conduzir e avaliar os
procedimentos relacionados a estes aspectos críticos.
13
Porém, um processo de software é um modelo estático que indica de que maneira
deve lidar com seus projetos de softwares. Conforme novas técnicas e ferramentas são
criadas, naturalmente novas tecnologias são disponibilizadas e novos obstáculos são
superados.
Um processo é um conjunto de passos parcialmente ordenados, constituídos por
atividades, métodos, práticas e transformações, usado para atingir uma meta. Essa meta
está associada a uma ou mais resultados concretos finais, que são os produtos da
execução do processo (PAULA FILHO, 2001).
Um processo deve conter documentações para que se possa relatar o que será
feito, quando e quem irá desenvolver, é preciso os requerimentos de necessidades e os
resultados, o nível de aprofundamento e detalhamento dos processos a serem
executados é decidido pela equipe de desenvolvimento do software. Os integrantes dessa
equipe têm a liberdade de acrescentar detalhes ou até mesmo suprimir partes, desta
forma é permitido alterar a sua ordem e executar paralelamente outras atividades, um
subprocesso é caracterizado por elementos de um processo
4.4. Tipos de processos
Modelo Cascata
Figura 2 - Artigo: Metodologias Ágeis para desenvolvimento de software – www.cpdti.com.br
14
O modelo cascata tem como referência fases bem definidas, com inicio e término
para as próximas fases, de forma seqüencial. Para que possa dar sequencia às próximas
fases é necessário obter um laudo da fase anterior com a aprovação para a próxima
etapa. Um processo pode ser subdividido em diversas formas, mas basicamente o
contexto principal consiste nas fases acima demonstradas na figura 2.
Requisitos: Tem como embasamento os famosos stakeholders (clientes, usuários,
gerentes, etc.), pois são eles que estão ligados diretamente ao projeto em questão,
podendo ser usuários ou até mesmo futuros usuários.
Análise: As especificações de requisitos transformam-se em modelos de software,
mas sem obter muito detalhamento técnico.
Projeto: São baseados na análise, nesta fase os modelos são detalhados para uma
futura aplicação, os modelos representam de uma forma mais “concreta” o problema que
for especificado.
Implementação: Nesta fase o projeto e análise são implementados, de uma maneira
mais automatizada utilizando linguagens de programação.
Testes: São realizados testes unitários e conseqüentemente testes integrados, desta
forma contendo todo o software.
Implantação: É a fase em que o software é colocado em prática, diversas atividades
são relacionadas, como por exemplo: bases de dados com dados reais, treinamento,
instalação, etc. Porém as suas atividades dependeram muito da empresa e do ambiente
em que o software irá ser executado.
Com ou sem especificações dos requisitos funcionais os desenvolvedores de
software codificam ou programam os processos.
15
Figura 3 - Artigo: Modelo de desenvolvimento de software – www.inf.unisul.br
Os processos são determinados por uma seqüência de desenvolvimento de software
com demarcações predefinidas de avaliação. Caso o processo não permita certa
flexibilidade do retorno nas seqüências, ele causará percas valiosas para seu usuário
final.
As suas fases são: definição e analise dos requerimentos do software; projeto do
software, implementação e testes; implantação e integração do produto, em cada tipo de
fases são definidas suas respectivas atividades e a partir desse conceito os produtos de
saída são gerados.
Espiral
Figura 4 - www.engsoftwaredpsi.blogspot.com
16
Esse processo permite varias repetições entre as fases do desenvolvimento, cada
repetição implica numa volta ao modelo espiral, desta maneira os desenvolvedores
podem alcançar os resultados desejados em menos tempo, esse tipo de modelo de
processos necessita de uma atenção especial dos seus gestores no que diz respeito ao
processo de repetições, principalmente quanto à qualidade de seus produtos gerados.
Entrega por estágios
Esse processo de software libera partes do software aos clientes ou usuários finais.
É uma combinação dos modelos cascata e prototipagem evolutiva.
17
5.
ENGENHARIA DE REQUISITOS E SEUS PROCESSOS
Todo projeto de software deverá ser desenvolvido a partir dos requisitos que
deverão ser estabelecidos, antes mesmo de sua inicialização. Antes da analise e
determinação dos requisitos é importante que os pré-requisitos sejam estabelecidos,
pois a partir deles é que será tomada a grande maioria das decisões para o seu
desenvolvimento.
De uma forma mais ampla pode-se dizer que a palavra “projeto” possui um
significado de “empreendimento”, e é um trabalho que visa à criação de um produto
ou a execução de um serviço especifico temporário, ou não repetitivo, e que envolve
de certa forma um grau de incerteza na sua realização. O trabalho de uma forma
geral normalmente é executado por pessoas que irão consumir horas, estão
limitadas no prazo, custo e escopo. Como em qualquer momento, empreendimento
ou realização é necessário que seja feito, um planejamento, programados, e durante
a sua execução é fundamental um monitoramento.
O perfil do profissional de qualidade é ser um profissional que tenha a
desenvoltura de se encaixar a todos os tipos de cliente final, ou seja, um profissional
eclético, que tenha conhecimentos técnicos, mas que também tenha o conhecimento
de negócios e principalmente do comportamento humano, isto é importante para que
possa atender as necessidades dos clientes de acordo com o seu perfil.
O comportamento humano, etnias e políticas estão de certa forma ligada às
atividades de sistemas ou software.
Existem também algumas atividades e habilidades que são adquiridas pelo
mercado, para que se possa atingir a qualidade, produtividade e efetividade total,
porém é necessário, que se tenha uma postura adequada e domínio das habilidades
técnicas.
18
5.1. Ciclos de vida do software;
O processo inclui a elaboração de um produto, esta elaboração poderá ser
referida como ciclo de vida, pois ela relata a “vida” do produto de software, desde a
concepção até a implantação, entrega, utilização e manutenção
É fundamental no momento de desenvolvimento, estabelecer o ciclo de vida,
determinar o usuário final, podendo ser um funcionário da organização, um cliente,
departamento de marketing ou vendas da organização produtora, este ciclo de vida
normalmente é feito a partir da percepção das necessidades, estará sujeito à
manutenção quando necessário e será retirado de operação ao final de sua vida útil.
Figura 5 - Análise de requisitos de software – www.eps.ufsc.br
Um ciclo de vida possui divisões e subdivisões, é fundamental observar a
codificação que representa a escrita final, essa codificação é uma das principais
tarefas do desenvolvedor de software.
Muitas vezes o ciclo de vida é confundido com modelo de processo, o ciclo de
vida descreve as fases do software, desde a sua criação até o fim de seu uso.
Diversas denominações podem ser usadas para as fases do ciclo de vida de um
software, neste modelo que veremos a seguir são 4 fases, cada fase possui suas
atividades. Essas fases são:
19
Definição
Desenvolvimento
Operações
Retirada
Nesta fase de definição do software é possível agir em conjunto com outras
atividades como a análise de sistemas e a modelagem de processos de negócios. É
essencial saber primeiramente identificar os problemas, para que a partir daí possa
criar uma proposta de solução de sistemas computacionais, nesta proposta deve-se
incluir a analise e o custo-benefício do projeto, informações sobre hardware,
software, procedimentos, informação e documentação.
Não existe uma regra para se determinar o fim da fase de definição, isto varia
muito com a complexidade do modelo de processo, dependendo do modelo adotado
a fase de desenvolvimento pode iniciar antes mesmo que a fase de definição seja
totalmente concluída.
Na fase de desenvolvimento é subdividido em etapas como design,
implementação, verificação e validação de software.
Design é a parte ilustrativa do projeto que é subdividido em design conceitual,
design de interface do usuário, design da arquitetura de software e design dos
algoritmos e estruturas de dados.
Design conceitual é a determinação dos elementos fundamentais de um
software exercendo uma influencia da interface de usuário e na arquitetura do
software.
Design da interface de usuário é a estrutura principal para o sucesso do
software, pois é a maneira do usuário realizar suas tarefas o layout das janelas e
telas.
Design de arquitetura de software é subdividida em visão conceitual, visão
módulos, visão de códigos e visão de execução; A visão conceitual é de uma
20
maneira geral uma arquitetura de camadas e arquitetura cliente/servidor é composta
por componentes conceituais.
Design de algoritmo e estruturas de dados é a linguagem de programação
adotada, soluções algorítmicas e estruturas de dados associados.
A implementação são as atividades de codificação, compilação, integração e
testes. A codificação é a transparência da estrutura e o comportamento descrito no
design, seu principal objetivo é traduzir design no programa, utilizando-se de
linguagem e ferramentas adequadas. No momento da implementação é fundamental
um gerenciamento de versões para um controle correto de tudo que esta sendo
codificado.
Verificação e validação, principal função é analisar se o sistema esta de
acordo com as expectativas de cliente e usuário, a validação assegura se o
programa está de acordo com a definição e especificação, a verificação visa analisar
se possui erros de execução, existem formas que podem ser utilizadas antes do
programa ser codificado, como inspeção analítica e revisão de modelos, documentos
e código fonte. A partir da execução de software existem vários fatores para uma
analise de qualidade como, teste de correção, desempenho, confiabilidade,
robustez, usabilidade, dentre outros, dentre estes fatores pode-se utilizar variadas
técnicas para aplicação.
A fase de operação do software é subdividida em atividades;
Distribuição e entrega;
Instalação e configuração
Utilização
Manutenção
A distribuição e entrega pode ser feita de uma forma mais direta pelo
desenvolvedor (quando personalizado), ou em pacote que poderão ser vendido por
prateleiras de lojas, ou ate mesmo para ser baixado pela internet.
21
O processo de instalação e configuração. Poderá ser feito com o auxilio de
softwares de instalação, que são disponibilizados por fabricantes de ambientes
operacionais.
O processo de utilização assim como o nome já diz é a usabilidade do
software.
O processo de manutenção poderá ser feito de duas maneiras: corretiva e
evolutiva. A manutenção corretiva tem como seu objetivo principal a solução de
problemas que poderão interferir na qualidade do software, como: falhas, baixo
desempenho, entre outros. A manutenção evolutiva que também poder ser nomeada
como evolução adaptativa, procura atender todos os requisitos do cliente através da
criação de novas versões de software, ou adaptando as novas tecnologias que
poderão surgir como (hardware, plataformas, linguagens, entre outros). No momento
em que ocorrem novas mudanças, novas tecnologias de software e hardware,
requerem uma evolução continuada.
A fase Retida é uma das etapas mais difíceis, principalmente nos tempos
atuais, pois a empresa de certa forma esta operando softwares que possuem
excelentes níveis de confiabilidade e de correção, mas é necessário uma evolução
para uma acompanhamento do desenvolvimento de uma maneira geral, para
acompanhar os novos requisitos exigidos, também é considerada uma situação
difícil, pois isso pode exigir ate mesmo que haja um treinamento da equipe operante,
pois será um software novo, com novas exigências e comandos, onde a equipe não
estará acostumada a lidar.
Um fator também que dificulta este processo é a questão da confiabilidade,
pois de uma maneira geral a organização já esta acostumada, confia no
desenvolvimento de seu trabalho, tem consciência que o novo software servira para
um aperfeiçoamento do anterior, mais muitas vezes poderão existir resistências do
setor, no período de adaptação.
O processo de software poderá ser aplicado para viabilizar a transferência de um
software anterior para um novo proporcionando assim uma substituição suave.
22
O projeto de uma maneira geral é dividido em fases para se ter um controle
gerencial e permitir uma melhor sintonia com os processos gerenciais, essas são
determinadas como ciclo de vida de um projeto.
O desenvolvimento de software é feito através do projeto, em todo projeto é
indispensável uma data de inicio e uma data de fim, uma equipe juntamente a um
gerente de projeto e outros recursos, ou seja, um projeto é a execução de um
processo.
Se o processo é bem estabelecido deverá ter subdivisões que permita a
avaliação e correção, em caso de problema essas subdivisões são denominadas de
fases, atividades ou interações, as subdivisões devem ser terminadas por marcos,
sendo associados a resultados concretos como documentos, modelos ou porções do
produto. O produto será associado ao marco de conclusão do projeto.
5.2. Etapas do Projeto de elaboração do software;
A base de um projeto é a identificação das partes interessadas (stakeholders),
ou seja, os responsáveis pelo resultado do empreendimento, mas existem outros
interesses que devem ser considerados como os próprios desenvolvedores, os
dirigentes da organização, os fornecedores de insumos e subcontratados e
autoridades reguladoras. Estas partes no momento de atividade de especificação,
planejamento, decisão, comunicação, revisões e avaliações, podem ter suas
participações. Nem sempre será viável o envolvimento de todas as partes, exceto o
seu ponto de vista que deverá ser representado por um componente da equipe.
Este plano de projeto poderá ser composto de uma variedade componente para
o seu desenvolvimento.
Para o desenvolvimento de software é necessária a estruturação das tarefas
requeridas para a elaboração com alta qualidade, pois o foco principal do
desenvolvimento de software é a qualidade utilizando processos, métodos e
ferramentas.
23
Caso o processo de desenvolvimento de um produto o resultado não seja
satisfatório, sem duvida o produto obtido também será de baixa qualidade, desta
forma vale ressaltar que não se deve focar apenas no processo, mas também no
produto.
O desenvolvedor de software necessita de uma resulto satisfatório tanto no
processo de desenvolvimento como no resultado final.
5.3. Projeto e seus processos;
“Um fator que impulsiona o gerenciamento de projetos é o crescimento da
competitividade. Quem for mais rápido e competente certamente conseguira
melhores resultados”. (VARGAS, 1999, p.5)
Processo de gerenciamento do projeto é composta de um conjunto de processos
que geram um produto final, este produto final precisa ser avaliado pela equipe
envolvida ao seu termino. Alguns desses processos são:
Processo de inicialização que é o momento em que o seu objetivo é reconhecer
que um produto ou fase devera começar e se comprometer para a sua execução.
Processo de Planejamento que tem como objetivo planejar e manter o esquema
de trabalho com um meio de se atingir as exigências do projeto.
Processo de execução tem como objetivo e foco principal a coordenação de
pessoas e outros recursos para se executar o plano como um todo.
Processos
de
controle
procuram
se
manter
um
controle
quanto
ao
desenvolvimento do projeto em questão, por meio de monitoramento e avaliação do
seu processo, tomando ações e decisões quando necessário.
Para se atingir os níveis de organização independente da quantidade de
pessoas envolvidas o projeto muitas vezes extrapola fronteiras atingindo até os
24
fornecedores, clientes, parceiros e governo podendo fazer parte da estratégia de
negocio da companhia.
Alguns exemplos de projetos:
Redação de uma livro
Remuneração de um determinado setor
Remuneração de um departamento da empresa
Elaboração de um plano de marketing e publicidade
Lançamento de um novo produto ou serviço
Informatização de um determinado setor da empresa
Aperfeiçoamento e substituição do software utilizado
Realização de uma viagem
O gerenciamento de processo de produção esta associado ao desenvolvimento
tendo a necessidade de aplicação de métodos, técnicas e ferramentas, para isto é
necessário que se tenha um planejamento de custos e prazos, montagem da equipe
qualificada e garantia de qualidade do produto e do processo.
A área de gestão de projetos normalmente é composta por nove áreas de
conhecimento em gerenciamento de projetos:
Gerenciamento de integração é um subconjunto do gerenciamento de projetos
que procura assegurar que todos os elementos do projeto sejam coordenados de
forma adequada.
Gerenciamento de escopo é um subconjunto do gerenciamento de projetos que
analise se todas as exigências e contextos que estão inclusos para uma elaboração
bem sucedida.
Gerenciamento de tempo é um subconjunto do gerenciamento de projetos que
visa que o projeto e seu desenvolvimento ocorram dentro do prazo previsto.
25
Gerenciamento de custos é um subconjunto do gerenciamento de projetos que
analise e vistoria se o projeto esta de acordo com Orçamento pré-estabelecido.
Gerenciamento de qualidade é um subconjunto do gerenciamento de projetos
que visa que seu produto esteja em conformidade com o cliente e ou contratante,
com a melhor qualidade conforme contratada.
Gerenciamento de recursos humanos é um subconjunto do gerenciamento de
projetos que tem como objetivo melhor o envolvimento de uma forma adequada das
pessoas do projeto.
Gerenciamento das comunicações é um subconjunto do gerenciamento de
projetos que visa que assegurar que as informações obtidas, comunicadas e
disseminadas, ocorram de uma forma adequada.
Gerenciamento de riscos é um subconjunto do gerenciamento de projetos onde
são analisados todos os riscos que estabelecidos, previamente, durante e após a
elaboração dos projetos. Na maioria das vezes estes riscos são determinados de
acordo com o perfil principal do cliente em questão.
Gerenciamento de suprimentos é um subconjunto do gerenciamento de projetos
administra a forma de aquisição de bens e serviços fora da organização provedora
do projeto em questão.
26
6.
REQUISITOS DE SOFTWARE:
A fase inicial para a elaboração dos requisitos é a elicitação de
requisitos, onde nesta fase serão determinadas as funções do software, ou seja,
identificar de uma forma conjunta com o cliente/usuário quais serão os objetivos do
sistema, de que maneira o sistema deverá se adequar as necessidades do negócio.
A parte mais complexa na criação de um software é conseguir identificar de maneira
correta o que se deve construir, para que assim a aplicabilidade do sistema possa se
encaixar com o que o projeto esteja impondo, essa fase do projeto pode
comprometer o resultado final caso não seja elaborado um escopo de forma
completa, os limites do sistema bem definidos e também é muito importante uma
boa comunicação e compreensão entre o desenvolvedor e o cliente/usuário, é
importantíssimo que o cliente/usuário detalhe as informações para o desenvolvedor
definindo as necessidades que o sistema deverá abranger. A forma mais utilizada
para superar esses obstáculos é a simplicidade na hora de abordar os requisitos,
quanto mais direta e objetiva a informação for passada, mais fácil ficará o
entendimento de ambas as partes.
Na fase da análise dos requisitos é preciso que tenha um grande
conhecimento e entendimento dos requisitos de software, nada adianta ser feito se o
programa for analisado e especificado de maneira errada, o resultado final com
certeza não irá satisfazer o cliente-usuário. A análise de requisitos requer um
processo de modelagem, refinamento e especificação, diagramas, modelos, e fluxos
também são utilizados para que o problema a ser resolvido possa ser bem
explicitado de uma maneira que faça com que o entendimento seja visivelmente
identificado. A analista é tido como um consultor e solucionador de problemas,
porém a análise e especificação de requisitos não são tarefa fácil, a
comunicabilidade entre as partes é constante, por este motivo a chance de ocorrer
algum tipo de erro é maior devido a má interpretação de alguma informação que
tenha sido passada.
A documentação dos requisitos é a parte formal do processo, significa
a especificação oficial dos requisitos do sistema para cliente/usuário final, e para o
desenvolvedor do software. A documentação de requisitos deve descrever todos os
27
serviços e funcionalidades que o sistema deve oferecer, quais são suas restrições,
informações sobre o domínio da aplicação, a documentação dos requisitos é tido
também como um contrato entre o cliente/usuário e o gerente de projeto, pois válida
o acordo firmado segundo a especificação requerida dos requisitos do cliente. A
documentação de requisitos é utilizada também para que possa comunicar as
necessidades do sistema a todos os envolvidos no processo de desenvolvimento de
software. É necessária uma estrutura para a elaboração dessa documentação dos
requisitos, esta estrutura deverá conter introdução, propósito do documento, escopo,
definições, acrônimos e abreviações, referências, casos de uso, diagramas, entre
outros.
O processo de verificação e validação dos requisitos de software serve
como base para que o software possa cumprir com as suas especificações e assim
atenda às necessidades dos clientes/usuários. O processo de validação e
verificação é muito abrangente, devem ser aplicados a cada etapa no que se diz
respeito ao processo de desenvolvimento, seus principais objetivos são relatar
algum possível erro no sistema e garantir se o sistema será ou não plausível de
utilização operacional. É necessária a realização de testes de programas que
auxiliará na identificação de possíveis erros ou ausência, existem alguns tipos de
testes, dois exemplos de testes são os testes de defeito e os testes estatísticos. Os
testes de defeito realizam testes com o intuito de descobrir defeitos do sistema, para
que um teste seja bem sucedido é necessária a presença de defeitos no sistema, os
testes estatísticos normalmente
utilizados para
testes de desempenho
e
confiabilidade dos programas, ou seja, tempo de execução e tempo de resposta,
devendo ser utilizados de forma paralela com a verificação estática para a validação
tendo uma cobertura total das atividades.
As metas estabelecidas no processo de validação e verificação dos requisitos
de software estabelecem um vínculo de confiança se adequando ao seu propósito,
devendo ser suficientemente adequado para o uso, o tipo de uso identificara o grau
de confiança que será necessário, não significando que será totalmente livre de
defeitos. A confiança estabelecida no processo de validação e verificação será de
acordo com o propósito do sistema, atendendo as necessidades dos usuários e do
ambiente de mercado, a função e as expectativas do software será de acordo com
28
as exigências da organização, o ambiente de mercado tem como o objetivo principal
inserir produtos no mercado, sendo mais importante esta inserção do que encontrar
os defeitos dos programas. A verificação e validação e teste, tem como foco principal
estabelecer a existência dos problemas e defeitos de um programa, já a depuração
esta com um foco maior na eliminação desses defeitos
O Processo de gerenciamento dos requisitos de software é o conjunto de
todas essas etapas descritas anteriormente estando associada aos principais
problemas e necessidades do desenvolvimento de software ele serve como um
estrutura base para as próximas etapas.
1. FIGURA 6 - ARTIGO DA REVISTA ENGENHARIA DE SOFTWARE – ARTIGO
ENGENHARIA DE SOFTWARE – INTRODUÇÃO A ENGENHARIA DE REQUISITOS.
WWW.DEVMEDIA.COM.BR
As atividades de produção de requisitos é uma concentração da maioria
dos processos de engenharia de requisitos, com o fluxo entre as atividades, na há
limites impostos entre elas.
29
No dia-a-dia há muita relação entre as atividades, no inicio do processo
são consideradas:
As descrições estabelecidas pelos stakeholders,
As informações necessárias para a substituição do sistema com qualquer
sistema que seja necessária a substituição, sendo primordial a interação entre
eles;
Seguir uma padronização adequada para auxiliar na pratica de
desenvolvimento de sistema, gerencia de qualidade, entre outros;
Obter um regulamento externo, como leis e regulamento de segurança ou
saúde;
Aquisição de domínio gerais de aplicação
6.1. Modelo do problema
O modelo problema é um processo de elaboração de requisitos de um projeto,
podendo referir-se a um produto indivisível de software ou um conjunto de componentes
de software, as principais características deste modelo incluem, funcionalidades,
interfaces externas, desempenho, outros atributos, restrições impostas pela aplicação.
A confecção deste modelo problema é constituída por equipes de desenvolvimento
de projeto tendo como participação obrigatória usuários do produto em pauta, este
usuário deverá ser indicado pelo cliente para definir os requisitos do produto, sendo
necessário ter o conhecimento e autoridade suficiente para definir as necessidades do
produto. Normalmente esse usuário passa por treinamentos sobre técnicas e noções que
serão utilizadas nas atividades da disciplina de requisitos.
Os usuários devem ter a consciência da função indispensável que desempenham
na modelagem do problema, é preciso também, informar o papel que terão no restante do
projeto, como no desenho das interfaces de usuário, avaliações do produto, revisões,
testes de aceitação e em todos os demais procedimentos de implantação que façam
parte do projeto.
30
A especificação de requisitos serve apenas para a elaboração de um relatório
destinado ao consumo dos clientes/usuários, quando se faz necessário uma
documentação que sirva de base contratual para que se possam definir os requisitos que
deverão ser suprimidos pelo produto. O conteúdo deste documento pode ser retirado do
modelo do problema de uma forma automatizada.
6.2. Modelo do sistema
Um produto de software deve conter toda a funcionalidade que o cliente necessita,
ou fazer parte de um sistema maior, no caso do modelo do problema ele é relativo ao
sistema maior, os requisitos de nível de sistema podem ser contidos nos seguintes
artefatos, um modelo do sistema, documento de definição do produto ou uma proposta de
desenvolvimento de sistema.
O artefato mais completo é o modelo de sistema, ele define os requisitos aplicáveis
ao sistema, os requisitos podem ser repassados aos componentes de software, já a parte
de desenho do modelo do sistema define interfaces e os outros componentes de
software. Os requisitos dos componentes de software não podem colidir com os requisitos
do sistema total.
Quando o software passar a fazer parte de um sistema maior, os requisitos do
sistema e de seus componentes passaram a ser definidos em conjunto pelas equipes do
sistema e negociados entre elas. Equipes com que as quais a equipe de modelagem dos
requisitos de software pode ter de interagir, são os desenvolvedores de hardware,
especialistas da área de aplicação, redes, banco de dados, além do departamento de
marketing e das áreas financeira e administrativa.
Esses grupos devem trabalhar em conjunto e também com os clientes e usuários
chaves para a definição dos requisitos nos níveis de sistema, seu dever é indicar para os
participantes do levantamento de requisitos de sistema se os requisitos que serão
aplicados são viáveis, a equipe de produto de software deve aprovar o requisito de
sistema caso ele tenha um grande impacto no desenvolvimento de software.
31
No decorrer do desenvolvimento dos requisitos de sistema, os participantes
precisam definir quais as características dos requisitos são mais críticas, principalmente
do ponto de vista dos clientes e usuários, é preciso estabelecer regras para o critério de
aprovação de cada componente do sistema que um grupo deva fornecer aos outros
grupos.
6.3. Modelagem de Processo, casos de uso e qualidade de software
Modelagem de processos de software serve como auxilio para a equipe entender as
descrições e os caminhos para elaboração do desenvolvimento do software, entre
algumas razoes para a modelagem do processo estão a necessidade de a equipe
registrar as descrições do processo de desenvolvimento do software, a criação de um
modelo de processo refletindo os objetivos de desenvolvimento, sendo necessário
primeiramente ser definida a situação na qual será utilizado.
Um caso de uso representa uma unidade de funcionalidade, casos de uso são mais
utilizados para descrever funções completas de um sistema, mas também podem ser
usados no nível de subsistemas e até de classes. Os serviços oferecidos pelo caso de
uso agregam valores externos que interagem com ele.
No nível de sistema, um caso de uso realiza um aspecto maior da funcionalidade do
produto, gerando benefícios para os clientes, usuários e sistemas, o conjunto dos casos
de uso cobre a funcionalidade do produto, e cada caso de uso tem a sua
representatividade em relação à funcionalidade.
32
Figura 7 - http://jonysberg.wordpress.com/category/mda/
A engenharia de requisitos se preocupa com o colhimento de informações para
elaborar os requisitos de um sistema de software, armazenamento e gerenciamento. Um
requisito é uma determinada função ou condição que o sistema tem que atender. O
requisito funcional descreve uma determinada função que o sistema deve suportar já um
requisito não funcional descreve um aspecto não funcional, mas que o sistema deve
acolher, requisitos não funcionais estão ligados com os aspectos do sistema, como:
desempenho, distribuição, segurança, integração com a internet, entre outros.
Devido à influência de métodos desenvolvidos por volta da metade da década de
1990, a UML incluiu os diagramas de casos de uso que permitem uma aproximação mais
focada nos usuários do sistema. A modelagem de requisitos funcionais, em meio à
especificação e casos de uso, é considerada extremamente adequada, pois facilita a
comunicação entre a equipe de projeto e os clientes, e, ainda viabiliza a comunicação, o
gerenciamento e a forma como é conduzida o desenvolvimento do projeto.
Essa relação entre casos de uso e requisitos é bem conturbada, há autores que
consideram os casos de uso uma boa forma de representar os requisitos, já outros
consideram requisitos e casos de uso como conceitos bem distintos; no entanto há
relações entre eles que devem ser notadas.
33
Há
algumas
características
importantes
na
especificação
de
requisitos,
características ligadas com a sua apresentação, organização e nível de detalhe.
Referente à sua organização e apresentação, há autores que defendem que os requisitos
devem ser apresentados visualmente através de diagramas de casos de uso, e cada caso
deve ser especificado detalhadamente em meio a uma descrição textual (definido pela
equipe de projeto) e também por diagramas de colaboração ou projetos de interfaces
homem-máquina.
Quando os requisitos são descritos de forma textual, é recomendado que sejam
organizados dentro de uma seqüência numérica e que haja pelo menos duas seqüências
diferentes: uma para os requisitos funcionais e outra para os requisitos não funcionais.
Por outro lado quando os casos de uso servem como base para os requisitos, é
importante que se use o pacote da UML como estrutura, essas duas posições vão ser
validas conforme forem utilizadas com freqüência e consistência. Porém a organização
dos requisitos em conjunto com os casos de uso facilita a comunicação com os usuários
e torna mais fácil o entendimento.
Quanto à especificação de requisitos e casos de uso, esta inteiramente ligada ao
tipo de projeto, perfil do cliente e ao tipo de sistema especificado. Porém é preciso estar
ciente que é possível haver um caso de uso descrito com apenas 3 paginas ou em um
com 40 páginas, em conseqüência desse fato é possível haver um sistema especificado
em uma dezena ou em uma centena de paginas
Qualidade de Software é estar em consonância com os requisitos estabelecidos com
o cliente, qualidade é satisfazer e ate mesmo antecipar as necessidades e desejos do
cliente, ter um controle e um relatório escrito a ser seguido também pode ser um
significado de qualidade.
34
Toda decisão tomada no decorrer do processo de desenvolvimento do software
poderá afetar a sua qualidade final. O produto final do processo de desenvolvimento é a
soma das decisões e operações realizadas juntamente com o ciclo de desenvolvimento.
Para que se possa produzir um software com alta qualidade é indispensável um
investimento em qualidade e todos os outros pontos do processo.
“Qualidade de Software é um processo sistemático que focaliza todas as etapas e
artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos,
prevenindo e eliminando defeitos” (Alexandre Bartié,Garantia da Qualidade de Software,
pag. 16) .
Softwares mal testados ocasionam grandes prejuízos as organizações, um pequeno
erro que venha a ocorrer internamente no projeto poderá acarretar gastos desnecessários
para a organização, como solicitação de manutenção antecipadamente, manutenção de
equipamentos, gerar estatísticas incoerentes, por este motivo é muito importante se obter
a qualidade.
35
7.
TIPOS DE REQUISITOS DE SOFTWARE:
Existem vários tipos de requisitos de software entre eles estão os requisitos de
usuário que possui uma linguagem bem natural onde também poderá ser
representado por diagramas que explicitam as funções que o sistema ira ter e as
suas restrições, seu desenvolvimento esta voltado para leitores como os Gerentes
de clientes, usuários finais do sistema, engenheiros do cliente, gerentes do
fornecedor e arquitetos de sistema.
Requisitos do sistema, neste tipo de requisito exigem uma documentação um
pouco mais detalhada relatando as funções e restrições do sistema, sua escritura
deverá ser basicamente como se fosse um contrato entre o cliente e o
desenvolvedor do software, estão voltados para leitores como usuário final de
sistema, engenheiros do cliente, arquitetos do sistema e desenvolvedores de
software.
Especificação do software neste tipo de requisito exige se que a prescrição seja
um pouco mais detalhada com relação ao software, pois servirá como base para o
projeto e a implantação, sua escritura normalmente é feita diretamente para os
desenvolvedores ou arquitetos de sistemas e raramente para engenheiros do
cliente.
Os Requisitos também podem ser definidos como requisitos funcionais,
requisitos não funcionais e requisitos de domínio, os requisitos funcionais são
basicamente as definições de serviços que o sistema devera fornecer e as reações
que o sistema devera ter em situações como a entradas especificas, os requisitos
não funcionais neste caso são as restrições sobre os serviços e funções que o
sistema fornecerá, já os requisitos de domínio se origina da aplicação do sistema os
refletem as características e definições do domínio, podendo ser ate mesmo
requisitos funcionais e não funcionais.
36
Basicamente os requisitos de software são metas que são determinadas por
usuários estabelecendo propriedades do sistema, ou seja, são os requisitos de
sistema que relatam as propriedades do software.
Requisitos de Software
“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”.
F. P. Brooks Jr, “No Silver Bullet: Essence and Accidents in
Software
Engineering”, IEEE Computer, abril 1987.
Os requisitos podem ser relatados como uma condição ou capacidade do
software, podendo solucionar problemas ou atingir um determinado objetivo, atender
necessidades ou limitações impostas pelos componentes do sistema.
Basicamente os requisitos são subdivididos em requisitos funcionais e nãofuncionais, os funcionais descrevem funções ou objetivos estabelecidos por clientes
e usuários, a função é utilizada no sentido similar de operação que poderá ser
utilizado pelo sistema através de comandos, eventos internos ou externos do
sistema. A especificação determinará o que se espera que o software execute, é
imprescindível estabelecer a diferença da atividade que ocorre no período de design
do software e das atividades de especificação. O design de software servirá para a
tomada de decisões onde as funções do sistema deverá satisfazer os usuários.
Os não-funcionais são as qualidades de um modo geral, como usabilidade,
desempenho, entre outros. De uma forma geral são descritos de maneira informal e
são difíceis de validar. Na medida em que o software de expande, a necessidade de
se obter requisitos precisos influência a determinação da maior dificuldade do
processo, como grande portabilidade fazendo-se necessária associação dos
requisitos em relação ao ciclo de vida do sistema.
37
Requisitos funcionais descrevem as funcionalidades ou
serviços que se espera do sistema (funções precípuas do
sistema). Exemplo: “o sistema deve notificar o requisitante por
e-mail quando sua requisição estiver disponível para retirada”.
Requisitos não funcionais são requisitos não diretamente
relacionados às funções precípuas do sistema. Exemplos:
requisitos de confiabilidade, robustez, eficiência e segurança.
EA976 – Prof. Eleri Cardozo – FEEC/Unicamp
7.1. Requisitos de usuários
Identifica a necessidade, destacando o problema e sua solução, iniciando-se
o estudo de detalhes para facilitar o domínio do problema, para uma solução mais
rápida. Com a aprovação dos requisitos de usuários é definido o inicio do ciclo de
desenvolvimento de um software, que tem como termino de validade a data
estipulada pelos desenvolvedores do software. A etapa operacional ocorre após a
aprovação provisória do software pelo operador e tem a sua desativação ao termino,
basicamente o ciclo de vida de um software ocorre com a aprovação da
documentação dos requisitos do usuário e termina com a sua desativação.
Nesta fase inicial descreve-se a formalização de um processo interativo, onde
o usuário pode definir suas necessidades, de forma precisa, completa, verificável e
viável, cujo é o principal meio de comunicação entre usuários e desenvolvedores,
esta fase só terá fim com a aprovação do DRU, após um processo classificado como
revisão formal.
Requisitos de usuário especificam o comportamento externo do
sistema sob a perspectiva do usuário (humano ou não).
Problemas na identificação dos requisitos de usuário:
• Falta de clareza ou ambigüidades, por serem descritos em
linguagem natural (ex.: “o usuário deve ser alertado sobre
operações perigosas”);
• Confusão entre requisitos funcionais, não funcionais e objetivos
do sistema (ex.: “o sistema deve facilitar a solicitação de
declarações”);
• Fusão de requisitos onde um único requisito é na verdade uma
condensação de vários requisitos (Ex.: “O sistema deve permitir
38
ao usuário escolher a imagem a ser processada (dentre os
diversos formatos permitidos) por meio de um file chooser”).
EA976 – Prof. Eleri Cardozo – FEEC/Unicamp
Acrogramas
PGQS Plano de Garantia Qualidade de Software
DRU Documento Requisito do Usuário
PGPS Plano Gerencial do Projeto de Software
.../RS secção Requisito de Software do...
PGCS Plano Gerencial de Configuração de Software .../RU secção Requisitos do Usuário do...
PVVS Plano de Verificação e Validação de Software .../TA secção Testes de Aceitação do....
Figura 8 - As Macro Atividades da Fase de RU - www.dem.inpe.br
A figura ilustra uma fase que compõe o desenvolvimento do ciclo de vida,
as atividades gerenciais administram as atividades executivas apoiando e
direcionando-as. As quatro atividades gerenciais maiores estão ilustradas na parte
inferior da figura e o restante é representado por corre-mãos. Os requisitos de
usuários estabelecem as necessidades do que deve ser feito e não como deve ser
feito.
39
7.2. Especificação e análise de requisitos de software
São atividades que determinam os objetivos do software e as restrições,
como elaborar a especificação do software podendo ser vista como parte da análise
do sistema normalmente iniciada com a análise do sistema, podendo ser estendida
após a elaboração de documentos de especificação, onde serão especificados os
requisitos de software.
Analise e especificações devem ser realizadas em conjunto, porém são
atividades interdependentes. A análise representa a modelagem dos elementos, é
necessário que se identifique a pessoas, atividades e informações do domínio, desta
forma será decidido o que fará ou não parte do sistema. Os componentes que não
são informatizados são automaticamente considerados uma entidade externa ao
software.
Especificação é basicamente a descrição do que o software pode fazer, seja
ela de uma forma sistemática ou abstrata, apresentando como solução os problemas
na análise e resolvidos pelo software do sistema visando descrever as propriedades
funcionais, tendo como objetivo solucionar o problema do domínio. A especificação é
uma forma de comunicação sistemática com arquitetos, programadores e testadores
do software em questão.
Requisitos de Sistema
Requisitos de sistema (funcionais, não funcionais e de domínio)
descrevem mais detalhadamente os requisitos de usuário. São
base para um contrato de implementação do sistema.
Problemas na identificação dos requisitos de sistema:
• Requisitos de sistema ainda são descritos em linguagem natural
acompanhada de diagramas ilustrativos (a ambigüidade persiste);
• Idealmente, os requisitos de sistema não devem conter decisões
de projeto, mas requisitos impostos pela arquitetura e sistemas
legados acabam sendo incorporados nos requisitos de sistema.
EA976 – Prof. Eleri Cardozo – FEEC/Unicamp
40
7.3. Requisitos e interfaces externas
Nesta etapa, descreve de forma detalhada os dados trocados e os
componentes de controle desta interface, de forma especifica os requisitos de
interface externa.
Interfaces externas estabelecem requisitos para que o sistema
possa interoperar com outros sistemas e com os usuários
humanos (são, portanto, requisitos de sistema). O IEEE
classifica as interfaces externas em:
• Interfaces de usuário;
• Interfaces de hardware;
• Interfaces de software;
• Interface de comunicação.
As interfaces de software definem:
• procedimentos (serviços providos/requeridos);
• estruturas de dados (trocados entre sistemas);
• representação de dados trocados (XML, Base64, ...).
EA976 – Prof. Eleri Cardozo – FEEC/Unicamp
41
8. CONCLUSÃO
Após as abordagens realizadas nesta monografia foi possível estabelecer
a importância dos requisitos de software, sendo eles fundamentais no que se diz
respeito à parte de um sistema computacional, porém para colocá-la em prática é
necessário que seja feita uma análise complexa contendo o máximo de informações
possíveis, pois desta forma viabiliza a criação do software com o mínimo de falhas
possíveis, identificando assim os problemas que venham a atrapalhar a criação de
um sistema de software.
Após o encerramento da fase de modelagem e verificação de requisitos
teremos um projeto que definirá os objetivos e necessidades que deverão ser
alcançados, possibilitando a definição do escopo do projeto com precisão, nesta
fase é necessário detalhar todos os aspectos funcionais e não-funcionais
estabelecendo um conjunto de especificações com um nível máximo de
detalhamento
Como já dito anteriormente, porém é sempre bom ressaltar que nunca
deixe de lado os desejos do cliente, pois é nele que é preciso se basear para que
possam ser elaborados os requisitos do software, tomando como base uma idéia
principal de desenvolvimento e o objetivo que o cliente deseja alcançar com a
criação do software.
É fundamental que os requisitos possam ser bem compreendidos pelos
desenvolvedores, para isso é preciso que se use uma linguagem clara e objetiva na
descrição dos requisitos de software, feito isso a chance de alcançar o êxito em sua
aplicação será bem maior.
42
9. ANEXOS – MODELOS DE DOCUMENTOS DE REQUISITOS
VOLATILIDADE DOS REQUISITOS
RQ
Alta
Média
Baixa
MATRIZ DE RASTREABILIDADE - REQUISITOS CLIENTE X PRODUTO
RQC
RQ
MATRIZ DE RASTREABILIDADE - REQUISITOS FUNCIONAIS E NÃO
FUNCIONAIS DO PRODUTO
RQC
RQ
MATRIZ DE RASTREABILIDADE - REQUISITOS DO PRODUTO X
COMPONENTES
Com
RQ
43
9. DOCUMENTO DE REQUISITOS
ID documento:
Data:
/
/
Versão
:
Responsável pelo documento:
ID Projeto:
HISTÓRICO DE REVISÕES
Data de
criação/
atualização
Descrição da(s) Mudança(s)
Ocorrida(s)
Autor
Versão do
Documento
ID.
Solicitação
de Mudança
44
MODELO DE DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS
Título: Documento de Especificação de Requisitos
Dados Gerais:
Projeto: <<Nome do Projeto>>
Versão: <<Número da Versão do Documento de Especificação de Requisitos>>
Responsáveis: <<Nomes dos Responsáveis>>
Seções do Documento e Instruções para seu preenchimento:
1. Introdução
Texto livre introdutório descrevendo o documento.
2. Propósito do Sistema
Texto apresentando uma descrição sucinta do negócio a ser tratado pelo
sistema em questão.
3. Modelo de Casos de Uso
Apresentação do modelo de casos de uso. Caso o sistema seja decomposto
em subsistemas, para cada subsistema, apresentar primeiro o diagrama de casos de
uso correspondente, seguido das descrições dos casos de uso desse diagrama,
observando a conformidade ao padrão de descrição de casos de uso apresentado a
seguir.
Observar, ainda, que os casos de uso devem ser nomeados com verbos no
infinitivo, seguidos por complemento.
45
1. Projeto:
Sub-Sistema:
Caso de Uso:
Data:
Descrição do Propósito: Descrição sucinta do propósito do caso de uso.
Cursos Normais: Descrição dos cursos normais dos fluxos de eventos relacionados
a esse caso de uso, abrindo um item específico para a descrição do curso normal de
cada um dos fluxos de eventos.
Nome do Fluxo de Eventos
Descrição
Cursos Alternativos: Para cada fluxo alternativo ou tratamento de exceção
identificado e não tratado na seção anterior, abrir um item para sua descrição.
Nome do Fluxo de Eventos
Descrição
Entidades: Relacionar as entidades do modelo ER que são relevantes para modelar
os conceitos envolvidos no caso de uso.
46
10. REFERÊNCIAS BIBLÍOGRAFICAS
Livro: Engenharia de Software (Fundamentos, métodos e padrões) – 3º
edição Autor: Wilson de Pádua Paula Filho, 2005.
Livro Engenharia de Software e Sistemas de Informação – 3ª Edição Autor:
Denis Alcides Rezende, 2003
Livro Projeto de Software - Autor Eric Braude, 2004.
Livro Gerenciando Projetos de Desenvolvimento de Software – 4ª Edição
Autor: Jose Carlos Cordeiro Martins. 2005
Livro Gerenciando Projetos – 6º edição autor Ricardo Vargas, 2006
Livro Engenharia de Software Teoria e Pratica 2ª Edição – Shari Lawrence
Pfleeger
Livro Garantia da Qualidade de Software – Alexandre Bartié
47
11. REFERÊNCIAS ELETRÔNICAS
http://www.wthreex.com/rup/process/activity/ac_prdsrs.htm#Detail the
software requirements - Copyright
(c) 1987 - 2001 Rational Software
Corporation
www.swebok.org
www.computer.org/certification
http://www.inf.ufpr.br/silvia/ES/SweES/SweESalunos.pdf
http://engenharia-de-software.nuvvo.com/lesson/11092-requisitos-de-software
http://www2.dem.inpe.br/ijar/ProdProcPadroes.html
http://www.lenep.uenf.br/~bueno/DisciplinaCpp/Aulas/aula_06-2Elaboracao.pdf
http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-softwareparte-1.html
http://www.tiagodemelo.info/aulas/cefet/2007/aula-engenharia-software.pdf
http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/NotasDeAula.pdf
http://alexandrebartie.spaces.live.com/?_c11_BlogPart_pagedir=Next&_c11_B
logPart_handle=cns!7F918BA9DA86720C!285&_c11_BlogPart_BlogPart=blo
gview&_c=BlogPart
http://www.devmedia.com.br/articles/viewcomp.asp?comp=8034
http://engenhariadesoftware.blogspot.com/2007/05/requisitos-de-software.html
http://www2.dem.inpe.br/ijar/EngSofRequisitosUsuario.html
48