SóProvas

Questões de Engenharia de Requisitos

ID
5413
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as afirmativas abaixo a respeito de técnicas de levantamento de requisitos:

I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente.

II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

Estão corretas apenas as afirmativas:

Alternativas
Comentários
  • Nunca imaginei que um requisito poderia ser "excitante" (não formalmente falando)! Acredite! Veja lá: PRESSMAN, Sexta edição, página 128: São requisitos "que vão além das expectativas do cliente e mostram ser muito satisfatórias quando presentes."

  • I - Uma entrevista não estruturada deve "fluir" entre o entrevistado e o entrevistador e, para isso, as questões a serem feitas não se devem ser definidas previamente. 

    ERRADO.  As questões devem ser definidas anteriormente, porém a forma com a qual essas questões serão estruturadas é que não é definida.

    As questões podem ser abertas (subjetivas) ou fechadas (objetivas) e podem ser estruturadas em várias estruturas (Pirâmide, Funil e Diamante), ou em nenhuma estrutura como cita a questão.
     

    II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software, identificando três tipos de requisitos: normais, esperados e excitantes.

    Sim, isso mesmo. (Requisitos Excitantes - Que excedem a expectativa do cliente )

    III - Amostragem é o processo de seleção sistemática de elementos representativos de uma população, que permite revelar informações úteis acerca da população como um todo.

    Correto também. Quando o universo da população é muito grande pode-se utilizar uma parcela dessa população para se representar o todo.

    IV - Uma técnica importante no levantamento de requisitos é observar o comportamento e o ambiente do indivíduo tomador de decisões, já que muitas informações passam desapercebidas com a utilização de outras técnicas.

    Observar o comportamento e o ambiente do indivíduo que toma decisões pode ser
    uma forma bastante eficaz de levantar informações que, tipicamente, passam
    desapercebidas usando outras técnicas.

    Note que as pessoas tem um conhecimento tácito, algo inerente a elas que não pode ser facilmente formalizado em um documento.

  • Eu havia considerado a IV incorreta por causa do "tomador de decisão"
     
    Etnografia para o sommerville:
    Utilizada para compreender os requisitos sociais e organizacionais. Um analista se insere no ambiente de trabalho onde o sistema será usado. Observa o trabalho do dia a dia e anota as tarefas reais nas quais os participantes estão envolvidos. O valor da etnografia está na ajuda que presta aos analistas para descobrir requisitos implícitos de sistemas que refletem os processos reais, e não os formais.
    Ela é eficaz para descobrir dois tipos de requisitos:
    1. derivados da maneira como as pessoas realmente trabalham
    2. derivados da cooperação e do conhecimento das atividades de outras pessoas.
     
    Não consigo enxergar o tomador de decisões neste contexto.
  • Entendo tomador de decisão como stakeholder nesta situação.

  • A Implantação da Função de Qualidade (IFQ) -Quality Function Deployment- traduz as necessidades do cliente para requisitos técnicos do software, maximizando a satisfação do cliente a partir do processo de engenharia de software com entendimento do que tem valor para o cliente e depois implanta-los por meio do processo de engenharia. A IFQ identifica três tipos de requisitos:

    requisitos normais: refletem os objetivos para um produto durante as reuniões com o cliente. Se esses requisitos estiverem presentes, o cliente fica satisfeito;

    requisitos esperados: implícitos e podem ser fundamentais; o cliente não se refere a eles explicitamente. Sua ausência seria insatisfação significativa (facilidade de interação homem/máquina, correção e confiabilidade operacional global e facilidade de instalação do software)- heuristicas de neuman sao referencia para cumprir os requisitos espeardos

    requisitos instigantes:além das expectativas do cliente

  • Leonardo Marcelino Teixeira, acredito que o enunciado IV não está abordando especialmente sobre o "tomador de decisões", mas sim, sobre o comportamento e ambiente do mesmo, pois, dependendo do indivíduo que toma tais decisões, suas técnicas e vícios de linguagem, por exemplo, podem dificultar a compreensão do que realmente é necessário e importante para o sistema, durante a fase de levantamento de requisitos.

ID
5419
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre a Análise e o Gerenciamento de Requisitos, é FALSO afirmar que:

Alternativas
Comentários
  • Item "C": It's not about the customer. It's about the requirement analyst.
  • Essa questão deveria ser anulada porque a letra "b" também está incorreta.  "formalização das necessidades e restrições dos usuários em requisitos funcionais de software.".  Restrições de usuarios são requisitos não-funcionais.  Quando se está lutando por uma vaga entre muitos para um emprego de mais de 6,000 reais mensais, não tem espaço para erros na elaboração de questões.  Realmente, preciso de um milagre para passar.

  • Realmente a letra B também está errada. 

  • Durante a elicitação dos requisitos, também deve ser levado em consideração as restrições do projeto ou do software. Que de uma forma meio estranha a questão chamou de restrições do usuário. Mas de qualquer maneira a opção C está muito mais errada pois quem "utiliza as melhores práticas de engenharia de requisitos na tarefa de descrever suas necessidades." é o analista de sistemas/negócios e não o cliente.

    https://www.devmedia.com.br/elicitacao-de-requisitos-levantamento-de-requisitos-e-tecnicas-de-elicitacao/31872

  • Assertiva errada, como pode o cliente usar das melhores práticas, se é ele quem precisa de ferramentas e técnicas oferecida pela análise para resolver o seu problema? Sem cabimento!

    Resposta: C

ID
7339
Banca
ESAF
Órgão
CGU
Ano
2004
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmações relativas à Engenharia de Software:

I. A análise de requisitos é responsável pela especificação dos requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.

II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.

III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for construído.

IV. A análise de requisitos possibilita que o engenheiro de software especifique a função e o desempenho do sistema e estabeleça quais são as restrições de projeto que o sistema deve atender.

Estão corretos os itens:

Alternativas
Comentários
  • Alternativa c) III e IV corretas

    I. A análise de requisitos é responsável pela especificação dos requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.

    II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.

  • Erro do item I. Não se trata dos requisitos que serão utilizados durante mas sim o que o software deverá ter após a sua implantação.

ID
8215
Banca
ESAF
Órgão
Receita Federal
Ano
2005
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmações relacionadas à Engenharia de Software, modelos de desenvolvimento e análise de requisitos:

I. O modelo de desenvolvimento denominado 4GT (técnicas de quarta geração) caracteriza-se pelo desaparecimento da atividade de Teste, que normalmente é a última atividade para os demais modelos de desenvolvimento de software. Essa característica especial do modelo 4GT é conseqüência do uso de ferramentas de desenvolvimento de software, que permite ao desenvolvedor especifi car características do software em um nível elevado, garantindo a qualidade em qualquer etapa do ciclo de vida do projeto.

II. Durante a análise de requisitos, são especifi cados a função e o desempenho do software, bem como a sua interface com outros elementos do sistema. Nessa etapa, também, são estabelecidas as restrições de projeto, a que o software deve atender.

III. Durante a análise de requisitos, o principal foco do analista recai sobre "como" e não sobre "o que". Nesse caso, o analista concentra-se em como o sistema produz ou consome dados, como o sistema deve executar as funções e como as restrições e interfaces são defi nidas.

IV. Durante a especifi cação dos requisitos, são estabelecidos os critérios que permitirão ao desenvolvedor e ao cliente avaliar a qualidade, assim que o software for construído.

Indique a opção que contenha todas as afirmações verdadeiras.

Alternativas
Comentários
  • I - FALSA - O modelo 4GT recomenda fortemente a atividade de testes e não o seu desaparecimento .

    II - VERDADEIRO - note que é utilizado a palavra especificar
    "são especifi cados a função e o desempenho do software"

    III- FALSA - Durante a analise o principal foco é conhecer o problema, ou seja, 'O que' resolver para que no design seja proposto 'como'
  • e...IV - certíssima: os requisitos são exatamente o principal parâmetro para a validação do software, e critérios de qualidade.Critérios de qualidade da norma ISO 9126:- Funcionalidade- Usabilidade (facilidade de aprender e usar)- Confiabilidade (frequência de falhas e recuperação dessas falhas)- Eficiência (desempenho)- Manutenibilidade (facilidade de manter o software)- Portabilidade (facilidade de portar o software para outros ambientes)
  • Para mim a alternativa II está errada no ponto em que fala que são especificadas as interfaces com outros elementos do sistema, uma vez que isso é feito durante o projeto.
  • "II. Durante a análise de requisitos, são especificados (analisados) a função e o desempenho do software,..."
     
    função-> requisitos funcionais
    desempenho -> requisitos não funcionais

    Enfim, os requisitos são especificados na fase de     Especificação de Requisitos.
    A análise de requisitos visa a descobrir alguns problemas e torná-los mais consistentes antes da especificação formal
    Atividades da análise de requisitos:
    Classificação e organização
    Checagens de:
    ?Consistência
    ?Ambiguidade
    ?Omissões
    ?Relacionamentos entre requisitos, etc
    Priorização e negociação
ID
11971
Banca
CESPE / CEBRASPE
Órgão
Polícia Federal
Ano
2004
Provas
Disciplina
Engenharia de Software
Assuntos

Considere que se deseja desenvolver um sistema para controle
de caixa de supermercado tendo como base um computador
que registra os produtos vendidos, interagindo com
dispositivos de entrada e saída tais como impressora, teclado
e leitora de código de barras. Esse sistema deve interagir
também com o operador do caixa e com um banco de dados do
estabelecimento. A partir dessas informações, julgue os itens
que se seguem.

A descrição informal do que o sistema deve fazer, tal como ler código de barras, identificar o produto e calcular o total da compra, faz parte da especificação de requisitos do programa.

Alternativas
Comentários
  • Não concordo com a resposta (C), pois a especificação de requisitos é o auge da Engenharia de Requisitos e serve para formalizar e documentar os requisitos capturados nas etapas anteriores.
    Segundo Pressman, as fases seriam: concepção, levantamento, elaboração, negociação, ESPECIFICAÇÃO, validação e verificação, e gestão.
    A descrição informal, como descrita no enunciado, seria na fase de elaboração.
  • também concordo, por mim a questão é incorreta, a engenharia de software recomenda a descrição formalizada do requisito para facilitar a sua análise
  • Descrição informal, pode se referir a respeito de requisitos não funcionais.
  • a questão está correta. Requisitos não funcionais sao exemplos

  • Pessoal,

    a questão está corretíssima! Tudo que foi falado na questão é requisito e a descrição pode ser formal ou informal.

    Quanto a interpretação de requisito funcional e não funcional esta questão nem toca nesse assunto, mas vamos lá:

    Os requisitos funcionais descrevem os serviços que os sistema deve oferecer e como reagir a certas situações (o que o sistema deve fazer!. Ex: ler código de barras, identificar produto, etc). Geralmente os requisitos funcionais são abstratos.

    Os requisitos não funcionais são RESTRIÇÕES sobre os serviços ou funções do sistema. Aplicam-se ao sistema como um TODO. (Requisitos de produto, organizacionais ou externos)

    Pessoal, finalizo com uma dica: se concentrem na questão, ela pedia apenas se o que o sistema vai fazer é requisito? Pronto, não pediu nada de req funcional ou não funcional. A CESPE faz isso mesmo bota um questão pro candidato filosofar sobre ela...ai ja era!

    Abraços

  • Tenho uma professora que diz "Se você curtir a questão, erra!"
    Em tempo: ela dizia isso muito tempo antes do facebook vingar aqui no brasil.

  • Gabarito Certo

    A análise e especificação de requisitos de software envolve as atividades de determinar os objetivos de um software e as restrições associadas a ele. Ela deve também estabelecer o relacionamento entre estes objetivos e restrições e a especificação precisa do software.

    A análise e especificação dos requisitos de software deve ser vista como uma sub-atividade da análise de sistemas. Normalmente ela é iniciada juntamente com a análise do sistema, podendo se estender após a elaboração do documento de especificação do sistema e do planejamento do desenvolvimento, quando serão refinados os requisitos do software.

    Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente. A análise é o processo de observação e levantamento dos elementos do domínio no qual o sistema será introduzido. Deve-se identificar  as pessoas, atividades, informações do domínio para que se possa decidir o que deverá ser informatizado ou não. Pessoas e as atividades que não serão informatizadas deverão ser consideradas entidades externas ao software.

    A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o problema do domínio. A especificação é também a forma de comunicação sistemática entre analistas e projetistas do software.

    O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para  que se possa avaliar se o sistema cumpre o que foi definido.

     

    "Retroceder Nunca Render-se Jamais !"
    Força e Fé !
    Fortuna Audaces Sequitur !

  • Assertiva correta, isto mesmo, no processo de levantamento de requisitos são levantadas as regras de negócios da empresa, como todo o processo ou fluxo de trabalho desta, quanto mais completa esta análise, menores são as possibilidades de erros na execução do processo assistida pelo sistema.

    Resposta: Certo

ID
43687
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as afirmativas a seguir, sobre requisitos em projetos de software.

I - O rastreamento de requisitos é de grande importância para conduzir análises de impacto quando há mudanças em requisitos.

II - O acrônimo FURPS+ se refere aos requisitos não funcionais das categorias de Feasibility, Usability, Reliability, Performance e Supportability.

III - Um requisito pode conter, além da especificação, atributos que sirvam ao seu gerenciamento.

IV - Casos de uso são descrições da interação entre um ator e o sistema e, portanto, especificam apenas requisitos funcionais.

Estão corretas APENAS as afirmativas

Alternativas
Comentários
  • FURPS+ (Functionality, Usability, Reliabilty, Performance, Supportability) o sinal de (+) significa outros requisitos não funcionais.
  • FURPS+ é um sistema para a classificação de requisitos, o acrônimo representa categorias que podem ser usadas na definição de requisitos, assim como representa atributos de Qualidade de Software, sendo ele parte do Rational Unified Process (RUP).Os requisitos, funcionais ou não, estarão contidos nestas categorias. Então FURPS+ não são requisitos não funcionais e sim categorias classificadoras de requisitos.
  • URPS+ é um sistema para a classificação de requisitos, o acrônimo representa categorias que podem ser usadas na definição de requisitos, assim como representa atributos de Qualidade de Software, sendo ele parte do Rational Unified Process (RUP):Functionality (Funcionalidade) – representa todo aspecto funcional do software, ou seja seus requisitos. É uma categoria com diversas subcategorias que variam de acordo com a aplicação. Sua medição considera, principalmente, o cumprimento dos requesitos especificados.Usability (Usabilidade) – é o atributo que avalia a interface com o usuário. Possui diversas subcategorias, entre elas: prevenção de erros; estética e design; ajudas (Help) e documentação; consistência e padrões.Reliability (Confiabilidade) – refere-se a integridade, conformidade e interoperabilidade do software. Os requisitos a serem considerados são: freqüência e gravidade de falha; possibilidade de recuperação; possibilidade de previsão; exatidão; tempo médio entre falhas (MTBF).Performance (Desempenho) – avalia os requisitos de desempenho do software. Podendo usar como medida diversos aspectos, entre eles: tempo de resposta, consumo de memória, utilização da CPU, capacidade de carga e disponibilidade da aplicação.Supportability (Suportabilidade) – os requisitos de suportabilidade agrupam várias características, como: testabilidade, adaptabilidade, manutenibilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade, localizabilidade entre outros.
  • O acrônimo FURPS+ não se refere apenas a requisitos não funcionais. O 'F' se refere a Funcionalidade, que é um requisito funcional.

    O acrônimo se refere ao requisito funcional Funcionalidade, aos requisitos não funcionais Usabilidade, Confiabilidade (Reliability), Desempenho (Performance) e Suportabilidade, e também a outros requisitos não funcionais (daí o + ao final do acrônimo).

  • O item I cai em gerenciamento de requisitos, onde são feitas tabelas de rastreamento dos mesmo. É possível através das tabelas de rastreamento ver como um requsito influencia em outro, ou em uma caracterísctica do sistema, ou de interface, e etc.

    III - O levantamento de requisitos possui algumas fases: concepção (onde é o início, onde uma oportunidade de negócio é descoberta, onde um cliente entra em contato com uma empresa pedindo serviços...é onde ocorrem várias perguntas livres dos analistas de software para os interessados. Tudo para obter o maior número de informações possíveis); levantamento de requisitos (onde a equipe sabe que os mesmos irão se alterar durante o desenvolvimento da engenharia de software); elaboração (onde é feito um refinamento dos requisitos, além do acréscimo de mais); negociação (onde são refinados os requisitos, retirando as ambiguidades e conflitos); especificação (documento que será a base para averiguar a qualidade); gestão de requisitos (administração dos requisitos, acompanhamento dos mesmo quanto a alterações: criação de tabelas de rastreamento).

    Assim sendo, um requisito não tem somente especificação, mas tem também um rastreador. Essas tabelas (são de vários tipos) fazem um cruzamento entre os requisitos e aspectos do software, outros requisitos e etc.

    IV - um caso de uso pode especificar requisitos não-funcionais. Ex: Ao clicar em um botão, o sistema deverá responder em menos de um segundo, mostrando a resposta em um página diferente e forma gráfica.

  • Pessoal, vamos aos erros da questão: O acrônimo se refere ao requisito funcional Funcionalidade, aos requisitos não funcionais Usabilidade, Confiabilidade (Reliability), Desempenho (Performance) e Suportabilidade, e também a outros requisitos não funcionais, o + ao final do acrônimo.

    Resposta: B

ID
51319
Banca
CESGRANRIO
Órgão
TJ-RO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Durante as atividades de Requisitos em um projeto de desenvolvimento de software, são realizadas entrevistas com clientes (usuários e stakeholders, no papel de entrevistados) com o objetivo de levantar suas necessidades e validar as características propostas para o software a ser desenvolvido. Os analistas, no papel de entrevistadores, em geral utilizam dois tipos de perguntas durante as entrevistas: perguntas livres de contexto e perguntas no contexto da solução. Sobre o tema, assinale a afirmativa correta.

Alternativas
Comentários
  • A) certa;

    B) primeiramente deve ser feita perguntas livres de contexto para evitar idéias preconcebidas sobre os requisitos e  ouvir os stakeholders. [Sommerville - pg 102] - errada

    C) "Entrevistas abertas, nas quais não existe um roteiro predefinido. A equipe de engenharia  de requisitos explora vários assuntos com os stakholders no sistema e, assim, desenvolve uma compreensão maior de suas necessidades."[sommerville - pg 101] trocou os conceitos - errada

    D) é uma pergunta livre de contexto

    E) "A entrevista não é uma técnica eficiente para a elicitação de conhecimentos sobre os requisitos..." [Sommerville - pg 102] - errada
ID
51322
Banca
CESGRANRIO
Órgão
TJ-RO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considere os quatro requisitos registrados em um projeto de uma aplicação para a Internet apresentados a seguir.

I - O tempo de resposta máximo do sistema a qualquer ação do usuário deve ser de 5s.

II - Clientes que tenham pago as últimas cinco compras à vista têm direito a um desconto não cumulativo de 10% na próxima compra.

III - A interface com o usuário deve ser organizada em abas e menus.

IV- Se o produto possuir uma quantidade máxima permitida por compra, esse limite deve ser imposto pelo sistema durante uma compra.

São tipicamente classificados como requisitos funcionais APENAS os requisitos

Alternativas
Comentários
  • Requisitos Funcionais - funcionalidades do sistema que os desenvolvedores precisam implementar para satisfazer os objetivos do negócio.Requisitos Não-Funcionais - padrões, descrições de interface externa, requisitos de desempenho, características de qualidade(confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade)
  • III- A interface com o usuário deve ser organizada em abas e menus. Requisito Não funcional
    Compare com o requisito funcional citado por Sommerville
    O sistema deve prover telas apropriadas para o usuário ler documentos no repositório de documentos. Requisito funcional
    Um Requisito não funcional é também restrições de sistema, que podem se enquadrar ou não em desempenho, usabilidade, portabilidade.

    Assim "abas e menus" é uma restrição de usabilidade, mas uma restrição específica na execução do sistema, pode não se enquadrar em desempenho,portabilidade, dentre outros, mas ainda assim será uma restrição. E como restrição será um Requisito Não Funcional.
ID
56725
Banca
CESPE / CEBRASPE
Órgão
ANAC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em engenharia de software, o processo de
desenvolvimento de software designa uma sequência de
atividades, agrupadas em fases e tarefas, executadas de forma
sistemática e uniformizada, realizadas por pessoas com
responsabilidades bem definidas e que, a partir de um conjunto
de entradas (inputs) produzem um conjunto de saídas (outputs).
Como objetivos, o processo de desenvolvimento de software deve
prover orientação sobre as sequências das atividades envolvidas,
especificar os modelos descritivos do sistema, gerenciar as tarefas
e definir métricas para os modelos e atividades.

R. A. Ramos. Treinamento em UML (com adaptações).

Quanto às fases e tarefas no processo de desenvolvimento de
software, julgue os itens de 64 a 67.

A fase de projeto define o que o software deve fazer, enquanto a fase de eliciação de requisitos define como o software deve atingir seus requisitos.

Alternativas
Comentários
  • Modelagem de negócio é que define o que o projeto deve fazer.
  • E elicitação é o levantamento dos requisitos.

  • Fase de eliciação de requisitos = análise de requisitos: Define o que o sistema deve fazer, focando apenas nas funções sem se preocupar como será implementado (tecnologia, linguagem, ambiente,...)

    Fase de projeto: Define como o sistema deve ser implementado para que melhor sejam executadas as funções que este deve fazer.

  • acredito que esteja invertido
ID
70279
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

São técnicas e abordagens utilizadas na obtenção dos requisitos:

Alternativas
Comentários
  • Técnicas de elicitação de requisitos:
    1. Amostragem
    2. Investigação de documentos
    3. Estudo Etnográfico
    4. Entrevista e questionário
    5. WorkShop de requisitos
    6. Cenários
    7. Prototipagem
    8. JAD - Joint Application Development
  • Interessante comentar que nem toda técnica de elicitação de requisitos são auto-suficientes.
    Muitas vezes é necessário combinar várias técnicas para alcançar o objetivo.
  • Pressman classifica as técnicas de elicitação em:
    1.       Pontos de Vista
    2.       Entrevistas
    3.       Cenários
    4.       Casos de Uso
    5.       Etnografia
     
    O Swebok (SoftWare Enginering Body of Knoledge) classifica as técnicas em:
    1.       Entrevistas
    2.       Cenários
    3.       Protótipos
    4.       Brainstorm
    5.       Observação

    Imagino que outros classifquem de outras formas.... a verdade é que não há uma LEI ou CONSENSO único internacionalmente estabelecido como padrão. Como o enunciado não cita a referência, resolvi esta questão por eliminação considerando os tipos de classificação que conheço.

  • Bom acredito que validação não seja de todo errado, pois durante a validação são feitas revisões, protótipos, casos de testes que quase sempre acabam por determinar novos requisitos ou rever antigos.

    Enfim D por ser a mais certa, mas fica o alerta. 

     

     

  •  d)pontos de vista, cenários e entrevista.

    obtenção de requisitos (requirement procurement)

    1 cenários - descrição do que eles querem, fluxo, erros, atividades paralelas, estados

    2 entrevistas - fechada ou aberta

    3- pontos de vista - interação (pessoas e outros sistemas), indireto (envolve stakeholders externos), dominio (features & restrições)

    4- casos de uso (baseados em cenarios e interações individuais com sistema)

  • Isso mesmo meus amigos, conforme abordado na aula, estas são técnicas de abordagem utilizadas na obtenção de requisitos.  

    Resposta: D

ID
70333
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação aos requisitos de software, considere:

I. funcionais são somente requisitos de usuário.

II. funcionais e não-funcionais podem ser requisitos de usuário.

III. funcionais e não-funcionais podem ser requisitos de sistema.

Está correto o que se afirma APENAS em

Alternativas
Comentários
  • Requisitos funcionais: são aqueles que descrevem o comportamento do sistema, ou seja, descreve O QUE o sistema deve fazer. Os requisitos não-funcionais geralmente estão ligados a qualidade do produto, como performance, robudez, confiabilidade. Eles definem se o sistema será eficiente ou não. Ele define COMO o sistema deve fazer.

  • Requisitos do usuário descrevem os requisitos funcionais, não funcionais e de domínio numa linguagem que o usuário final possa entender.

    Requisitos do sistema descrevem os requisitos de usuário de forma mais detalhanda, usando-se termos técnicos e diagramas.

    Requisitos não-funcionais são classificados em 3 tipos: Produto / Organizacional / Externo

    As assertivas:

    I. funcionais são somente requisitos de usuário. ERRADO

    II. funcionais e não-funcionais podem ser requisitos de usuário. CERTO

    III. funcionais e não-funcionais podem ser requisitos de sistema. CERTO.

  • Requisitos do usuário descrevem os requisitos funcionais, não funcionais e de domínio numa linguagem que o usuário final possa entender. Requisitos do sistema descrevem os requisitos de usuário de forma mais detalhada, usando-se termos técnicos e diagramas. Nestes diagramas podemos citar os Diagramas de Caso de Uso, que mostra em fluxo como o sistema em seu comportamento no momento da interação entre atores deste, assim como no fluxo de execução.

    Resposta: E

ID
72100
Banca
CESGRANRIO
Órgão
IBGE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com o objetivo de minimizar os problemas enfrentados e melhorar o processo de engenharia de requisitos, um engenheiro de requisitos decidiu elencar uma série de medidas que poderá empregar em seus futuros projetos, tais como:

I - aplicar a técnica de IFQ (Implantação da Função de Qualidade) que permite coletar os requisitos excitantes, os quais refletem características que vão além das expectativas do cliente e mostram ser muito satisfatórios quando presentes;

II - utilizar tabelas de rastreamento que relacionam os requisitos identificados a um ou mais aspectos do sistema;

III - utilizar casos de uso para fazer uma coleta iterativa de requisitos, uma vez que o processo de levantamento de requisitos é uma atividade evolutiva.

Está(ão) correta(s) a(s) medida(s)

Alternativas
Comentários
  • Segundo Pressman (Engenharia de Software, 6ª edição, seção 7.4.2)  A Implantação da Função de Qualidade (AFQ), ou Quality Function Deployment (QFD), é uma técnica que traduz as necessidades do cliente para requisitos técnicos de software. Ela identifica três tipos de requisitos:

    Requisitos normais - foram definidos em reuniões com clientes. Se estes requisitos estiverem presentes, o cliente fica satisfeito.

    Requisitos esperados - estão implícitos no sistema e podem ser tão fundamentais que o cliente não se refere a eles explicitamente. Sua ausência seria causa de insatisfação significativa.

    Requisitos excitantes - vão além das expectativas do cliente. Mostram ser muito satisfatórios quando presente.
  • Pressman 7a edição
    Requisitos fascinantes - Esses recursos vão além da expectativa dos clientes e demonstram ser muito satisfatórios quando presentes. página 136
    Requisitos fascinantes = requisitos excitantes
  • Pensei que o item III estivesse errado. Não consigo entender porque o levantamento de requisitos é uma atividade evolutiva. Depende do contexto. Dentro de um modelo incremental a tarefa de levantamento fará parte dessa evolução do projeto como um todo. Agora, falando de uma tarefa, uma sprint, na minha visão o levantamento não pode ser evolutivo. Ele precisa estar completo para que a execução seja realizada.
    Alguém consegue explicar melhor porque esse item está correto?
    Obrigada.
  • Ola Ieda, então... primeira coisa é separar as matérias, vejo vc citando sprint, percebo que vc esta com a matéria de Scrum no meio... A questao trata de requisitos e não de metodologias ageis de desenvolvimento.
    Segundo, pensa comigo... cenários, etnografia, são todas técnicas de elicitação de requistos.
    Cenários podem evoluir? SIM
    Etnografia devem ser feitas somente uma vez? NAO... entao tambem podem evoluir...
    espero ter ajudado! abraço

  • Questão ruim. Onde que levantamento é evolutivo? Pode sofrer alteração, mas evolutivo nunca. 

  • Eu não sabia que casos de uso era iterativo
