1. Este trabalho trata-se da engenharia de software onde mais especificamente requisitos de
software ,e também descreve algumas dificuldades existentes e apresenta praticas para o
auxilio de elaboração dos requisitos necessários para o sistema solicitado ao usuário final.
Software é toda a parte logica que o usuário pode ver e usar em um computador , a analise
de sistemas identifica problemas existentes no mesmo, e apresenta meios para soluções.
Após ser feita a analise do computador , é realizado o escorpo onde os requisitos de
software são definidos.
Os requisitos de um sistema
Os requisitos de um sistema refletem as necessidades dos clientes de um sistema que
ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar um
pedido ou encontrar informações. O processo de descobrir, analisar, documentar e
verificar esses serviços e restrições é chamado de engenharia de requisitos( R E –
RequirementsEngineering).” (Ian Sommerville/2007)
Requisitos funcionais
São declarações de serviços que o sistema fornece, como o mesmo deve reagir as estradas
especificas e como ele deve se comportar em uma determinada situação. Em alguns casos
o mesmo pode funcionar também estabelecer o que o sitema não deve fazer.
Requisitos não funcionais
Os requisitos não funcionais são aqueles diretamente relacionados as funções especificas
fornecidas pelo sistema. Esses requisitos podem especificar desempenho, proteção ,
disponibilidade entre outras propriedades emergentes de sistema.
Requisitos não funcionais determinam o processo que deve ser usado para desenvolver o
sistema. Exemplo: as especificações no padrão de qualidade, o tópico de ferramentas CASE
e uma descrição do processo que deve ser seguido.
Os requisitos não funcionais surgem pela as necessidades do usuário final, às
restrições de orçamento, as políticas organizacionais
* Requisitos de produto: especificam o comportamento do produto. Entre eles estão
requisitos de desempenho, confiabilidade, portabilidade e usabilidade.
* Requisitos organizacionais: este requisito é derivado de políticas da organização do
cliente e do desenvolvedor, exemplo requisito de implementação como a linguagem de
programação ou o método de projeto usado e requisitos de entrega que especificam
quando o produto e a sua documentação devem ser entregues.
* Requisitos externos: são requisitos derivados de fatores externos ao sistema e seu
processo de desenvolvimento. Podem incluir requisitos de interoperabilidade, requisitos
legais e requisitos éticos.

2. Os tipos de requisitos não funcionais são:
* Requisitos de produto: neste requisito ele montra o comportamento do produto. Entre
eles estão requisitos de desempenho, confiabilidade e usabilidade.
* Requisitos organizacionais: neste requisito é derivado de políticas da organização do
cliente e do desenvolvedor, exemplo: requisito de implementação como a linguagem de
programação ou o método de projeto usado e requisitos de entrega que especificam
quando o produto e a sua documentação devem ser entregues.
* Requisitos externos: são requisitos derivados de fatores externos ao sistema e seu
processo de desenvolvimento. Podem incluir requisitos de interoperabilidade, requisitos
legais e requisitos éticos.
Requisitos de Usuário
Os requisitos de usuário de um sistema se define pela descrição do que o sistema deve
fazer (requisitos funcionais e não funcionais) que seja compreendido pelo usuário não
final . Deve ser escrito em uma linguagem simples.
Entretanto, alguns problemas podem surgir com essa especificação em linguagem
natural. São eles: falta de clareza; confusão de requisitos e fusão de requisitos.
O requisito de usuário deve simplesmente enfocar apenas características
essenciais ao sistema. Requisitos muito detalhado geralmente limitam as soluções para os
problemas e são difíceis de serem compreendidos.
Requisitos de sistema
Os requisitos de sistemas são versões expandidas dos requisitos de usuários usados pelos
engenheiros de software como ponto de partida para o projeto de sistema.” (Sommerville
– 2007).
São descrições detalhados pelos usuários sobre o sistema que servem como base para a
implementação com a especificação completa e consistente de todo o sistema.
Uso da linguagem estruturada, que é padronizada, a torna com a liberdade mais
limitada e com isso mantém a facilidade de expressão e compreensão .
Podemos também usar tabelas ou modelos gráficos para facilitar o entendimento do
sistema de como é processada a informação, como a informação é armazenada e as
sequencias de ações que serão tomadas de maneira bem detalhada e assim reduzir as
dúvidas do usuário sobre o funcionamento do sistema.

3. Documentos de Requisitos
Como resultado do processo de levantamento de requisitos é feito o documento de requisitos
do sistema. Este documento contém todas as especificações de todos os requisitos funcionais
e não funcionais do software, incluindo as capacidades do produto, os recursos disponíveis, os
benefícios e os critérios de aceitação ou não.

