UNIVERSIDADE DO ESTADO DO RIO GRANDE DO NORTE UERN

FACULDADE DE CINCIAS EXATAS E NATURAIS FANAT

CINCIA DA COMPUTAO
ENGENHARIA DE SOFTWARE

Discente: Joo Pedro da Costa Ribeiro
RESUMO CAPTULO 4

Engenharia de Requisitos

Os requisitos de um sistema so as descries do que o sistema deve fazer, os
servios que oferece e as restries a seu funcionamento. Esses requisitos refletem as
necessidades dos clientes para um sistema que serve a uma finalidade determinada,
como controlar um dispositivo, colocar um pedido ou encontrar informaes. O
processo de descobrir, analisar, documentar e verificar esses servios e restries
chamado engenharia de requisitos. Requisitos de usurio e requisitos de sistema podem
ser definidos como de usurios sendo declaraes, em uma linguagem natural com
diagramas, de quais servios o sistema dever fornecer a seus usurios e as restries
com as quais este deve operar e requisitos de sistema so descries mais detalhadas das
funes, servios e restries operacionais do sistema de software. O documento de
requisitos do sistema deve definir exatamente o que deve ser implementado.
Os requisitos de software so frequentemente classificados como requisitos
funcionais e requisitos no funcionais, onde requisitos funcionais so declaraes de
servios que o sistema deve fornecer, de como o sistema deve reagir a entradas
especficas e de como o sistema deve se comportar em determinadas situaes. Em
alguns casos, os requisitos funcionais tambm podem explicitar o que o sistema no
deve fazer. J os requisitos no funcionais, so restries aos servios ou funes
oferecidos pelo sistema. Incluem restries de timing, restries no processo de
desenvolvimento e restries impostas pelas normas. Aos contrrio das caractersticas
individuais ou servios do sistema, os requisitos no funcionais, muitas vezes, aplicam-
se ao sistema como um todo. Os requisitos no so independentes e muitas vezes geram
ou restringem outros requisitos. Portanto, os requisitos de sistema no apenas
especificam os servios ou as caractersticas necessrias ao sistema, mas tambm a
funcionalidade necessria para garantir que esses servios/caractersticas sejam
entregues corretamente.
Os requisitos funcionais de um sistema mais especificamente, descrevem o que
ele deve fazer. Eles dependem do tipo de software a ser desenvolvido, de quem so seus
possveis usurios e da abordagem geral adotada pela organizao ao escrever os
requisitos. Quando expressos como requisitos de usurios, os requisitos funcionais so
normalmente descritos de forma abstrata, para serem compreendidos pelos usurios do
sistema. No entanto, requisitos de sistema funcionais mais especficos descrevem em
detalhes as funes do sistema, suas entradas e sadas, excees etc. Em principio, a
especificao dos requistos funcionais de um sistema deve ser completa e consistente.
Completude significa que todos os servios requeridos pelo usurio devem ser
definidos. Consistncia significa que os requisitos no devem ter definies
contraditrias. Na prtica, para sistemas grandes e complexos, praticamente
impossvel alcanar completude e consistncia dos requisitos.
Os requisitos no funcionais, como o nome sugere, so requisitos que no esto
diretamente relacionados com os servios especficos oferecidos pelo sistema a seus
usurios. Eles podem estar relacionados s propriedades emergentes do sistema, como
confiabilidade, tempo de resposta e ocupao de rea. Uma alternativa a esse cenrio
seria os requisitos definirem restries sobre a implementao do sistema, como as
capacidades dos dispositivos de E/S ou as representaes de dados usadas nas interfaces
com outros sistemas. Os requisitos no funcionais, como desempenho, proteo ou
disponibilidade, normalmente especificam ou restringem as caractersticas do sistema
como um todo. Requisitos no funcionais so frequentemente mais crticos que
requisitos funcionais individuais. Requisitos no funcionais podem afetar a arquitetura
geral de um sistema em vez de apenas componentes individuais; um nico requisito no
funcional, tal como um requisito de proteo, pode gerar uma srie de requisitos
funcionais relacionados que definam os servios necessrios no novo sistema.
Requisitos podem ser de produto, organizacionais ou externos. De produto, especificam
ou restringem o comportamento do software, os organizacionais, so os requisitos gerais
de sistemas derivados das polticas e procedimentos da organizao do cliente e do
desenvolvedor, e os externos, que abrange todos os requisitos que derivam de fatores
externos ao sistema e seu processo de desenvolvimento, podem incluir requisitos
reguladores, requisitos legais e ticos. Na prtica, no documento de requisitos, difcil
separar os requisitos funcionais dos no funcionais. Se no apresentados separadamente,
os relacionamentos entre eles podem ficar difceis de serem entendidos. No entanto, os
requisitos claramente relacionados com as propriedades emergentes do sistema, como
desempenho ou confiabilidade, devem ser explicitamente destacados. Voc pode fazer
isso colocando-os em uma seo separada do documento de requisitos ou distinguindo-
os, de alguma forma, dos outros requisitos de sistema.
O documento de requisitos de software, s vezes chamado Especificao de
Requisitos de Software, uma declarao oficial de o que os desenvolvedores do
sistema devem implementar. Deve incluir tanto os requisitos de usurio para um sistema
quanto uma especificao detalhada dos requisitos de sistema. Em alguns casos, os
requisitos de usurio e de sistema so integrados em uma nica descrio. Em outros, os
requisitos de usurio so definidos em uma introduo especificao de requisitos de
sistema. Documentos de requisitos so essenciais quando um contratante externo est
desenvolvendo o sistema de software. Entretanto, os mtodos geis de desenvolvimento
argumentam que os requisitos mudam to rapidamente que um documento de requisitos
j est ultrapassado assim que termina de ser escrito. O nvel de detalhes que deve-se
incluir em um documento de requisitos depende do tipo de sistema em desenvolvimento
e o processo usado. Os sistemas crticos precisam ter requisitos detalhados, porque a
segurana e a proteo devem ser analisadas em detalhes. Naturalmente, a informao
includa em um documento de requisitos depende do tipo de software a ser
desenvolvido e a abordagem de desenvolvimento que est em uso. Se uma abordagem
evolutiva adotada para um produto de software, o documento de requisitos deixar de
fora muitos dos captulos detalhados sugeridos. O foco ser sobre a definio de
requisitos de usurio e os requisitos no funcionais de alto nvel de sistema. Em uma
estrutura de um documento de requisitos deve conter prefcio, introduo, glossrio,
definio de requisitos de usurio, arquitetura do sistema, especificao de requisitos do
sistema, modelos do sistema, evoluo do sistema, apndices e ndice.
Especificao de requisitos o processo de escrever os requisitos de usurio e de
sistema em um documento de requisitos. Idealmente, os requisitos de usurio e de
sistema devem ser claros, inequvocos, de fcil compreenso, completos e consistentes.
Na prtica, isso difcil de conseguir, pois os stakeholder interpretam os requisitos de
maneiras diferentes, e, muitas vezes, notam-se conflitos e inconsistncias inerentes aos
requisitos. Modelos grficos so mais teis quando voc precisa mostrar como um
estado se altera ou quando voc precisa descrever uma sequncia de aes. Diagramas
de sequncia e de estado da UML mostram a sequncia de aes que ocorrem em
resposta a uma determinada mensagem ou evento. Especificaes matemticas formais
so, por vezes, usadas para descrever os requisitos para os sistemas crticos de
segurana ou de proteo, mas raramente so usadas em outras circunstncias.
Especificao em linguagem natural, desde o inicio da engenharia de software a
linguagem natural tem sido usada para escrever os requisitos para o software.
expressiva, intuitiva e universal. As formas de escrever uma especificao de requisitos
de sistema, por meio de sentenas em linguagem natural onde os requisitos so escritos
em frases numeradas em linguagem natural; linguagem natural estruturada, os requisitos
so escritos em linguagem natural em um formulrio padro ou template; linguagem de
descrio de projeto, essa abordagem usa uma linguagem como programao, mas com
caractersticas mais abstratas, para especificar os requisitos, definindo um modelo
operacional do sistema; notaes grficas, para definio dos requisitos funcionais para
o sistema so usados modelos grficos, suplementados por anotaes de texto,
diagramas de caso de uso e de sequncia da UML so comumente usados; especificao
matemticas, essa notaes so baseadas em conceitos matemticos, como mquinas de
estado finito ou conjuntos. Embora essas especificaes inequvocas possam reduzir
ambiguidade de um documento de requisitos, a maioria dos clientes no entende uma
especificao formal.
Especificaes estruturadas, a linguagem natural estrutura uma forma de
escrever os requisitos do sistema na qual a liberdade do escritor dos requisitos
limitada e todos os requisitos so escritos em uma forma-padro. Essa abordagem
mantm grande parte da expressividade e compreenso da linguagem natural, mas
garante certa uniformidade imposta sobre a especificao. Notaes de linguagem
estruturada usam templates para especificar os requisitos de sistema. A especificao
pode usar construes de linguagem de programao para mostrar alternativas e
iterao. Usar as especificaes estruturadas elimina alguns dos problemas de
especificao em linguagem natural. Reduz-se a variabilidade na especificao, e os
requisitos so organizados de forma mais eficaz. No entanto, algumas vezes ainda
difcil escrever os requisitos de forma clara e inequvoca, especialmente quando
processamentos complexos devem ser especificados.
Processos de engenharia de requisitos, eles podem incluir quatro atividades de
alto nvel. Elas visam avaliar se o sistema til para a empresa, descobrindo requisitos,
convertendo-os em alguma forma-padro, e verificar se os requisitos realmente definem
o sistema que o cliente quer. As atividades so organizadas em torno de uma espiral,
como um processo iterativo, sendo a sada um documento de requisitos de sistema. A
quantidade de tempo e esforo dedicados a cada atividade em cada iterao depende do
estgio do processo como um todo e do tipo de sistema que est sendo desenvolvido.
Em praticamente todos os sistemas os requisitos mudam. As pessoas envolvidas
desenvolvem uma melhor compreenso do que querem do software, a organizao que
compra o sistema tambm muda, modificaes so feitas no hardware, no software e no
ambiente organizacional do sistema. O processo de gerenciamento desses requisitos em
constante mudana chamado de gerenciamento de requisitos.
Elicitao e anlise de requisitos, aps um estudo inicial de viabilidade,
prximo estgio do processo de engenharia de requisitos. Nessa atividade, os
engenheiros de software trabalham com clientes e usurios finais do sistema para obter
informaes sobre o domnio da aplicao, os servios que o sistema deve oferecer, o
desempenho do sistema, restries de hardware e assim por diante. A elicitao e
anlise de requisitos podem envolver diversos tipos de pessoas em uma organizao. As
atividades do processo so a descoberta de requisitos, classificao e organizao de
requisitos, priorizao e negociao de requisitos e especificao de requisitos.
Descoberta de requisitos, o processo de reunir informaes sobre o sistema
requerido e os sistemas existentes e separar dessas informaes os requisitos de usurios
e de sistema. Fontes de informao durante a fase de descoberta de requisitos incluem
documentao, stakeholders do sistema e especificaes de sistemas similares. Os
stakeholders variam desde os usurios finais, passando pelos gerentes do sistema at
stakeholders externos, como reguladores, que certificam a aceitabilidade do sistema.
Entrevistas formais ou informais com os stakeholders do sistema so parte da
maioria dos processos de engenharia de requisitos Nessas, entrevistas a equipe de
engenharia de requisitos questiona os stakeholders sobre o sistema que usam no
momento e sobre o sistema que ser desenvolvido. Requisitos surgem a partir das
respostas a essas perguntas. As entrevistas podem ser fechadas ou entrevistas abertas.
Entrevistas so boas para obter uma compreenso global sobre o que os stakeholders
fazem, como eles podem interagir com o novo sistema e as dificuldades que eles
enfrentam com os sistemas atuais. Informaes recolhidas em entrevistas suplementam
outras informaes sobre o sistema, advindas de documentos que descrevem processos
de negcios ou sistemas existentes, observaes do usurio etc.
Cenrios, as pessoas geralmente acham mais fcil se relacionar com exemplos
da vida real do que com descries abstratas. Elas podem compreender e criticar um
cenrio de como elas podem interagir com um sistema de software. Engenheiros de
requisitos podem usar a informao obtida a partir deste debate para formular os
requisitos do sistema atual. Os cenrios podem ser particularmente teis para adicionar
detalhes a uma descrio geral de requisitos. Trata-se de descries de exemplos de
sesses de interao. Cada cenrio geralmente cobre um pequeno nmero de interaes
possveis. Diferentes cenrios so desenvolvidos e oferecem diversos tipos de
informao em variados nveis de detalhamento sobre o sistema. Um cenrio comea
com um esboo da interao. Durante o processo de elicitao, so adicionados detalhes
ao esboo, para criar uma descrio completa dessa interao. Em sua forma mais geral
um cenrio pode incluir, uma descrio do que o sistema e os usurios esperam quando
o cenrio se iniciar; uma descrio do fluxo normal de eventos do cenrios; uma
descrio do que pode dar errado e como isso tratado; informaes sobre outras
atividades que podem acontecer ao mesmo tempo; e uma descrio do estado do sistema
quando o cenrio acaba. Os cenrios podem ser escritos como texto, suplementados por
diagramas, telas etc.
Casos de uso so uma tcnica de descoberta de requisitos introduzida
inicialmente no mtodo Objectory. Eles j se tornaram caracterstica fundamental da
linguagem de modelagem unificada. Em sua forma mais simples, um caso de uso
identifica os atores envolvidos em uma interao e d nome ao tipo de interao. Essa ,
ento, suplementada por informaes adicionais que descrevem a interao com o
sistema. A informao adicional pode ser uma descrio textual ou um ou mais modelos
grficos, como diagrama de sequncia ou de estados da UML. Os casos de uso so
documentados por um diagrama de casos de uso de alto nvel. Os casos de uso
identificam as interaes individuais entre o sistema e seus usurios ou outros sistemas.
Cada caso de uso deve ser documentado com uma descrio textual.
Etnografia, os sistemas no existem isoladamente. Eles so usados em um
contexto social e organizacional, e requisitos de software do sistema podem ser
derivados ou restringidos desse contexto. Geralmente, satisfazer a esses requisitos
sociais e organizacionais crtico para o sucesso do sistema. Uma razo pela qual
muitos sistemas de software so entregues, mas nunca so usados, que seus requisitos
no levam devidamente em conta a forma como o contexto social e organizacional afeta
o funcionamento prtico do sistema. Etnografia uma tcnica de observao que pode
ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de
apoio para esses processos. Uma analista faz uma imerso no ambiente de trabalho em
que o sistema ser usado. O trabalho do dia a dia observado e so feitas anotaes
sobre as tarefas reais em que os participantes esto envolvidos. O valor da etnografia
que ela ajuda a descobrir requisitos implcitos do sistema que refletem as formas reais
com que as pessoas trabalham, em vez de refletir processos formais definidos pela
organizao. A etnografia particularmente eficaz para descobrir dois tipos de
requisitos, requisitos derivados da maneira como as pessoas realmente trabalham, e no
da forma como as definies dos processos dizem que deveriam trabalhar; e requisitos
derivados da cooperao e conhecimento das atividades de outras pessoas. A etnografia
pode ser combinada com prototipao. A etnografia informa o desenvolvimento do
prottipo, para que menos ciclos de refinamento do prottipo sejam necessrios.
Validao de requisitos, o processo pelo qual se verifica se os requisitos
definem o sistema que o cliente realmente quer. Ela se sobrepe analise, uma vez que
est preocupada em encontrar problemas com os requisitos. A validao de requisitos
importante porque erros em um documento de requisitos podem gerar altos custos de
retrabalho quando descobertos durante o desenvolvimento ou aps o sistema j estar em
servio. Durante o processo de validao de requisitos, diferentes tipos de verificao
devem ser efetuados com os requisitos no documento de requisitos. Essas verificaes
incluem a verificao de validade, de consistncia, de completude, de realismo e a
verificabilidade. Existe uma srie de tcnicas de validao de requisitos que podem ser
usadas individualmente ou em conjunto como revises de requisitos, prototipao e
gerao de casos de teste.
Gerenciamento de requisitos, o processo de compreenso e controle das
mudanas nos requisitos do sistema. preciso se manter a par das necessidades
individuais e manter as ligaes entre as necessidades dependentes para conseguir
avaliar o impacto das mudanas nos requisitos. Voc precisa estabelecer um processo
formal para fazer propostas de mudanas e a ligao destas s exigncias do sistema. O
processo formal de gerenciamento de requisitos deve comear assim que uma verso
preliminar do documento de requisitos estiver disponvel. No entanto, deve-se comear
a planejar como gerenciar mudanas de requisitos durante o processo de elicitao de
requisitos.
Planejamento de gerenciamento de requisitos, o primeiro estgio essencial no
processo de gerenciamento de requisitos, e determina o nvel de detalhamento requerido
no gerenciamento de requisitos. Durante o estgio de gerenciamento de requisitos, deve-
se decidir sobre a identificao de requisitos, o processo de gerenciamento de
mudanas, sobre polticas de rastreabilidade e ferramenta de apoio. O gerenciamento de
requisitos precisa de apoio automatizado, e as ferramentas de software para esse
gerenciamento devem ser escolhidas durante a fase de planejamento. Precisa-se de
ferramentas de apoio para o armazenamento de requisitos, gerenciamento de mudanas
e gerenciamento de rastreabilidade.
O gerenciamento de mudana de requisitos, aps a aprovao do documento de
requisitos, deve ser aplicado a todas as mudanas propostas aos requisitos de um
sistema. O gerenciamento de mudanas essencial, pois necessrio decidir se os
benefcios da implementao de novos requisitos justificam os custos de
implementao. A vantagem de se usar um processo formal de gerenciamento de
mudanas que todas as propostas de mudanas so tratadas de forma consistente, e as
alteraes nos documentos de requisitos so feitas de forma controlada. Existem trs
estgios principais em um processo de gerenciamento de mudanas, que so a anlise de
problema e especificao de mudanas, a anlise de mudanas e custos, e a
implementao de mudanas. Processos geis de desenvolvimento como Extreme
Programming, foram concebidos para lidar com requisitos mutveis durante o processo
de desenvolvimento. Nesses processos, quando um usurio prope uma mudana nos
requisitos, a mudana no passa por um processo formal de gerenciamento de
mudanas. Pelo contrrio, o usurio tem de priorizar essa mudana e, em caso de alta
prioridade, decidir quais recursos do sistema planejados para a prxima iterao devem
ser abandonados.