ID
79225
Banca
FCC
Órgão
TRT - 18ª Região (GO)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considerando que a especificação dos requisitos pode não ser completa durante o estágio de Análise de Requisitos, em razão da imaturidade de conhecimento de clientes e desenvolvedores, é recomendável que a análise e modelagem dos requisitos tenham uma abordagem

Alternativas
Comentários
  • Resposta letra D.
    Desenvolvimento Iterativo:
    Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que consiste em várias iterações. Uma iteração incorpora um conjunto quase seqüencial de tarefas em modelagem de negócio, requisitos, análise e design, implementação, teste e implantação, em várias proporções, dependendo do local em que ela está localizada no ciclo de desenvolvimento.As iterações nas fases de iniciação e de elaboração concentram-se nas atividades de gerenciamento, requisitos e design. As iterações na fase de construção concentram-se no design, na implementação e no teste. E as iterações na fase de transição concentram-se no teste e na implantação.As iterações devem ser gerenciadas em um estilo com caixa de hora, ou seja, o planejamento de uma iteração deve ser considerado fixo e o escopo do conteúdo da iteração gerenciado ativamente para atender a esse planejamento.

  • Mas porque o processo Iterativo? Um projeto que faça o uso do desenvolvimento iterativo, tem um ciclo de vida que consiste em várias iterações. Uma iteração incorpora um conjunto sequencial das tarefas em sum modelagem de negócio, requisitos, análise e design, implementação, teste e implantação, em várias proporções. Dependendo de onde está localizado no ciclo de desenvolvimento. As iterações nas fases de iniciação e de elaboração concentram-se nas atividades de gerenciamento, requisitos e design. As iterações na fase de construção concentram-se no design, na implementação e no teste. E as iterações na fase de transição concentram-se no teste e na implantação. As iterações devem ser gerenciadas em um estilo com caixa de hora, ou seja, o planejamento de uma iteração deve ser considerado fixo e o escopo do conteúdo da iteração gerenciado ativamente para atender a esse planejamento. Mas o grande segredo deste modelo em todo o processo é: ele segue um fluxo de constante contato com o cliente durante o desenvolvimento do projeto.

    Resposta: D

ID
81616
Banca
FCC
Órgão
TRE-AM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Para se garantir a qualidade dos processos, vários passos devem ser tomados, entre eles:

I. Gerenciar os requisitos, identificando quais são as principais necessidades do software, levanto em conta tanto os requisitos funcionais quanto os não funcionais.

II. Acompanhar o projeto de software para que se possa ter uma visão bem realista do progresso do projeto, sendo possível tomar ações eficazes quando o desempenho software se desviar de forma significativa dos planos do projeto.

III. Gerenciar a configuração do software para estabelecer e manter a integridade dos produtos do projeto ao longo do ciclo de vida do software para dar maior segurança ao desenvolvedor e permitir maior controle de desenvolvimento.

IV. Desenvolver um processo padrão para ser gerenciado e revisado, Identificar os pontos fortes e fracos do processo de desenvolvimento e planejar atividades de melhoramento.

É correto o que se afirma em

Alternativas
Comentários
  • O enunciado deveria ser:

    Para se garantir a qualidade "do software" e não "dos processos".

    Com esse enunciado entendo que a resposta correta seria letra A(ítens II e IV).

  • 1 – Para se garantir a qualidade dos processos, vários passos devem ser tomados, entre eles: Gerenciar os requisitos, identificando quais são as principais necessidades do software, levanto em conta tanto os requisitos funcionais quanto os não funcionais.

     

    2 - Acompanhar o projeto de software para que se possa ter uma visão bem realista do progresso do projeto, sendo possível tomar ações eficazes quando o desempenho software se desviar de forma significativa dos planos do projeto, é um passo para se garantir a qualidade dos processos.

     

    3 – Gerenciar a configuração do software para estabelecer e manter a integridade dos produtos do projeto ao longo do ciclo de vida do software para dar maior segurança ao desenvolvedor e permitir maior controle de desenvolvimento, é um passo para se garantir a qualidade dos processos.

     

    4 – Desenvolver um processo padrão para ser gerenciado e revisado, Identificar os pontos fortes e fracos do processo de desenvolvimento e planejar atividades de melhoramento, é um passo para se garantir a qualidade dos processos.

  • Embora não ache que irá ser tema de questão, uma coisa me chamou a atenção neste comentário: "pela autoridade ou pelo particular". Parece besteira, mas nunca tinha atentado ao fato que um particular também pode provocar ou forjar um flagrante. Apenas um comentário pessoal :)

ID
105598
Banca
FCC
Órgão
DPE-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto da Engenharia de Requisitos, considere:

I. O sistema deve fornecer uma entrada de dados que possibilite a inclusão de atributos de permissão de acesso às dependências da corporação por técnicos, supervisores e chefes.

II. Algumas permissões de acesso deverão ter tratamento especial para a entrada de atributos. Para este tipo de permissão, atributos excedentes a uma faixa predeterminada só poderão ser incluídos por chefes de seção.

Em relação às assertivas acima, é correto afirmar:

Alternativas
Comentários
  • O II é requisito não funcional?
    " só poderão ser incluídos por chefes de seção." 
     isso é uma regra funcional ao sistema, ou regra de negócio... seria requisito funcional também.
  • Eu marquei a questão C.
  • Em todos os tipos de especificação há 2 tipos de requisitos a considerar:
    • Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.
    • Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.
    http://pt.wikipedia.org/wiki/Engenharia_de_requisitos
  • Ponto pacífico que a opção (B) está errada.
    As opções (D) e (E) tbm estão erradas pois constitui requisitos (basta isso para invalidar a opção, independente do resto da frase).

    A dúvida está na (A) ou (C).
    Concordo com os amigos. Eu também marquei a letra (C).

    O fato da assertiva II dizer "tratamento especial para a entrada de atributos" , não a torna um requisito funcional?
    Tem uma parte da definição de RF que diz "as funções ou serviços são, em geral, processos que utilizam entradas para produzir saídas."

    Entrada:
    "Atributos excedento faixa determinada" E alterados/incluído por "chefe".

    Saída:
    Permissão concedida.
  • Eu também marquei a C. Mas lendo Sommerville, encontrei um trecho na página 122 da 8a. Edição que talvez dê base para o gabarito:

    "non-funcional requirements arise through user needs, because of budget constraints, because of ORGANISATIONAL POLICIES, ..."

    Creio que o item II se encaixa como Requisitos Organizacionais dos Requisitos Não-Funcionais.
  • Como a palavra chave, na própria definição de um requisito não funcional, é RESTRIÇÃO, basta observarmos o início da frase do item II: "Algumas permissões de acesso devem ter tratamento especial.....", isto quer dizer, é uma restrição clara para a entrada de atributos.

  • Requisito Funcional
    Declaração de uma função ou de uma característica que deve ser implementada no sistema.


    Requisito Não Funcional
    Declaração de uma restrição ou de um comportamento esperado que se aplica ao sistema. Essa restrição pode se refe­rir às propriedades emergentes do software que está sendo desenvolvido ou ao processo de desenvolvimento.


    Fonte: 9°edição - Ian Sommerville Glossário

ID
105601
Banca
FCC
Órgão
DPE-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na Engenharia de Requisitos, dentre passos a serem seguidos para elicitação de requisitos é INCORRETO:

Alternativas
Comentários
  • a) Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista.Ponto de Vista é um dos métodos para elicitação de requisitos. VORD (View Oriented Requirement Definition). * b) Identificar regras de domínio que limitam a funcionalidade ou desempenho do sistema ou produto que será construído.Segundo Sommerville, os requisitos são divididos em: funcionais, nao-funcionais e de DOMÍNIO. A afirmativa descreve corretamente os requisitos de domínio.c) Definir um ou mais métodos de elicitação de requisitos.Alguns métodos, como o VORD da letra a, não são auto-suficientes. Eles servem de apoio apenas. Outros métodos de elicitação precisam ser usados em determinadas situações.d) Selecionar as pessoas sem preconceitos organizacionais para auxiliar a especificar os requisitos.ERRADODesconheço essa regra. Na verdade, acredito eu, é bom ter certo critério. Não adianta, por exemplo, escolher os gerentes para definir requisitos. O software final poderá ser extramamente complexo de operar pois opniões de funcionários de escalha hierárquica inferior (que irão operar o software) foi descartada. É preciso ter uma mistura de opniões (pontos de vistas). e) Identificar claramente a justificativa de existência para cada requisito registrado; Identificar requisitos ambíguos que serão candidatos a prototipação.É preciso ter rastreabilidade dos requisitos (quem solicitou?). Onde houver dificuldades poderemos usar protótipos para facilitar o entendimento.
  • Dado que é FCC, isso deve estar escrito em algum lugar claramente. 

    Mas não é muito dificil ver o erro da questão: existe uma clara distinção entre quem faz o que na organização, e na hora de fazer a gerência dos requisitos, os papéis desempenhados por cada um são bem definidos.

    Como preconceito organizacional pode ser traduzido como "distinção do que a pessoa faz na organização", é claro que esse tipo de preconceito é necessário na hora de tratar os requisitos.

  • Bom a FCC também gosta de cobrar português. Além da necessidade de critérios que ajudem a selecionar boas fontes de informação, deve-se lembrar que ELICITAR é diferente de ESPECIFICAR.

  • Essa foi uma baita pegadinha.. o ESPECIFICAR na letra D passa desapercebido fácil.

  • Apesar do cuidado e dedicação de Saia e jorge cho nos comentários, acredito que o problema da questão seja mesmo o verbo 'ESPECIFICAR'. Não fosse isso a afirmação seria correta.

  • LIXOOOO

  • FCC forçando como sempre

  • Novamente uma questão polemica e meia que subjetiva, quando fala em pegar as pessoas sem preconceitos organizacionais é meio perigoso, entretanto, este modelo funciona bem somente na teoria dos livros.

    Resposta: D

ID
106057
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No âmbito da Engenharia de Requisitos, uma revisão técnica formal é

Alternativas
Comentários
  • Segundo Pressman, 6a.Ed., pág.120:
    O principal mecanismo de validação de requisitos e a revisão técnica formal.
  • Dentre as técnicas de validação de requisitos estão: a revisão ou inspeção, a prototipagem (que também pode ser usada na elicitação) e a geração de casos de teste.

  • RPGA


    R - revisão técnica formal
    P - prototipação
    G - geração dos casos de testes
    A - análise consistência

  • validação.

    As fases da engenharia de rquisitos- estudo de viabilidade, elicitação e analise, especifucação, e validação. validação consiste em técnicas tais como: revisaõ tecnica (informal, o qual é uma conversao com stakeholders, & formal, o que é explicação dos requrimentos), prototipação (usuario testa o prototipo do sistema), geração de casos de testes (testar os req).

  • Revisão Técnica Formal (FTR)

    Uma Revisão Técnica Formal (FTR) é uma atividade de Garantia da Qualidade de Software realizada por engenheiros de software (e outros). A FTR é o filtro mais efetivo do ponto de vista de Garantia da Qualidade.

    Os objetivos da FTR são:
    - descobrir erros na função, na lógica ou na implementação, para qualquer representação do software;
    - verificar se o software sob revisão satisfaz seus requisitos;
    - garantir que o software tenha sido representado de acordo com padrões predefinidos;
    - conseguir software que seja desenvolvido de modo uniforme;
    - tornar os projetos mais administráveis.

     

    http://jkolb.com.br/revisao-tecnica-formal-ftr/

  • O mecanismo de validação, nada mais é que, uma revisão técnica do que foi levantado, por isso assertiva a ser escolhida é a letra E.

    Resposta: E

ID
106060
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A confiabilidade especificada para um software aplicativo é

Alternativas
Comentários
  • Os requisitos não funcionais são aqueles que expressam como deve ser feito (não confundir requisitos não funcionais com design). Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc.

    O requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema.

  • Segundo a INBR ISO/IEC 9126-1:2003, página 6 e 8 respectivamente:

    "a confiabilidade de um produto de software é avaliada pela extração das falhas observadas, somente daqueles defeitos que ocorreram por causa do software (originárias dos requisitos, projeto ou implementação).";

    "6.2 Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições
    especificadas".

    Diante das premissas acima, podemos concluir que trata-se de um requisito não funcional, pois não é um mecanismo, restrição ou requisito funcional (não se implementa a confiabilidade em linha de código).


  • Confiabilidade segundo Garden:

    - O software fornece todos os recursos e capacidade sem falhas?

    - Esta dispível quando necessário?

    - Fornece funcionalidades sem a ocorrência de erros?

    Confiabilidade segundo McCall:

    Confiabilidade é uma sub-característica do fator de qualidadeOperação do Produto, existem mais dois fatores que são:Revisão doproduto e transição do produto, porém voltando ao assuntoconfiabilidade é definino como: O quanto se pode esperar queum programa realize a função pretendida com a precisão exata.

    Confiabilidade segundo ISO 9126:

    Confiabilidade é a quantidade detempo que o software fica disponível para uso conforme indicadopelos seguintes subatributo:maturidade, tolerância a falhas efacilidade de recuperação.


    Capítulo 14, 7a. EdiçãoPressman

    Fazendo um leitura em relação asdefinições acima e observando algumas palavras, como por exempo:

    - “disponível quandonecessário”;

    - “O quanto se pode esperar” ;

    - “a quantidade de tempo que osoftware fica disponível”.

    Trata-sede requisito não-funcional.


  • e-

    Requisitos nao-funcionais sao caracteristicas do sistema, geralmente o comportamento e.g.: portabilidade, desempenho, compatibilidade etc

ID
106081
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No âmbito da Engenharia de Software, um cenário de constantes mudanças políticas como as que ocorrem em uma aplicação governamental, por exemplo, propõe a especificação de um elemento de software que é o

Alternativas
Comentários

  •  

    Requisitos permanentes (estáveis) - Derivados da atividade principal da organização. Exemplo: em um hospital sempre haverá requisitos relativos as médicos, aos pacientes, aos tratamentos, etc. Derivados do modelo de domínio
    Requisitos Voláteis - Requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Exemplo: Requisitos resultantes de políticas governamentais.
     
    Fonte: Livro Engenharia de Software, de Sommerville.

  • Para entender melhor a questão, você precisa conhecer o conceito do item escolhido como a opção certa. Requisitos Voláteis - Requisitos que se modificam durante o desenvolvimento ou quando o sistema está em uso. Exemplo: Requisitos resultantes de políticas governamentais.

    Resposta: B

ID
106084
Banca
FCC
Órgão
PGE-RJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No processo de elicitação e análise de requisitos, a técnica pela qual o analista, como recurso, insere-se no ambiente de trabalho onde o sistema será usado, observando e registrando a rotina diária dos envolvidos para descobrir requisitos implícitos do sistema que reflitam os processos reais e não os formais, denomina-se

Alternativas
Comentários
  • Os estudos etnográficos são uma técnica, proveniente das disciplinas de Antropologia Social, que consiste no estudo de um objecto por vivência directa da realidade onde este se insere. Permitindo analisar a componente social das tarefas desempenhadas numa dada organização tornam-se, no âmbito da Engenharia de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na recolha dos requisitos derivados de formas rotineiras e tácitas de trabalharFonte: http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico

  • Walkthrough Cognitivo

    O cognitive walkthrough é uma técnica de avaliação do desenho de interfaces, com especial atenção para o suporte que a interface pode dar a uma aprendizagem exploratória, ou seja, a utilização pela primeira vez, sem nenhum treino prévio [Rienman95]. O método pretende responder a uma questão: até que ponto consegue o sistema em análise guiar um utilizador não treinado na sua utilização, de modo a permitir-lhe atingir os seus objectivos?

    Fonte e texto integral: Aplicação de um Cognitive Walkthrough [PDF]

    Joint Application Development — JAD ou Joint Application Design é uma metodologia criada pela IBM do Canadá em 1977 e adaptada para o Brasil em 1982 por Hugo Gattoni para moderação de discussões de brainstorming acelerando e consolidando o desenvolvimento de aplicações de Sistemas de Informação.
    Guiados por um líder de reunião, usuários e analistas projetam o sistema juntos, em sessões de grupo estruturadas. JAD utiliza a criatividade e o trabalho em equipe de dinâmica de grupo para definir o ponto de vista dos usuários sobre o sistema, desde os objetivos e aplicações do sistema até a geração de telas e projetos de relatórios. A aplicação JAD permite a criação, em menos tempo, de sistemas mais eficazes.

    fonte: wikipédia

     

  • A Etnografia é um método utilizado pela antropologia na coleta de dados. Ela se baseia no contato entre o antropólogo e seu objeto de estudo, geralmente um grupo social constituído formalmente. Na engenharia de software a etnografia é caracterizada como uma técnica de observação utilizada para mapear requisitos implícitos que refletem processos reais dentro de um ambiente sistêmico. Compreender requisitos sociais e organizacionais, promover um entendimento dos aspectos culturais que regem o ambiente sistêmico direcionam os procedimentos etnográficos. Para aplicar a referida técnica no processo de levantamento de requisitos é necessário estruturar um protocolo (conjunto de regras) etnográfico.

    DOS PROTOCOLOS:

    1) Identifique as áreas do negócio a serem observadas;

    2) Identifique os usuários chaves de cada área;

    3) Obtenha aprovação da gerência da empresa para aplicar a técnica e deixe clara a finalidade do estudo que será desenvolvido;

    4) Insira o analista no ambiente de trabalho, importante: não identifique o analista, ele deve desempenhar algum papel (ou cargo) dentro do ambiente;

    5) O analista deve colher informações sobre o cargo que desempenha e do restante do ambiente. Manuais, procedimentos, formulários, relatórios, estatísticas sobre a execução das tarefas e exceções devem ser colecionados;

    6) O analista deve documentar as informações, utilize uma linguagem clara, concisa e consistente na documentação;

    7) Consolide o estudo efetuado pelos analistas;

    8) Valide as informações consolidadas.

    Resposta: A

  • Letra A - Etnografia

ID
118864
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação aos princípios fundamentais da análise de requisitos, considere:

Ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa mais fácil e sistemática e tornando-se a base para o projeto, fornecendo ao projetista uma representação essencial do software, que pode ser mapeada num contexto de implementação.

A afirmação acima refere-se ao princípio

Alternativas
Comentários
  • Dentro das etapas da Engenharia de Requisitos definidas por Pressman, na Elaboração, após a coleta e refinamento de informações nas etapas anteriores, há o desenvolvimento de MODELOS do sistema, que serão negociados posteriormente com o cliente, especificados formalmente e servirão de base para o desenvolvimento do sistema no decorrer do projeto.

    "O resultado final da Elaboração é um modelo de análise que define o domínio do problema informacional, funcional e comportamental"

    Pág. 119
    Engenharia de Software, 6a. Edição - Roger S. Pressman
  • Para ajudar no entendimento de modelagem:
    No RUP, a disciplina de Análise e Projeto (modelagem) consiste em:
    a) Análise: Identificar todo o problema a ser resolvido; e
    b) Modelagem: dar solução ao problema.
    Como a questão informou:
    ..."fornecendo ao projetista uma representação essencial do software, que pode ser mapeada num contexto de implementação."
    Ele quis dizer que, será apresentada uma solução para o software, um solução para o problema e, esta solução da modelagem será para a implementação.

    Tanto é que, no RUP, a disciplina de análise e projeto antecede a disciplina de implementação. Logo, para que ocorra uma boa implementação, é necessário que a solução para o problema esteja bem adiantada.
    OBS: Lembrando que, segundo o "modelo das baleias" do RUP, as disciplinas podem sim ocorrer simultaneamente, porém com um esforço menor.

  • O modelo ajuda o analista a entender a informação, a função e o comportamento de um sistema, tornando a tarefa de análise de requisitos mais fácil e mais sistemática.

    http://slideplayer.com.br/slide/8296531/

  • e-

    A modelagem é a conversao dos requisitos funcionais e nao-funcionais, servindo para capturar a essencia do dominio do problema

ID
120691
Banca
FCC
Órgão
SERGAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto dos requisitos necessários, em relação à implantação de sistemas, é INCORRETO que haja

Alternativas
Comentários

  •  É correto 'testes unitários' na implantação?

  • Prezado... nao entendi sua pergunta...
    Onde esta essa afirmacao???
    Apenas complementando, a participacao do usuario sempre e' relevante pois ele e' a unica razao do sistema existir
  • No contexto dos requisitos necessários, em relação à implantação de sistemas, é INCORRETO que haja
     
     a) reuniões entre os profissionais de análise, programação e implementação para homologar o sistema, não sendo relevante a participação de usuários. (Em relação a requisitos não se envolve com parte código (programação e implementação)
     
     b) envolvimento dos usuários-chave das áreas de manutenção, calibração e validação.
     c) realização de testes unitários e de integração das funcionalidades.
     d) envolvimento dos usuários das áreas de interface, quais sejam, a área de programação de produção e de garantia da qualidade.
     e) treinamentos operacionais de todos os usuários do sistema e das equipes do setor de suporte operacional.
  • a participação do usuário é importante em todas as fases.


  • típica questão da FCC em que deve-se escolher a mais incorreta..
    de longe, alternativa "C" está incorreta, entretanto a "A" está muito mais

    foco e força...

  • a-

    embora nao seja sempre seguido, a participação de usuários é sempre relevante

ID
126238
Banca
FCC
Órgão
DPE-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre análise de requisitos da engenharia de software, considere:

I. Os requisitos de usuário podem descrever tanto requisitos funcionais quanto requisitos não- funcionais.

II. Os requisitos de sistema podem descrever apenas requisitos não funcionais.

III. Os requisitos não-funcionais podem ser divididos em requisitos de produto, organizacionais e externos.

Está correto o que se afirma em

Alternativas
Comentários

  • Vou tentar explicar resumidamente:

    a) Requisitos do usuário descrevem os requisitos funcionais, não funcionais e de domínio numa linguagem que o usuário final possa entender.

    b) Requisitos do sistema descrevem os requisitos de usuário de forma mais detalhanda, usando-se termos técnicos e diagramas.

    c) Requisitos não funcionais são classificados em 3 tipos:

    Produto -> especificam o comportamento do produto. Ex: o tempo de resposta da consulta deve ser de 5 segundos

    Organizacional --> segue procedimentos organizacionais. Ex: todo relatório gerado deve ter o formato XYZ

    Externo --> consequência de fatores externos. Ex: ser implementado conforme uma legislação


    Portanto concluimos que I e III estão corretas

  • Complementando o que o colega indicou, o erro está em dizer que: Os requisitos de sistema podem descrever apenas requisitos não funcionais; quando na verdade, requisitos do sistema são funcionais!!!

  • Meus queridos, o erro da questão está em: II – os requisitos de sistemas podem descrever apenas requisitos não funcionais e sabemos que isto é uma inverdade, pois os requisitos podem descrever itens funcionais que podem ser descrição e funções dos sistemas, como requisitos não funcionais no que envolva a segurança destes.

    Resposta: C

ID
130105
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência às áreas da engenharia de software, julgue os
itens que seguem.

O gerenciamento de requisitos inclui, entre outras, as seguintes atividades: levantar, analisar, especificar, validar e prototipar requisitos funcionais e não-funcionais.

Alternativas
Comentários

  • Não concordo com o gabarito.

    Como se pode prototipar REQUISITOS NÃO-FUNCIONAIS ??

  • Respondendo ao colega abaixo... O protótipo de uma interface gráfica, para verificar a facilidade de uso, é um tipo de Protótipo de Requisito Não Funcional.

  • O conceito apresentado na questão é de engenharia de requisitos e não gerenciamento de requisitos.

    O gerenciamento de requisitos, segundo Sommerville, é um processo para compreender e controlar as mudanças dos requisitos de sistema.

    Já engenharia de requisitos tem como objetivo criar e manter um documento de requisitos de sistema. Para Sommerville, esse processo é dividido em quatro subprocessos:
    • Estudo de viabilidade;
    • Elicitação e análise;
    • Especificação;
    • Validação.
    Prototipação nem sequer é um processo ou atividade da engenharia de requisitos, mas sim apenas uma técnica para elicitação e análise de requisitos. Portanto, item errado.
  • na minha opinião ele não citou nenhuma atividade de gestão de requisitos, apenas de engenharia de requisitos.

    A gestão de requisitos engloba identificação de requisitos, rastreabilidade, realizar estudo de impacto das mudanças e manter a documentação atualizada frente às alterações nos requisitos...a questão não citou nada disso, pra mim a banca boiou na maionese!!!kkk

  • Exatamente Elizabette. Esta questão está totalmente errada.

  • Essas atividades referem-se a ENGENHARIA DE REQUISITOS e não Gestão de Requisitos:

    Retirado do material do estratégia concursos:

    "Galera, a questão trata claramente de Engenharia de Requisitos e, não,
    Gerenciamento de Requisitos. Eu não sei se não entraram com recurso contra essa
    questão ou se entraram e o CESPE o ignorou. O fato é que essa questão é
    absurdamente errada, mas o gabarito foi mantido como correto."

    Prof Diego Carvalho

  • No fundo esse é o grande mal de questões de TI, principalmente de engenharia de software. Agente nunca sabe qual a referência a banca usa para elaborar essas questões. Com certeza isso está errado de acordo com Sommerville, mas não duvido que exista algum processo, framework, doutrina onde tudo isso faça parte da gerência de requisitos.

     

    Enfim acredito que as bancas deveriam se ater a fazer questões mais objetivas e menos doutrinárias. Quando fossem exigir conceitos doutrinários deveriam ao menos deixar isso claro na questão e no edital.

     

     

ID
130108
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência às áreas da engenharia de software, julgue os
itens que seguem.

O levantamento de requisitos é importante, porém não é fundamental, pois recomenda-se avançar o quanto antes para as demais atividades que permitam uma visualização do software e reduzam a ansiedade do cliente em ver algo pronto.

Alternativas
Comentários

  • Erro: é fundamental sim, porém principalmente no desenvolvimento ágil pode-se passar para uma fase seguinte sem terminar esta etapa. Mas todos projetos iniciam com os requisitos, mesmo que sendo desenvolvido em um modelo espiral!

    Abraços

  • "O levantamento de requisitos combina elementos de resolução de problemas, elaboração, negociação e especificação. Para encorajar uma abordagem colaborativa e orientada às equipes em relação ao levantamento de requisitos, os interessados trabalham juntos para identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução"
    Pressman, 7ed, pag 133

    Logo, o levantamento é fundamento para o sucesso do projeto. Porém, nada impede que outras atividades sejam feitas em paralelo.

  • KKKKKKKKKKK

ID
133996
Banca
CESPE / CEBRASPE
Órgão
CEHAP-PB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência a requisitos de software, assinale a opção correta.

