1 / 16

Análise de requisitos

Análise de requisitos. Profa . Reane Franco Goulart. Requisitos.

perry
Download Presentation

Análise de requisitos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Análise de requisitos Profa. Reane Franco Goulart

  2. Requisitos “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”. Frederick P. Brooks Jr, “No Silver Bullet: Essence and Accidents in Software Engineering”, IEEE Computer, abril 1987.

  3. O quesãorequisitos? • Requisitos são as necessidades do cliente para um sistema de software. • Requisitos são descritos em diferentes níveis de abstração: • Requisitos de usuário: especificam em linguagem natural as funções que o sistema deve prover ao usuário final;

  4. O quesãorequisitos? • Requisitos de sistema: especificam em linguagem natural (mais estruturada) as funções e restrições (especificação funcional) para que o sistema de software seja capaz de atender os requisitos de usuário.

  5. Níveis de abstração dos requisitos?

  6. RequisitosFuncionais • Descrevem as funcionalidades ou serviços que se espera do sistema. • Estes requisitos tem uma característica importante, pois são eles que agregam valor ao software ou facilitam a vida do usuário. • Exemplo: “o sistema deve notificar ao requisitante por e-mail quando sua requisição estiver disponível para retirada”.

  7. RequisitosFuncionais • Eles expressam o comportamento de um software. • As informações de entrada, o processamento e a saída emitida por uma funcionalidade são informações necessárias para especificar o requisito do referido grupo.

  8. Requisitosnãofuncionais • Mapeiam os aspectos qualitativos de um software, por exemplo: • performance (tempo de resposta); • segurança (restrições de acesso, privilégios); • perspectiva do usuário (padrão das cores, disposição dos objetivos na tela); • comunicabilidade (e-mail, VoIP, Browser); • usabilidade e portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis, desktop, notebook).

  9. Requisitosnãofuncionais • Este grupo é de suma importância e não deve ser desprezado durante o processo de produção de software. Como qualquer outro tipo de requisito, ele deve ser levantado, analisado, especificado e validado.

  10. Validação de um requisito não funcional • Exemplo: • Um requisito não funcional qualquer estabelece que o software tem que ter um bom tempo de resposta. • Para quantificar esse requisito, pergunte ao usuário o que ele considera um bom tempo de resposta. Uma variação ente 0,5 e 2 segundos é aceitável? • Enfim, os requisitos não funcionais são de suma importância e podem delimitar o sucesso ou o fracasso de um projeto de software.

  11. Documentação dos requisitos • Documentar requisitos custa caro. • Você pode chegar numa documentação de 500 páginas de um único requisito com diagramas, protótipos, documentação descritiva e no final das contas produzir um artefato que ninguém vai ler ou seguir, ou ainda, escrever uma documentação de meia-página que não ilustra o problema real. • Então como chegar no nível certo de documentação?

  12. Documentar um requisito • O cliente entende o documento? • Ele entende que o documento é uma poderosa ferramenta para garantir que todas as suas solicitações serão contempladas no sistema?

  13. Documentar um requisito • O desenvolvedor entende o documento? • Ele entende que esse é sua única garantia de que está atendendo todas as solicitações do usuário e qualquer solicitação fora disso poderá ser considerado como modificação e ele terá tempo extra para fazê-las?

  14. Documentar um requisito • O responsável pela implantação consegue entender como o sistema funciona baseado nesse documento?

  15. Que artefatos usar para documentar um requisito? • Para cada metodologia, usa-se um nome diferente para um documento de requisito ou artefato diferente para realizar a documentação: • Em análise estruturada (voltando aos anos 70-80), usava-se o DFD, e muita documentação descritiva. • Em UML geralmente chama-se de “caso de uso”.

  16. http://rodrigodotnet.wordpress.com/2010/09/01/levantamento-de-requisitos-parte-1/http://rodrigodotnet.wordpress.com/2010/09/01/levantamento-de-requisitos-parte-1/ • http://eduardo-prola.blogspot.com.br/2011/10/pessoal-excelentes-dicas-para-o.html • http://codipse.tigris.org/planatividades.htm

More Related