Sei sulla pagina 1di 4

1

Exemplo:

Engenharia de requisitos

Analise de requisito, engenharia de requisitos ou requisito de software so sinnimos. Requisitos de software tratam as questes bsicas para se conhecer a fundo o modelo de negocio do qual seu produto far parte. Os requisitos do sistema so servios que sero fornecidos pelo sistema e refletem as necessidades do cliente. O proposito da engenharia de requisitos ,consiste no processo de descobri ,analisar , documentar e verificar os servios e requisies de devem esta presentes no software

Na hora de detalhar devemos dizer: o sistema deve... + verbo + complemento O Sistema deve validar campo CPF. O Sistema deve emitir relatrio semanal. O Sistema deve manter (Inserir, editar, excluir e pesquisar). Classificao de Requisitos: Requisitos Funcionais: So as declaraes de servios que o sistema deve fornecer como deve reagir a entradas especificas e se comportar em determinadas situaes. Requisitos no funcionais: So Restries sobre os servios ou as funes oferecidos pelo sistema, especificam desempenho, proteo, disponibilidade e outras propriedades do sistema. Exemplo: uma funo ter que ser executada em tanto tempo e com tal recurso ou um sistema web tem que est sempre disponvel para um diretor de uma empresa para tomar uma deciso, nesse caso se for feito um sistema apenas para desktop? Requisitos no funcionais podem ser classificados de 3 formas: Requisitos de Produto esto atrelados a eficincia, confiabilidade e layout da interface. Requisito de Processo envolve requisitos de entrega, de implementaes e de padres. Requisitos Externos Legislao, oramento e interoperabilidade.

Ento se o software no atender os requisitos no funcionais, pode ser que o sistema se torne intil. Requisitos de Domnio: So requisitos provenientes do domnio da aplicao do sistema e refletem as caractersticas e as restries desse domnio. So requisitos tanto funcionais quanto no funcionais, geralmente o analista tem certa dificuldade em

Lucas Daniel Borges

identificar, porque geralmente um domino (um ambiente) diferente que no esto habituados.

Exemplo: uma aplicao de medicina, o domnio especifico da rea de medicina onde o analista no esta acostumado com o vocabulrio. Na minha pesquisa achei sete tarefas da E.R 1. Concepo 2. Levantamento 3. Elaborao 4. Negociao 5. Especificao 6. Validao 7. Gesto

Concepo: onde o analista identifica o que necessrio para se obter o produto final, uma descrio de todo o processo , saber oque deve ser feito para se chegar ao objetivo.(viso inicial). Levantamento: perguntas aos usurios sobre os objetivos e que precisa ser fornecido, dentro das necessidades. Elaborao: Enfoca o desenvolvimento de um modelo tcnico refinado das funes caractersticas e restries do software. O inicio do documento. Negociao: cliente, usurio e outros interessados so solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade. Especificao: o documento de requisitos, a descrio de todo o processo. Validao: examina a especificao, verificar erros. Gesto: Consiste na identificao, rastreamento dos requisitos a serem desenvolvidos com a utilizao de uma tabela a de rastreamento. (ou tabela de rastreabilidade). Fazer como se fosse um checkist , listar todas as funcionalidades e verificar se elas realmente esto no sistema. Tcnicas de levantamento de requisitos: 1. FAST 2. JAD 3. Questionrio

Lucas Daniel Borges

4. Brainstorming 5. Observao Direta

Fast e JAD, so diferentes, mais tem coisas em comum, como por exemplo, uma metodologia que define reunies estruturadas, pr-determinadas, ao final de cada reunio j feio um documento com os requisitos levantados e pode ter a presena de um facilitador para gerenciar as reunies.

Questionrio: pode ser de forma objetiva ou subjetiva podendo esta apresentando esse questionrio para vrios setores da empresa.

Brainstorming: Todas as ideias so validas, todas as pessoas do as ideias e tudo anotado e depois feito o refinamento

Observao Direta: o analista vai esta presente no cotidiano da empresa, pegando as informaes necessrias

Documento de Requisitos

a declarao oficial do que os desenvolvedores de sistemas devem implementar aceito pelo cliente.

No existe software sem documento de requisitos onde estejam descritos inicio e fim e o que deve ser feito.

Modelo mais conhecido de documento de requisitos IEEE/ANSI 830/1998.

Consequncias de no se definir os requisitos adequadamente: 1. Mais manuteno 2. Mais Custos 3. Mais tempo 4. Menos Credibilidade

Lucas Daniel Borges

5. Perda de Clientes

Lucas Daniel Borges

Potrebbero piacerti anche