Alternativas
Comentários

  • * a) Os requisitos não-funcionais FUNCIONAIS de um sistema descrevem o que o sistema deve fazer e estão relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento.  ( REQUISITOS NÃO-FUNCIONAIS)

    * b) Os requisitos relacionais descrevem a função do sistema, como, por exemplo, suas entradas, saídas e exceções. ( NUNCA OUVI FALAR EM TAL PESSOA)

    * c) Os requisitos funcionais surgem devido às necessidades do usuário, às restrições de orçamento, às políticas organizacionais, à necessidade de interoperabilidade com outros sistemas de hardware e software ou a fatores externos. (SÃO REQUISITOS NÃO-FUNCIONAIS EXTERNOS, ORGANIZACIONAIS)

    * d) Os requisitos de um sistema são descrições dos serviços fornecidos pelo mesmo e suas restrições operacionais, sendo que os requisitos não-funcionais podem ser requisitos de produto, organizacionais ou externos.  ISSO ISSO ISSO
     

  • a) Os requisitos não-funcionais de um sistema descrevem o que o sistema deve fazer e estão relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento.

     

    Se é algo que o sistema tem que fazer e esse algo é relativo a tempo de resposta e espaço de armazenamento, para mim, isso é uma NFR

  • Com referência a requisitos de software, assinale a opção correta.

     a) Os requisitos não-funcionais (Requisitos Funcionais) de um sistema descrevem o que o sistema deve fazer e estão relacionados às propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de armazenamento.

     b) Os requisitos relacionais (Desconheço) descrevem a função do sistema, como, por exemplo, suas entradas, saídas e exceções.

     c) Os requisitos funcionais surgem devido às necessidades do usuário, às restrições de orçamento, às políticas organizacionais (Requisito Não- Funcional de Organizacional), à necessidade de interoperabilidade com outros sistemas de hardware e software ou a fatores externos (Requisito Não- Funcional de Externo).

     d) Os requisitos de um sistema são descrições dos serviços fornecidos pelo mesmo e suas restrições operacionais, sendo que os requisitos não-funcionais podem ser requisitos de produto, organizacionais ou externos. (Correta)
ID
135412
Banca
CESPE / CEBRASPE
Órgão
EMBASA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Métricas são utilizadas para medir produtividade, estimar qualidade
dos software e identificar e quantificar as funcionalidades
requeridas para um projeto. Com relação a esse assunto, julgue os
itens que se seguem.

Itens de contagem para pontos de função incluem entradas, saídas, requisitos, arquivos internos, interfaces externas. Nesse contexto, requisitos são pares de solicitação-resposta que não mudam os dados internos, e saídas são os dados da aplicação exibidos, em que campos individuais são considerados saídas separadas.

Alternativas
Comentários

  • O erro na questão é que campos individuais não são considerados saídas separadas

  • outro erro da afirmação é  o fato de que os requisitos podem mudar,sim, dados internos.

  •  Concordo com Hitalo, mas discordo do Marciostf, pois requisitos (Consultas Externas) não podem mudar os dados internos, ao contrário das Saídas Externas, que podem.

  • Eu marquei errado porque juguei que a questão colocou o termo "requisitos" no lugar de "consultas"

    No  Handbook de TI: "Uma consulta é definida como uma entrada que resulta na geração de alguma resposta imediata."

    Isso em um tópico que fala justamente sobre isso:

    10.3.2 Métricas Orientadas a Função

    1 - Quantidade de Entradas do Usuário
    2 - Quantidade de Saídas do Usuário
    3 - Quantidade de Consultas do Usuário
    4 - Quantidade de Arquivos
    5 - Quantidade de Interfaces Externas

  • Não são requisitos são consultas.

  • sao consultas, nao requisitos.

ID
136276
Banca
ESAF
Órgão
MPOG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

As áreas de esforços da Análise de Requisitos são:

Alternativas
Comentários

  • A análise de requisitos de software pode ser dividida em cinco áreas de esforço:
    1. Reconhecimento do problema;
    2. Avaliação e síntese;
    3. Modelagem;
    4. Especificação;
    5. Revisão.
    Fonte:     http://www2.dem.inpe.br/ijar/AnalEstr.html

  • Alguém sabe a fonte original disso? Pressman, Sommerville, etc.
  • Foi Pressman, aqui estão os links:

    http://books.google.com.br/books?id=rtBvl_L-1mcC&pg=PT146&lpg=PT146&dq=%C3%A1reas+de+esfor%C3%A7o+an%C3%A1lise+de+requisito+pressman&source=bl&ots=9ygk2O2vZp&sig=KU7WTAkcdFTHZuXJeCBEF_2xyUQ&hl=pt&sa=X&ei=VHA3UdTwOobmyQHVqoG4Bg&ved=0CC0Q6AEwAQ

    http://pt.scribd.com/doc/15922676/PRINCIPIOS-FUNDAMENTAIS-DA-ANALISE-DE-REQUISITOS
ID
137095
Banca
FGV
Órgão
Senado Federal
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considere a lista de requisitos, a seguir, de um sistema que será desenvolvido.

1. O sistema deverá emitir relatórios de compras a cada 15 dias.
2. O sistema só irá permitir a visualização do campo "valor máximo" para gerentes.
3. O sistema deverá fornecer diariamente o relatório de despesas.
4. O sistema não poderá excluir um fornecedor do cadastro se o fornecedor estiver inadimplente.
5. O sistema não permitirá acesso aos registros de compras após as 17 horas.

Em relação a esses requisitos, é correto afirmar que:

Alternativas
Comentários
  •  Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.
    "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
    "o software deve emitir relatórios de compras a cada quinze dias"
    "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.
    Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente quer segurança mas os usuários querem facilidade de uso) e são difíceis de validar.
    "a base de dados deve ser protegida para acesso apenas de usuários autorizados".
    "o tempo de resposta do sistema não deve ultrapassar 30 segundo".
    "o software deve ser operacionalizado no sistema Linux"
    "o tempo de desenvolvimento não deve ultrapassar seis meses".

    Fonte:http://engenhariadesoftware.blogspot.com/
  • 1. O sistema deverá emitir relatórios de compras a cada 15 dias.
    Ok : requisito funcional.

    2. O sistema só irá permitir a visualização do campo "valor máximo" para gerentes.
    Por que esté requisito é funcional? Pela especificação do campo?

    3. O sistema deverá fornecer diariamente o relatório de despesas.
    Ok : requisito funcional.

    4. O sistema não poderá excluir um fornecedor do cadastro se o fornecedor estiver inadimplente.
    Ok : requisito funcional.

    5. O sistema não permitirá acesso aos registros de compras após as 17 horas.
    Por que esté requisito é funcional?

  • O requisito é funcional quando está diretamente associado à funcionalidade do sistema, ou seja, aos resultados que o sistema tem que produzir para o usuário. Todo requisito funcional tem ligação com o negócio, ao contrário dos não-funcionais, que estão mais ligados à forma de utilização do sistema (Ex.: adoção de tecnologias, tempo de resposta, disponibilidade, segurança, quantidade de acessos simultâneos, etc).

    2. O sistema só irá permitir a visualização do campo "valor máximo" para gerentes.

    Por que esté requisito é funcional? Pela especificação do campo?

    Trata-se de regra de negócio. Requisito funcional.

    5. O sistema não permitirá acesso aos registros de compras após as 17 horas.

    Por que esté requisito é funcional?

    A menção a horário pode confundir, mas ainda assim trata-se de regra de negócio. Requisito funcional.
  • Alguns dos requisitos listados parecem com requisitos de domínio que, via de regra, estão mais próximos aos requisitos funcionais.
  • Requisitos de Domínio podem ser funcionais ou não funcionais.

    Os requisitos não funcionais estão relacionados à restrições, e restrição não é apenas desempenho, segurança, etc..

  • Não consegui compreender qual a lógica da alternativa abaixo ser funcional, afinal de contas ela estabelece bem objetivamente uma restrição :

    2. O sistema só irá permitir a visualização do campo "valor máximo" para gerentes.

  •  a)são todos requisitos funcionais.

    Os requisitos funcionais sao funcionalidades especificadas pelo usuario. sao entendidos como o que o sistema deve fazer. Ja os requisitos nao-funcionais sao o suporte os funcionais, o que significa que o usuario nao necessita saber que eles existem, mas eles sao necessarios para garantir o cumprimento dos que ele quer. requisitos nao-funcionais sao requisitos do  como o sistema como um todo deve agir. geralmente esta relacionado com restrições data input, timeout & armazenamento

ID
137137
Banca
FGV
Órgão
Senado Federal
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Entre as atividades listadas a seguir, uma não faz parte da Engenharia de Requisitos. Assinale-a.

Alternativas
Comentários

  • Primeiro. Vamos ao conceito de Engenharia de Requisitos. Engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua e sua manutenção ao longo do tempo.

    Este processo deve ser precedido de estudos de viabilidade.

    O processo de engenharia de requisitos e composto por 4 atividades de alto nível:

    •Identificação: Caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos: Na identificação dos requisitos e a fase onde e feito o levantamento dos requisitos.

    •Analise e negociação: Após a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos

    •Especificação e documentação: É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos.

    •Validação: Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.


    Analisando os itens da questão:

    A) Estudo de viabilidade: Representado pelo primeiro processo onde e realizado um estudo de viabilidade do projeto;

    B) Analise de riscos: Não há nenhum atividade que realize analise de riscos;

    C) Levantamento das necessidades do cliente: Este levantamento e realizado na atividade de Identificação;

    D) Verificação: E realizado pela atividade de validação neste processo demonstramos que o documento de requisitos corresponde de fato as espectativas do cliente;

    E) Gerenciamento: E realizado na atividade de analise e negociação.

    Desta forma temos como item errado a letra B.

    fonte:http://pt.wikipedia.org/wiki/Engenharia_de_requisitos

  • No meu ver, essa questão deve ser respondida pensando  na mais errada, no caso "análise de  risco ".

    Verificação = é se estou fazendo certo ou do melhor jeito?

    Validação = fizemos o que foi solicitado?

    Ex: O cliente  pediu para o dividir mas vc programou para multiplicar. Você fez a programação  de multiplicação de forma coreta e até  da melhor forma. Mas é na  VALIDAÇÃO que vaí ser visto que está  errado.

  •  b)análise de risco.

    Engenharia de requisitos usa 4 atividades basicas - estudo de vabilidade, elicitação & analise, especificação & validação. Nao ha uma atividade especifica para análise de risco.

ID
140842
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a requisitos de software, julgue os itens a seguir.

As principais entidades intervenientes do gerenciamento de requisitos são os usuários, os clientes, os analistas de mercado, as agências reguladoras e os engenheiros de software.

Alternativas
Comentários
  • ô loko, nunca tinha nem ouvido falar em analistas de mercado e agências reguladoras botando o bedelho no gerenciamento de requisitos...
  • Questao polemica..

    do timaster..
    -------
    8 edição do Sommerville:

    página 99:

    "*Os stakeholders variam de usuários finais do sistema a gerentes e
    envolvidos externos, como regulamentadores que certificam a aceitação do
    sistema.*"
    --------

    Há outra referência: o guia SWEBOK. Foi retirada de lá a questão, mas de forma
    errônea. O guia cita as entidades da questão como "exemplos típicos" e não como
    "principais entidades".
  • É necessário lembrar que os requisitos se dividem em categorias diferentes (funcionais, não funcionais e de domínio, por exemplo), e a ação de algum dos agentes citados na questão pode acarretar modificações em algum requisito, que devem ser devidamente gerenciadas.

  • Bom dia, colegas.

    Trata-se de uma prova da ANTAQ. Creio que antes deveria ter alguma instrução relevante para tal.


    Bons estudos!

  • Cespe  miserável,  nada a ver
ID
140845
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a requisitos de software, julgue os itens a seguir.

Uma técnica para levantamento de requisitos eficiente e recomendada pelo SWEBOK é o envio de questionário por e-mail, visto ser uma forma de se elucidar com precisão as necessidades do usuário.

Alternativas
Comentários
  • Uma técnica para levantamento de requisitos eficiente e recomendada pelo SWEBOK é o envio de questionário por e-mail, visto ser uma forma de se elucidar com precisão as necessidades do usuário.

    O erro é apenas afirmar que elucida com precisão?
  • Elucidar apenas por mail para alguma implementação real pode até dar certo; teoricamente, é incorreto.
    O que as boas práticas apregoam é complementariedade, juntando formulários com entrevista, etnografia, etc.
  • Para uma elucidação mais precisa não é indicado apenas o uso de questionários enviados por email - inclusive muitos usuários nem irão responde-lo.
    Para uma elicitação de requisitos mais precisa é importante até mesmo combinar várias técnicas como: questionários, entrevistas, análise de documentação, análise de sistema legado, etnografia, JAD, brainstorming, cenários, dentre outras.

  • Vasculhei o SWEBOK em português e em inglês e não tem nada sobre entrevista ou questionário por e-mail. Nem mesmo a palavra e-mail aparece em nenhum dos dois. Como e de onde vem a informação de questionário por e-mail?

     

  • e-

     

    Para "se elucidar com precisão as necessidades do usuário", é necessário uma combinação das técnicas; todas as tecnicas de levantamento de requisitos possui pros & cons devido à comcplexidade e natureza do software.

  • Elucidar por e-mail não é nada aconselhável, pelo fato de não ter o usuário presente.

ID
140848
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a requisitos de software, julgue os itens a seguir.

O gerenciamento de requisitos é uma atividade básica que deve anteceder as demais atividades da engenharia de software, pois é pré-requisito para todas elas.

Alternativas
Comentários

  •  De acordo, com o Pressman, no livro engenharia de software, sexta edição, a engenharia de requisitos é composto por quatro atividades, nesta ordem:

     - Concepção - estabelecer um entendimento básico do problema, o pessoal que quer uma solução, a natureza da solução desejada e a efetividade da comunicação e colaboração preliminares entre cliente e desenvolvedor
     - Levantamento - É realizado um detalhamento do que foi feito na concepção. 
     - Elaboração - As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante esta atividade. Enfoca o desenvolvimento de um modelo técnico refinado das funções, características e restrições do software.
     - Negociação - Diferentes clientes/usuários proponham requisitos conflitantes. Nesta atividade, o engenheiro de requisitos precisa reconciliar esses conflitos, ou seja, clientes, usuário e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade.
     - Especificação - é o produto de trabalho final produzido pelo engenheiro de requisitos. Ela serve como fundamento das atividades de engenharia de software subsequentes. Ela descreve a função e o desempenho de um sistema baseado em computador e as restrições que governarão o seu desenvolvimento.
     - Validação - Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante o passo desta atividade. 
     - Gestão de Requisitos - É um conjunto de atividade que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue. são idênticas às teénicas de gestão de configuração software.
     
    Portanto, a gestão de requisitos não é NECESSARIAMENTE é pré-requisito para todas elas, pois existem atividades que podem ser independentes ao gerenciamento de requisito.
     

  • Acrescentando:

    A gerência de requesitos é uma atividade que identificar, CONTROLAR e RASTREAR requisitos e MUDANÇAS de requisitos, ou seja ela continua sendo executada mesmo após a etapa da elicitação de requisitos. Por esse motivo ela não é pré-requisito das outras atividades de ES (Análise, Codificação, Testes, etc).

    Os requisitos podem sofrer modificações e continuam sendo rastreados a QUALQUER TEMPO! Isso mata a questão!

    Abraços

  • Acrescentando mais,

    O gerenciamento dos requisitos é realizado juntamente com as outras fases da engenharia de requisitos : elicitação; análise; especificação e validação. Portanto ele não antecede a ninguém.

  • O comando da questão diz :

    "O gerenciamento de requisitos é uma atividade básica que deve anteceder as demais atividades da engenharia de software, pois é pré-requisito para todas elas."

    A minha dúvida é em relação a redação empregada no enunciado!

    Entendo que temos atividades dentro da Engenharia de Requisitos, dentre elas a Gestão de Requisitos.
    Interpretei "gerenciamento de requisitos" como referente a todas as atividades envolvendo requisitos.
    Note que o enunciador NÃO diz que esta atividade deve anteceder as demais atividades da engenharia de requisitos, e SIM, da engenharia de software, que corresponde a todo o processo de confecção do software.

    Ainda estou um tanto confuso!
  • Acho que o examinador quis confundir o candidato misturando conceitos de gerencimanento de requisitos e disciplinas RUP. Analisando sob a visão do RUP, antes dos requisitos vem a Modelagem de negócio.
  • Pessoal,

    Não faz sentido, para se gerenciar requisitos temos que ter  primeiramente os requisitos.
    O gerenciamento de requisitos se inicia após um levantamento inicial de requisitos.

    Bons estudos!
  • "A gestão de requisitos começa com a identificação. A cada requisito é atribuído um modo identificador."
    Pressman, 6a ed, pág. 121

    Logo é necessário ter feito o levantamento e análise, para então iniciar o processo de gerenciamento de requisito.
    A gestão de requisitos é fundamentalmente o trabalho de manter as tabelas de rastreabilidade dos requisitos.

    Bons estudos.

  • @Luciano: infelizmente interpretei como você, supondo que o enunciado se referia a todo o conjunto de atividades que envolviam requisitos, incluindo o levantamento.

  • Em alguns casos (sistemas simplórios, por exemplo), a gestão de requisitos nem é recomendada...mas caso ela ocorra, sim, ela pode anteceder várias outras fases da eng. de requisitos.

  • Anteceder TODAS as atividades da ENGENHARIA de software é uma grande responsabilidade! E a análise de viabilidade do sistema, onde ficaria? 

ID
140851
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a requisitos de software, julgue os itens a seguir.

A especificação de requisitos é uma atividade fundamental do processo de software, mas carece de normas e técnicas que auxiliem as equipes nessa tarefa.

Alternativas
Comentários

  •  De acordo com Pressman, no livro engenharia de software, sexta edição: "Uma especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários de uso, um protótipo ou qualquer combinação desses elementos."

    Mesmo tendo várias formas de especificar requisitos, como os citados acima, existem normas para realizá-los.

  •  

    "The System Specification is the final work product produced by the system and
    requirements engineer. It serves as the foundation for hardware engineering, software
    engineering, database engineering, and human engineering. It describes the
    function and performance of a computer-based system and the constraints that will
    govern its development. The specification bounds each allocated system element.
    The System Specification also describes the information (data and control) that is input
    to and output from the system." - Pressman Software Engeneering
     
    Especificação de requisitos não é uma atividade do processo de software. É, na verdade, um artefato produzido pela engenharia de requisitos.
  • Existe a ISO 830/1998, muito conhecida e usada para requisitos.
ID
140854
Banca
CESPE / CEBRASPE
Órgão
ANTAQ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a requisitos de software, julgue os itens a seguir.

A validação de requisitos deve ser feita tanto por meio da análise subjetiva quanto por meio de atividades técnicas de revisão, prototipação, validação de modelo e testes de aceitação.

Alternativas
Comentários
  • Formas de validação:

    Revisões dos requisitos
     
    Prototipificação

    Geração de casos de teste

    Análise de consistência automática
  • Segundo o livro do Pressman 6 edição pg. 140, existe uma série de requisitos e características a serem validadas. Porém, todas estas são OBJETIVAS,  não existe esta análise subjetiva. Questão errada. 

  • Ao meu ver o Gab e "E" porque o teste de aceitação é do sistema e não dos requisitos.

  • A meu ver a questão está errada, tendo em vista que, de acordo com o PRESSMAN, existem 3 técnicas de validação:

    Revisão de Requisitos

    Prototipação

    Geração de casos de testes

ID
141220
Banca
ESAF
Órgão
ANA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmações sobre requisitos de sistemas de software:

I. Requisitos funcionais declaram as funções que o sistema deve fornecer, seu comportamento, e ainda, o que o sistema não deve fazer.
II. Requisitos de domínio são, exclusivamente, funcionais, pois exibem as características do domínio de aplicação do sistema.
III. Requisitos não-funcionais compreendem restrições sobre serviços ou funções do sistema.

Assinale a opção correta.

Alternativas
Comentários

  •  Na Engenharia de requisitos, é necessário entender o conceito de requisito funcional e não-funcional.

     
    - Os requisitos funcionais (o que ele faz) são requisitos que expressam FUNÇÕES ou SERVIÇOS que um software deve ou pode ser capaz de executar ou fornecer. As funções ou serviços são, em geral, processos que utilizam entradas para produzir saídas.
     
    - Os requisitos não-funcionais (como o sistema é) são requisitos que declaram RESTRIÇÕES, ou atributos de QUALIDADE para um software e/ou para o processo de desenvolvimento deste sistema. Segurança, precisão, usabilidade, performance e manutenabilidade são exemplos de requisitos não-funcionais.
     
    - Os requisitos de domínio são derivados a partir do domínio da aplicação. Descrevem as características do sistema refletindo o domínio. Podem ser novos requisitos FUNCIONAIS, RESTRIÇÕES ou definir computações específicas.
     
    I - Verdadeira, de acordo com o conceito de requisitos funcionais.
    II - Falsa, requisitos de dominio pode ser funcionais e não funcionais.
    III - Verdadeira, de acordo com o conceito acima de requisitos não-funcionais.

  • Nao entendi.  Requisitos Funcionais NAO  compreendem o NAO deve fazer. Como o item I está correto?

  • Olá Anne,

    A questão da Esaf se baseou na classificação de requisitos  do Sommerville.Segundo o autor requisitos funcionais são:

    -declarações de funções que o sistema deve fornecer, como sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações

    -recursos específicos que devem ser fornecidos pelo sistema

    -podem tb explicitamente declarar o q o sistema não deve fazer

    A meu ver, o não dever fazer representa uma funcionalidade que o sistema não oferece. Já os requisitos não funcionais ,restringem as funcionalidades existentes do sistema.

    Portanto, o item A está correto.

  • O Item II esta errado por conta do "exclusivamente", pois requisitos de dominio podem ser funcionais ou nao funcionais [sommervile].

    item III correto: são restrições sobre os serviços ou as funções oferecidas pelo sistema (desempenho, tempo, padrão, seg, usabilidade, confiabilidade, portabilidade, etc); Reqs não funcs normalmente são  + críticos q os funcionais. 

    Item I Correto: requisitos delimitam as fronteiras do sist, logo o q deve se feito pelo sist, e o q espera q nao seja feito pelo sist;
ID
142048
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a opção correta quanto a requisitos de software.

Alternativas
Comentários

  • Os comentários aqui realizados são baseados no Livro Engenharia de Software, de Ian Sommerville, 8ª Edição (página 106).
    Consta nesta página que uma série de técnicas de validação de requisitos pode ser usada em conjunto ou individualmente:
    1. Revisões de requisitos: Os requisitos são analisados sistematicamente por uma equipe de revisores.
    2. Prototipação: Nesta abordagem de validação, um modelo executável do sistema é apresentado para usuários finais e clientes.
    3. Geração de casos de teste: Os requisitos devem ser testáveis.
    Logo, questão correta: letra E
    Espero ter colaborado.

  • a) propriedades citadas sao requisitos nao funcionais;
    b) sempre q possivel vc deve descrever os requisitos nao funcionais quantitativamente(Somerville);
    c) requistos externos (podem ser provenientes de outros sisdtemas;
    d) oferece, sim
  • a) trata-se de requisitos não funcionais
    b) Os requisitos não funcionais podem ser descritos de forma quantitativa. Por exemplo: O sistema não deve ultrapassar 5 segundos para efetuar uma determinada busca no banco de dados.
    c) Requisitos podem ser provenientes de diversas fontes, como pessoas, documentos, outros sistemas...
    d) A matriz de rastreabilidade, produzidade na etapa de gestão de requisitos (segundo Pressman, 6ed) e fornece um suporte extremo para requisitos funcionais, sendo possível obter uma visão das depêndencias dos requisitos e seus possíveis impactos, em caso de mudanças.
    e) CORRETA. Geração de casos, protóripos, revisão técnica formal, análise de consistência automática (feita por ferramenta CASE) e checklist são exemplos de técnicas para validação de requisitos.
ID
142819
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação aos requisitos de software, é incorreto afirmar que:

Alternativas
Comentários
  • Alguém poderia exemplificar :

    e) a falha em cumprir um requisito funcional pode degradar o sistema, porém a falha em cumprir um requisito não funcional pode tornar todo o sistema inútil.
  • A respeito da letra "e" segue um trecho retirado do livro do Sommerville: 
    "Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a características individuais do sistema. Isso significa que eles são, frequentemente, mais importantes do que os requisitos funcionais individuais. Enquanto que a falha em cumprir um requisito funcional individual pode degradar um sistema, a falha em cumprir um requisito não funcional do sistema pode tornar todo o sistema inútil. Por exemplo, se um sistema de aviação não atender aos seus requisitos de confiabilidade, ele não será atestado como seguro para operação; se um sistema de controle em tempo real falhar em cumprir seus requisitos de desempenho as funções de controle não operarão corretamente"

  • d-

    as recomendações éticas e legais que os futuros sistemas devem atender sao parte dos requisitos nao funcionais. fazem parte da politica de compliance

ID
143731
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à Engenharia de Requisitos de Software, é correto afirmar que:

Alternativas
Comentários
  • Questão Estúpida, se a Alternativa E) está correta, então podemos marcar qualquer alternativa.

    D) também está correta, então deveria ser anulada. 

  •  e)todas as alternativas estão corretas.

    o objetivo de engenharia de requisitos é produzir o documento de requisitos do sistema. este processo inclui 4 processos: estudo de viabilidade, elicitação/analise, especirficação (onde se obtêm, classificam, priorizam e documentam os requisitos), validação

ID
144598
Banca
CESPE / CEBRASPE
Órgão
SECONT-ES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, a respeito da engenharia de requisitos de
software.

Durante a elicitação de requisitos de um projeto pode ser empregada uma técnica denominada workshop, na qual os principais stakeholders de um projeto são reunidos por um curto período de tempo. Essa técnica prevê a existência de um facilitador, que deve ser um dos stakeholders e não deve interferir nas decisões do grupo ou emitir opiniões.

Alternativas
Comentários

  • O nome da técnica é brainstorm.

  • Para mim, o que realmente soou estranho na questão foi o fato do examinador afirmar que o facilitador DEVE ser um stakeholder. A princípio, isso não faz sentido, já que o mais sensato é que alguém da equipe de requisitos faça esse papel. O que acham?

  •  Pelo que li sobre esta técnica, o facilitador tem que ser neutro, só para mediar a reunião. E além dos stakeholders do projeto, também estão presentes representantes da equipe de desenvolvimento.

  • O Workshop de Requisitos consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então obter um conjunto de requisitos bem definidos.

    Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro (aqui está o erro da questão !!!) cujo papel é conduzir a workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador.

    Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade de idéias) como forma de gerar um elevado número de ideias numa pequena quantidade de tempo.

    Fonte: wikipedia

  • Na minha opinião, o erro está em dizer que quem participa do workshop são os stakeholders e o facilitador. 

    "Segundo Paula Filho (2004, p. 114), Workshop de requisitos são reuniões estruturadas para a definição conjunta dos requisitos, envolve desenvolvedores, usuários e outros especialistas." http://www.upf.br/computacao/images/stories/TCs/arquivos_20072/juciane_broca.pdf

  • O erro da questão está em afirmar que o Workshop é feito em um curto período de tempo.

    De acordo com Sommerville, o Workshop é feito em um período intenso (focado)...
  • Penso que o erro está aqui:  na qual os principais stakeholders de um projeto são reunidos
    Na verdade, alguns stakeholders E analistas é que se reúnem.

    http://www.devmedia.com.br/artigo-engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151
  • A técnica citada é a de BrainStorming. O brainstorming é uma técnica para geração de idéias. Consiste em uma ou várias reuniões que permitem que as pessoas explorem idéias e pensamentos. As idéias são encorajadas pois frequentemente estimulam os participantes e isso pode levar a soluções criativas sobre o problema. É ideal para levantamento de requisitos. Essa técnica prevê a existência de um facilitador, que deve ser um dos stakeholders e não deve interferir nas decisões do grupo ou emitir opiniões.

    O Workshop utiliza momentos de descontração como forma de dinamizar o trabalho em equipe; Interagem equipes do cliente e de desenvolvedores
  • Corrigindo a questão:
    Durante a elicitação de requisitos de um projeto pode ser empregada uma técnica denominada workshop, na qual TODOS stakeholders de um projeto são reunidos por um período intensivo (focado). Essa técnica prevê a existência de um facilitador, que deve ser um dos stakeholders e não deve interferir nas decisões do grupo ou emitir opiniões.

    Sommerville.

  • Erro está em "deve ser um dos stakeholders". 

    Será Stakeholder apenas se não encontrar alguém externo.


    Escolha do facilitador:

    É recomendável que a escolha do facilitador seja a de alguém externo à organização e ao

    conjunto de stakeholders do sistema. Também é desejável que ele tenha familiaridade com a atividade de levantamento de requisitos...

    ...Se for necessário que alguém do time seja o facilitador, ele não deve contribuir na discussão com ideias e temas no workshop, pois isso poderia desvirtuar a construção do consenso.


    fonte: https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAA&url=http%3A%2F%2Fanotacoes-ufpr.googlecode.com%2Fsvn%2Ftrunk%2Fengenharia_de_requisitos%2Fpdfs%2FUnidade2-WorkshopsdeRequisitos.pdf&ei=QghbVOnXE9WuyAT67YCoBQ&usg=AFQjCNFjao4wnF6h857JJgEZxw7vCvmx2g&sig2=RWCWJF9Zbu1AusevU_ar5Q&bvm=bv.78677474,d.aWw&cad=rja

