Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
código fonteEntendendo os Requisitos de Software - Revista .Net Magazine 97
O artigo demonstra os conceitos dos tipos (por exemplo, os Funcionais) de requisitos de software. Estes requisitos são documentados em modelos padrões e refletem as necessidades dos clientes de softwares em resolver determinado problema
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
.net Magazine 97
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 97
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 97
Os requisitos de software são atributos que que desejamos implementar em um sistema. Eles refletem as necessidades dos clientes em relação ao software, por exemplo, cadastrar produtos, incluir pedidos ou consultar estoques.
Para obter a percepção detalhada daquilo que o sistema deve fazer, é recomendado utilizar um conjunto de técnicas de elicitação de requisitos, que visam obter do cliente informações necessárias para desenvolver o projeto de software. Essas técnicas podem envolver diferentes tipos de stakeholders, como: usuários, gerentes, desenvolvedores, especialistas de domínio e sindicatos.
Nota do DevMan
Stakeholders são os usuários envolvidos no sistema, como clientes, analistas de sistemas, desenvolvedores, testador de software, gerentes, entre outros.
As técnicas de elicitação de requisitos e sua compreensão pelos stakeholders são difíceis devidos alguns fatores, tais como:
• Os stakeholders na maioria das vezes não sabem o que desejam no sistema;
• Os stakeholders informam os requisitos de forma que o analista, por falta de conhecimento na área dos stakeholders, não compreende ou compreende de forma ambígua;
• Diferentes stakeholders compreendem os requisitos de maneiras diferentes;
• Fatores políticos e econômicos podem influenciar na especificação de requisitos para o sistema.
Sommerville (2007), ver seção Livros, apresenta um modelo de elicitação e análise de requisitos, o modelo segue conforme mostra a Figura 1.
As atividades do modelo proposto são:
1. Obtenção dos requisitos: processo de interação com os stakeholders para a coleta de requisitos.
2. Classificação e obtenção de requisitos: coleta de requisitos não estruturados, agrupando-os e organizando de forma coerente.
3. Priorização e negociação de requisitos: processo de busca de conflitos de requisitos.
4. Documento de requisitos: processo em que os requisitos são documentados.
As técnicas de elicitação de requisitos poderão incluir a elaboração de questionários (para utilizar na entrevista), observação de comportamento, aprendizagem com o usuário, prototipagem, brainstorming, análise de texto e reutilização de requisitos:
• Entrevistas: as entrevistas com os stakeholders podem ser formais ou informais. Na entrevista, os stakeholders respondem um conjunto de perguntas elaboradas pela equipe de analistas de requisitos, na maioria das vezes as respostas dos stakeholders levam a abordar outros assuntos. As entrevistas são técnicas e, bem úteis, para proporcionar à equipe de analistas o entendimento de como será o sistema.
• Observação do comportamento: técnica utilizada para observar os usuários no ambiente de trabalho;
• Aprendizagem com o usuário: analisa e debate com o usuário sobre a forma de trabalho;
"
Este é um post disponível para assinantes MVP
Para obter a percepção detalhada daquilo que o sistema deve fazer, é recomendado utilizar um conjunto de técnicas de elicitação de requisitos, que visam obter do cliente informações necessárias para desenvolver o projeto de software. Essas técnicas podem envolver diferentes tipos de stakeholders, como: usuários, gerentes, desenvolvedores, especialistas de domínio e sindicatos.
Nota do DevMan
Stakeholders são os usuários envolvidos no sistema, como clientes, analistas de sistemas, desenvolvedores, testador de software, gerentes, entre outros.
As técnicas de elicitação de requisitos e sua compreensão pelos stakeholders são difíceis devidos alguns fatores, tais como:
• Os stakeholders na maioria das vezes não sabem o que desejam no sistema;
• Os stakeholders informam os requisitos de forma que o analista, por falta de conhecimento na área dos stakeholders, não compreende ou compreende de forma ambígua;
• Diferentes stakeholders compreendem os requisitos de maneiras diferentes;
• Fatores políticos e econômicos podem influenciar na especificação de requisitos para o sistema.
Sommerville (2007), ver seção Livros, apresenta um modelo de elicitação e análise de requisitos, o modelo segue conforme mostra a Figura 1.
As atividades do modelo proposto são:
1. Obtenção dos requisitos: processo de interação com os stakeholders para a coleta de requisitos.
2. Classificação e obtenção de requisitos: coleta de requisitos não estruturados, agrupando-os e organizando de forma coerente.
3. Priorização e negociação de requisitos: processo de busca de conflitos de requisitos.
4. Documento de requisitos: processo em que os requisitos são documentados.
As técnicas de elicitação de requisitos poderão incluir a elaboração de questionários (para utilizar na entrevista), observação de comportamento, aprendizagem com o usuário, prototipagem, brainstorming, análise de texto e reutilização de requisitos:
• Entrevistas: as entrevistas com os stakeholders podem ser formais ou informais. Na entrevista, os stakeholders respondem um conjunto de perguntas elaboradas pela equipe de analistas de requisitos, na maioria das vezes as respostas dos stakeholders levam a abordar outros assuntos. As entrevistas são técnicas e, bem úteis, para proporcionar à equipe de analistas o entendimento de como será o sistema.
• Observação do comportamento: técnica utilizada para observar os usuários no ambiente de trabalho;
• Aprendizagem com o usuário: analisa e debate com o usuário sobre a forma de trabalho;
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Celina Ferreira Ribeiro
Sou graduada no curso de Tecnologia em Sistemas para a Internet do Instituto Federal de Educação, Ciência e Tecnologia do Tocantins - Campus Palmas. Atuei durante quatro anos no Projeto SIGA-EPCT-EDU (Sistema Integrado de Gestão Acadêmica da Educação Profissional, Científica e Tecnológica) nas segui...
O que você achou deste post?
Cursos relacionados
Publicidade