4. Características do documento de requisitos
O documento de requisitos do sistema deve ser composto por sentenças em linguagem
natural, seguindo determinados padrões:
1) Iniciar com “O sistema deve”.
2) Deve-se usar frases curtas
• Exemplo: “O sistema deve rodar em microcomputadores com memorias ram acima de 2 gb”

5. SCRUM
O SCRUM é um modelo de desenvolvimento ágil de software para fornece métodos para se
definir o planejamento, os principais papéis de pessoas e a forma de trabalho. A ideia do
SCRUM é justamente definir papéis bem específicos para as pessoas envolvidas no projeto ,ou
seja, o que cada uma vai ter que fazer para o desenvolvimento do software .
Em geral e de forma reduzida, esta metodologia funciona da seguinte forma:
1. O produto é definido: quais são realmente seus requisitos? O que realmente o cliente
deseja ?
2. O Proprietário do Produto define quais são as funcionalidades do programa que mais
importam.
3. Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, uma
espécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e o
Time de desenvolvimento definem o que chamamos de Sprints.
RUP
O Processo Unificado da Rational conhecido como RUP , é um processo de engenharia de
software criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma
sistemática para se obter vantagens no uso da UML. Foi criado pela Rational Software
Corporation e adquirido em fevereiro de 2003 pela IBM. O principal objetivo do RUP é atender
as necessidades dos usuários garantindo uma produção de software de alta qualidade que
cumpra um cronograma e um orçamento exato. Assim, o RUP mostra como o sistema será
construído na fase de implementação, gerando o modelo do projeto . O RUP define
perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando
devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para
que sejam alcançadas.
O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões
sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação
do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido,
distribuídos entre vários profissionais como o Analista de sistema, Projetista, Projetista de
testes, entre outros.

6. Fases do RUP
1-Fase de Concepção / Iniciação: Nesta fase do RUP abrange as tarefas de comunicação com
o cliente e planejamento. É feito um plano de projeto avaliando todos os riscos possíveis , as
estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do
sistema e preliminarmente analisá-lo.
2-Fase de Elaboração: O objetivo desta fase é analisar de forma mais detalhada a análise do
domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto
começa a ter sua forma básica. Por exemplo as duvidas mais apontadas são “O plano do
projeto é confiável?”, “Os custos são admissíveis?” todas e mais duvidas são esclarecidas
nesta etapa.
3-Fase de Construção: O principal objetivo desta fase é a construção do sistema de software,
com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de
Construção que a maior parte de codificação ocorre.
4-Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo
desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final.
Xp
O método XP, do inglês eXtremingProgramming, é uma proposta de desenvolvimento ágil e se
repete diversas vezes para se chegar a um resultado. O método XP propõe um processo leve,
e com a entrega constante de pequenas partes da funcionalidade do software. As partes
devem ser incrementadas e requerem a melhoria constante do código .
A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto
no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um
participante da equipe de desenvolvimento. Esta é uma das características importantes para o
método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação
ativa.
Uma das características importantes do XP é que não existe um processo de design
tradicional com a elaboração de modelos da arquitetura do software.

7. O retrabalho ou pré-fabricação é uma atividade fundamental e necessária para o XP funcionar.
Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para
remover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura . O
retrabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do código
e aumenta a qualidade do software produzido.
Regras e Práticas
Planejando
* Planejando liberações e pequenas liberações
* Dividir projetos em diversas partes
* Medindo velocidade do projeto
* Reuniões diárias
Projetando
* Simplicidade
* Metáfora
* Re-fabricar
Codificando
* O cliente deve estar sempre disponível.
* Programação em pares.
* Codificar de acordo com padrões acordados.
* Codificar testes de unidade primeiro.
* Integrar com frequência.
* O código é propriedade coletiva.

8. .
Testando
* Todo código deve ter os testes de unidade.
* Cada unidade deve ser testada antes de liberada.
* Quando um erro é encontrado, testes devem ser realizados.
* Testes de aceitação devem ser freqüentes.
A programação extrema tem sido bem sucedida em projetos pequenos com times
pequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.

9. Conclusão

10. Bibliografia
SOMMERVILLE, Ian – Engenharia de Software. 8ª Ed. Pearson Education, 2007.
CARDOZO, Eleri – Requisitos de Software 2ª parte. FEEC/Unicamp, 2007.
KOTONYA, Gerald - http://www.scc.lancs.ac.uk/
IEEE Std 830-1998,
IEEE RecommendedPractice for Software RequirementsSpecifications -
http://www.ieee.org.br/
* http://www.agilealliance.org/article/articles_by_category/17
* http://www.codeproject.com/KB/architecture/scrum.aspx