ID
144601
Banca
CESPE / CEBRASPE
Órgão
SECONT-ES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, a respeito da engenharia de requisitos de
software.

O gerenciamento de requisitos deve compreender e controlar mudanças nos requisitos de sistema, além de avaliar os seus impactos. Para atingir esse propósito, podem ser mantidas informações de rastreabilidade a serem usadas para avaliar quais outros requisitos seriam afetados por uma mudança, bem como o impacto da mudança de requisitos no projeto e na implementação do sistema.

Alternativas
Comentários

  •  Engenharia de requisitos é o termo usado para descrever as atividades relacionadas a produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos.

  • Questão correta. No livro "Engenharia de Software" (8ª Edição) do autor SommerVille, encontramos a seguinte redação:
    [...]
    O gerenciamento de requisitos é um processo para compreender e controlar as mudanças dos requisitos de sistema. É preciso manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos depedentes, de modo que seja possível avaliar o impacto das mudanças de requisitos.
    [...]
ID
144604
Banca
CESPE / CEBRASPE
Órgão
SECONT-ES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir, a respeito da engenharia de requisitos de
software.

No processo de requisitos, é importante que haja um bom entendimento do domínio do problema e das necessidades que devem ser atendidas. Ao final do processo devem estar definidos os requisitos do sistema a ser implementado, os quais não devem incluir informações a respeito do projeto ou da arquitetura do sistema. Portanto, informações como a linguagem de programação ou o sistema gerenciador de banco de dados a serem utilizados não devem estar presentes nos requisitos de software documentados.

Alternativas
Comentários

  • "... os quais não devem incluir informações a respeito do projeto ou da arquitetura do sistema."

  • "Ao final do processo devem estar definidos os requisitos do sistema a ser implementado, os quais não devem incluir informações a respeito do projeto ou da arquitetura do sistema. Portanto, informações como a linguagem de programação ou o sistema gerenciador de banco de dados a serem utilizados não devem estar presentes nos requisitos de software documentados."

    Não é que não devem estar, na verdade eles não são necessários nesta fase (domínio do problema). Mas caso o cliente exija podem ser adicionados no documento de identificação dos requisitos.

  •  O que invalida a questão é: "Os quais não devem".

     

    Se um cliente quiser um sistema a que opere em um servidor de aplicação JEE, isto será um requisito (não funcional). 

     

     

  • Complementando:

    as informações como a linguagem de programação ou o sistema gerenciador de banco de dados a serem utilizados DEVEM estar presentes nos requisitos de software documentados!

    O motivo é justamente o que o colega explicou logo abaixo: essas informações são requisitos não funcionais, ou seja, sem essas informações o sistema não poderá funcionar!

    Parece estranho né! mas em alguns projetos os requisitos não funcionais são mais importantes que os funcionais! Isto está no livro so Sommerville, e se dá pois um programa que deva ser integrado a outro sistema que utiliza uma base de dados Oracle deve necessariamente ter documentado como requisito NÃO  funcional esta restrição. Ja pensaram se implementam um sistema utilizando outra tecnologia? Simplesmente o sistema não vai funcionar!

    Abraços

  • O correto seria "...informações como a linguagem de programação ou o sistema gerenciador de banco de dados podem ser utilizadas ..."
  • Segundo Sommerville, requisitos não funcionais podem ser de três tipos:
    • De produto;
    • Organizacionais;
    • Externos.

    Requisitos organizacionais, por sua vez, também podem ser divididos em alguns subtipos, dentre os quais tempos os requisitos de implementação. Portanto, a organização pode decidir que um projeto deve ser feito em Java e deve utilizar Oracle, por exemplo.

    Segue uma imagem com os tipos de requisitos não funcionais: http://2.bp.blogspot.com/_nwUNsRiQl3I/TIMVmtBahAI/AAAAAAAAAYg/f9vQ11hKfnk/s1600/rnf.png
  • O documento de especificação funcional é o contrato entre o cliente e o desenvolvedor.
    Este documento contém os todos os requisitos do sistema.
  • Item incorreto
    Sommervile "O nível de detalhes que deve incluir em um documento de requisitos depende de tipo de sistema em desenvolvimento e o processo usado. Os sistemas críticos precisam ter requisitos detalhados, porque a segurança e a proteção devem ser analisados em detalhes", em outro trecho: " o apêndice do documento de requisitos deve fornecer informações detalhadas e específicas relacionadas à  aplicação em desenvolvimento, além de descrições de hardware e banco de dados"
    Abraços, vamo que vamo.
  • Corrigindo a última frase:
    Informações como a linguagem de programação ou o sistema gerenciador de banco de dados a serem utilizados devem estar presentes nos requisitos de software documentados.

    Essas informações são exemplos de requisitos não-funcionais. Outro exemplo:
    - O software deve ser operacionalizado no sistema Linux.
ID
147259
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Quanto aos requisitos de software, considere:

I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema.
II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser aplicadas na elicitação.
III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema existente, de análise do domínio do problema ou de estudos do mercado.

Está correto o que se afirma em

Alternativas
Comentários

  • Etnografia: técnica de observação que pode ser usada para compreender os requisitos sociais e organizacionais. O objetivo é descobrir os requisitos implícitos e não os formais com os quais as pessoas estão envolvidas.

  • Curiosidade!

    ELICITAR é um neologismo criado do verbo Inglês "to elicit" que tem o significado de extrair, provocar uma resposta. Usado tecnicamente como "extrair informação subjetiva" do usuário.
  • JAD (Joint Application Design)
    - Técnica utilizada para promover cooperação, entendimento e trabalho
    em grupo entre os usuários desenvolvedores.
    - O JAD facilita a criação de uma visão compartilhada do que o produto
    de software deve ser. Através da sua utilização os desenvolvedores
    ajudam os usuários a formular problemas e explorar soluções. Dessa
    forma, os usuários ganham um sentimento de envolvimento, posse e
    responsabilidade com o sucesso do produto.
    - A técnica JAD tem quatro princípios básicos:
    - A técnica JAD é composta de duas etapas principais: planejamento,
    que tem por objetivo elicitar e especificar os requisitos; e projeto, em
ID
147262
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere:

"Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software".

Quanto aos requisitos de software, a descrição acima está

Alternativas
Comentários

  • Alguns comentários:

    "...as características e restrições do produto de software..." - correspondem aos requisitos funcionais e não funcionais do sistema;

    "...do ponto de vista de satisfação das necessidades do usuário." - Os requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema.

    "...independem da tecnologia empregada na construção da solução..." - um requisito é simplesmente uma declaração abstrata de alto nível de um serviço que o sistema deve fornecer . No outro extremo, é uma definição formal e detalhada de uma função do sistema.

    "...propensas a erros no desenvolvimento de software"  - É natural que um desenvolvedor de sistema interprete um requisito ambíguo de modo a simplificar sua implementação. Frequentemente, no entanto, isso não é o que o cliente quer.

    Baseado no Livro Engenharia de Software, de Sommerville.

  • a) incoerente ao afirmar que expressam restrições.
    Existem requisitos funcionais (características/funções/operações) e não funcionais (restrições).

    b) incoerente ao afirmar que independem da tecnologia.
    Certamente, independe de tecnologia escolhida. Afinal, por exemplo, calcular sálario é uma abstração funcional não atrelada a qualquer tecnologia!

    c) incoerente ao afirmar que expressam características do ponto de vista de satisfação das necessidades do usuário.
    Requisitos não funcionais estão ligados a qualidade do software, e, portanto, relacionados a satisfação do usuário/cliente.

    d) totalmente coerente.

    e) incoerente ao afirmar que os requisitos são uma das partes mais críticas e propensas a erros.
    Exatamente o contrário!
  • Talvez na teoria independa da tecnologia, mas na pratica os requisitos limitam-se a tecnologia aplicada na construção do sistema. Por ex, não terei os mesmos requisitos no jogo WarCraft para PS3 e para o antigo ATARI, Não terei exatamente o mesmo aplicativo Autocad para Desktop e Iphone.
    Por esse pensamento que fui na letra B, masssss..... não importa o que penso e sim o que a banca acha...
  • às vezes algumas tecnologias fazem parte dos requisitos, como exemplo:

    O sistema deve se comunicar com o banco de dados Oracle (já existente antes do sistema).

    Observamos a afirmação: "Em geral, independem da tecnologia empregada na construção da solução"

    Geralmente, é assim mesmo, independente. Poucas exceções contém também tecnologias. A idéia do requisito é mais abstrata, a necessidade.

    A necessidade, abstratamente, poderia ser realizada com qualquer tecnologia.

ID
147265
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

"É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto.

A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software especificados para um sistema de gestão de pessoal.

No texto, são requisitos não-funcionais:

Alternativas
Comentários

  • Os requisitos não funcionais, como o nome sugere, são aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema.

    No caso do exemplo, a métrica utilizada para especificar o requisto não funcional foi o "tempo de resposta das consultas", correspondendo a propriedade velocidade.

    Fonte: Livro Engenharia de Software, de Sommerville.

  • "software seja operacionalizado usando código aberto" também não é um requisito não-funcional?
  • Concordo com o comentário do Eduardo Vinicius, " software de código aberto" não é um requisito funcional.
    Questão mal formulada.

  • Em resposta aos comentários:

                                                    Comentado por Eduardo Vinicius há 4 meses.
                                              "software seja operacionalizado usando código aberto" também não é um requisito não-funcional?

                                        Comentado por José Fábio de Oliveira há aproximadamente 1 mês.
     
                                               Concordo com o comentário do Eduardo Vinicius, " software de código aberto" não é um requisito funcional.
                                               Questão mal formulada.

    O código aberto é um requisito não funcional, mas a emissão quinzenal de relatório é funcional.
  • Ok, Mas entrega do produto final não pode ultrapassar o prazo de oito meses.
    Isso não seria uma restrição de tempo de projeto? não entendi onde se encaixa como requisito não - funcional.
  • Francisco Faria,

    restrições de entrega (como prazo), de implementação (linguagem de programação utilizada) e padrões são requisitos não funcionais organizacionais.

  •  d)tempo de resposta das consultas não deve superar os quinze segundos e entrega do produto final não pode ultrapassar o prazo de oito meses.

    req. nao funcionais sao como o sistema deve ser. geralmente nao é especificado pelo usuario por case uses, mas sao restrições ao uso do sistema e se manifestam em prppriedades como confiabilidade, tempo resposta, restrições ao data input. e.g.: quando tu respondeu a questão, houve um periodo entre o clique no botão e o feedback da resposta (correto/errado). se foi rapido, significa que o sistema do qc esta com este requisito nao-funcional cumprido. 

    p.s.: tempo de resposta de uma ação em uma interface deve ser indicada por avisos na tela de que o request esta processando, senao configura violação da heuristica de Nielsen status do sistema.

ID
147268
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

"É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto.

A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software especificados para um sistema de gestão de pessoal.

No texto, são requisitos funcionais:

Alternativas
Comentários
  • Resposta letra A.
    Requisitos Funcionais:
    Descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.
  • a) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente.
    Requisitos funcionais.

    b) Necessito, ainda, forte  gerenciamento de risco, prazo e cust o e a  base de dados  deve estar protegida e com acesso rest rito aos usuários autori zados.
    Requisitos não funcionais ou suplementares.

    c) é fundamental que o software seja operacionalizado usando código aberto e emita relatórios mensais sumariados por tipo de salário.
    Requisitos não funcionais ou suplementares. Requisitos funcionais.

    d) emita relatórios mensais sumariados por tipo de salário e Necessito, ainda, forte gerenciamento de risco, prazo e custo.
    Requisitos funcionais. Requisitos não funcionais ou suplementares.

    e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do produto final não pode ultrapassar o prazo de oito meses.
    Requisitos não funcionais ou suplementares.
  • Complementando: 

    e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do produto final não pode ultrapassar o prazo de oito meses.

    a segunda parte se refere a uma restrição de projeto.

  • a)calcule os salários dos diarisas e mensalistas e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente.

    req. funcionais sao como o sistema se comporta. depende de variaveis como usuarios, tipode software etc

ID
147295
Banca
FCC
Órgão
SEFAZ-SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A engenharia de software está inserida no contexto

Alternativas
Comentários
  • das engenharias de sistemas, de processo e de produto.
  • Pô baiano, isso é "preguiça" de fazer um comentário?
    Nem precisava ter feito todo esse esforço de copiar, colar e ainda por cima somar.....

  • O sujo falando do mal lavado rs... achei a questão bem estranha e não achei qualquer fonte de onde a mesma pudesse ter sido tirada, o que achei mais próximo de ser entendível foi:


    Engenharia de sistemas - OK

    Processo - Temos várias técnicas de engenharia que estruturam processos de desenvolvimento de software. Então processo possui a eng de sw. inserida.

    Produto - A análise do produto é uma fonte de requisitos durante a parte de análise de design do sw.

    Fonte: https://br.groups.yahoo.com/neo/groups/timasters/conversations/topics/139052?var=1

    Eu ainda diria que sistema pode ser entendido como um produto é o resultado da engenharia de software que preconiza o uso de processos para alcance da qualidade, assertividade nas previsões e entregas, etc. Advém da gestão de projetos em outras áreas de engenharia, que tinham sucesso nesta gestão, bem diferente do software quando começou a ser desenvolvido, que não tinha qualquer garantia de entrega, muito menos no prazo e menos ainda dentro do custo previsto. 

  • Complementando a explicação da Michele:

    Sabemos que a Engenharia de Sistemas é uma área mais ampla por tratar de todos os aspectos de sistemas baseados em computadores, incluindo hardware e engenharia de processos além do software. Os processos de engenharia de sistemas são orientados a produtos. Isto é, são processos preocupados com a correta identificação de necessidades e requisitos, traduzidos do domínio do problema para os diferentes níveis de requisitos e especificações no domínio da solução. Basicamente, engenharia de sistemas gerencia o escopo do produto, que vai além do projeto. A preocupação da engenharia de sistemas é todo o ciclo de vida do produto, desde sua concepção e desenvolvimento (projeto) até a sua operação e descarte.

    Podemos dizer que Engenharia de Sistemas é um processo mais amplo que inclui a engenharia de software e utiliza processos para elaboração de produtos.

  • o que mata a questão é a palavra apenas

ID
147730
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Considere a seguinte especificação: "O sistema deverá inserir os dados por ordem de telefonema (data e hora) atentando para os critérios de segurança e confiabilidade ora estabelecidos. A arquitetura deve ser suficientemente prática, a fim de oferecer a máxima manutibilidade e a orientação a objeto é fundamental para garantir a reusabilidade".

São requisitos não funcionais

Alternativas
Comentários
  • Requisitos não funcionais: descrevem a qualidade do sistema (como o sistema é) ao invés de  suas funcionalidades ( o que ele faz).
    A qualidade afeta diretamente a satisfação do clientes envolvidos com o sistema.

    Requisitos de qualidade visiveis ao usuário:
    Usabilidade, performance
  • Ordem de inserção é Requisito Funcional.
    O resto é Não funcional
ID
147733
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

A fase do desenvolvimento de sistema na qual as necessidades dos usuários são identificadas e as funcionalidades do sistema são modeladas é atualmente conhecida como

Alternativas
Comentários
  • Resposta letra B.
    Conforme o RUP, as funcionalidades são definidas na fase de Levantamento de Requisitos (Elicitação de Requisitos).
    Fases:
    1. Concepção: ênfase no escopo do sistema;
    2. Elaboração: ênfase na arquitetura;
    3. Construção: ênfase no desenvolvimento;
    4. Transição: ênfase na implantação.
    Disciplinas:
    1. Modelagem de Negocio
    2. Levantamento de Requisitos
    3. Análise e Design
    4. Implementação
    5. Testes
    6. Implantação.
ID
147736
Banca
FCC
Órgão
MPU
Ano
2007
Provas
Disciplina
Engenharia de Software
Assuntos

Em um artigo sobre uma rede de lojas do varejo, refere-se que um sistema de informações permitiria uma economia de milhões de reais com a geração automática de carnês. Entretanto, a utilização desse sistema provocou um aumento acentuado na inadimplência. O motivo do insucesso foi porque o carnê era grande e não cabia no bolso. Por causa disto os carnês eram guardados em gavetas e esquecidos pelos clientes. Detalhes como esse, que não são capturados durante a análise,

Alternativas
Comentários

  •  Acho muito difícil que inspeção formal de software detecte problemas tão sutis como esses...  Mas se eles acreditam nisso...

  • Concordo, e esta questão é bem subjetiva.

    Por curiosidade: O texto refere-se a rede Casas Bahia

  • Realmente questão bem subjetiva.

    Nesse caso, acredito que temos que usar o bom senso para resolvê-la.
    As informações propostas no enunciado deixam claro que a questão é sobre os requisitos de software, pois conta uma bela historinha. Pelos outros métodos de desenvolvimento de software não é possível detectar isso (Análise, Projeto, Construção, Testes, Implantação, etc).

    Se observarmos as opções c e e que mencionam o defeito de especificação dos requisitos é claro que foi esquecido de incluir na lista de requisitos a opção de tamanho para o carnê. O difícil de engolir na alternativa e é que não é possível reduzir a ocorrência durante o processo de software. É claro que isso não é válido, tendo em vista que existem técnicas de revisão realizada em todas as etapas de construção de um software. Ficando mais fácil matar a questão por elimininação na letra c, pois a banca ao mencionar inspeção formal de software se refere as revisões do processo de desenvolvimento de software.

    Mesmo assim, essa questão é muito subjetiva e engloba diversos conceitos na engenharia de software.
  • Nem o cliente do software poderá prever que haverá inadimplência por consequência da inserção do software no ambiente de trabalho.

    Como o cliente irá prever que haverá caloteiro, quem é honesto não sossega enquanto não tiver pago suas dívidas. 

    Se fosse como diz a questão, a empresa não poderá levar ninguém ao SPC/Serasa, pois foi culpa dela mesma, me poupe né.
  • Por eliminação:

    • a) certamente serão observados na fase de testes e homologação de produtos de software.
    • -> Certamente não foram observados, por isso ocorreu o defeito já em produção.
    • b) são objeto do levantamento especificado na fase de modelagem funcional.
    • -> esta opção não tem sentido e não traz nenhum valor para o problema.
    • c) constituem defeitos de especificação, cuja ocorrência pode ser reduzida por inspeção formal de software.
    • -> é um defeito, provacado por falha na especificação. o método formal levaria todos os atributos dos cenários de uso para representações matemáticas, e assim, poderia ter previnido o problema. não é perfeita, pois sabemos que não é assim no mundo real, mas é a melhor alternativa.
    • d) são obrigações da engenharia de requisitos praticáveis durante a fase de modelagem de dados.
    • -> e o que seriam requisitos praticáveis? nada a ver com modelagem de dados.
    • e) constituem defeitos de especificação e não há como reduzir sua ocorrência durante o processo de software.
    • -> constituem defeitos de especificação, certo. mas é claro que a banca não quer aprovar o candidato que diz que é impossível previnir tais tipos de problemas.
ID
148099
Banca
FCC
Órgão
TRT - 16ª REGIÃO (MA)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Dentre os requisitos não funcionais, classificados em

I. De produto.

II. Organizacionais.

III. Externos.

Corresponde a I, II e III, respectivamente,

Alternativas
Comentários

  •  Requisitos do Produto: Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.)

    Requisitos Organizacionais: Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)

    Requisitos Externos: Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)

     

  • Os requisitos não-funcionais podem ser classificados em

    I. Requisitos de Produto - Características e restrições que são aplicadas diretamente ao produto entregável

    II. Requisitos Organizacionais - Consequência de políticas, processos e padrões organizacionais

    III. Requisitos Externos - Decorrente de fatores que são externos ao sistema, como legislação.


    Os requisitos de produto podem ser:
    Usabilidade, Requisitos de Eficiência em Desempenho ou Espaço, Confiabilidade e Portabilidade.

    Os requisitos Organizacionais podem ser:
    Requisitos de Entrega, Implementação e Pradrões.

    E os requisitos Externos:
    Requisitos Legais de Privacidade e Segurança, Éticos e de  Interoperabilidade.
  • Requisitos não funcionais são  classificados de três formas:

    Requisitos de produto:
    Confiabilidade
    Desempenho
    Eficiencia
    Espaço
    Facilidade de uso
    Portabilidade

    Requisitos organizacionais:

    Padrão
    Entrega
    Implementação

    Requisitos externo:

    Segurança
    Interoperabilidade
    Privacidade
    Legais
    Eticos

  • Os requisitos não-funcionais podem ser classificados em:

    I. Requisitos de Produto - Características e restrições que são aplicadas diretamente ao produto entregável


    Podem ser, exemplo: Usabilidade, Requisitos de Eficiência em Desempenho ou Espaço, Confiabilidade e Portabilidade.




    II. Requisitos Organizacionais - Consequência de políticas, processos e padrões organizacionais


    Podem ser, exemplo: Requisitos de Entrega, Implementação e Pradrões.




    III. Requisitos Externos - Decorrente de fatores que são externos ao sistema, como legislação.


    Podem ser, exemplo:Requisitos Legais de Privacidade e Segurança, Éticos e de  Interoperabilidade.

  • 1. Requisitos de Produto: especificam ou restringem o comportamento.e.g: desempenho, confiabilidade, portabilidade, proteção e usabilidade.

    2. Requisitos Organizacionais: políticas/procedimentos da organização do cliente e do desenvolvedor.e.g: requisitos dos processos operacionais (uso do sistema), desenvolvimento (escolha da linguagem de programação) e requisitos ambientais (ambiente operacional do sistema).

    3. Requisitos Externos: externos ao sistema.requisitos legais e éticos

ID
157816
Banca
FCC
Órgão
METRÔ-SP
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No processo de engenharia de software, os requisitos funcionais podem ser também definidos como requisitos de

Alternativas
Comentários
  • Um requisito é definido como "uma condição ou uma capacidade com a qual o sistema deve estar de acordo".Existem vários tipos de requisitos, dentre os quais destacamos os seguintes:• Funcionalidade• Usabilidade• Confiabilidade• Desempenho• Suportabilidade

  • Pela afirmação abaixo, um requisito funcional é uma capacidade e não um requisito de capacidade. Na minha opinião a questão está mal formulada.

  • Capacidade se refere a que o sistema é capaz de fazer. O que ele é capaz de fazer são as especificações do cliente, ou seja, os seus requisitos funcionais. Os não-funcionais são requisitos de qualidade, p. exemplo.

  • Até o nome do Cargo tá errado. TREINEE ??? Seria Trainee...hhehe Essa prova toda deve ter sido um lixo, segunda questão que vejo mal formulada. Péssima.

  • Requisito pode ser descrito como: Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;

     

    http://javafree.uol.com.br/artigo/871451/Especificacao-de-Requisitos-uma-abordagem-orientada-ao-sucesso.html

  • b-

    Os requisitos de desempenho permitem ou coibem a inclusão de elementos que sobrecarregam a estrutura.

ID
162175
Banca
FCC
Órgão
TCE-AL
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Em um sistema cujo objetivo principal seja emitir guias de cobrança de impostos e fazer o controle de contribuintes, NÃO é um produto inerente ao trabalho de levantamento de requisitos

Alternativas
Comentários

  • Na engenharia de sistemas e engenharia de software, análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte importante do processo de projeto de sistemas, na qual o engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou requisitos de um cliente. Uma vez que os requisitos do sistema tenha sido identificados, os projetistas de sistemas estarão preparados para projetar a solução.

    A opção A é a única que não se enquadra no levantamento de requisitos, pois se trata de detalhes de implementação do sistema.

  • A analise de pontos de função é feita a partir dos requisitos. Então não pode ser produto do levantamento dos requisitos.
ID
163024
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto da engenharia de software, o processo conhecido como engenharia de requisitos permite ao engenheiro de software

Alternativas
Comentários
  • - A IFQ concentra-se em maximizar a satisfação do cliente apartir do processo de engenharia de software, entendendo o que tem valor para ele, e implantando-o;
    - A volatilidade sempre haverá, pois, muitas vezes, depende de fatores externos. Pode ser minimizada;
    - O escopo inicial do sistema eh definido na concepção;
    -
  • Eliminar a volatilidade: depende apenas do negócio do cliente. Muito improvável que aconteça.

    Postergar a definição do escopo está incorreto. A definição do escopo, mesmo que grosseiro, é feita na bem no início do processo de engenharia de software: comunicação.

    A Implantação da Função da Qualidade (IFQ) tem como objetivo transformar as vontades, desejos, necessidades e expectativas dos clientes em requisitos técnicos do sistema. Tem, ainda, o objetivo de maximizar a satisfação do cliente. A IFQ identifica trê tipos de requisitos: normais (especificados pelo cliente, como desempenho e funcionalidades), implícitos (tão importantes que nem são mencionados pelo cliente, como interface amigável, fácil manuseio, etc) e excitantes (não previstos nos casos anteriores e que surpeeendem os clientes posistivamente).
    Assim, ele não  para softwares já existentes, como dito em "C".

    Os requisitos do sistema e as regras do negócio estão ligados intimamente. Regra do negócio é como o sistema funcionará, com as dependências dos componentes e tudo mais. Elas surgiram dos requisitos.

    O modelo de casos de uso, ou comumente chamado de cenários de usuário, é usado para descrever o sistema; o que ele faz quando um ator interage com o sistema. Poder ser usado para levantamento dos requiitos, para testes do sistema, para verificar ambiguidades, inconsistências e etc. Está correta a alternativa.
ID
164611
Banca
FGV
Órgão
BADESC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Analise o fragmento a seguir:

"a base de dados deve ser protegida para acesso apenas de usuários autorizados".

O fragmento acima apresenta um exemplo do seguinte requisito:

Alternativas
Comentários

  • Requisitos funcionais

    Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações.

     

    Requisitos não funcionais

    Restrições sobre os serviços ou as funções oferecidas pelo sistema.

     

    Requisitos de domínio

    Requisitos que se originam do domínio da aplicação do sistema e que refletem características desse domínio (Podem ser requisitos funcionais e não funcionais).

     

    Requisitos de sistema se destinam a comunicar, de modo preciso, as funções que o sistema tem de fornecer

     

     

     

    Requisitos de Usuário

    Devem descrever os requisitos funcionais e não funcionais de modo compreensível pelos usuários

    do sistema, que não tem conhecimentos técnicos detalhados.

    Requisitos do usuário são definidos usando linguagem natural, tabelas e diagramas.

  • Interessante que sommerville, p81 diz que a distinção entre os diferentes tipos de requisitos não são tão claras como sugerem as definições. Um requisito de usuário relacionado à proteção, por exemplo, pode parecer um requisito não funcional. No entanto, quando desenvolvido mais detalhadamente, esse requisito pode gerar outros requisitos claramente funcionais, como a necessidade de incluir recursos de autenticação de usuário no sistema.

    Com base nisso, não seria sensato a letra A?
  • O próprio Sommervile diz que os requisitos não funcionais estão raramente associados às características individuais do sistema. A fato da base de dados ser protegida envolve segurança, aplicando-se ao sistema como um todo.

    Ademais, segurança é uma característica elencada entre os tipos de requisitos não funconais que Sommerville expõe em seu livro:

  • Pode parecer meio confuso, mas veja "a base de dados deve ser protegida para acesso apenas de usuários autorizados". Quando há uma restrição, temos requisito não-funcional.

ID
174847
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as afirmações relacionadas com a engenharia de requisitos:

I. os requisitos do sistema não são, necessariamente, resultantes dos requisitos do cliente;

II. os requisitos consistem em ideias do cliente associadas ao custo do sistema;

III. é importante estabelecer uma linha de base de requisitos (requirements baseline) com a finalidade de gerenciamento de requisitos.

Sobre as afirmações, pode-se dizer que está correto o contido apenas em

Alternativas
Comentários
  • I. os requisitos do sistema não são, necessariamente, resultantes dos requisitos do cliente;
    AFIRMATIVA CORRETA Os requisitos podem ter natureza nao funcional por exemplo
    II. os requisitos consistem em ideias do cliente associadas ao custo do sistema;
    AFIRMATIVA ERRADA Nao faz o menor sentido associar ao custo do sistema os requisitos
    III. é importante estabelecer uma linha de base de requisitos (requirements baseline) com a finalidade de gerenciamento de requisitos.
    AFIRMATIVA CORRETA E' a definicao de requirements baseline
  • I. os requisitos do sistema não são, necessariamente, resultantes dos requisitos do cliente;
    Correto. Os requisitos podem ser provenientes da Legislação (Normativos), de documentos de sistema legado, etc.

    III. é importante estabelecer uma linha de base de requisitos (requirements baseline) com a finalidade de gerenciamento de requisitos.
    Correto. Linha de Base, pode estar associada à rastreabilidade. Mudança de Requisitos, precisaria de uma aprovação formal. Lembrar das Linhas de Base no RUP. Linha de Base seria uma documentação com a rastreabilidade, associando os requisitos a outros, a fontes, a projeto.
ID
178030
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere o seguinte texto extraído de um documento de requisitos:

Os dados devem ser armazenados no banco de dados utilizando um formato padrão e hierárquico, que facilite sua leitura e a geração de relatórios.

O texto apresenta um exemplo de requisito

Alternativas
Comentários
  • Se a questão dissesse, por exemplo, que dados de clientes, de produtos etc. devem ser armazenados, seria um requisito funcional.

    Porém, a questão limita a forma como os dados podem ser armazenados. Trata-se, portanto, de uma restrição, e não de um serviço fornecido pelo sistema.

    Serviços fornecidos pelo sistema são requisitos funcionais.
    Restrições que limitam as possíveis soluções do sistema (soluções que serão desenvolvidas na fase de projeto) são requisitos não funcionais.
  • Isto não é requisito. Requisito é o que o sistema deve ou não fazer. Dizer qual SGBD deve ser utilizado já está na especificação do sistema.
ID
178033
Banca
VUNESP
Órgão
CETESB
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere o seguinte enunciado de um requisito não funcional:

O sistema deve estar funcional e acessível para os usuários em 98% do tempo. Os logs do tempo em que o sistema esteve fora do ar - e suas possíveis causas - devem ser fornecidos ao cliente de forma automática, via email.

Assinale a alternativa que apresenta o requisito não funcional abordado no enunciado.

Alternativas
Comentários
  • Um sistema de alta disponibilidade é um sistema informático resistente a falhas de software e energia, cujo objetivo é manter os serviços disponibilizados o máximo de tempo possível.
    Disponibilidade (%) Downtime/ano Downtime/mês
    95% 18 dias 6:00:00 1 dias 12:00:00
    96% 14 dias 14:24:00 1 dias 4:48:00
    97% 10 dias 22:48:00 0 dias 21:36:00
    98% 7 dias 7:12:00 0 dias 14:24:00
    99% 3 dias 15:36:00 0 dias 7:12:00
    99,9% 0 dias 8:45:35.99 0 dias 0:43:11.99
    99,99% 0 dias 0:52:33.60 0 dias 0:04:19.20
    99,999% 0 dias 0:05:15.36 0 dias 0:00:25.92
    Geralmente, quanto maior a disponibilidade, maior a redundância e custo das soluções. Tudo depende do tipo de serviço que se pretende disponibilizar. Por exemplo, um operador de telecomunicações quererá certamente o mais elevado a fim de poder garantir um elevado nível de disponibilidade, sob pena de perder os seus clientes caso o sistema sofra falhas constantemente
    Fonte:     http://pt.wikipedia.org/wiki/Sistema_de_alta_disponibilidade
ID
190705
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

As técnicas de identificação de requisitos de sistemas possuem características apropriadas a cada situação. Nesse contexto, analise as afirmações sobre as técnicas a seguir, considerando que a abordagem baseada em

I - Workshop de Requisitos utiliza momentos de descontração como forma de dinamizar o trabalho em equipe;

II - Cenários utiliza exemplos práticos descritivos do comportamento de um sistema;

III - Entrevistas e Questionários mostra-se inadequada na fase inicial de obtenção de dados.

Está correto o que se afirma em

Alternativas
Comentários
  • Algumas técnicas para levantamento de requisitos:
    1. Entrevistas e Questionários
    2. Workshops de requisitos
    3. Cenários
    4. Prototipagem
    5. Estudo etnográfico
  • Entrevistas e Questionários Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas).   Workshops de requisitos O Workshop de Requisitos consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então obter um conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão).   Cenários Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. 
  • III - Entrevistas e Questionários mostra-se inadequada   adequada   na fase inicial de obtenção de dados.
    (mesmo que os resultados nem sempre sejam tão satisfatórios!)
  • III - Entrevistas e Questionários mostra-se inadequada na fase inicial de obtenção de dados.
    Os questionários muitas vezes não fornecem um feedback apropriado na fase inicial de obtenção de requisitos, por ser muito restrito. Já as entrevistas podem sim ser muito adaquadas e eficientes na fase incial de obtenção de requisitos
ID
191779
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma fábrica de software recomenda que a documentação de especificação funcional de um sistema deve ser clara para o cliente e detalhada para o desenvolvedor, estabelecendo um contrato entre eles. Documentos de especificação funcional têm como característica

Alternativas
Comentários
  • Com relação ao erro da letra c,

    Pesquisei no sommerville e ele diz:  "Requisitos de sistema definem, detalhadamente, as funções, os serviços e as restrições operacionais do sistema. O documento de requisitos de sistema (às vezes chamado de ESPECIFICAÇÃO FUNCIONAL) deve ser preciso. Ele deve definir exatamente O QUE será implementado. Pode ser parte do contrato entre o comprador do sistema e os desenvolvedores de software"   página 80

    página 87:

    "... os requisitos de sistema devem simplesmente descrever o comportamento externo do sistema e suas restrições operacionais. Eles não devem estar relacionados a como o sistema pode ser projetado ou implementado."

    confirmando a alternativa B:
    "... uso de uma arquitetura específica para satisfazer os requisitos não funcionais..."
  • Colega eu gostei da sua pesquisa. Achei boa e valida sim....porem,
    Como os Documentos de especificação funcional têm como característica podem conter os requisitos não funcionais pertinentes ao problema a ser resolvido?
    Nao sei nao. Essa questao me pareceu mal formulada, Eu marquei a letra A , mas tinha ficado em duvida entre A e B. Nao marquei a B exatamente por essa discordancia que apresentei acima...Ate' pq na vida pratica e' sempre um habito os diagramas de interacao relacionados aos requisitos contidos na especificacao virem junto com o restante dos documentos para auxiliar na compreensao do problema...Achei mal formulada a questao... Mas... o importante e' acertar o gabarito nao e'?
  • Analisei o item B da seguinte forma: se numa especificação o cliente deseja que seja apresentado o ano para o qual os dados devem ser apresentados, é um requisito funcional. Mas além disso o cliente deseja que sejam apresentados somente os cinco últimos a partir do ano atual, isso é um requisto não funcional que pode estar contido na especificação. Por isso entendo que realmente a letra B está correta.
  • A J,

    Desculpe, mas acho que o exemplo que vc apresentou trata de um requisito FUNCIONAL.  

    Seria um requisito NÃO FUNCIONAL se fosse algo do tipo: ao solicitar a funcionalidade X, o cliente deve obter a resposta em Y segundos. Ou, para desenvolver a funcionalidade Z, deve ser utilizado uma solução de web service...

    Quanto a questão em si, eu procurei em Pressman e em Sommerville e não encontrei nada relacionado à resposta dada pelo gabarito... queria até saber qual foi a fonte que eles utilizaram...

    • Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.
    • Requisitos não-funcionais -
      referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade
    analise e veja se a resposta que melhor se encaixa não é a letra "C"
  • Janio,
    O problema da "C" é o trecho:  "...como ele deve ser implementado." 
    Isso é requisito não funcional! 
    É vc falar por exemplo, que vai desenvolver em Java, usando JSF, numa arquitetura MVC com web services. 
  • sOMMERVILLE Separa os requisitos em Requisitos de usuário e Requisitos de Sistema.
    Segundo o autor Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de quais serviços o sistema deve fornecer a seus usuários(Requisitos Funcionais) e as restrições com as quais este deve operar(Requisitos não funcionais).(Pág 58)
    O documento de Requisitos de Software, as vezes chamado Especificação de Requisitos de Software, é uma declaração oficial de o que os desenvolvedores do sistema devem implementar. Deve incluir tanto os requisitos de usuário para um sistema quanto uma especificação detalhada dos requisitos de sistemas.(Pag. 63)
    Acredito que a questão tenha sido infeliz ao declarar Especificação Funcional como sinônimo de Especificação de Requisitos de Software.
    Concordo com os colegas de que a quetão poderia ter sido anulada
    Fonte: Sommerville 9° Ed.

  • Concordo com a análise do Filipe.  Escrevi 3 comentarios sobre a questao. Segue primeiro deles (1/3)

    No livro do Sommerville 8a. edicao Item 6.5 Documento de requisitos de software (pag 91), o autor define 

    "O documento de requisitos de Software  (algumas vezes chamado de especificacao de requisitos de software...) é a declaração oficial do que os desenvolvedores devem implementar. Deve incluir requisitos do usuário e uma especificacao detalhada dos requisitos do sistema.  ...   O documento de requisitos possui um conjunto diversificado de usuarios, desde a gerencia senior até os engenheiros responsaveis..."

    Dentre os usuarios citados no livro: Clientes, Gerentes, Engenheiros de teste, de sistemas e de manutencao.

    Notar que, no inicio do enunciado da questao, é definido "...a documentação de especificação funcional de um sistema deve ser clara para o cliente e detalhada para o desenvolvedor,...". Na verdade, a especificação citada no enunciado refere-se ao documento de requisitos de software. (O que na minha opinião seria suficiente para invalidar a questão, mas..)

    Voltando ao Sommerville, na pagina 92, ele cita a estrutura para Documento de requisitos do IEEE 830:

    1. Introducao

    2. Descricao Geral

    3. Requisitos especificos: abrangem requisitos funcionais, nao funcionais e de interfaces.

    4. Apendices

    5. Indice

  • Também encontrei na internet uma explicação simples para esta questão (2/3)

    "Existem as especificações funcionais e especificações técnicas, por outro
    lado existem os requisitos funcionais, e requisitos não funcionais.
    A especificação funcional tem como alvo também, o usuário, e contém por
    isso, requisitos não funcionais."

    Fonte: https://br.groups.yahoo.com/neo/groups/timasters/conversations/topics/154777

    Para os que gostam de referencia do Sommerville e Pressman, vide explicacao abaixo.

  • Para completar a analise desta questão (3/3)

    A letra A está inválida pq o documento de requisitos de software pode até possuir um diagrama de interacao porém nao é característica, ou seja, obrigatório, marcante, necessário. Já a descricao dos requisitos funcionais está explicitada na tabela 6.5 Estrutura de um documento de requisitos (pag 93 Somerville 8a. edicao):

    Esta tabela contém varios tópicos da estrutura de um documento de requisitos, dentre eles:

    "Definicao dos requisitos de usuario:  ... Essa descricao pode usar linguagem natural, diagramas e outras notacoes compreensiveis pelos usuarios. ..."

    "Especificacao de requisitos de sistema: Deve escrever os requisitos funcionais e nao funcionais mais detalhadamente. ..."


ID
191782
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Para superar as dificuldades encontradas na execução do levantamento de requisitos de sistemas, uma empresa estuda as vantagens e as desvantagens de diferentes técnicas. Qual a técnica de levantamento de requisitos, baseada na observação, em que o analista se insere no ambiente de trabalho no qual o sistema será utilizado, para compreender a política organizacional e a cultura de trabalho, com o objetivo de familiarizar-se com o negócio e sua história?

Alternativas
Comentários
  • Etnografia é a especialidade da antropologia, que tem por fim o estudo e a descrição dos povos, sua língua, raça, religião, e manifestações materiais de suas atividades, é parte ou disciplina integrante da etnologia é a forma de descrição da cultura material de um determinado povo.
  • Etnografia

    A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um entendimento completo e detalhado de culturas particulares.

    Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.

    Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

    1.      Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;

    2.      Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
     
    Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observação:

    ·         Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo;

    ·         Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as operações normais de negócios acima é importante observar as exceções;

    ·         Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
     
    A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações. Mas em geral a técnica de observação é muito útil e freqüentemente usada para complementar descobertas obtidas por outras técnicas.
  • Na técnica de etnografia, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.

    Fonte: http://www.devmedia.com.br/artigo-engenharia-de-software-2-tecnicas-para-levantamento-de-requisitos/9151

  • d-

    Tecnicas de requisitos:

     

    1- Brainstorming: sem julgamentos ou análises,ambiente descontraído e informal, para novos produtos.

     

    2- JAD: cooperação, entendimento e trabalho em grupo 

     

    3- Análise de documentos quantitativos: formulários e relatorios

     

    4- Reunião: licitação de requisitos em grupo

     

    5- Prototipagem: para atrair aspectos críticos quando nao ha domínio mínimo da aplicação.

     

    6- Entrevista: conversa para extrair tópicos importantes.

     

    7- Questionários: questões subjetivas e objetivas.

     

    8- Observação: comportamento e o ambiente 

     

    9- Levantamento Orientado a Ponto de Vista: pontos de vista dos usuários, analisar as diferenças e similaridades

     

    10- Etnografia: para entender a organização, sua cultura e o objetivo 

     

    11- Caso de Uso: comportamento externo de um sistema descrevendo ações para produzir um resultado observável por um ator, através de interação entre um ator (usuário, outro sistema computacional ou um dispositivo) e um sistema.

ID
191788
Banca
CESGRANRIO
Órgão
ELETROBRAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma equipe de desenvolvimento de sistemas foi contratada para confeccionar o software de controle de voo de uma nova aeronave. Sabendo-se que esse assunto é novo para os membros da equipe, a primeira ação a ser tomada, no contexto de levantamento de requisitos, é

Alternativas
Comentários
  • Acredito que sejam requisitos antes de qualquer etapa, como por exemplo, neste exercício, a Elicitação de Requisitos.

    Áreas de especialização necessárias aos profissionais de gerência de projetos:

    -Conhecimento, normas e regulamentos da área de aplicação: cada área de aplicação, em geral, possui um conjunto de normas, regulamentos e práticas aceitas.
    -Entendimento do ambiente do projeto: ambiente cultural e social, ambiente internacional e político, ambiente físico.
    -Conhecimento e habilidade em gerenciamento geral: contabilidade, finanças, aquisições, vendas, marketing, contratos, legislação comercial, fabricação, distribuição, logística, planejamento estratégico, tático e operacional, estruturas organizacionais, comportamento organizacional, administração de pessoal, planos de carreira, tecnologia de informação, etc...
    -Habilidades interpessoais: comunicação eficaz, influência sobre a organização, o liderança, motivação, negociação e gerenciamento de conflitos, resolução de problemas.

  • A chave da questão está em: Sabendo-se que esse assunto é novo para os membros da equipe.

    Portanto como vão elaborar um questionário (A), modelar o sistema (B) criar um protótipo (D) e verificar viabilidades (E) se eles não domínam o domínio do sistema ?
ID
192841
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na engenharia de software, etnografia é

Alternativas
Comentários

  • Os estudos etnográficos são uma técnica, proveniente das disciplinas de Antropologia Social, que consiste no estudo de um objecto por vivência directa da realidade onde este se insere. Permitindo analisar a componente social das tarefas desempenhadas numa dada organização tornam-se, no âmbito da Engenharia de Requisitos, extremamente uteis para ultrapassar a dificuldade que existe na recolha dos requisitos derivados de formas rotineiras e tácitas de trabalhar:

    Fonte: http://pt.wikipedia.org/wiki/Estudo_etnogr%C3%A1fico

  • A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de familiarizar-se com o sistema e sua história.
  • Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

    1. Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;

    2. Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.

  • c-

    etnografia (éthnos - pessoas estranhas; graphé - escrita) é um metodo sistematico de descrever um meio por vivencia regular no proprio campo de pesquisa, ganhando conhecimento por observacoes compartihadas com os participantes da comunidade observada.

  • Etnografia:

    "técnica observacional que pode ser utilizada na elicitação e análise de requisitos. O etnógrafo mergulha no ambiente do usuário e observa seus hábitos de trabalho diários. Requisitos para apoio do software podem ser inferidos a partir dessas observações" (SOMMERVILLE, 2019, p. 725).

ID
192844
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

As políticas de rastreabilidade de requisitos são decididas durante o estágio de

Alternativas
Comentários
  • Segundo Somerville (Edição 6, pág 118)

    "O gerenciamento de requisitos é o processo de compreender e controlar as mudanças nos requisitos de sistemas. O processo de gerenciamento de requisitos é realizado em conjunto com outros processos de engenharia de requisitos. O planejamento se inicia ao mesmo tempo que o levantamento inicial de requisitos, e o gerenciamento ativo dos requisitos deve começar assim que um esboço da versão do documento de requisitos estiver disponível."

    No gerenciamento de requisitos são definidas também as Políticas de Facilidade de Rastreamento, que definem as relações entre os requisitos do projeto.
  • Rastreabilidade é a capacidade de mensurar o impacto causado na mudança de um requisito.
  • Durante o estágio de gereciamento de requisitos, deve-se decidir sobre?
    identificação de requisitos
    processo de gerenciamento de mudanças
    políticas de rastreabilidade
    ferramenta de apoio

  • 2015

    O gerenciamento de requisitos em grandes sistemas envolve o processamento de grandes volumes de informações sobre requisitos, o que exige o uso de apoio automatizado. As ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento de gerenciamento de requisitos. As ferramentas de apoio são usadas, principalmente, para

     a) identificação de requisitos, classificação de requisitos e gerenciamento de mudanças.

     b) classificação de requisitos, armazenamento de requisitos, validação de requisitos e gerenciamento de rastreabilidade.

     c) armazenamento de requisitos, gerenciamento de mudanças e gerenciamento de rastreabilidade.

     d) classificação de requisitos, validação de requisitos e armazenamento de requisitos.

     e) identificação de requisitos, armazenamento de requisitos, classificação de requisitos e gerenciamento de mudanças.


     

    2012

    A gestão de requisitos é um conjunto de atividades que tem como principal objetivo ajudar a equipe de projeto a

     a) utilizar ferramentas de engenharia de software para modelar os requisitos do sistema, através da UML.

     b) identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue.

     c) construir um modelo técnico refinado de funções, características e restrições do software.

     d) negociar com os clientes os conflitos de prioridade de requisitos e identificar e analisar os riscos associados a cada requisito.

     e) avaliar os requisitos quanto à qualidade, garantindo que ambiguidades, inconsistências, omissões e erros tenham sido detectados e corrigidos.

     

  • e-

    gerenciamento de requisitos é uma sub-area da engenharia de requisitos para desenvolvimento eficiente e de qualidade de sistemas complexos. Outras disciplinas que participa, deste processo sao elicitacao de requisitos e validacao de requisitos, enquanto que ger. req usa como regra controle, direcao e administracao de requisitos, assim como gerenciamento de risco e implementacao.

ID
192847
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Para decidir sobre os limites do sistema, ou seja, distinguir o que é o sistema e o que é o ambiente do sistema, um trabalho é feito em conjunto com os stakeholders em um estágio inicial de elicitação e análise de requisitos. Esse trabalho culmina, em primeira instância, com um modelo

Alternativas
Comentários

  • Não encontrei até o presente momento o modelo afirmado pela banca desta questão. O que podemos fazer para responder a esta questão é utilizar de analogia.

    A elicitação de requisitos é a fase, dentro do processo de Engenharia de Requisitos, que possui o desafio de entender os desejos e necessidades do cliente.
    A grande questão que envolve o processo de elicitaçãode requisitos é a dificuldade de obtenção de uma visão real do que deve ser o sistema. Sommerville [13].

    Devido a esta dificuldade de definição e realizadas estas técnicas para elicitação dos requisitos.


    Desta forma, várias técnicas de elicitação sãoutilizadas visando minimizar estes problemas, comosugere Kasse [12]: Diálogos; Cenários; Demonstração detecnologias; Modelos; Simulações; Protótipos;Brainstorming; Observação de sistemas existentes  e Extrações de documentos.

    Baseado nestas informações temos a definição do Modelo de contexto.

    Modelos de contexto procuram identificar os “contornos” do sistema em termos de outras entidades de hardware e software com os quais o sistema interagirá.58

    Na elicitação de requisitos temos a dificuldade de definirmos os limites do sistema e com um artefato de modelo de contexto conseguimos identificar estes limites do sistema relacionados a hardware e software.

    Nesta fonte temos uma figura que exemplifica o modelo de contexto: http://docs.google.com/viewer?a=v&q=cache:bmc2bxRO2v8J:143.106.50.145:8080/Cursos/EA976/02-08/EA976-Modelos.pdf+modelo+de+contexto&hl=pt-BR&gl=br&pid=bl&srcid=ADGEESjzwfAIf21DvZQMYm6Up3tTNKzGDk_F_3tP5zvgIaXG2lO2r0PNU0S8AUWUxPtPaUeZlj2Z7Q-XSrGedOCIJfxiPC4FKP9nMPKIWPPa4_0EUB0oKiHadn8VzBvwAiQdtegZ_pyy&sig=AHIEtbSNS9gbdqFHW3GCsU2xD9gXsUEQ4A

    fonte: http://pt.scribd.com/doc/52620385/Elicitacao-de-Requisitos-e-Design-Participativo-atraves-de-Prototipos-de-Baixa-Fidelidade-%E2%80%93-Um-Estudo-de-Caso

     


     

    .
     .

  • A resposta sobre essa questão encontra-se no livro Engenharia de Software do Ian Sommerville, dependendo da edição, no tópico 5.1 (9ª edição) ou 8.1 (8ª edição), que trata de Modelos de Contexto.

    Transcrevo o início do tópico:

    "Em um estágio inicial da especificação de um sistema, você deve decidir os limites do sistema. Isso envolve trabalhar com os stakeholders para decidir qual funcionalidade deve ser incluída no sistema e o que é fornecido pelo ambiente do sistema."

  • Diagrama de Casos de Uso = Diagrama de Contexto

    se a questão pede um trabalho que é feito com os stakeholders em um estagio inicial de ELICITAÇÃO de requisitos e análise, logo como principal ferramente é o caso de uso que no final das contas é o documento que vai ser gerado. 

    letra A

  • E um sinomio a DFD-Diarama de Fluxo de Dados que especifica o Diarama de Contexto. Que mapeia as etidades internas (pertencentes ao sistema) e entidades externas ao sistema.

  • E um sinonimo a DFD-Diarama de Fluxo de Dados que especifica o Diarama de Contexto. Que mapeia as etidades internas (pertencentes ao sistema) e entidades externas ao sistema.- Obs.:Estou com problema no teclado

ID
192856
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre requisito funcional, considere:

I. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos.

II. O usuário deve ser capaz de fazer uma busca em todo o conjunto inicial de banco de dados.


III. O sistema deve atender aos requisitos de confiabilidade, usabilidade e portabilidade.

Está correto o que se afirma em

Alternativas
Comentários

  • Segundo Sommerville

    Requisitos funcionais são declarações de servicos que o sistema deve fornecer, como o sistema deve reagir a entrada específicas e como o sistema deve se comportar em determinadas situacoes. Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve fazer

    Requisitos nao funcionais: sao restrições sobre os serviços ou as funçoes oferecidos pelo sistema. Eles incluem restrições de timming, restricoes sobre o processo de desenvolvimento e padrões. Os requisitos não funcinais aplicam-se frequentemente, ao sistema como um todo. Em geral eles não se aplicam às características ou serviçõs individuais de sistema.

     

    Portanto, como  "confiabilidade, usabilidade e portabilidade" se aplica a todo o sistema e impõe restrições sobre funões oferecidas, trata-se de um requisito não funcional.

     

  • I. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos.

    "Telas apropriadas" não é relativo a usabilidade?

  • O item 1  sem dúvida é o que separa os homens de meninos. Quando ele diz:  "O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos." significa que o usuário poderá ler os documentos no próprio sistema, mais especificamente dentro do repositório. Logo isso é uma funcionalidade que o sistema deve se comprometer a realizar. 

    No item não se deve dar uma importância maior para "telas apropriadas" e sim para toda a frase. O objetivo maior seria que: o usuário poderá ler os documentos no repositório de documentos a partir de telas apropriadas no sistema. E isso é um requisito funcional. Sabendo o que significa RF e RNF o item se torna uma questão de interpretação.

  • Primeiro que "tela apropriada" nem requisito é. Se o é, está muito mal documentado. Seria a mesma coisa que "o sistema deve ser rápido"...o que é apropriado? e o que é rápido? Quais os critérios de aceitação? o cara que cria uma questão dessa merece um tiro!

  • "O sistema deve fornecer telas apropriadas" pode ser substituído por "O sistema deve fornecer telas"
    A questão quis confundir com um requisito não-funcional de usabilidade. 

  • A alternativa I foi tirada do exemplo de algum livro (O sistema LIBSYS), uma rapida procura no google (http://ivansowa.blogspot.com/2011/04/requisitos-de-software.html) me levou a um conjunto de requisitos funcionais desse sistema.

    Exemplos de requisitos funcionais
    O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele.
    Para todo pedido deve ser alocado um identificador único (ORDER_ID) que o usuário possa copiar para a área de armazenamento permanente da sua conta.
    O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos.

    Ou seja, a FCC apenas copiou a frase de algum lugar, nao elaborou nada complexo.
  • Realmente o item I separa os homens dos meninos e é por isso que mantenho minha opinião que é um requisito não-funcional de usabilidade.

    O foco principal no período é: "Deve haver telas apropriadas para algum fim.".  Não importa que esse fim seja um requisito funcional.  Todos, inclusive a banca, devem prestar atenção no idioma Português e semântica em períodos.  Na minha opinião, a resposta correta é letra "b" e se fosse comigo, eu entraria com recurso.
  • Esqueçam o "apropriada". Ou então leiam apropriada como "com a finalidade de".

    Leiam: O sistema deve fornecer telas para o usuário ler os documentos no repositório de documentos.

    Isso num é um requisito funcional não? Ter a função de ler documentos de um repositório?
  • Ainda acho que vale o que está escrito... Como diz o Arnaldo: "A regra é clara!"
    Do modo como está escrito, também entendo como um requisito não-funcional...
  • Pessoal,
    Trabalho com requisitos há 5 anos e também errei a questão, marquei a letra B, interpretei o item 1 como Requisito Não-Funcional. Agora por quê? Porque o requisito foi mal definido, esse requisito não ficou claro. “Requisitos ambíguos podem ser interpretados de maneira diferentes pelos desenvolvedores e usuário” assim explica o autor do artigo onde a FCC copiou a questão. (http://ivansowa.blogspot.com.br/2011/04/requisitos-de-software.html). O autor utilizar o item 1 dessa questão, para descrever que problemas surgem quando os requisitos não são bem definidos. A FCC copiou um item mal elaborado e utilizou na questão, o examinador não teve a capacidade de ler o artigo por completo. Em minha opinião, essa questão deveria ser anulada.
  • Questão maliciosa sim e de dúbio sentido, com certeza nem de longe isso é um requisito funcional e nem de longe não funcional... telas adequadas??? o que são? como testar se são adequadas? ainda que fosse usabilidade também teria sério problema de clareza. Mas também não acho que seja funcional.. ficou em cima do muro..em ambas situações, esse requisito está mal escrito. Essa palavra adequada é relativa assim como palavras: (Rápido
    Flexível, Adaptável, Intuitivo)
    uma boa prática é :  "Garanta que cada requisito seja verificável ou testável" Um requisito é verificável se e somente se existir  algum processo efetivo ao qual uma pessoa ou máquina possa checar que o produto de software é semelhante ao requisito. No geral qualquer requisito ambíguo não é verificável.
    Recomendo leitura da norma IEEE STD 830. Recommended Practice for Software Requirements Specifications, 1998.

  • O Item III representa o requisitos não-funcionais do sistema: Confiabilidade, usabilidade e portabilidade. Eles são alcançados através da definição de uma arquitetura de software que considerem esses requisitos. Requisitos funcionais estão ligados ao que o sistema deverá realizar, que atividades e serviços o sistema deverá fornecer.

    Marquei o item B, a príncipio, discordo desse gabarito.
ID
195271
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, a respeito de engenharia de requisitos.

Para o desenvolvimento de casos de uso, é fundamental a identificação dos atores, tanto os principais quanto os secundários, já na primeira iteração do levantamento de requisitos.

Alternativas
Comentários

  • Na primeira iteração do levantamento de requisitos, identifica-se primeiramente APENAS os atores principais.

  •  Não há impedimento que outros atores sejam identificados em outras iterações.

  • Eu penso que nada garante que os atores estarão claros ou bem definidos na primeira iteração.
    Pode ser necessário uma compreensão do sistema antes de identificar os atores, o que pode acontecer em iterações posteriores.
  • Atores secundários são aqueles que existem apenas para que os atores primários utilizem o sistema. (Fonte: Princípios de Análise e projeto de Sistemas com UML). Logo, é pouco provável que já na primeira iteração, possa-se identificá-los.
  • Capítulo 7, Engenharia de Requisitos (PRESSMAN), página 130:

    “Como o levantamento de requisitos é uma atividade evolutiva, nem todos os atores são identificados durante a primeira iteração. É possível identificar atores principais durante a primeira iteração, e os atores secundários quando se fica sabendo mais a respeito do sistema. O atores principais interagem para conseguir a função desejada do sistema e derivar o benefício pretendido com o sistema. Eles trabalham direta e frequentemente com o software. Os atores secundários dão suporte ao sistema, de modo que os atores principais possam fazer o seu trabalho."

    Errado. Apenas os atores PRINCIPAIS são identificados na primeira iteração.
ID
195277
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, a respeito de engenharia de requisitos.

Por se tratar de função essencial da engenharia de requisitos, a gestão formal de requisitos é indispensável mesmo para projetos de pequeno porte, com apenas duas ou três dezenas de requisitos identificáveis.

Alternativas
Comentários

  • Questão de Rodapé.

    Pressman 6ed, p121

    Veja link abaixo

    http://screencast.com/t/OWFmNWJhZDct

  • Conforme o livro do Pressman.

    A gestão formal de requisitos é iniciada somente para grandes projetos com centenas de requisitos identificáveis, Para projetos pequenos, essa função de engenharia de requisitos é consideravelmente menos formal.

  • Desculpem, mas pedir nota de rodapé já é demais!
  • Quer o que tb, né? Pra entrar no TCU é isso ae, saber até nota de rodapé!

  • Essa tava na cara que tava errada, não precisava nem saber de requisito.


    Quem vai limitar ou não os requisitos em duas ou três dezenas!?

  • gestão formal de requisitos é algo dispendioso... para sistemas pequenos, a rastreabilidade pode ser informal...

ID
197503
Banca
CESPE / CEBRASPE
Órgão
DETRAN-DF
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca do desenvolvimento de aplicações e da arquitetura OLAP,
julgue os itens a seguir.

Requisitos funcionais são restrições sobre as funções ou serviços oferecidos pelo sistema. Esses requisitos consideram as declarações de serviços, a forma do sistema reagir e como ele deve se comportar em determinadas situações. Cenários e casos de uso são técnicas eficazes para elicitação de requisitos funcionais segundo pontos de vista de interação.

Alternativas
Comentários

  • O que restrigem as funções ou os serviços são os não funcionais, já que os funcionais definem comportamentos do sistema.

  • Complementando o colega, os requisitos de domínio - em certos casos -  podem oferecer restrições, assim como os não funcionais.

     

  • Pessoal,

    A banca misturou os conceitos de requisitos funcionais e não funcionais.Vejam :

    Requisitos NÃO funcionais são restrições sobre as funções ou serviços oferecidos pelo sistema.(SOMMERVILLE,PG 83) Esses requisitos(REQUISITOS FUNCIONAIS) consideram as declarações de serviços, a forma do sistema reagir e como ele deve se comportar em determinadas situações.(SOMMERVILLE,PG 83).
     

    ITEM ERRADO.

     

  • Requisitos funcionais são restrições sobre as funções ou serviços oferecidos pelo sistema. Esses requisitos consideram as declarações de serviços, a forma do sistema reagir e como ele deve se comportar em determinadas situações. Cenários e casos de uso são técnicas eficazes para elicitação de requisitos funcionais segundo pontos de vista de interação.

    Requisitos funcionais
    Requisitos não-funcionais
ID
201352
Banca
CESPE / CEBRASPE
Órgão
Banco da Amazônia
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A validação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a verificação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.

Alternativas
Comentários

  • Questão simples, os conceitos de validação e verificação estão invertidos.

  • A Verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores ou seja se "os produtos atendem os Requisitos".
    enquanto a Validação determina se os requisitos e o produto final, sistema ou produto de software  construído atendem ao (Cliente) uso específico pretendido .
  • A validação Verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a verificação Validação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.
  • Verificação = Processo 
    Validação = Produto Final ( Software )

  • A verificação é o processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles nas atividades anteriores, enquanto a validação determina se os requisitos e o produto final, sistema ou produto de software construído atendem ao uso específico pretendido.

    como o colega colocou, verifica-se processos, o usuario valida o sw.

    1° se verifica, depois se valida

ID
201484
Banca
FCC
Órgão
BAHIAGÁS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

É uma restrição sobre os serviços ou as funções oferecidos pelo sistema. Pode ser uma restrição de timing, sobre o processo de desenvolvimento, sobre o desempenho ou sobre a confiabilidade do sistema, entre outras. Trata-se de

Alternativas
Comentários
  • A afrimação no enunciado da questão é a definição de requisitos não funcionais.
  • Os requisitos não funcionais, como o nome sugere, são aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema. Eles podem estar relacionados a propriedades de sistemas emergentes, como confiabilidade, tempo de resposta e espaço em disco.

    Sommerville, 8a ed., pág 85.
  • Complementando as explicações dos colegas, a imagem abaixo ilustra os tipos de requisitos não-funcionais:

  • Palavra chave do requisito não funcional: restrição

ID
205354
Banca
FEPESE
Órgão
SEFAZ-SC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Considere a seguinte relação de requisitos estabelecida para um software hipotético.

1. O software deverá ser implementado em Java.

2. O software deve interagir com o usuário por meio de um navegador (browser), isto é, deve ser implementado como uma aplicação para Web.

3. O software deve registrar log de todas as operações realizadas.

4. O software deve responder a qualquer solicitação do usuário em, no máximo, 500 milissegundos.

5. O conjunto de produtos gerados deve incluir especificação de projeto em UML.

6. O software deve ser desenvolvido na plataforma Eclipse.

Assinale a alternativa que contém apenas números correspondentes a requisitos classificáveis como não funcionais.

Alternativas
Comentários

  •  

    Os REQUISITOS NÃO FUNCIONAIS estão relacioandos a:

    1. Segurança: Descreve os requisitos associados à integridade dos dados, privacidade, como o sistema trata de informação confidencial, liberação de acesso aos usuários do sistema.


    2. Performance: Descreve o tempo de resposta do sistema durante o uso dos recursos disponibilizados. (Ex: O software deve responder a qualquer solicitação do usuário em, no máximo, 500 milissegundos).


    3. Usabilidade: Descreve os requisitos não-funcionais associados à facilidade de uso do sistema. (Ex: O software deve interagir com o usuário por meio de um navegador (browser), isto é, deve ser implementado como uma aplicação para Web).


    4. Confiabilidade: Descreve os requisitos não funcionais associados à freqüência de falha, e a robustez do sistema na recuperação destas falhas.


    5. Padrões: Descreve quais os padrões e normas a serem seguidas ao desenvolvimento do sistema.


    6. Hardware e Software: Descreve qual o hardware e software que será utilizado pelo sistema. (Ex. O software deverá ser implementado em Java, O software deve ser desenvolvido na plataforma Eclipse).
     

  • Eu considero essa questão errada pois "realizar log de todas as operações" é um requisito de segurança.
  • armazenar um documento de texto com informações sobre operações realizadas é requisito funcional

    Se esse documento vai ser utilizado ou não é outra história. Mesmo que o documento sirva para melhorar a segurança, continua sendo uma funcionalidade do sistema gerar esse documento.
  • Prezados,

    A necessidade de implementação em java é um requisito não funcional
    A necessidade da aplicação ser web é um requisito não funcional
    A necessidade de o software registrar log é um requisito funcional, é uma funcionalidade do sistema
    A necessidade do software responder em tempo determinado é requisito não funcional
    A necessidade dos produtos seguirem UML é um requisito não funcional
    A necessidade do software ser desenvolvido em eclipse é um requisito não funcional.

    Basicamente os requisitos funcionais representam funcionalidades do sistema , enquanto os requisitos não funcionais representam condições que o software ou projeto tem que atender.

    Portanto a alternativa correta é a letra B

ID
205360
Banca
FEPESE
Órgão
SEFAZ-SC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Relacione as características de técnicas de eliciação (elicitação) de requisitos da Coluna 2 com os identificadores corretos de técnicas de eliciação da Coluna 1.

Coluna 1

1. Enfoque antropológico
2. Entrevista estruturada
3. Entrevista tutorial
4. Observação (passiva)
5. Reuso

Coluna 2

( ) Análise de soluções previamente elaboradas.
( ) Diálogo em que o cliente "dá uma aula" sobre o domínio do negócio.
( ) Não inclui diálogo.
( ) Demanda questões previamente elaboradas.
( ) O desenvolvedor exerce o papel do cliente no ambiente de atuação deste.

Assinale a alternativa que indica a sequência correta, de cima para baixo.

Alternativas
Comentários
  • ( ) Não inclui diálogo. 4. Observação (passiva)
    Temos X - X - 4 - X - X.
    Descarta os itens (b), (c)

    ( ) O desenvolvedor exerce o papel do cliente no ambiente de atuação deste. 1. Enfoque antropológico - (ETNOGRAFIA).
    Temos : X - X - 4 - X - 1.
    Descarta os itens (a), (b), (c).

    ( ) Demanda questões previamente elaboradas.  2. Entrevista estruturada
    Temos: X - X - 4 - 2 - 1.
    Descarta os itens (a), (b), (c), (d)

    Resposta: (E)

  • Reuso - Analise  de solucoes pre' elaboradas => So' pode ser reutilizado o que ja foi pre' elaborado como solucao antes
    Entrevista Tutorial - Diálogo em que o cliente "dá uma aula" sobre o domínio do negócio. => Nesse tipo de entrevista nao existem questoes previamente estabelecidas, o elicitador apenas ouve o cliente/ator
    Observacao - Nao inclui dialogo => bem intuitivo, mas apenas completando, siginica dizer que o analista de requisitos apenas observa sem manter nenhum tipo de interacao ou questionamento quanto ao funcionamento do sistema observado
    Entrevista estruturada - Demanda questões previamente elaboradas. => Nesse tipo de entrevista as questoes sao elaboradas anteriormente ao encontro com o entrevistado
    Enfoque antropológico  - O desenvolvedor exerce o papel do cliente no ambiente de atuação deste => Por isso se da' o nome de enfoque antropologico, pois o cerne da analise diz respeito ao cliente e ao papel que o mesmo exerce n oseu ambiente de atuacao.

    Bons estudos
  • Prezados,

    Em se tratando de técnicas de elicitação, temos a seguinte associação :

    Enfoque antropológico : O desenvolvedor exerce o papel de cliente no ambiente de atuação dele
    Entrevista estruturada : Demanda questões previamente elaboradas
    Entrevista tutorial : Diálogo em que o cliente da uma aula sobre o domínio do negócio
    Observação : Não inclui diálogo
    Reuso : Análise de soluções previamente elaboradas

    Portanto a alternativa correta é a letra E

ID
215638
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

Embora a criação de uma sequência ilustrada de telas por meio de programas de desenho gráfico seja útil para a identificação de alguns requisitos do software, ela não é considerada uma atividade de prototipação por não envolver o uso de uma linguagem de programação.

Alternativas
Comentários

  •  A questão encontra-se errada.
    Os comentários aqui realizados são baseados no Livro Engenharia de Software, de Ian Sommerville, 8ª Edição.

    A prototipação (evolucionária ou exploratória) é a única maneira prática de projetar e desenvolver interfaces gráficas (telas) com o usuário para sistemas de software.
    Uma das maneiras de se utilizar um protótipo em um processo de desenvolvimento de software é no processo de engenharia de requisitos, onde o protótipo pode ajudar na descoberta e validação dos requisitos do sistema. Baseado nestes conceitos anteriores, acredito que está correto o trecho da questão evidenciado por "Embora a criação de uma sequência ilustrada de telas por meio de programas de desenho gráfico seja útil para a identificação de alguns requisitos do software".
    Segundo Sommerville, existe a chamada prototipação de papel que é uma abordagem onde não se necessita desenvolver qualquer software executável e os projetos não devem ser elaborados com padrões profissionais. Pode-se desenhar versões em papel das telas do sistema com as quais os usuários interagem e projetar um conjunto de cenários que descrevam como o sistema pode ser usado. Logo, esta abordagem é considerada uma protipação e independe de linguagem de programação, onde eu considero o erro da questão no segundo trecho "ela não é considerada uma atividade de prototipação por não envolver o uso de uma linguagem de programação".

    Espero ter colaborado.

     

  • GABARITO ERRADO!

    .

    .

    Temos até mesmo a prototipação feita em uma folha de papel.

ID
215641
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

O levantamento de requisitos é realizado ao final da primeira versão de um protótipo, para se definir, junto aos envolvidos no processo, quais são as premissas básicas para o início do entendimento das funcionalidades desejadas.

Alternativas
Comentários

  • É feito ao mesmo tempo,  clientes e desenvolvedores ficam em constante interação, podem ocorrer diversas versões de protótipo até se chegar em um entendimento correto do requisito.

  • Questao errada, pois não há como ser feito um protótipo sem ao menos fazer a primeira parte da engenharia de requisitos que é o levantamento dos requisitos. A prototipagem pode ser realizado durante varias fases da eng. de requisitos inclusive na fase de levantamento. Portanto o protótipo é uma técnica de levantamento e identificação de requisitos assim como questionário, entrevista, JAD, etc são. A questão está tratando o protótipo como uma fase da engenharia de requisitos, mas na verdade o protótipo é uma técnica para levantamento de requisitos.

  • Questão totalmente errada. Eu vou fazer o protótipo com base em que? Precisa ser antes da primeira versão.

    Abraços e bons estudos.
  • Questão incorreta. O processo de levantamento de requisitos utiliza protótipos para melhor entendimento e obtenção dos requisitos. No livro "Engenharia de Software" do autor SommerVille, encontramos o seguinte trecho:
    [...]
    A obtenção de requisitos é o processo que reúne informações sobre o sistema proposto e os existentes para obter os requisitos de usuário e de sistema com base nessas informações. As fontes de informações, durante a fase de obtenção de requisitos, incluem documentação, stakeholders de sistema e especificações de sistemas similares. A interação com os stakeholders ocorre por meio de entrevistas e observações, podendo ser usados cenários e protótipos para auxiliar na obtenção dos requisitos.
    [...]

  • Etapas da Engenharia de Requisitos

    • Concepção;
    • Levantamento;
    • Elaboração;
    • Negociação;
    • Especificação;
    • Validação;
    • Gestão de Requisitos.

    Concepção

    Concepção inicial do software. O objetivo desta etapa é entender o problema, quais os envolvidos, a natureza da solução e iniciar o processo de comunicação entre clientes e colaboradores.

    Levantamento

    Perguntar aos envolvidos no projeto:

    • Qual o objetivo do produto?
    • Como o produto se enquadra nas necessidades do negócio?
    • Como o produto será utilizado?

    Entretanto, existem diversos problemas nesse ponto do projeto:

    Problemas de escopo: Não se identifica corretamente os limites do que o Software deve ou não fazer, muitas vezes requisitos técnicos desnecessários confundem o entendimento da solução esperada;

    Problemas de entendimento: O cliente não tem dominio suficiente do problema, não conhece o potencial de uma solução computacional, omite informações óbvias, entre outros;

    Problemas de volatividade: Os requisitos mudam ao longo do tempo.

    Elaboração

    Refinamento das informações obtidas na etapa anterior com a inclusão de modelagens de cenários de interação do usuário com o sistema e modelagem das classes envolvidas tanto como a relação entre elas.

    Negociação

    É frequente que após a etapa de elaboração muitos requisitos não estejam de acordo com a disponibilidade de recursos disponíveis ou ainda sejam conflitantes entre si. Nesse ponto os requisitos são avaliados junto ao cliente e podem ser excluídos, combinados ou ainda serem acrescentados novos requisitos.

    Especificação

    A especificação é a apresentação formal dos dados obtidos até o momento podendo incluir gráficos, textos em linguagem natural, modelagem de cenários ou um protótipo. O principal é que a especificação possa guiar o desenvolvimento futuro indicandos os limites do software com as suas possibilidades e limitações.

    Validação

    Nesse ponto, todos os envolvidos (clientes, colaboradores e usuários) avaliam os requisitos em busca de erros de interpretação, ambiguidade e omissões. Pode ser usado um modelo de questões checklist para validar os requisitos.

    Gestão de Requisitos

    A gestão de requisitos é o processo que visa identificar, controlar e rastrear requisitos e modificações nos requisitos ao longo de um projeto. Em projetos de grande porte com centenas de requisitos é essencial um modelo formal, muitas vezes baseado em tabelas que cruzam estes requisitos com os aspectos do sistemas como interface e dependências. Para projetos menores esse processo pode ser feito de forma mais informal.

ID
215644
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

A verificação de requisitos tem por objetivo analisar se os modelos construídos estão de acordo com os requisitos definidos. Por sua vez, a validação de requisitos visa assegurar que as necessidades do cliente estão sendo atendidas por tais requisitos.

Alternativas
Comentários

  • Verificação: ”Estamos construindo certo o produto?"  (de acordo com os requisitos)
    Validação: ”Estamos construindo o produto certo?" (o que o cliente quer)

  • Fonte: Engenharia de Software - Roger s. Pressman (Sexta Edição)
    Página: 289

    13.1.1 Verificação e Validação
    ...
    Verificação: Estamos construindo o produto corretamente?
    Validação: Estamos construindo o produto certo?
    ...
  • A verificação de requisitos tem por objetivo analisar se os modelos construídos estão de acordo com os requisitos definidos.
    Suponha um requisito somarDoisNumeros. Na verificação será inspecionado se dado dois números como parâmetros de entrada, o resultado obtido por este requisito seja efetivamente a soma destes dois números. Desta forma, a pergunta é válida: construimos o software corretamente?

    Por sua vez, a validação de requisitos visa assegurar que as necessidades do cliente estão sendo atendidas por tais requisitos.
    As necessidades do cliente estão diretamente relacionadas com a satisfação/qualidade do software. Utilizando o requisito anterior, como exemplo, ao final do desenvolvimento, o software ao receber dois números como parâmetros de entrada, retorna a subtração dos números! A conta de subtração foi realizada corretamente, mas não era o que o cliente necessitava! Desta forma, a pergunta é válida: construimos o software certo?
  • A questão trata de verificação e validação de requisitos. Não é teste de software. Todos os comentários acima são inválidos.



    Verificação de requisitos: se encarrega de verificar se há inconsistências nos requisitos e a sua completeza. Se encarrega ainda de verificar se o produto descrito na especificação é o que o cliente realmente deseja.

    Validação: parecido com a análise de requisitos. Tem o objetivo de mostrar que os requisitos descritos na especificação realmente definem o produto que o cliente deseja.  Tanto a análise de requisitos quanto a validação dos requisitos verificam problemas com os requisitos, contudo o primeiro verifica problemas com os requisitos sem ainda termos um documentos de requisitos completo, enquanto o segundo trabalha com o documentos de requisitos completo.

    "A verificação de requisitos tem por objetivo analisar se os modelos construídos estão de acordo com os requisitos definidos." =>não entendi o porquê de estar certo.

    "a validação de requisitos visa assegurar que as necessidades do cliente estão sendo atendidas por tais requisitos" => os conceitos que dei acima respondem essa afirmativa como correta.

    Verifiquem bem o enunciado antes de comentarem!!
  • Macete para Validação x Verificação
     
    Verificação é algo mais proximo do código, já a validação, mais próximo às regras de negócio.
    Alternativa: Certa

  • Certo.

    Segundo Sommerville, 6ed:

    Verificação de requisitos:  Os requisitos são verificados, a fim de se descobrir se eles são completos e consistentes e se estão em concordância com o que os stakeholders realmente desejam do sistema. (pag 105);

    A validação de requisitos se ocupa de mostrar que as requisitos realmente definem o sistema que o cliente deseja. Ela tem muito em comum com a análise de requisitos, uma vez que se preocupa em descobrir problemas nos requisitos. Contudo, esses são processos distintos, já que a validação deve se ocupar da elaboração de um esboço completo do documento de requisitos, enquanto a análise envolve trabalhar com requisitos incompletos. (pag 115)

    Na validação ocorrem diferentes tipos de verificação. (pag 116)

    Então não há dúvida de que o item está correto.


ID
215647
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

A especificação de requisitos permite, em determinado momento, revelar o que o sistema irá realizar no que se refere às funcionalidades, sem definir, nesse momento, como as funcionalidades serão implementadas.

Alternativas
Comentários
  • Os requisitos, assim como os casos de uso, definem o que sistema deve fazer sem entrar em detalhes de implementação. Não importa como será feito e sim, o que será feito.
  • Gostaria de acrescentar que às vezes temos a utilização de uma tecnologia como requisito, por exemplo: Java, Oracle, etc.

    RNF: O sistema precisa se comunicar com o banco de dados Oracle que já existe.

    É registrado como um requisito não funcional, e os detalhes ficam para etapa de Análise e Projeto, de Engenharia de Software.
ID
215650
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

Na validação de requisitos - parte integrante da especificação desses requisitos -, é correto o uso de diagramas da UML, tais como diagrama de classes, de casos de uso e de interação.

Alternativas
Comentários

  • Não há como dizer se é correto ou não. Isso é alternativo!

  • nao encontrei referencias sobre o uso de diagrama de classses e de interacao.(sommerville e pressman)
    No capitulo referente a engenharia de requisitos é citado a utilização de casos de uso, sequência e atividades.
  • Acredito que seja falsa. Já pensou os analistas validando requisitos com o cliente usando diagramas de classes? e de interação?
  • Eu optei por FALSA justamente por esse pensamento. 

    VALIDAÇÃO -> CLIENTE 

    Imagina eu conversando com meu cliente com um monte de diagrama na mão.

    Mais depois observando melhor "Diagramas UML" engloba todos os diagramas, o CASO de USO pode ser um bom diagrama para validar os requisitos junto ao cliente.
  • Não é apenas porque não se encontra em livros que está errado, quando se trabalha em um projeto de software, é necessário validar o requisito não apenas negocialmente, mas também se este é possível de se desenvolver e para essa validação podemos utilizar estas ferramentas, questão feita para quem possui experiência na prática, não apenas teórica
  • Eu marquei errado tbm, mais analisando melhor a questão a UML e seus diagramas são apenas uma linguagem para se modelar sendo possivel sua utilização em qualquer parte do processo até mesmo na validação dos requisitos. Concordo com o Felipe.
  • Eu marquei errado porquer diz que a validacao de requisitos é parte integrante da especificacao.

    Aguem pode explicar o motivo de estar correta esta afimacao.
  • Marquei errado pelo mesmo motivo do colega acima.

    No livro do pressman ele separa especificação de validação.  Pag 120 6° edição
  • Uma das técnicas de validação é a Análise de Consistência automatizada, descrita por Sommerville. Se os requisitos são descritos utilizando um modelo de sistema baseado em um modelo estruturado, como o orientado a objetos (UML), ferramentas CASE podem ser usadas para avaliar a consistência desses requisitos. Assim, é correto o uso de diagramas UML na validação. Esse uso é indireto, pois quem analisará a consistência na validação são as ferramentas CASE, contudo baseado nos modelos estruturados (diagramas de classe, casos de uso, sequência...)
  • Conforme explicação acima do amigo Wilson
    Temos:
    Na validação de requisitos - parte integrante da especificação desses requisitos -, é correto o uso de diagramas da UML, tais como diagrama de classes, de casos de uso e de interação.

    Utilização de diagrama UML está correto de acordo com técnicas de validação é a Análise de Consistência automatizada
    Porém, validação de requisitos não é parte da especificação de requisitos.
    São duas fases distintas, portanto está errado.
  • Quando diz parte integrante da especificação de requisitos. A única ideia que me veio é que a validação de requisitos é feita em cima da especificação de requisitos, ou seja, provavelmente com base em documentos formais e informais. Desta forma, a validação é uma reafirmação da especificação , ou seja, parte integrante.

  • Discordo do gabarito. Não por não achar que se deve usar UML para validação. Acho que podemos sim, mas deve-se atentar ao conteúdo dos diagramas. Não daria pra usar os mesmos diagramas do desenvolvimento. Discordo por achar que a validação não é parte da especificação de requisitos. Segundo pressman: Tarefas da eng de requisitos: concepção, levantamento, elaboração, especificação, negociação, validação e gestão.Segundo Sommerville a engenharia de requisitos é composta pelas atividades:  Estudo da viabilidade do sistema.  Elicitação e análise de requisitos.  Especificação de Requisitos.  Validação de requisitos. Ou seja sempre se trata a validação como coisa diferente de especificação.

    Eu entraria com recurso!

  • A literatura (Pressman e Sommerville) recorrem a esses recursos para auxiliar a elicitação de requisitos. Nada impede que a validação use tais recursos! Porém, não encontrei essa afirmação explícita!

  • Falar em sobreposição até vai. Mas ser parte integrante foi demais.

  • Será que teve recurso ganho para alteração do gabarito dessa questão? Um absurdo, são fases distintas.

  • Problema dessa questão não é o UML, e sim, que o Pressman separa especificação de validação.


    E a questão diz que é parte integrante.... Errei o gabarito e a questão errou o conceito.

  • Fiz uma leitura minuciosa no capítulo do Pressman "engenharia de requisitos" e lendo várias vezes a parte de especificação cheguei a conclusão de que a questão está realmente certa. Pressman diz que a especificação pode ser um documento por escrito, um conjunto de modelo gráficos, um modelo formal, um conjunto de cenários de uso, um protótipo ou qualquer combinação de fatores citados. Eu errei a questão por pensar que a especificação era apenas um "detalhamento do documento produzido na fase anterior" com isso acabei errando a questão. Como podem ver especificação não é só documento, isso vai variar em cada projeto. Ele fala em modelo de gráficos deixando em aberto que pode ser tanto aqueles usados para modelar OO (UML) ou para modelar o estruturado (modelo estruturado), por isso que ele diz que vai variar em cada projeto.  

    Pressman diz também que esses artefatos produzidos na especificação são avaliados na fase de "validação", ou seja, a validação de requisitos examina a especificação (que pode ser em alguns casos um conjunto de cenários e pouco mais do que isso, pode ser um documento contendo cenários, modelos e descrições por escrito) para garantir que todos os requisitos de software tenham sido declarados de forma não ambígua, omissões e erros tenham sido detectados e corrigidos e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto.

    Questão muito difícil que obriga uma interpretação muito acima do normal rsrsrssr, é um tipo de questão que tem que ficar armazenada no bloco de notas. 

    Bons estudos.

  • está complicado estudar, questão fugindo do conceito padrão

ID
215653
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de requisitos, julgue o item subsequente.

Os requisitos normativos, geralmente oriundos da análise das regras de negócio a que está submetido um sistema, nunca podem ser considerados requisitos funcionais, por estarem fora do sistema, ou seja, do domínio do negócio.

Alternativas
Comentários
  • Analisando os livros Engenharia de Software, 8 edição(Sommerville) e Engenharia de Software, 6 edição(Pressman), não foram encontradas referências diretas a requisitos normativos.
    No entanto, Sommerville(2010) classifica os requisitos não-funcionais de 3 formas:
    - De produtos: relacionado ao comportamento do produto. Ex.: quanto de memória o produto requer;
    - Organizacionais: derivados de políticas da organização. Ex.: Uso de determinado padrão de processo;
    - Externos: Abrange requisitos derivados de fatores externos, como os requisitos legais(NORMATIVOS), para assegurar q o sistema funcione dentro da lei.
    Portanto, segundo o renomado autor, os requisitos normativos incluem-se na categoria de um requisito não-funcional externo.
    Até aqui tudo bem. Só que a questão afirma q os requisitos normativos “nunca podem ser considerados requisitos funcionais, por estarem fora do domínio do negócio”.
    Como mencionado, apesar de as literaturas não mencionarem diretamente, analisaremos o seguinte requisito de um sistema de call center:
    - O sistema deve emitir um protocolo de atendimento para o cliente.
    A legislação brasileira está obrigando as empresas de atendimento a emitirem um protocolo de atendimento para fiscalização posterior, de necessário.
    Esse eh um requisito funcional. E normativo. Portanto, pode haver requisitos normativos que sejam também funcionais.

    Fonte: http://questoesdeti.wordpress.com/2011/02/19/cespe2010mpu-requisitos-normativos/
  • Segundo Bezerra (2007) os requisitos são categorizados em:
    .  requisitos funcionais,
    .  requisitos não funcionais e
    .  requisitos normativos.

    Os requisitos funcionais representam as necessidades que o sistema deve prover. Por exemplo:
    .  “O sistema deve permitir que o professor lance as notas de um aluno”,
    .  “O sistema deve permitir que o cliente se cadastre para receber emails”,
    .  “O sistema deve permitir que o gerente de vendas visualize o relatório de vendas por região”.

    Os requisitos não funcionais representam características de qualidade que o sistema deve ter e que não estão relacionadas com suas funcionalidades. Alguns tipos de requisitos não funcionais são:

    .  Confiabilidade: tempo médio entre falhas, recuperação de falhas ou número de erros por milhares de linhas de código.
    .  Desempenho: tempo de resposta esperado para cada funcionalidade do sistema.
    .  Portabilidade: restrições sobre as plataformas de hardware ou software nas quais o sistema ser implementado e o grau de portabilidade para outras plataformas.
    .  Segurança: limitações sobre segurança do sistema em relação a acessos não autorizados.
    .  Usabilidade: requisitos sobre facilidade de uso, idiomas, acessibilidades especiais, necessidade ou não de treinamento.


    Por fim, os requisitos normativos representam restrições impostas sobre o desenvolvimento do sistema como:
    .  Adequações a custos, prazos, plataforma, aspectos legais, além de regras de negócio e políticas de funcionamento.
  • Segundo o Sommerville, os requisitos normativos são requisitos de Domínio - referem-se ao domínio do sistema.
    Segundo o mesmo autor, requisitos de domínio podem ser funcionais ou não funcionais.
    Para mim, aí está o erro: "...regras de negócio a que está submetido um sistema, nunca podem ser considerados requisitos funcionais, ...".
    Os requisitos normativos podem ser requisitos funcionais.

    Abraços
  • Se é FUNCIONAL faz parte do que o sistema se propoe a fazer.

  • Na realidade a distinção entre diferentes tipos de requisitos não é tão clara como sugerem essas definições simples. Um requisito de usuário relacionado com proteção, tal como uma declaração de limitação de acesso a usuários autorizados, pode parecer um requisito funcional. No entanto, quando desenvolvido em mais detalhes, esse requisito pode gerar outros requisitos, claramente funcionais, como a necessidade de incluir recursos de autenticação de usuário no sistema (Pg 59, Sommerville 9 edição)

  • O termo "nunca" invalida a questão. Requisitos normativos (regulatórios) podem obrigar um sistema a mudar sua funcionalidade para estar de acordo com legislação. Para que ocorra essa adequação, é necessário alterar funcionalidades. Exemplo de órgão regulatório é a ANS.

ID
224017
Banca
UFF
Órgão
UFF
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Na engenharia de requisitos, a etapa em que a equipe de revisão examina a especificação do sistema, procurando erros de conteúdo ou interpretação, áreas em que esclarecimentos podem ser necessários, informação omissa, inconsistências, requisitos conflitantes ou requisitos não realísticos, é conhecida como:

Alternativas
Comentários

  • Considerações:
    O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005):
    Identificação.
    Análise e negociação.
    Especificação e documentação.
    Validação.
    Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos (change management, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos), entre outras).

    Na Validação
    À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.

    A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.
     

  • Pressman
    Validacao de Requisitos   Os produtos de trabalho criados como conseqüência da engenharia de requisitos  (uma especificação dos requisitos do sistema e informações relacionadas)  devem ser validados quanto à qualidade durante o passo de validação de  requisitos. Esta validação examina a especificação para garantir que todos  os requisitos do sistema foram estruturados de maneira não ambígua, que as  inconsistências, omissões e erros foram apagados e corrigidos, e que os  produtos de trabalho estão em conformidade com os padrões estabelecidos  para o processo, para o projeto e para o produto.   O mecanismo primário de validação de requisitos é a revisão técnica formal.  O time de revisão inclui os engenheiros de sistema, clientes, usuários e  outros stakeholders que examinam a especificação do sistema à procura de  erros de conteúdo ou interpretação, pontos onde pode ser necessário  esclarecimento, perda de informações, inconsistências (um dos maiores  problemas da engenharia de grandes produtos), requisitos conflitantes,  ou requisitos irreais (de desenvolvimento impossível).
  • Pressman e Sommerville tem tarefas diferentes da Engenharia de Requisitos. O enunciado está mostrando a tarefa de validação de requisitos de acordo com o Pressman. A definção foi muito bem demonstrada pelo colega Luciano. As outras tarefas da Engenharia de requisitos de acordo com Pressman são: concepção, levantamento, elaboração, negociação, especificação, validação e gestão.

  •  e) validação de requisitos é para identificar falhas nos req. as verificações sao: validade, consistencia, completeza, realismo & facilidade de verificação. As tecnicas sao: revisao de req, prototipação & geração de casos de teste;

     

ID
230932
Banca
FUNCAB
Órgão
PRODAM-AM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Os documentos de definição e especificação de requisitos descrevem as formas de interação do sistema com o meio ambiente que o cerca.

As alternativas a seguir tratam dos aspectos da segurança de um sistema que devem ser levantados e documentados, EXCETO:

Alternativas
Comentários
  • O tempo médio entre falhas (MTBF) é uma métrica de confiabilidade. Não de segurança.
ID
233017
Banca
FUNIVERSA
Órgão
CEB-DISTRIBUIÇÃO S/A
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Análise de requisitos é uma importante fase da engenharia de software, na qual os desenvolvedores do sistema identificam as necessidades do cliente para posteriormente projetarem uma solução. Assinale a alternativa que apresenta as principais atividades da fase de análise de requisitos, dentro do processo de desenvolvimento de sistemas.

Alternativas
Comentários
  • Geralmente, as atividades envolvidas no processo de requisitos são:

    Elicitação/Levantamento de Requisitos
    A descoberta dos requisitos Inclui técnicas como Observação, Entrevistas, Análise de Protocolo, Sessões JAD, PD, CRC, FAST, Prototipação e Cenários.


    Análise de Requisitos
    Podem possivelmente utilizar as metodologias de:
    Análise Estruturada, Análise Essencial ou Análise Orientada a Objetos.
    As principais ferramentas para a modelagem essencial:  Diagrama de Fluxo de Dados, Diagrama de Entidade-Relacionamento, Diagrama de Transição de Estado.

    Documentação de Requisitos


    Verificação e Validação de Requisitos

    Gerenciamento de Requisitos
    Onde os requisitos são gerenciados e rastreados. Uma ferramenta utilizada é a matriz de rastreabilidade.
  • O problema é que a Universa usou Análise de Requisitos como sinônimo para Engenharia de Requisitos.
    A análise é uma etapa da engenharia.

    Mas as outras alternativas são tão incoerentes que não tem como errar.
  • Nossa colega Josiane tem razão. Segue um esquema tirado do Sommerville (não sei página, pois estou sem o livro):
ID
239743
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de requisitos, julgue os itens a seguir.

Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.

Alternativas
Comentários

  • As técnicas não funcionais verificam a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a tolerância e a robustez do software em lidar com o inesperado.

    ... também, declarações de serviços que o sistema deve fornecer ... ?

  • Requisitos não funcionais definem as propriedades e restrições do sistema.  São requisitos mensuráveis. A questão está errada quando diz que requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema. As funções oferecidas pelo sistema são requisitos funcionais.


  • NÃO FUNCIONAIS: Restrições sobre os serviços ou as funções oferecidas pelo sistema.

    FUNCIONAIS: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.
  • ERRADO.
    A questão descreveu foi os REQUISITOS FUNCIONAIS.

    {}s
    Marcelo
    Bons estudos
  • Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.
  • Sinceramente, para que este comentário do indivíduo ai de cima (Douglas)?  Repetir a questão que está errada???
  • Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema (Define requisitos funcionais), e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações.
  • Na verdade o item misturou conceitos de requisitos funcionais e não funcionais, vejamos:

    "Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema ..."- 1ª parte correta, trata-se de requisitos não funcionais.

    "...e podem ser, também, declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações." 2ª parte errada, trata-se de requisitos funcionais.

    Sommerville, 9ª Edição - página 59.
    Abraços, vamo que vamo.

  • A questão fez uma mistura de funcionais e não funcionais, mas foi um pouco difícil cravar que estava a errada.

    Suponha que tenho um requisito não funcional que diga que ele deve operar via webservice SOAP.

    Neste caso isso não implicaria que em alguns serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve comportar-se em diversas situações?

     

     

  • Prezados,

    Relembrando para não esquecer :
    Requisitos funcionais são funções ou comportamentos que o software deve ter.
    Requisitos não funcionais são requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança , etc.

    O comando da questão afirma que declarações de serviços que o sistema deve oferecer, como o sistema deve reagir a entradas especificas , isso tudo é requisito funcional .

    Portanto a questão está errada.

  • Misturou os bichos!

ID
239746
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de requisitos, julgue os itens a seguir.

Em sistemas de grande porte, um único requisito pode ser implementado por diversos componentes; cada componente, por sua vez, pode incluir elementos de vários requisitos, o que facilita o seu reúso, pois os componentes implementam, normalmente, uma única abstração do sistema.

Alternativas
Comentários

  • "cada componente, por sua vez, pode incluir elementos de vários requisitos, o que facilita o seu reúso..."

    Se eu não estiver enganado, acho que é aqui que está o erro.

    Com cada componente tendo elementos de vários requisitos, como você pode facilitar o reúso?

  • Você está correto. Em programação um componente (ou classe, ou módulo) precisa ser altamente coeso. Isso significa, fazer uma coisa apenas.

    Se ele incluir elementos de vários requisitos, ele se tornará pouco coeso reduzindo sua reusabilidade.

  • Em sistemas de grande porte, um único requisito pode ser implementado por diversos componentes; cada componente, por sua vez, pode incluir elementos de vários requisitos implementa apenas um requisito, o que facilita o seu reúso, pois os componentes implementam, normalmente, uma única abstração do sistema.
  • Um único requisito pode ser implementado por uma série de componentes e cada componente pode incluir elementos de vários requisitos.
    Isso significa que a implementação de uma mudança de requisito pode envolver a mudança de muitos componentes! O que, evidentemente, dificulta o reuso.
  • Questão muito boa!

    Vamos primeiro definir o que é um requisito em termos gerais: uma funcionalidade do sistema. Como um exemplo, podemos ter o caso de uso (uma funcionalidade) CriarConta, que descreve a criação de uma conta corrente em um banco qualquer. O que acontece se eu pegar os métodos desse caso de uso e espalhar por vários componentes? Irá acontecer que, como esses métodos estão relacionados, quando um deles for chamado, este irá executar a sua função e, depois, irá chamar o outro método que se encontra em outro componente. Esse segundo método irá executar e, depois, chamará o terceiro. Isso é chamado de alto acoplamento. Muito ruim para reúso.

    Que nem já comentaram: os componentes também devem ser coesos, ou seja, realizarem apenas uma coisa.

  • Achei estranha essa questão. Como não fecha, entendi como requisito tanto os funcionais quanto os não funcionais. Quanto aos funcionais, realmente a questão está incorreta. Porém, os requisitos não funcionais podem sim ser implementado em diversos componentes, o que facilita o reuso.

  • Prezados,

    Um componente que atende vários requisitos está mal projetado , por falha de coesão. Isso impacta o reuso do mesmo.

    Portanto a questão está errada.
ID
239749
Banca
CESPE / CEBRASPE
Órgão
ABIN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação à engenharia de requisitos, julgue os itens a seguir.

Se os requisitos forem organizados de acordo com os diversos pontos de vista relativos a grupos de usuários do sistema, é possível identificar aqueles comuns a todos ou à maioria dos pontos de vista. Esses requisitos comuns podem estar relacionados a assuntos separados, implementados como extensões da funcionalidade central.

Alternativas
Comentários

  • Os requisitos comuns farão parte da funcionalidade central.

    Os requisitos não comuns poderão ser extensões da funcionalidade central.

    A questão está errada pois diz que "requisitos comuns (...) implementados como extensões da funcionalidade central"

  • Galerinha. O que estaria correto aí seria a troca dos termos "extensões" para inclusões. Pois se trata de pontos COMUNS, requisitos comuns é significado de INCLUSÃO e não EXTENSÃO.

    Abraços e bons estudos.
  • Alguém poderia citar a bibliografia....?
  • Leandro,

    A questão trata do método VORD  (viewpoint oriented requirements definition) - método de levantamento de requisitos orientado a pontos de vista.
  • "Uma abordagem orientada a pontos de vista para engenheiros de requisitos, em que cada ponto de vista representa os requisitos de grupos relacionados de stakeholders, é uma maneira de separar interesses principais de secundários. Se você organizar os requisitos de acordo com os pontos de vista de stakeholders, poderá analisá-los para desecobrir requisitos relacionados que aparecem em todos ou na maioria dos requisitos. Eles representam a funcionalidade central do sistema. Outros requisitos de ponto de vista podem ser requisitos que são específicos para esse ponto de vista e podem ser implementados como extensões da funcionalidade central."

    Sommerville - 9 ed - pg 404

  • De acordo com Sommerville: “Diferentes fontes de requisitos (stakeholders, domínio, sistemas) podem ser representadas como pontos de vista do sistema, com cada ponto de vista mostrando um subconjunto de requisitos para o sistema. Pontos de vista diferentes sobre um problema percebem o problema de maneiras diferentes. No entanto, suas perspectivas não são completamente independentes; em geral, elas se sobrepõe e, dessa forma, apresenta, requisitos comuns. Você pode usar esses pontos de vista para estruturar a descoberta e a documentação dos requisitos do sistema” (Pg. 72, Sommerville 9 edição)

    Sendo assim, o erro na questão está na palavra “extensão”. Requisitos comuns significam inclusões da funcionalidade central e não extensões da funcionalidade central

  • Prezados,

    Essa questão foi extraída do sommerville , que explica essa análise baseada em ponto de vista, entretanto o examinador adicionou um erro no comando da questão.

    Segundo o autor, na abordagem orientada a pontos de vista, a funcionalidade central do sistema será a funcionalidade onde os requisitos aparecem em todos os ou na maioria dos pontos de vistas dos stakeholder. Algum stakeholder pode ter um ponto de vista especifico, algo que só ele deseja , então esse requisito deve ser implementado como extensão da funcionalidade central, e não os requisitos comuns a todos ou a maioria dos pontos de vista.

    Portanto a questão está errada.

ID
240784
Banca
FCC
Órgão
TRT - 8ª Região (PA e AP)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Considere um sistema de controle de estoque com
cadastramento de materiais e movimentação do estoque.
São necessários os seguintes cálculos automáticos: controlar
o saldo, o ponto de reposição e o lote econômico. O
cadastro de materiais é feito pelo almoxarife (responsável)
e as requisições são feitas por todos os departamentos
da empresa e ficam guardadas. A cada entrega
de material, o almoxarife dá baixa na requisição (atendida)
e, com isso, o sistema faz todos os cálculos acima.
A entrada de materiais também é feita pelo almoxarife,
quando os cálculos também são realizados. Os dados
calculados devem ficar guardados também e o tempo de
resposta de consultas feitas no cadastro de materiais não
deve exceder a 5 milissegundos (ms).

É considerado um requisito NÃO funcional

Alternativas
Comentários
  • O requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. São o cérebro do projeto, já que descrevem as funcionalidades que o sistema deve dispor.

    Os requisitos não funcionais são aqueles que expressam como deve ser feito (não confundir requisitos não funcionais com design). Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc. São muito importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a fazer ou não. Um sistema ineficiente certamente não será usado. Neles também são apresentados restrições e especificações de uso para os requisitos funcionais.

    Resposta: B
    Justificativa: O tempo de resposta máximo do sistema trata de como deve ser feito o processamento, ou seja, um quesito da qualidade do sistema e não o comportamento do sistema (o tempo de resposta não faz parte do sistema, como as outras alternativas da questão).
ID
246913
Banca
COVEST-COPSET
Órgão
UFPE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A técnica que busca o consenso entre um grupo de especialistas através de rodadas de respostas anônimas a questionários e que ajuda a reduzir a parcialidade nos dados e evita que alguém possa indevidamente influenciar o resultado é chamada de:

Alternativas
Comentários
  • A resposta é Delphi.

    Método de planejamento em que situações de carência de dados históricos ou nas quais pretende-se estimular a criação de novas idéias. O Delphi se mostra muito útil quando se quer realizar uma análise quantitativa do mercado, permitindo que se projetem tendências futuras em face de descontinuidades tecnológicas e mudanças sócio-econômicas.

    Em linhas gerais, o Delphi consulta um grupo de especialistas a respeito de eventos futuros através de um questionário, que é repassado continuadas vezes até que seja obtida uma convergência das respostas, um consenso, que representa uma consolidação do julgamento intuitivo do grupo. Pressupõe-se que o julgamento, ao ser bem organizado, é melhor do que a opinião de um só individuo.
  • O método Delphi é um método sistemático e interativo de estimativa que se baseia na experiência independente de vários especialistas. Os especialistas são cuidadosamente selecionados pela sua experiência e respondem a um questionário em um ou mais ciclos. Após cada ciclo, um facilitador provê um sumário anônimo das estimativas de cada especialista no ciclo, bem como as razões sobre as quais cada um baseou sua estimativa. Os especialistas são então encorajados a revisar suas estimativas anteriores com base nas opiniões dos demais participantes. Busca-se durante este processo que ocorra uma convergência das estimativas para o que seja a “resposta”correta. Finalmente, o processo é encerrado com base em um critério predefinido de finalização (ou seja, um número de ciclos ou de atingimento do consenso, ou estabilidade de resultados) quando a média ou mediana do ciclo final estabelece o resultado final.
  • Brainstorming - O brainstorming (literalmente: "tempestade cerebral" em inglês) ou tempestade de ideias, mais que uma técnica de dinâmica de grupo, é uma actividade desenvolvida para explorar a potencialidade criativa de um indivíduo ou de um grupo - criatividade em equipe - colocando-a a serviço de objetivos pré-determinados. Utilizado na Elicitação de Requisitos.

    Mapa mental, ou mapa da mente - nome dado para um tipo de diagrama, sistematizado pelo inglês Tony Buzan, voltado para a gestão de informações, de conhecimento e de capital intelectual; para a compreensão e solução de problemas; na memorização e aprendizado; na criação de manuais, livros e palestras; como ferramenta de brainstorming (tempestade de ideias); e no auxílio da gestão estratégica de uma empresa ou negócio. Os desenhos feitos em um mapa mental partem de um único centro, a partir do qual são irradiadas as informações relacionadas. Podem ser elaborados por meio de canetas coloridas sobre folhas de papel ou um programa de computador dedicado.

    Diagrama de Afinidade - usa a afinidade entre dados verbais, parciais e itens fragmentados (retalhos), para que de uma sistemática, ajudar a entender a estrutura de um problema amplo, abrangente. O diagrama de afinidade utiliza um processo de brainstorm, ou seja, de livre debate em que os participantes dão sugestões para auxiliar o grupo a coletar e organizar grande quantidades de contribuições criativas (idéias, fatos, opiniões) com relação a um problema de processo ou produto.

    A Técnica de Grupo Nominal (T.G.N.) ou método de Delbecq, em homenagem a quem o divulgou, é um processo que recorrendo a um grupo de peritos permite seleccionar, fazer julgamentos e fomentar a criatividade de sugestões para a resolução de um problema complexo.

    Objetivos

    1. Identificar as sugestões para resolução de um dado problema, nomeadamente quando este é complexo e envolve vários aspectos;
    2. Ordenar as sugestões apresentadas de acordo com as prioridades estabelecidas;
    3. Desenvolver a capacidade de criar ideias e de decidir sobre a sua prioridade em relação à reso1uçao de um problema.
ID
249481
Banca
CESPE / CEBRASPE
Órgão
DETRAN-ES
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens de 81 a 94, acerca de princípios, métodos, técnicas
e processos da engenharia de software e de bancos de dados.

A técnica de brainstorm é adequada para a produção de especificações de requisitos para um sistema de informação em desenvolvimento.

Alternativas
Comentários
  • Brainstorm é adequado para o levantamento de requisitos, não especificação.

    Outras técnicas quentes para isso:

    * Sessões JAD
    * Entrevistas ( que podem ser estruturadas ou não estruturadas )
    * Etnografia - Análise do ambiente de trabalho do usuário
    * Questionário
  • Usa-se brainstorm como etapa preliminar para o desenvolvimento, não quando é necessário elicitá-lo.
  • Brainstorming - Uma técnica usada para gerar e coletar múltiplas idéias relacionadas aos requisitos do projeto e do produto.

    Fonte: PMBOK 4a. edição
  • produção de especificações de requisitos deu a entender que era produção de requisitos, descobrir requisitos.

    Especificações de requisitos, como sendo os próprios requisitos, e não a fase Especificação de requisitos.

    pegadinha sacana..
  • Brainstorm é uma técnica para levantamento de requisitos e não especificação.

    A Técnica de elicidação de Requisitos -Brainstorn- consiste na geração de ideias, que permite a realização de UMA ou VÁRIAS reuniões, para que pessoas sugiram e explorem ideias.

    Suas etapas:
    1) Seleção dos Participantes
    2) Explicação das técnicas e regras a serem seguidas
    3) Produzir uma boa quantidade de ideias

    Conclusão, usado para levantamento de requisitos.
  • Sacanagem, casca de banana essa questão. Como já foi esclarecido, brainstorm é utilizado na elicitação de requisitos e não na especificação.

ID
249568
Banca
CESPE / CEBRASPE
Órgão
DETRAN-ES
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A complexidade das grandes organizações gera demandas relativas
à formalização e controle organizacionais, muito estudadas no
âmbito da gestão, inclusive de tecnologia da informação. Julgue os
itens seguintes, relativos a formalização e controle organizacionais.

As entrevistas podem ser não estruturadas, semiestruturadas ou estruturadas. Os dois primeiros tipos são recomendados quando o perfil dos entrevistados não é bem conhecido. Entrevistas estruturadas, por sua vez, são, geralmente, embasadas em questionários com questões predefinidas, que podem ser aplicados com maior uniformidade a uma grande quantidade de pessoas.

Alternativas
Comentários
  • A entrevista estruturada ou questionário geralmente é utilizado nos censos como, por 
    exemplo, os do IBGE (Instituto Brasileiro de Geografia e Estatística), nas pesquisas 
    de opinião, nas pesquisas eleitorais, nas pesquisas mercadológicas, pesquisas de 
    audiência, etc. 
    Algumas das principais vantagens de um questionário é que nem sempre  é 
    necessário a presença do pesquisador para  que o informante responda as questões. 
    fonte: http://www.emtese.ufsc.br/3_art5.pdf
     
  • Tipos de Entrevistas

    Podem ser classificadas de acordo com dois aspectos: controle do informante e a uniformidade de estímulos apresentados;
    1.  Não estruturadas;
    2.  Semi-estruturadas;
    3.  Estruturadas.
     
    Nas entrevistas não-estruturadas, o entrevistador segue o informante, mas faz perguntas ocasionais para ajustar o foco ou
    para clarificar aspectos importantes. O pesquisador tem geralmente um guia com os tópicos a serem cobertos na entrevista, mas não tem uma ordem para perguntar sobre estes tópicos;
    Nas entrevistas semi-estruturadas, este guia contém sugestões de perguntas e dicas (prompts) a serem usados pelo pesquisador para garantir que todos os tópicos de interesse serão abordados;
    Nas entrevistas estruturadas, o entrevistador quer ter certeza que ele faz as mesmas perguntas para cada informante. As perguntas estão claramente definidas;
    No questionário, as perguntas e as respostas já estão definidas. Um questionário pode ser respondido face a face ou remotamente;
     
    Fonte:http://www.ufpa.br/cdesouza/teaching/topes/3-interviews.pdf

  • Upgrade no formato visual da resposta, replicando:


    Tipos de Entrevistas

    Podem ser classificadas como: Não estruturadas;  Semi-estruturadas;  Estruturadas.


    Nas entrevistas não-estruturadas, o entrevistador segue o informante, mas faz perguntas ocasionais para ajustar o foco ou para clarificar aspectos importantes. O pesquisador tem geralmente um guia com os tópicos a serem cobertos na entrevista, mas não tem uma ordem para perguntar sobre estes tópicos;


    Nas entrevistas semi-estruturadas, este guia contém sugestões de perguntas e dicas (prompts) a serem usados pelo pesquisador para garantir que todos os tópicos de interesse serão abordados;


    Nas entrevistas estruturadas, o entrevistador quer ter certeza que ele faz as mesmas perguntas para cada informante. As perguntas estão claramente definidas; No questionário, as perguntas e as respostas já estão definidas. Um questionário pode ser respondido face a face ou remotamente;


     
    Fonte:http://www.ufpa.br/cdesouza/teaching/topes/3-interviews.pdf

ID
252046
Banca
CESPE / CEBRASPE
Órgão
STM
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os próximos itens, a respeito dos requisitos de um sistema,
que definem o que o sistema deve fazer e as restrições existentes.

São consideradas técnicas de validação de requisitos: revisões de requisitos, prototipação e geração de casos de teste.

Alternativas
Comentários

  • Técnicas de validação


    Revisões dos requisitos
    Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos).
     
    Prototipificação
    (Ou prototipação) A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).
     
    Geração de casos de teste
    Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.
     
    Análise de consistência automática
    Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.

  • Item correto.

    Técnicas de Validação de Requisitos.

    • Revisões de Requisitos: análise sistemática e manual dos requisitos.

    Um grupo de revisores é alocado para examinar a especificação dos requisitos do software: verificando que esse documento satisfaz os critérios de qualidade desejados; procurando por: erros no conteúdo ou de interpretação; hipóteses confusas ou equivocadas; falta de clareza na descrição dos requisitos; desvios em relação aos padrões estabelecidos no processo ou projeto; falta de alguma informação; inconsistências entre requisitos; requisitos não alcançáveis. 

    • Prototipação: utilização de um modelo do sistema para validar seus requisitos.

    Meio de validar a interpretação do analista de requisitos sobre os requisitos do software.
    Vantagem: as hipóteses e interpretações do analista de requisitos sobre os requisitos do software são mais facilmente visualizadas, permitindo identificar onde ele está enganado, se for o caso. Desvantagem: perigo da atenção do usuário desviar-se das funcionalidades do sistema para questões cosméticas ou problemas de qualidade do protótipo.

    • Validação do Modelo de Análise: validação dos modelos produzidos durante a Análise de Requisitos.

    A qualidade dos modelos desenvolvidos durante a Análise de Requisitos normalmente também é validada. Se notações formais foram utilizadas para especificar os requisitos do software é possível utilizar procedimentos automatizados para provar algumas características do modelo de análise.

    • Geração de Testes de Aceitação: desenvolvimento de testes para os requisitos. 

    Propriedade essencial de todo requisito de software: deve ser possível validar que o produto final o satisfaz. Essa técnica consiste em desenhar testes de aceitação que serão utilizados para verificar a conformidade do produto final com cada requisito de software. Requisitos que não podem ser validados por meio de testes de aceitação não são requisitos. 

    Bibliografia

    PRESSMAN, Roger S. Engenharia de Software. 5ª ed., Rio de Janeiro: McGraw Hill, 2002, capítulos 10 e 11.

    IEEE. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004,capítulo 2.

  • correto 

    revisões de requisitos - quando ambos os revisam. pode ser informal (conversa com stakeholders) & formal (quando ha explicações de implicações de req)

    prototipação - cliente experimenta

    geração de casos de teste - os requisitos sao testados. 

ID
252049
Banca
CESPE / CEBRASPE
Órgão
STM
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os próximos itens, a respeito dos requisitos de um sistema,
que definem o que o sistema deve fazer e as restrições existentes.

Requisitos não funcionais são declarações dos serviços a serem fornecidos pelo sistema, enquanto requisitos funcionais restringem tanto o sistema quanto o processo de desenvolvimento que deve ser usado. Os requisitos funcionais podem ser de produto, organizacionais ou externos.

Alternativas
Comentários
  • Requisitos funcionais são as declarações dos serviços que um sistema vai oferecer, como por exemplo, validar usuários, executar a simulação, editar variáveis etc. Já os requisitos não funcionais tem maior relação com a qualidade do software podendo restringir o desempenho, o tamanho do software, escalabilidade, usabilidade etc.
    Já a segunda setença está correta.
  • Retificando o colega,

    Os requisitos NÃO funcionais podem ser de produto, organizacionais ou externos.
  • A classificação usada na questão refere-se àquela proposta por Somerville. Para complementar o colega, cito uma referência acerca da classificação dos requisitos não funcionais:
    1)Página 82 do livro "Engenharia de software 8 edição - Somerville"
    2)http://pt.scribd.com/doc/2210932/Requisitos-Nao-Funcionais
         OBS: requisitos de processo == requisitos organizacionais
      
  • Requisitos não funcionais
    São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema.
    Segundo Thayer (1990)  em engenharia de sistemas de software, um requisito não funcional de software é aquele que descreve não o que o sistema fará, mas COMO ele fará.
    Requisitos não funcionais são aqueles que não estão diretamente relacionados à funcionalidade de um sistema.

    Requisitos funcionais
    São requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar.
    Thayer (1990)  corrobora a definição anterior, ao especificar que requisitos funcionais é um requisito de sistema de software que especifica uma função que o sistema ou componente deve ser capas de realizar. Estes são requisitos de software que definem o comportamente do sistema, ou seja, o processo ou transformação que componentes de software ou hardware efetuam sobre as entradas para gerar as sídas. Esses requisitos capturam as funcionalidades sob o ponto de vista do usuário.
  • Requisitos não funcionais são declarações dos serviços a serem fornecidos pelo sistema, enquanto requisitos não funcionais restringem tanto o sistema quanto o processo de desenvolvimento que deve ser usado. Os requisitos não funcionais podem ser de produto, organizacionais ou externos.
ID
252052
Banca
CESPE / CEBRASPE
Órgão
STM
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os próximos itens, a respeito dos requisitos de um sistema,
que definem o que o sistema deve fazer e as restrições existentes.

Um processo de elicitação e análise de requisitos envolve as seguintes atividades: obtenção de requisitos, em que são coletados os requisitos e os requisitos de domínio; classificação e organização de requisitos, que agrupa e organiza os requisitos relacionados; priorização e negociação de requisitos, em que, com a participação dos stakeholders, são resolvidos os conflitos de requisitos; e documentação de requisitos, para a produção dos documentos de requisitos formais ou informais.

Alternativas
Comentários
  • A elicitação/levantamento de requisitos corresponde a identificar junto aos stakeholders quais são os objetivos do sistema ou produto de software, o que deve ser acompanhado, como o sistema ou produto se 'encaixa' no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia.
    Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade:
    • Problemas de escopo: os limites do sistema são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários;
    • Problemas de compreensão: os clientes/usuários geralmente não estão completamente certos das necessidades, têm uma compreensão pobre das capacidades e limitações de seu ambiente computacional ou do domínio do seu negócio, omitem informações que julgam óbvias e etc.
    • Problemas de volatilidade: os requisitos mudam o tempo todo.
    Para auxiliar a superar estes problemas, os engenheiros de sistema devem abordar os requisitos de maneira organizada. Alguns passos são sugeridos para elicitação de requisitos:
    •     Avaliar a viabilidade técnica e de negócio para o sistema proposto;
    •     Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais;
    •     Definir o ambiente técnico no qual o sistema será instalado;
    •     Identificar regras de domínio que limitam a funcionalidade ou desempenho do sistema ou produto que será construído;
    •     Definir um ou mais métodos de elicitação de requisitos;
    •     Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista;
    •     Identificar claramente a justificativa de existência para cada requisito registrado; Identificar requisitos ambíguos que serão candidatos a prototipação.

  • O que seriam requisitos informais?

  • Também fiquei na dúvida em relação a esses requisitos informais.


  • As atividades do processo de engenharia de requisitos são:


    1. Descoberto de requisitos. Essa é a atividade de interação com os stakeholders do sistema para descobrir seus requisitos. Os requisitos de domínio dos stakeholders e da documentação também são descobertos durante essa atividade. Existem várias técnicas complementares que podem ser usadas para descoberta de requisitos, que discuto mais adiante.


    2. Classificação e organizaçao de requisitos. Essa atividade toma a coleção de requisitos não estruturados, agrupa requisitos relacionados e os organiza em grupos coerentes. A forma mais comum de agrupar os requisitos é o uso de um modelo de arquitetura do sistema para identificar subsistemas e associar requisitos a cada subsistema. Na prática, a engenharia de requisitos e projeto da arquitetura não podem ser atividades completamente separadas.

     

    3. Priorizaçao e negociação de requisitos. Inevitavelmente, quando os vários stakeholders estão envolvidos, os re­quisitos entram em conflito. Essa atividade está relacionada com a priorização de requisitos e em encontrar eresolver os conflitos por meio da negociação de requisitos. Normalmente, os stakeholders precisam se encon­trar para resolver as diferenças e chegar a um acordo sobre os requisitos.


    4. Especificação de requisitos. Os requisitos são documentados e inseridos no próximo ciclo da espiral. Documen­tos formais ou informais de requisitos podem ser produzidos, como discutido na Seção 4.3.

     

    Na seção 4.3, Sommerville diz:

     

    Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais de modo que sejam compreensíveis para os usuários do sistema que não tenham conhecimentos técnicos deta­lhados. Idealmente, eles devem especificar somente o comportamento externo do sistema. O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema. Consequentemente, se você está escrevendo requisitos de usuário, não deve usar o jargão de software, notações estruturadas ou notações formais; você deve escrever os requisitos de usuário em linguagem natural, com tabelas simples, formas e diagramas intuitivos.

    Fonte: Sommerville, 9ª Edição, Capítulo 2.

ID
267814
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de engenharia de software, julgue os itens subsequentes.

Para se chegar ao produto, a primeira ação que se deve fazer é definir o escopo do projeto. Para tal, é necessário realizar um levantamento inicial de requisitos, decompondo-se o problema segundo a abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em submódulos ou funções, até que se obtenha uma visão geral das funcionalidades a serem tratadas no projeto.

Alternativas
Comentários
  • Correto

  • Essas questões sem contexto são muito difíceis de responder. Qualquer pessoa que tenha estudado o assunto mais a fundo ou tenha experiência prática sabe que essa assertiva não é verdade para todos os casos. Por exemplo, em prototipação não é necessário nem definir o escopo do projeto, já que os requisitos e as necessidades de desenvolvimento vão surgindo no decorrer do processo. 

  • Realmente... Esses "deve" deixam a questão, no mínimo, confusa. Na prova, não arriscaria respondê-la. 

  • No que se refere ao produto, a primeira coisa a se fazer é definir o escopo do projeto. Para tal, é necessário fazer um levantamento de requisitos inicial. A idéia é decompor o problema, em uma abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em sub-módulos ou funções, até que se tenha uma visão geral das funcionalidades a serem tratadas no projeto. 

     

    FALBO, R. Engenharia de Software. 2005. 99 f. Notas de Aula (Disciplina de Engenharia de Software) – Universidade Federal do Espírito Santo, Espírito Santo, 2005

ID
273427
Banca
CESPE / CEBRASPE
Órgão
FUB
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Requisitos de sistema são descrições dos serviços fornecidos pelo
sistema e as suas restrições operacionais. Engenharia de requisitos
é o processo de descobrir, analisar, documentar e verificar esses
serviços e restrições. Acerca desse assunto, julgue os itens que se
seguem.

A etnografia, uma técnica de levantamento de requisitos, é uma abordagem completa para elicitação, utilizada para compreender os requisitos sociais e organizacionais e que identifica novas características a serem acrescentadas em um sistema.

Alternativas
Comentários
  • Etnografia é uma das abordagem para elicitação de requisitos: brainstorm, pontos de vista, entrevista, cenários, casos de uso, jad entre outros.

  • acho que o erro está em "identifica novas características"


    O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.

    Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

    1.      Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo dizem como elas deveriam trabalhar;

    2.      Os requisitos derivados da cooperação e conscientização das atividades de outras pessoas.

    http://www.devmedia.com.br/articles/viewcomp.asp?comp=9151


     

  • Ajudam a descobrir requisitos implicitos ao processo de uma tarefa rotineira de um usuário.
    Então não é uma abordagem COMPLETA e sim apenas para levantar requisitos implicitos (detalhes  que o cliente não consegue levantar) no sistema.
  • A etnografia, uma técnica de levantamento de requisitos, é uma abordagem completa complementar para elicitação, utilizada para compreender os requisitos sociais e organizacionais e que identifica novas características a serem acrescentadas em um sistema.
  • Sommerville:  "A etnografia não é, portanto, uma abortdagem completa para elicitação..." pag 105 Engª de Software 8ª Edição!
  • "Os estudos de etnografia podem revelar detalhes importantes do processo frequentemente ignorados por outras técnicas de elicitação de requisitos. No entanto, devido a seu foco no usuário final, essa abordagem não é apropriada para obter os requisitos organizacionais ou de domínio. Os estudos etnográficos nem sempre podem identificar novas características a serem adicionadas a um sistema. A etnografia não é, portanto, uma abordagem completa para elicitação e deve ser usada para complementar outras abordagens, como análise de casos de uso."

    Fonte:  Sommerville, Engenharia de Software 8ª edição
  • ETNOGRAFIA - É uma técnica de observação, onde o Analista se insere no ambiente de trabalho em que o sistema será utilizado. A técnica ajuda a descobrir requisitos de sistemas implícitos, que refletem os processos reais.
    Uma das desvantagens da técnica é consumir bastante tempo e muitas vezes induzindo o analista a erros em suas observações, por ser uma tecnica de observação, não pode ser considerada como uma abordagem completa.

    • De acordo com Sommerville

      • Os sistemas de software não existem isoladamente. Eles são usados em um contexto social e organizacional. Requisitos de software podem ser derivados ou restringidos desse contexto

      • Uma razão pelo qual muitos sistemas entregues nunca são usados é que seus requisitos não levam devidamente em conta a forma como o contexto social e organizacional afeta o funcionamento prático do sistema

      • Etnografia é uma técnica de observação que pode ser usada para compreender os processos operacionais e ajudar a extrair os requisitos de apoio para esses processos

      • A etnografia ajuda a descobrir os requisitos implícitos do sistema que refletem as formas reais com que as pessoas trabalham, em vez de refletir processos formais definidos pela organização

      • A etnografia é eficaz para descobrir dois tipos de requisitos:

        • Requisitos derivados da maneira como as pessoas realmente trabalham e não da forma como a definição dos processos dizem que elas deveriam trabalhar

        • Requisitos derivados da cooperação e do conhecimento das atividades de outras pessoas

      • A etnografia pode ser combinada com a prototipação. A etnografia informa o desenvolvimento do protótipo para que menos ciclos de refinamento do protótipo sejam necessários.

      • Estudos etnográficos podem revelar detalhes críticos  do processo que muitas vezes  são ignorados por outras técnicas de elicitação de requisitos

      • O foco da etnografia é o usuário final. Sendo assim, essa abordagem nem sempre é apropriada para:

        • Descobrir requisitos organizacionais ou de domínio

        • Identificar novos recursos  a serem adicionados ao sistema

        • A etnografia não é uma abordagem completa para elicitação e deve ser usada para complementar outras abordagens, como análise de caso de uso


  • "Ethnography is not, therefore, a complete approach to elicitation on its own and it should be used to complement other approaches, such as use case analysis."

    Sommerviller

ID
273430
Banca
CESPE / CEBRASPE
Órgão
FUB
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Requisitos de sistema são descrições dos serviços fornecidos pelo
sistema e as suas restrições operacionais. Engenharia de requisitos
é o processo de descobrir, analisar, documentar e verificar esses
serviços e restrições. Acerca desse assunto, julgue os itens que se
seguem.

O estudo de viabilidade, uma atividade inicial do processo de engenharia de requisitos, consiste em um conjunto preliminar de requisitos de negócio, um esboço da descrição do sistema e da forma como o sistema pretende apoiar os processos de negócios.

Alternativas
Comentários
  • A entrada para o estudo de viabilidade é uma descrição geral do sistema e de como ele será utilizado dentro de uma organização.
    Os resultados devem ser um relatório que recomenda se vale a pena ou não realizar o processo de engenharia de requisitos e o processo de desenvolvimento do sistema.
    Deve responder as seguintes perguntas: 
    O sistema contribui para os objetivos gerais da organização?
    O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e de prazo?
    O sistema pode ser integrado com outros sistemas já em operação?

    Prof Marcio Victorino

    www.dominandoti.com.br
  • Para todos os sistemas novos, o processo de engenharia de requisitos de sistema deve começar com um estudo de viabilidade.
    A entrada para o estudo de viabilidade é uma descrição geral do sistema e de como ele será utilizado dentro de uma organização.
    Os resultados do estudo de viabilidade devem ser um relatório que recomenda se vale a pena ou não realizar o processo de engenharia de requisitos e o processo de desenvolvimento de sistemas.

    Retirado de SOMMERVILLE, 8a Ed., pag 117.
  • Em todos os sistemas novos, o processo de engenharia de requisitos deve começar com um estudo de viabilidade.
    A entrada para o estudo de viabilidade consiste de um conjunto preliminar de requisitos de negócios, um esboço da
    descrição do sistema e como o sistema pretende apoiar os processos de negócios.

    Sommerville 8ª edição pág. 97
ID
280882
Banca
INSTITUTO CIDADES
Órgão
AGECOM
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído. De forma geral, a Engenharia de Requisitos de Software é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de forma apropriada para análise, comunicação e posterior implementação. Com relação à engenharia de requisitos de software, analise as seguintes afirmativas:

I. As descrições das funções que um sistema deve incorporar e das restrições que devem ser satisfeitas são os requisitos para o sistema.
II. Requisitos funcionais descrevem restrições sobre as funções oferecidas, tais como restrições de tempo e de uso de recursos.
III. Os requisitos não funcionais apontam as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações.

Podemos afirmar corretamente que:

Alternativas
Comentários

  • c-

    Requisitos representam as entradas do sistema, necessárias para colocar em prática o seu funcionamento. Os requisitos não funcionais sao responsáveis por características como desempenho, usabilidade, suportabilidade, portabilidade, entre outras. Requisitos funcionais e não-funcionais traduzem necessidades e auxiliam codigo do sistema. Os requisitos não-funcionais correspondem às restrições, condições, consistências, validações que devem ser levadas a efeito sobre os requisitos funcionais.

     

    Requisitos nao funcionais tambem identificam regras de negócio: políticas, normas e condições estabelecidas pela empresa a serem seguidas.

ID
283732
Banca
FUNIVERSA
Órgão
IPHAN
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No desenvolvimento de um software, a fase em que se determinam os objetivos e as restrições do sistema, utilizando-se técnicas como entrevistas, questionários, prototipagem, entre outras, chama-se

Alternativas
Comentários
  • Olá, pessoal!

    O gabarito foi atualizado para "C", conforme edital publicado pela banca e postado no site.

    Justificativa da banca:  Houve erro na divulgação do gabarito preliminar.

    Bons estudos!

  • c-

    técnicas de levantamento de requisitos incluem use case diagrams, etnografia, joint application design, prototipos, brainstorming etc

ID
309799
Banca
CESPE / CEBRASPE
Órgão
TJ-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de engenharia de software, métricas, RUP, UML e teste de
software, julgue os itens subsequentes.

Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo.

Alternativas
Comentários
  • Engenharia de Requisitos
    Consiste de um processo que envolve todas as atividades exigidas para criar e manter o documento de requisitos de sistema.

    Tem por objetivo ajudar os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver.
     
    Inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software.
     
    Tarefas:
     
    Concepção: A intenção é estabelecer um entendimento básico do problema
    Levantamento: Ajuda o cliente a definir o que é necessário
    Elaboração: As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas
    Negociação: reconciliar conflitos ocasionados por clientes e usuários
    Especificação: documento escrito
    Validação: avaliados quanto à qualidade.
  • A validação de requisitos se ocupa de mostrar que os requisitos realmente definem o sistema que o cliente deseja.
    Técnicas de validação de requisitos:
    -Revisões de requisitos.
    -Prototipação.
    -Geração de casos de teste.
                              -Análise automatizada de consistência (linguagem formal)
  • Pressman
    Validacao de Requisitos
     
    Os produtos de trabalho criados como conseqüência da engenharia de requisitos 
    (uma especificação dos requisitos do sistema e informações relacionadas) 
    devem ser validados quanto à qualidade durante o passo de validação de 
    requisitos. Esta validação examina a especificação para garantir que todos 
    os requisitos do sistema foram estruturados de maneira não ambígua, que as 
    inconsistências, omissões e erros foram apagados e corrigidos, e que os 
    produtos de trabalho estão em conformidade com os padrões estabelecidos 
    para o processo, para o projeto e para o produto.
     
    O mecanismo primário de validação de requisitos é a revisão técnica formal. 
    O time de revisão inclui os engenheiros de sistema, clientes, usuários e 
    outros stakeholders que examinam a especificação do sistema à procura de 
    erros de conteúdo ou interpretação, pontos onde pode ser necessário 
    esclarecimento, perda de informações, inconsistências (um dos maiores 
    problemas da engenharia de grandes produtos), requisitos conflitantes, 
    ou requisitos irreais (de desenvolvimento impossível).
  • "A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa."

    Marquei errado pq achei que esse trecho era uma uma referência a ESPECIFICAÇÃO de requisitos. O que acham?

  • Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. OK validação 

    Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo. Isso não seria a verificação?!

    Fiquei na dúvida por isso marquei errada a questão!!!

  • Sempre chato isso de ter que ficar pensando se a questão está cobrando mais o lado do Sommerville ou do Pressman. Acho que no Sommerville já teríamos algumas dessas atividades na fase de "elicitação e análise", mas no Pressman é na validação mesmo.

  • Validação do SommerVille: Errado. 

    Validação do Presman: Certo.

    Ou seja, precisa conhecer os dois e ver se um bate na hora da prova....

  • Concordo com Força E Fé: 

    Assim como o software, os requisitos também devem ser avaliados quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de forma clara e precisa. OK validação 

    Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às normas estabelecidas para o projeto, produto e processo. Isso não seria a verificação?!

    Fiquei na dúvida por isso marquei errada a questão!!!

ID
314647
Banca
FCC
Órgão
TRT - 1ª REGIÃO (RJ)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A técnica utilizada na compreensão de requisitos sociais e organizacionais por observação das rotinas dos envolvidos é a

Alternativas
Comentários
  • Etnografia é uma técnica de observação usada para compreender os requisitos sociais e organizacionais de uma sociedade.usadas por cientistas sociais e antropólogos.
    Na engenharia de software é uma técnica na qual o analista se insere no ambiente de trabalho em que o sistema será utilizado para observar o trabalho diário. Com esta técnica consegue-se descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais.
    É útil para a descoberta de dois tipos de requisitos:
     
    1 - Requisitos derivados da maneira como as pessoas realmente trabalham.
    2 - Requisitos derivados da cooperação e conscientização das atividades de outras pessoas.
  • Etnography is an observational technique that can be used to understand operational processess and help derive suport requirements for these processes. An analist imerses himself in the working environment where the system will be used.The day-to-day work is observed and notes made of the actual tasks in which participants are involved.
    SommerVille, 9 ed. p. 108

  • 2015

    Um Técnico participou do levantamento de requisitos de um novo sistema do Tribunal. Devidamente autorizado, ele se inseriu no ambiente de trabalho em que o sistema seria utilizado e observou o trabalho diário, anotando as tarefas reais. Seu principal objetivo era descobrir requisitos de sistema implícitos, que refletissem os processos reais nos quais as pessoas estão envolvidas, ao invés de processos formais. Além destes requisitos, ele também coletou os requisitos derivados da cooperação e conscientização das atividades de outras pessoas envolvidas. O Técnico estava colocando em prática a técnica de levantamento de requisitos denominada.....

ID
315628
Banca
FCC
Órgão
TRE-RN
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considere os requisitos:

I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar.

II. O software deve ser processável tanto em alta quanto em baixa plataforma.

III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos.

Exemplo de requisito não funcional consta APENAS em

Alternativas
Comentários
  •     Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido.
       
    Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.

    fonte: pt.wikipedia.org/wiki/Engenharia_de_requisitos

    3.1.Requisitos Funcionais:

    Estão intimamente ligados às funcionalidades propostas pelo sistema, e que serão usadas na resolução do problema do contratante, e atenderá todas as suas necessidades funcionais. Resumidamente, são os requisitos que objetivamente cumprem as reais necessidades do usuário do sistema.
    Exemplo: Controle financeiro, controle de tráfego aéreo, controle de produção.

    topo

    3.2.Requisitos Não-Funcionais:

    Geralmente ligados à qualidade do produto como, por exemplo, robustez, segurança ou integridade. Dividem-se, assim como a qualidade de produtos, em dois sub-ramos:

    Dependência positiva:


    Quando da presença de um o outro é mais facilmente incorporado.

    Figura 02 – Dependência positiva


    Dependência negativa:

    São conflitantes entre si, a presença ou existência de um compromete o outro ou diminui seu grau de atuação.

    Figura 03 – Dependente negativa.

    Requisitos não-funcionais podem ser classificados como:

    Orientados ao consumidor:

    Observáveis pelos clientes, não necessariamente os contratantes, mas os usuários dos software. Por exemplo: eficiência, amigabilidade, ergonomia.

    Atributos orientados tecnicamente:

    Ligados diretamente ao sistema e que garantem a sua qualidade como tratamento de erros ou anomalias (robustez), processamento em tempo real.

    Duas abordagens podem ser utilizadas na engenharia de requisitos:

    Orientada ao produto:

    Uma abordagem onde o produto a ser produzido é focalizado como principal fonte de elicitação de requisitos não funcionais. Naturalmente a de mais assimilação pelo contratante, já que é feita de acordo com ponto de fácil mensuração por alguém que não tenha experiência técnica.

    Exemplo:
    Deve ser veloz (eficiente), seguro contra erros do usuário (robusto), etc.

    Orientada ao processo

    Abordagem técnica que prioriza o processo de desenvolvimento e não somente o produto, usa a premissa que através de um processo bem estruturado e de qualidade comprovada, o produto final incorpora as qualidades propostas pelo processo de desenvolvimento.
    Exemplo:
    O sistema deve ser feito em Java, deve ser orientado a objetos e deve usar como base de dados MySQL.

    fonte: http://www.inf.ufsc.br/~wesley/engSoft/corpo.htm#reqNFunc

  • II. O software deve ser processável tanto em alta quanto em baixa plataforma.

  • b-

    os requisitos funcionais sao geralmente levantados nos casos de uso. Sao os aspectos que o cliente diretamente deseja. Requisitos nao-funcionais sao o comportamento do sistema, como desempenho, portabilidade, confiança, manutenção etc.