O documento discute a importância da identificação de requisitos funcionais no desenvolvimento de software. Ele explica que requisitos funcionais definem o que o software deve fazer e, se não forem corretamente especificados, podem causar problemas em todas as etapas do projeto. Além disso, apresenta técnicas para coletar requisitos funcionais através de entrevistas, questionários e prototipagem.
1) A análise de requisitos é fundamental para obter um software de alta qualidade e envolve descobrir e refinar os requisitos através da comunicação entre cliente e desenvolvedor.
2) Os principais passos da análise incluem modelar o domínio da informação, desenvolver modelos do sistema, particionar o problema e especificar requisitos funcionais e não funcionais.
3) Uma especificação de requisitos efetiva separa funcionalidade de implementação, modela o sistema e seu ambiente, e é revisada para garantir completude e
Método RON - Requisitos Orientado ao Negócio
Tem por objetivo apresentar método de definição e gerencia de requisitos com base nas atividades de um processo de negócio.
O documento discute os processos de engenharia de requisitos para software, incluindo a definição de requisitos funcionais e não funcionais. Apresenta os tipos de requisitos como requisitos de usuário, sistema e especificação de software. Também discute representações estruturadas de requisitos e linhas guias para elaboração de requisitos.
O documento discute a importância da engenharia de requisitos no desenvolvimento de sistemas e softwares. Apresenta os principais conceitos e atividades da engenharia de requisitos como elicitação, modelagem e validação de requisitos. Também destaca os desafios e erros comuns na especificação de requisitos que levam a problemas e falhas nos projetos.
O documento discute a qualidade de software, definindo-a como a conformidade aos requisitos dos clientes. Apresenta diferentes visões de qualidade de software e discute padrões e normas importantes como ISO 9126 para garantir a qualidade. Também descreve exemplos históricos de bugs caros que ocorreram por falta de qualidade.
O documento discute os desafios da análise de requisitos, incluindo compreensão do domínio do problema, comunicação, evolução contínua e reutilização. Ele também aborda conceitos como domínio do problema, responsabilidade do sistema, comunicação, mudança contínua de requisitos e reutilização. Finalmente, discute as tarefas da engenharia de requisitos, como concepção, levantamento, elaboração, negociação, especificação, validação e gestão.
O documento discute processos de engenharia de software, incluindo modelos como cascata e incremental. O modelo em cascata é composto por sequências de atividades como análise de requisitos, design, implementação e testes. Já o desenvolvimento incremental envolve o desenvolvimento inicial e versões sucessivas com base em comentários. A engenharia de software orientada a reuso busca incorporar códigos e sistemas semelhantes ao projeto.
1) A análise de requisitos é fundamental para obter um software de alta qualidade e envolve descobrir e refinar os requisitos através da comunicação entre cliente e desenvolvedor.
2) Os principais passos da análise incluem modelar o domínio da informação, desenvolver modelos do sistema, particionar o problema e especificar requisitos funcionais e não funcionais.
3) Uma especificação de requisitos efetiva separa funcionalidade de implementação, modela o sistema e seu ambiente, e é revisada para garantir completude e
Método RON - Requisitos Orientado ao Negócio
Tem por objetivo apresentar método de definição e gerencia de requisitos com base nas atividades de um processo de negócio.
O documento discute os processos de engenharia de requisitos para software, incluindo a definição de requisitos funcionais e não funcionais. Apresenta os tipos de requisitos como requisitos de usuário, sistema e especificação de software. Também discute representações estruturadas de requisitos e linhas guias para elaboração de requisitos.
O documento discute a importância da engenharia de requisitos no desenvolvimento de sistemas e softwares. Apresenta os principais conceitos e atividades da engenharia de requisitos como elicitação, modelagem e validação de requisitos. Também destaca os desafios e erros comuns na especificação de requisitos que levam a problemas e falhas nos projetos.
O documento discute a qualidade de software, definindo-a como a conformidade aos requisitos dos clientes. Apresenta diferentes visões de qualidade de software e discute padrões e normas importantes como ISO 9126 para garantir a qualidade. Também descreve exemplos históricos de bugs caros que ocorreram por falta de qualidade.
O documento discute os desafios da análise de requisitos, incluindo compreensão do domínio do problema, comunicação, evolução contínua e reutilização. Ele também aborda conceitos como domínio do problema, responsabilidade do sistema, comunicação, mudança contínua de requisitos e reutilização. Finalmente, discute as tarefas da engenharia de requisitos, como concepção, levantamento, elaboração, negociação, especificação, validação e gestão.
O documento discute processos de engenharia de software, incluindo modelos como cascata e incremental. O modelo em cascata é composto por sequências de atividades como análise de requisitos, design, implementação e testes. Já o desenvolvimento incremental envolve o desenvolvimento inicial e versões sucessivas com base em comentários. A engenharia de software orientada a reuso busca incorporar códigos e sistemas semelhantes ao projeto.
O documento discute conceitos sobre sistemas de informação, incluindo: (1) a definição de sistemas como conjuntos de elementos inter-relacionados que trabalham juntos para atingir um objetivo comum; (2) o ciclo de vida de um sistema, desde a concepção até a vida útil e eventual "morte"; (3) a distinção entre dados e informação, onde dados são fatos brutos e informação é o agrupamento organizado de dados para gerar significado.
Este documento discute os principais tópicos da engenharia de requisitos, incluindo a importância da engenharia de requisitos, o que são requisitos, classificação de requisitos funcionais e não funcionais, documento e especificação de requisitos, processos de engenharia de requisitos como elicitação e análise de requisitos. O documento também aborda técnicas para obter requisitos como entrevistas e casos de uso.
Este documento descreve os principais protocolos de rede utilizados na Internet das Coisas, incluindo protocolos de enlace, roteamento, encapsulamento e sessão. Além disso, aborda os desafios do universo IoT, como mobilidade, confiabilidade, escalabilidade, gerenciamento, disponibilidade, interoperabilidade e segurança/privacidade.
O documento apresenta os conceitos e técnicas fundamentais de teste de software, descrevendo os objetivos do teste, os principais papéis e responsabilidades na equipe de teste, assim como os estágios e ciclo de vida dos testes.
Esse slide mostra a necessidade do processo de teste de software nos projetos de desenvolvimento de softwares, vamos demostrar as técnicas, tipos, fases, ferramentas, modelos e normas envolvidas na execução dos testes de software com o intuito de obter um ótimo nível de qualidade dos softwares gerados.
O documento descreve conceitos e técnicas relacionadas a diagramas de casos de uso, incluindo: (1) casos de uso capturam interações entre usuários e sistemas; (2) diagramas de casos de uso ajudam no entendimento dos requisitos funcionais de um sistema; (3) casos de uso representam versões externas do sistema e envolvem atores e sequências de ações.
O documento resume os principais tópicos sobre desenvolvimento de sistemas web, incluindo: (1) a diferença entre Internet e Web, como a Web usa a Internet para compartilhar hipertextos; (2) o modelo cliente-servidor e como ele funciona; (3) URLs e como elas localizam recursos na Web.
O documento apresenta conceitos gerais sobre engenharia de requisitos, incluindo seus processos, técnicas de levantamento, análise, documentação, verificação e validação de requisitos. Demonstra essas práticas em um projeto real de desenvolvimento de software, enfatizando a importância da engenharia de requisitos para o sucesso de um projeto.
Este documento resume os requisitos funcionais e não funcionais para o desenvolvimento de um software de lista de presença. Ele especifica os requisitos para realizar chamadas, visualizar e editar presenças, agendar chamadas, visualizar estatísticas e configurar a lista de presença. Além disso, descreve requisitos de usabilidade, confiabilidade, interface e documentação.
Este documento discute implantação e manutenção de software. Ele descreve brevemente a história profissional e acadêmica do autor, sua área de atuação em TI, processos de implantação de software incluindo planejamento, preparação, treinamento e execução, e processos de manutenção de software como correção de erros e adição de novas funcionalidades.
Apresentação sobre UML com foco nos Diagramas de Caso de Uso e Diagrama de Classes; apresentada na SESTINFO2009 (Semana de Estudos em Tecnologia da Informação) realizada na Universidade Metodista de São Paulo.
O documento apresenta uma introdução sobre Fernando Cunha e sua experiência profissional. Em seguida, fornece uma classificação dos principais tipos de bancos de dados NoSQL, exemplos e quais empresas os utilizam, abordando questões como suporte a queries e linguagens. Por fim, discute sobre as oportunidades do mercado NoSQL.
O documento discute a importância dos diagramas de contexto e fornece diretrizes para sua criação. Ele explica que os diagramas de contexto definem o escopo do sistema, auxiliam na estimativa de orçamento e capturam a visão compartilhada de stakeholders. Também descreve os elementos chave de um diagrama de contexto, como entidades externas e fluxos de dados, e dá recomendações sobre a diagramação.
Revisão dos conceitos básicos de alguns diagramas UML:
* Diagrama de Caso de Uso
* Diagrama de Classes
* Diagrama de Sequência
* Diagrama de Atividades
* Diagrama de Estados
* Diagrama de Componentes
[1] A autora apresenta um livro com 51 exercícios resolvidos de modelagem em UML, incluindo questões de concursos públicos. [2] O livro é dividido em capítulos tratando de temas como identificação de classes, atributos, relacionamentos e casos de uso a partir de exemplos reais. [3] A autora espera que o material atenda a professores, alunos e profissionais da área para ajudar no aprendizado prático de modelagem em UML.
O documento discute os modelos CMM e CMMI para avaliação e melhoria de processos de desenvolvimento de software. Apresenta os cinco níveis de maturidade do CMM, caracterizando cada nível, e explica conceitos-chave do CMMI como áreas de processo e objetivos.
O documento discute o padrão de projeto Factory Method, onde uma classe delega a responsabilidade de instanciação de objetos às subclasses. O padrão é ilustrado em um exemplo de sistema bancário que envia mensagens a clientes por diferentes meios, como SMS, e-mail ou JMS. Uma interface Emissor padroniza as classes responsáveis pelo envio e um teste direto mostra o uso dos diferentes emissores.
Aula que ministro no CEBRAC . Explico o que são Sistemas Operacionais, apresento os 3 mais conhecidos, discuto sobre as vantagens e desvantagens de cada um e por fim lanço uma perguntinha bem tranquila para exercitar o cérebro dos alunos.
O documento introduz a engenharia de requisitos, que ajuda a compreender o problema a ser resolvido pelo software. Ele descreve as etapas da engenharia de requisitos, incluindo concepção, elicitação, elaboração, negociação, especificação e validação. Além disso, discute a importância da gestão de requisitos para rastrear e controlar requisitos e mudanças.
O documento discute engenharia de requisitos de software, descrevendo algumas dificuldades e práticas para elaborar requisitos para o usuário final. Também aborda requisitos funcionais e não funcionais, tipos de requisitos, documentação de requisitos e métodos ágeis como Scrum, RUP, XP.
O documento discute conceitos sobre sistemas de informação, incluindo: (1) a definição de sistemas como conjuntos de elementos inter-relacionados que trabalham juntos para atingir um objetivo comum; (2) o ciclo de vida de um sistema, desde a concepção até a vida útil e eventual "morte"; (3) a distinção entre dados e informação, onde dados são fatos brutos e informação é o agrupamento organizado de dados para gerar significado.
Este documento discute os principais tópicos da engenharia de requisitos, incluindo a importância da engenharia de requisitos, o que são requisitos, classificação de requisitos funcionais e não funcionais, documento e especificação de requisitos, processos de engenharia de requisitos como elicitação e análise de requisitos. O documento também aborda técnicas para obter requisitos como entrevistas e casos de uso.
Este documento descreve os principais protocolos de rede utilizados na Internet das Coisas, incluindo protocolos de enlace, roteamento, encapsulamento e sessão. Além disso, aborda os desafios do universo IoT, como mobilidade, confiabilidade, escalabilidade, gerenciamento, disponibilidade, interoperabilidade e segurança/privacidade.
O documento apresenta os conceitos e técnicas fundamentais de teste de software, descrevendo os objetivos do teste, os principais papéis e responsabilidades na equipe de teste, assim como os estágios e ciclo de vida dos testes.
Esse slide mostra a necessidade do processo de teste de software nos projetos de desenvolvimento de softwares, vamos demostrar as técnicas, tipos, fases, ferramentas, modelos e normas envolvidas na execução dos testes de software com o intuito de obter um ótimo nível de qualidade dos softwares gerados.
O documento descreve conceitos e técnicas relacionadas a diagramas de casos de uso, incluindo: (1) casos de uso capturam interações entre usuários e sistemas; (2) diagramas de casos de uso ajudam no entendimento dos requisitos funcionais de um sistema; (3) casos de uso representam versões externas do sistema e envolvem atores e sequências de ações.
O documento resume os principais tópicos sobre desenvolvimento de sistemas web, incluindo: (1) a diferença entre Internet e Web, como a Web usa a Internet para compartilhar hipertextos; (2) o modelo cliente-servidor e como ele funciona; (3) URLs e como elas localizam recursos na Web.
O documento apresenta conceitos gerais sobre engenharia de requisitos, incluindo seus processos, técnicas de levantamento, análise, documentação, verificação e validação de requisitos. Demonstra essas práticas em um projeto real de desenvolvimento de software, enfatizando a importância da engenharia de requisitos para o sucesso de um projeto.
Este documento resume os requisitos funcionais e não funcionais para o desenvolvimento de um software de lista de presença. Ele especifica os requisitos para realizar chamadas, visualizar e editar presenças, agendar chamadas, visualizar estatísticas e configurar a lista de presença. Além disso, descreve requisitos de usabilidade, confiabilidade, interface e documentação.
Este documento discute implantação e manutenção de software. Ele descreve brevemente a história profissional e acadêmica do autor, sua área de atuação em TI, processos de implantação de software incluindo planejamento, preparação, treinamento e execução, e processos de manutenção de software como correção de erros e adição de novas funcionalidades.
Apresentação sobre UML com foco nos Diagramas de Caso de Uso e Diagrama de Classes; apresentada na SESTINFO2009 (Semana de Estudos em Tecnologia da Informação) realizada na Universidade Metodista de São Paulo.
O documento apresenta uma introdução sobre Fernando Cunha e sua experiência profissional. Em seguida, fornece uma classificação dos principais tipos de bancos de dados NoSQL, exemplos e quais empresas os utilizam, abordando questões como suporte a queries e linguagens. Por fim, discute sobre as oportunidades do mercado NoSQL.
O documento discute a importância dos diagramas de contexto e fornece diretrizes para sua criação. Ele explica que os diagramas de contexto definem o escopo do sistema, auxiliam na estimativa de orçamento e capturam a visão compartilhada de stakeholders. Também descreve os elementos chave de um diagrama de contexto, como entidades externas e fluxos de dados, e dá recomendações sobre a diagramação.
Revisão dos conceitos básicos de alguns diagramas UML:
* Diagrama de Caso de Uso
* Diagrama de Classes
* Diagrama de Sequência
* Diagrama de Atividades
* Diagrama de Estados
* Diagrama de Componentes
[1] A autora apresenta um livro com 51 exercícios resolvidos de modelagem em UML, incluindo questões de concursos públicos. [2] O livro é dividido em capítulos tratando de temas como identificação de classes, atributos, relacionamentos e casos de uso a partir de exemplos reais. [3] A autora espera que o material atenda a professores, alunos e profissionais da área para ajudar no aprendizado prático de modelagem em UML.
O documento discute os modelos CMM e CMMI para avaliação e melhoria de processos de desenvolvimento de software. Apresenta os cinco níveis de maturidade do CMM, caracterizando cada nível, e explica conceitos-chave do CMMI como áreas de processo e objetivos.
O documento discute o padrão de projeto Factory Method, onde uma classe delega a responsabilidade de instanciação de objetos às subclasses. O padrão é ilustrado em um exemplo de sistema bancário que envia mensagens a clientes por diferentes meios, como SMS, e-mail ou JMS. Uma interface Emissor padroniza as classes responsáveis pelo envio e um teste direto mostra o uso dos diferentes emissores.
Aula que ministro no CEBRAC . Explico o que são Sistemas Operacionais, apresento os 3 mais conhecidos, discuto sobre as vantagens e desvantagens de cada um e por fim lanço uma perguntinha bem tranquila para exercitar o cérebro dos alunos.
O documento introduz a engenharia de requisitos, que ajuda a compreender o problema a ser resolvido pelo software. Ele descreve as etapas da engenharia de requisitos, incluindo concepção, elicitação, elaboração, negociação, especificação e validação. Além disso, discute a importância da gestão de requisitos para rastrear e controlar requisitos e mudanças.
O documento discute engenharia de requisitos de software, descrevendo algumas dificuldades e práticas para elaborar requisitos para o usuário final. Também aborda requisitos funcionais e não funcionais, tipos de requisitos, documentação de requisitos e métodos ágeis como Scrum, RUP, XP.
1. A engenharia de requisitos envolve a descoberta do que o sistema deve fazer e possíveis restrições através de técnicas como entrevistas, observação e prototipagem.
2. É importante documentar os requisitos levantados para que sirvam de base para o desenvolvimento de software.
3. As principais etapas da engenharia de requisitos são concepção, levantamento, elaboração, negociação, especificação, validação e gestão.
A análise de requisitos é um processo importante na gestão de projetos para (1) recolher dados sobre as necessidades e expectativas dos usuários, (2) definir corretamente os requisitos do sistema, e (3) determinar o sucesso ou fracasso do projeto. Ela envolve técnicas como entrevistas e questionários para especificar funcionalidades, desempenho e restrições do sistema.
Princípios Fundamentais da Análise de Requisitoselliando dias
O documento discute princípios fundamentais da análise de requisitos para o desenvolvimento de software. Ele descreve as etapas da análise de requisitos, incluindo descoberta, refinamento e modelagem. Também discute os participantes do processo e suas responsabilidades, como o cliente e o analista de sistemas. Finalmente, fornece diretrizes para a especificação e comunicação de requisitos.
O documento discute a engenharia de requisitos, definindo-a como o processo de coleta, análise, documentação e gerenciamento de requisitos ao longo do ciclo de vida de um software. Detalha os principais conceitos como requisito, stakeholder e as atividades-chave da engenharia de requisitos: elicitação, documentação, validação e gerenciamento. Também aborda tipos de requisitos, desafios da análise de requisitos e a importância de um processo eficiente de engenharia de requisitos.
O documento discute técnicas para análise de requisitos, incluindo entrevistas, questionários, observação direta e brainstorming. A análise de requisitos é o primeiro passo no processo de engenharia de software para definir o que o sistema deve fazer através da perspectiva dos usuários. Requisitos funcionais e não funcionais devem ser especificados para guiar o desenvolvimento do sistema.
Este documento descreve as principais atividades e artefatos produzidos durante a fase de concepção de um sistema, incluindo: levantamento de requisitos através de técnicas como entrevistas e questionários; organização dos requisitos em casos de uso, tabelas e diagramas; e produção de um modelo conceitual preliminar do sistema.
O documento discute engenharia de requisitos, definindo-a como o processo de aquisição, refinamento e verificação das necessidades de um sistema. Aborda os tipos de requisitos funcionais e não funcionais, métodos para obter requisitos como entrevistas e questionários, validação de requisitos e desafios na análise de requisitos.
Os aspectos mais relevantes da Engenharia de RequisitosJosé Vieira
O documento discute os aspectos mais relevantes da Engenharia de Requisitos, incluindo suas tarefas e princípios para uma boa especificação de requisitos. A Engenharia de Requisitos é importante para entender as necessidades dos clientes e desenvolver software com qualidade e de acordo com os requisitos.
Modelos e etapas do processo de software.pdfIvanFontainha
O documento discute os fundamentos da engenharia de software, incluindo modelos de processo de software, requisitos funcionais e não funcionais, regras de negócio, projeto de software e validação de requisitos. Apresenta também exercícios para identificar requisitos e regras de negócio para um sistema.
O documento discute os requisitos de software, definindo-os como declarações que especificam o que um sistema deve fazer. Apresenta o processo de engenharia de requisitos, incluindo a elicitação, especificação e validação de requisitos, além de classificar requisitos funcionais e não funcionais.
Ap i unidade 3 - levantamento de requisitosGlauber Aquino
Este documento discute a importância da análise e levantamento de requisitos para o desenvolvimento de sistemas de software. Realiza uma distinção entre requisitos funcionais e não funcionais e discute os cuidados necessários no processo de análise de requisitos, como evitar ambiguidades e considerar outros aspectos do projeto.
Aula 01 e 02 - Engenharia de Software.pdfJadna Almeida
Este documento discute engenharia de software, abordando os seguintes pontos:
1) A engenharia de software surgiu para solucionar problemas da "crise do software" e melhorar a qualidade e produtividade no desenvolvimento de software.
2) Existem diversos modelos de processo de software, como cascata, evolucionário, baseado em componentes e iterativos como espiral e incremental. Cada modelo possui vantagens e desvantagens dependendo do projeto.
3) Fatores como custo, qualidade, facil
O documento apresenta uma aula introdutória sobre análise de sistemas orientada a objetos. Aborda conceitos sobre sistemas de informação, engenharia de requisitos, modelagem de processos de negócio e casos de uso, análise orientada a objetos com UML e avaliação. A bibliografia inclui referências sobre UML, análise e projeto de sistemas orientados a objetos.
A proposal to combine elicitation techniques to write vision document and use...André Agostinho
Analyse a proposal to combine elicitation techniques to write vision document and use cases specifications. The results obtained from this study showed that the combination of selected techniques can generate effectively a vision document and use case specifications and align them to Scrum methodology by product backlog generation and user story derived from use cases.
Especificações funcionais descrevem como um relatório ou transação deve funcionar e ser interagido pelo usuário. Isso inclui o que o relatório fará, como os usuários irão interagir com ele e como ele será visualizado. Criar especificações funcionais ajuda a orientar o desenvolvimento do software e gerenciar as expectativas dos clientes.
Como especificar requisitos em metodologias ágeis?Priscilla Aguiar
O documento discute como os requisitos são especificados em metodologias ágeis. Apresenta user stories como uma forma de descrever requisitos de maneira sucinta, focada no valor para o usuário, e discute técnicas como modelagem de casos de uso para requisitos complexos.
Este documento apresenta uma aula sobre levantamento e análise de requisitos, cobrindo tópicos como:
- Definição de requisitos e seus objetivos
- Classificação de requisitos em funcionais, não funcionais, de domínio, do usuário e do sistema
- Exemplos de cada tipo de requisito
O documento descreve o Rational Unified Process (RUP), um modelo de processo de software que fornece boas práticas para o desenvolvimento de sistemas. O RUP é dividido em quatro fases principais: Iniciação, Elaboração, Construção e Transição. Cada fase tem objetivos, artefatos esperados e critérios de avaliação para marcos importantes no projeto. O documento detalha os principais elementos de cada fase do RUP.
Semelhante a Identificar Requisitos Funcionais.pdf (20)
1. Identificar requisitos funcionais
Apresentação
Requisitos funcionais podem ser considerados, com toda a segurança, os itens mais importantes
durante a modelagem de um produto de software. A partir deles, todo o projeto é desenvolvido —
se um requisito funcional não estiver correto, todos os passos posteriores de modelagem, projeto,
desenvolvimento, testes e entrega irão apresentar problemas. Um requisito funcional define uma
função particular de um sistema ou algum dos seus componentes. Eles representam "o quê o
software faz", em termos de tarefas e serviços.
Imagine um requisito de uma bola que seja: "a bola deve rolar". Essa é uma característica muito
importante para que o produto "bola", ao final do projeto, possa ser útil. Agora, imagine que, na
coleta de requisitos, o analista não coletou adequadamente o requisito e, ao final, seja criada uma
bola que não role. Qual seria a utilidade desse produto entregue? O mesmo ocorre para produtos
de software! Devido a sua complexidade e, às vezes, à falta de conhecimento do usuário, erros são
muito comuns na coleta de requisitos. Logo, uma atenção especial e a utilização de boas práticas
são essenciais nessa etapa.
Nesta Unidade de Aprendizagem, você irá conhecer o processo de coleta e documentação de
requisitos funcionais. Entenderá o que são requisitos funcionais e suas características. Também,
identificará e documentará esses requisitos.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Descrever o que são requisitos funcionais e suas características.
•
Identificar quais são os requisitos funcionais da solução que compõem o escopo.
•
Organizar a documentação dos requisitos funcionais.
•
2. Desafio
Você é analista de sistemas e está em processo de identificação e coleta de requisitos funcionais.
Conteúdo interativo disponível na plataforma de ensino!
A partir do diálogo, você pode conhecer algumas necessidades do cliente.
Agora, especifique ao menos 2 requisitos funcionais, e descreva-os utilizando a estrutura:
Nome do requisito:
Ator:
Prioridade:
Entradas e pré-condições:
Saídas e pós-condições:
Fluxo de eventos principal:
4. Aponte a câmera para o
código e acesse o link do
conteúdo ou clique no
código para acessar.
5.
6. Conteúdo do livro
Nada como um exemplo para aprender um novo conceito, certo? Então, veja um exemplo de um
requisito funcional: “um sistema deve enviar um e-mail sempre que uma determinada condição for
atendida (por exemplo, um pedido é colocado, um cliente inscreve-se, etc.)”. O requisito funcional
descreve o comportamento do sistema em relação à sua funcionalidade. Eles são as principais
coisas que o usuário espera do software — por exemplo, se o aplicativo for bancário, ele deve ser
capaz de criar uma nova conta, atualizá-la, excluir uma conta, etc. Neste capítulo, vocêr vai estudar
os requisitos funcionais e as suas características. Vai entender como identificar os requisitos
funcionais que compõem uma solução e como documentar esses requisitos. Leia o capítulo
Identificar requisitos funcionais, do livro Análise e projeto de sistemas.
Boa Leitura!
8. Identificar requisitos
funcionais
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
„
„ Descrever o que são requisitos funcionais e suas características.
„
„ Identificar quais são os requisitos funcionais da solução que compõem
o escopo.
„
„ Organizar a documentação dos requisitos funcionais.
Objetivos de aprendizagem
Requisitos funcionais podem ser considerados, com toda a segurança,
os itens mais importantes durante a modelagem de um produto de
software, pois é a partir dos requisitos funcionais que todo o projeto é
desenvolvido. Se um requisito funcional não estiver correto, todos os
passos posteriores, como modelagem, projeto, desenvolvimento, testes
e entrega irão apresentar problemas. Um requisito funcional define uma
função particular de um sistema ou algum dos seus componentes; eles
representam “o quê o software faz”, em termos de tarefas e serviços.
Imagine que um dos requisitos de uma bola seja “a bola deve rolar”.
Assim, esta é uma característica muito importante para que o produto
“bola”, ao final do projeto, possa ser útil. Agora, imagine que na coleta
de requisitos, o analista não coletou adequadamente este requisito e ao
final seja criada uma bola que não role. Se o produto final não atender
a esse importante requisito, ele não terá utilidade. O mesmo ocorre em
produtos de software. E devido à sua complexidade e, às vezes, falta de
conhecimento do usuário, erros são muito comuns na coleta de requisitos.
Logo, uma atenção especial e a utilização de boas práticas são essenciais
nesta etapa.
Neste texto, você irá conhecer o processo de coleta e documentação
de requisitos funcionais. Irá entender o que são requisitos funcionais e
suas características. Também irá identificar e documentar estes requisitos.
9. Requisitos funcionais
A coleta de requisitos é um processo de quatro passos, que inclui o estudo de
viabilidade, recolhimento de requisitos, especificação de requisitos de software
e validação de requisitos de software. Você vai entender o que significa cada
um destes elementos antes de entrar nos conceitos de requisitos funcionais.
Estudo de viabilidade: quando o cliente se aproxima da organização para
obter desenvolvido o produto desejado. Ele apresenta uma ideia aproximada
sobre o que todas as funções que o software deve executar e quais são todos
os recursos esperados. Referindo-se a essa informação, os analistas fazem um
estudo detalhado sobre o sistema desejado e se sua funcionalidade é viável
para desenvolver (MALL, 2014).
Esse estudo de viabilidade está focado no objetivo da organização, pois
analisa se o produto de software pode ser, na prática, materializado em termos
de implementação, contribuição do projeto para organização, restrições de
custo conforme valores e objetivos da organização. Ele explora os aspectos
técnicos do projeto e do produto, como usabilidade, capacidade de manutenção,
produtividade e capacidade de integração.
O resultado desta fase deve ser um relatório de estudo de viabilidade, que
deve conter comentários adequados e recomendações para o gerenciamento,
e se o projeto deve ou não ser realizado.
Coleta de requisitos: se o relatório de viabilidade for positivo para o em-
preendimento, a próxima fase começa com os requisitos de coleta do usuário.
Analistas e engenheiros se comunicam com o cliente e os usuários finais para
conhecer as suas ideias sobre o que o software deve fornecer e quais recursos
eles querem que sejam incluídos.
Validação de requisitos de software
Depois que as especificações de requisitos são desenvolvidas, os requisitos
mencionados neste documento são validados. O usuário pode solicitar uma
solução ilegal, impraticável ou os especialistas podem interpretar incorre-
tamente os requisitos. Isso resulta em um enorme aumento no custo, se não
for examinado. Os requisitos podem ser verificados em relação às seguintes
condições (MALL, 2014):
Identificar requisitos funcionais
2
10. „
„ Se eles podem ser, na prática, implementados.
„
„ Se eles são válidos e de acordo com a funcionalidade e o domínio do
software.
„
„ Se há ambiguidades.
„
„ Se estão completos.
„
„ Se podem ser demonstrados.
Processo de elicitação de requisitos
O processo de elicitação de requisitos pode ser representado pelo diagrama,
conforme a Figura 1:
Figura 1. Diagrama.
Coleta
de
requisitos
Organização
de
requisitos
Negociação
e
discussão
Especificação
„
„ Coleta de requisitos: os desenvolvedores discutem com o cliente e
os usuários finais, e conhecem as suas expectativas sobre o software.
„
„ Organização de requisitos: os desenvolvedores priorizam e organizam
os requisitos por ordem de importância, urgência e conveniência.
„
„ Negociação e discussão: se os requisitos são ambíguos ou existem
alguns conflitos em requisitos de várias partes interessadas, é negociado
e discutido com essas partes. Assim, os requisitos podem, então, ser
priorizados e razoavelmente comprometidos, pois, provêm de vários
partes interessadas. Para remover a ambiguidade e os conflitos, eles
devem ser discutidos com clareza e exatidão, já que os requisitos irre-
alistas comprometem essa etapa.
„
„ Especificação: todos os requisitos formais e informais, funcionais e
não funcionais são documentados e disponibilizados para o próximo
processamento da fase.
3
Identificar requisitos funcionais
11. Técnicas de elicitação de requisitos
A elicitação de requisitos é o processo para descobrir os requisitos para um
sistema de software pretendido, comunicando-se com o cliente, usuários finais,
usuários do sistema e outros que tenham participação no desenvolvimento do
sistema de software.
Existem várias maneiras de descobrir os requisitos (SCHACH, 2009):
„
„ Entrevistas: as entrevistas são um meio forte para cobrar os requisitos.
A organização pode realizar vários tipos de entrevistas, tais como:
■
■ Entrevistas estruturadas (fechadas), em que cada informação é única
para coletar dados, sendo decidida com antecedência, porque elas
seguem um padrão e a questão de discussão firmemente.
■
■ Entrevistas não estruturadas (abertas), em que a informação a reunir
não é decidida com antecedência, mais flexível e menos tendenciosa.
■
■ Entrevistas orais.
■
■ Entrevistas escritas.
■
■ Entrevistas individuais que são realizadas entre duas pessoas em
todo o país.
„
„ Pesquisa: a organização pode realizar pesquisas entre várias partes
interessadas, que consultarão sobre as expectativas e os requisitos do
próximo sistema.
„
„ Questionário: o documento, com um conjunto pré-definido de questões
objetivas, é entregue a todas as partes interessadas para ser respondido,
assim, posteriormente, serão coletadas e compiladas as respostas. Uma
lacuna dessa técnica é, se uma opção para algum problema não for
mencionada no questionário, a questão pode ser deixada sem supervisão.
„
„ Análise de tarefas: a equipe de engenheiros e desenvolvedores pode
analisar a necessidade da operação do novo sistema. Se o cliente já tiver
algum software para executar determinada operação, ele é estudado e
os requisitos do sistema proposto são coletados.
„
„ Análise de domínio: todo o software cai em alguma categoria de do-
mínio. As pessoas experientes no domínio podem ser de grande ajuda
para analisar os requisitos gerais e específicos.
„
„ Debate: um debate informal é realizado entre as várias partes interes-
sadas e todos os seus insumos são registrados para análise adicional
de requisitos.
„
„ Prototipagem: é a construção de uma interface de usuário, sem adicio-
nar funcionalidades detalhadas para que o usuário interprete os recursos
Identificar requisitos funcionais
4
12. do produto de software pretendido. Isso ajuda a dar uma melhor ideia
a respeito dos requisitos. Se não houver nenhum software instalado no
trabalho final do cliente, para a referência do desenvolvedor, e o cliente
não estiver ciente de seus próprios requisitos, o desenvolvedor criará
um protótipo com base em requisitos inicialmente mencionados. O
protótipo é mostrado ao cliente e o feedback é anotado. Ele serve como
uma entrada para a coleta de requisitos.
„
„ Observação: a equipe de especialistas visita a organização ou o local de
trabalho do cliente. Eles observam o funcionamento real dos sistemas
existentes, também analisam o fluxo de trabalho final do cliente e como
os problemas de execução são tratados. A equipe em si desenha algumas
conclusões que ajudam a formar os requisitos esperados do software.
Características de requisitos de software
Coletar os requisitos de software é a base de todo o projeto do seu desenvol-
vimento. Portanto, eles devem ser claros, corretos e bem definidos.
Uma especificação completa de requisitos de software deve ser:
„
„ Clara
„
„ Correta
„
„ Consistente
„
„ Coerente
„
„ Compreensível
„
„ Modificável
„
„ Verificável
„
„ Sem ambiguidade
„
„ Rastreável
„
„ Fonte credível
Requisitos de software
Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação
e processamento de dados, além de outras funcionalidades específicas que
definem o que um sistema deve realizar. Os requisitos comportamentais, que
descrevem todos os casos em que o sistema usa os requisitos funcionais, são
capturados em casos de uso. Os requisitos funcionais são suportados por
5
Identificar requisitos funcionais
13. requisitos não funcionais (também conhecidos como requisitos de qualidade),
que impõem restrições ao projeto ou implementação (como requisitos de de-
sempenho, segurança ou confiabilidade). Geralmente, os requisitos funcionais
são expressos na forma “o sistema deve fazer <requisição>”, enquanto os
requisitos não funcionais são “o sistema deve ser <requisito>”. O plano para
implementar requisitos funcionais é detalhado no design do sistema. O plano
de implementação de requisitos não funcionais é detalhado na arquitetura do
sistema (LAPLANTE, 2013).
Conforme definido na engenharia de requisitos, os requisitos funcionais
especificam resultados de um sistema. Isso deve ser contrastado com requisitos
não funcionais que especificam características gerais, como custo e confia-
bilidade. Os requisitos funcionais conduzem a arquitetura de aplicativos de
um sistema, enquanto os requisitos não funcionais conduzem a arquitetura
técnica de um sistema (WIEGERS; BEATTY, 2013).
Em alguns casos, um analista de requisitos gera casos de uso após reunir
e validar um conjunto de requisitos funcionais. A hierarquia dos requisitos
funcionais é: solicitação do usuário / stakeholder → recurso → use case →
business rule. Cada caso de uso ilustra cenários comportamentais por meio
de um ou mais requisitos funcionais. Muitas vezes, um analista começará
provocando um conjunto de casos de uso, dos quais ele pode derivar os requi-
sitos funcionais que devem ser implementados para permitir que um usuário
execute cada caso de uso.
Os requisitos, que estão relacionados ao aspecto funcional do software, se
enquadram nesta categoria. Eles definem funções e funcionalidades dentro e
a partir do sistema de software.
Analise alguns exemplos de requisitos funcionais:
„
„ Opção de pesquisa fornecida ao usuário para pesquisar de várias faturas.
„
„ O usuário deve enviar qualquer relatório para o gerenciamento.
„
„ Os usuários podem ser divididos em grupos e os grupos podem receber
direitos separados.
„
„ Deve cumprir regras de negócios e funções administrativas.
„
„ O software é desenvolvido mantendo a compatibilidade descendente
intacta.
Identificar requisitos funcionais
6
14. Escopo e requisitos
Pode-se dividir os requisitos de acordo com o escopo ao qual eles fazem parte.
Em muitos projetos, os requisitos são obtidos de forma conjunta, sem uma
classificação. A fase de organização é essencial para permitir a separação de
acordo com determinadas partes de um sistema. Você verá alguns exemplos
de escopos e seus requisitos.
Requisitos de interface
„
„ O campo 1 aceita a entrada numérica de dados.
„
„ O campo 2 apenas aceita datas antes da data atual.
„
„ A tela 1 pode imprimir dados na tela para a impressora.
Requisitos de negócio
„
„ Os dados devem ser inseridos antes que um pedido possa ser aprovado.
„
„ Ao clicar no botão aprovar, mova a solicitação para o fluxo de trabalho
de aprovação.
„
„ Todo o pessoal que estiver usando o sistema será treinado de acordo
com o SOP interno AA-101.
Requisitos de regulamentação/conformidade
„
„ O banco de dados terá uma trilha de auditoria funcional.
„
„ O sistema irá limitar o acesso a usuários autorizados.
„
„ A planilha pode proteger dados com assinaturas eletrônicas.
Requisitos de segurança
„
„ Os membros do grupo de entrada de dados podem inserir solicitações,
mas não podem aprovar ou excluir solicitações.
„
„ Os membros do grupo gerentes podem inserir ou aprovar um pedido,
mas não podem excluir solicitações.
7
Identificar requisitos funcionais
15. „
„ Os membros do grupo administradores não podem entrar ou aprovar
pedidos, mas podem excluir pedidos.
Especificação de requisitos funcionais
Uma especificação de requisitos de software (SRS) é uma descrição de um
sistema de software a ser desenvolvido. Ele estabelece requisitos funcionais
e não funcionais e pode incluir um conjunto de casos de uso que descrevem
as interações do usuário que o software deve fornecer.
A especificação de requisitos de software estabelece a base de um acordo
entre clientes e contratados ou fornecedores (em projetos orientados para o
mercado, essas funções podem ser desempenhadas pelas divisões de marketing
e desenvolvimento) sobre o que o produto de software deve fazer, bem como,
o que não é esperado que façam. A especificação de requisitos de software
permite uma avaliação rigorosa dos requisitos antes que o projeto possa come-
çar e reduz o redesenho posterior. Também, deve fornecer uma base realista
para estimar os custos, os riscos e os horários dos produtos. Usado de forma
adequada, as especificações de requisitos de software podem ajudar a evitar
falhas no projeto (PRESSMAN, 2016).
O documento de especificação de requisitos do software lista requisitos
suficientes e necessários para o desenvolvimento do projeto. Para derivar os
requisitos, o desenvolvedor precisa ter uma compreensão clara e completa dos
produtos a serem desenvolvidos ou em desenvolvimento. Isso é alcançado e
refinado com comunicações detalhadas e contínuas com a equipe do projeto
e o cliente, até a conclusão do software.
O SRS pode ser uma das descrições de itens de dados entregues por contrato
ou ter outras formas de conteúdo com mandato organizacional.
No documento de especificação de requisitos, há uma seção especial em
que são colocados os requisitos funcionais. Nessa seção, além de uma abertura
que introduz o contexto dos requisitos, tem-se todos os requisitos descritos
na Figura 2:
Identificar requisitos funcionais
8
16. Figura 2. Descrição dos requisitos.
[RF001] <Nome do requisito funcional>
<Opcional - forneça uma pequena explicação do propósito do requisito funcional (útil quando o
nome do requisito funcional não deixa suficientemente claro qual é o seu objetivo) e o(s) seu(s)
respectivo(s) ator(es).>
Ator: <informe o(s) ator(s) do requisito funcional.>
Prioridade: Essencial / Importante / Desejável
Interface(s) associada(s) <Opcional> : <inclua aqui o(s) identificador(es) da(s) respectiva(s)
interface(s) do requisito funcional.>
Entradas e pré-condições: <liste aqui todas as entradas e/ou pré-condições do requisito funcional.
Pré-condição de um requisito funcional é o estado em que o sistema deve estar para realizar o
requisito funcional.>
Saídas e pós condições: <liste aqui todas as saídas e/ou pós condições do requisito funcional.
Pós-condição de um requisito funcional é a lista de possíveis estados em que o sistema pode estar
imediatamente após o término da realização do requisito.>
Fluxo de eventos principal
<Descreva aqui o fluxo de eventos principal que ocorre durante a execução do requisito.>
Fluxos secundários (alternativos e de exceção) <Ocupacional>
Fluxo secundário XXX
Use este espaço para descrever o fluxo secundário XXX.
Fluxo secundário YYY
Prossiga na descrição dos fluxos secundário, desenvolvendo cada um deles separadamente.
Além da descrição dos requisitos funcionais, em alguns casos, é comum
a aparição de diagramas de casos de uso ou de processos para facilitar o
entendimento dos requisitos pelas pessoas que estão envolvidas no projeto.
Para você ver mais um exemplo de solução de problemas e melhoria de processos,
leia o artigo “Proposta de melhoria do processo de uma fábrica de polpas por meio
da metodologia de análise e solução de problemas” (SOUSA et al., 2015).
LAPLANTE, P. A. Requirements engineering for software and systems. Boca Raton: CRC
Press, 2013.
MALL, R. Fundamentals of software engineering. New Delhi: PHI Learning, 2014.
9
Identificar requisitos funcionais
17. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional.
8. ed. Porto Alegre: AMGH, 2016.
SCHACH, S. Engenharia de Software: os paradigmas clássico e orientado a objetos. 7.
ed. Porto Alegre: McGraw-Hill, 2009.
WIEGERS, K.; BEATTY, J. Softwarerequirements. 3. ed. London: Pearson Education, 2013.
Leituras recomendadas
GONÇALVES, L. C. Engenharia de Requisitos.SemeruBlog,2013. Disponível em: http://
www.semeru.com.br/blog/engenharia-de-requisitos/. Acesso em: 14 set. 2017.
VENTURA, P. O que é Requisito Funcional. Até o momento, Belo Horizonte, 2017.
Disponível em: http://www.ateomomento.com.br/o-que-e-requisito-funcional/.
Acesso em: 14 set. 2017.
Identificar requisitos funcionais
10
18.
19.
20. Dica do professor
Nesta Dica do Professor, você vai ver assuntos sobre os requisitos funcionais, como coletar, o que
fazer após a coleta e como documentá-los.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
21. Exercícios
1) O que é um requisito funcional?
A) São os requisitos que descrevem as funcionalidades específicas que definem o que um
sistema deve realizar.
B) São os requisitos que descrevem como o sistema deve realizar o que o usuário/cliente
solicitou.
C) Trata-se de algo que não é uma funcionalidade, mas que precisa ser realizado para que o
software atenda ao seu propósito.
D) São requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade,
confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas.
E) São requisitos que incluem atributos de qualidade para o produto.
2) Uma das técnicas utilizadas para coletar requisitos funcionais são as entrevistas. Temos 5
tipos de entrevistas. Qual tipo de entrevista de coleta de requisito possui a característica de
especificação com antecedência das informações que serão adquiridas e que seguem a pauta
e a questão de discussão sem desvios?
A) Entrevista aberta.
B) Entrevistas orais.
C) Entrevista fechada.
D) Entrevista escrita.
E) Entrevista individual.
3) Em um sistema de compra e venda de produtos, quais dos seguintes requisitos é funcional?
A) O sistema estará disponível pelo menos 99,7% do tempo em dias de semana, entre 06:00 e
meia-noite, e pelo menos 99,95% entre 16:00h e 18:00h.
B) O gerente pode gerar um relatório de vendas do último mês.
22. C) O sistema deve fazer log dos pagamentos autorizados via cartão de crédito, em 24 horas.
D) O sistema deverá ser acessado completamente via browser HTTP/HTML.
E) O software será disponibilizado em inglês.
4) Supondo que temos o seguinte requisito de um sistema de compra e venda: os vendedores
podem registrar novas compras, mas não poderão editá-las ou excluí-las. Apenas o gerente
poderá editar e excluir compras. Podemos classificar esse requisito em quais dos escopos a
seguir?
A) Requisito de interface.
B) Requisito de negócio.
C) Requisito de regulamentação/conformidade.
D) Requisito de segurança.
E) Requisito sem classificação.
5) O que é uma especificação de requisitos de software (SRS)?
A) É um documento que captura restrições de design e requisitos de alto nível para que o cliente
possa compreender o sistema que será desenvolvido. Seu objetivo é fornecer uma visão
ampla do produto que se pretende desenvolver, sem aprofundamento em detalhes.
B) É um documento que inclui as ações necessárias para definir, coordenar e integrar todos os
planos auxiliares do projeto.
C) É um documento com uma abordagem sistemática para o teste de sistemas, como hardware
ou software. Ele geralmente consiste em uma modelagem detalhada do fluxo de trabalho
durante o processo.
D) É uma descrição de um sistema de software a ser desenvolvido. Ele estabelece requisitos
funcionais e não funcionais.
E) É um artefato composto e abrangente, que reúne todas as informações necessárias ao
gerenciamento do projeto.
23. Na prática
Como todos sabemos, os recursos (tanto naturais como tecnológicos) são finitos. Logo, atender a
todas as demandas necessárias, às vezes, torna-se impossível, principalmente se temos também o
fator tempo.
Em muitos projetos, os usuários podem solicitar uma quantidade muito grande de requisitos. Por
isso, a priorização é uma tarefa que requer uma atenção especial, já que vai impactar no que será
entregue ao usuário. Além disso, a priorização de requisitos ajuda a resolver conflitos, a planejar
entregas e a decidir sobre quais requisitos implementar. Na priorização de requisitos, devem
participar os seguintes profissionais:
- Gerente do projeto: lidera o processo, arbitra conflitos e ajusta as entradas dos outros
participantes, se necessário;
- Representantes do cliente: fornecem a classificação dos benefícios e penalidades;
- Representantes de desenvolvimento: como líderes técnicos da equipe, avaliam o custo e o risco.
Agora, imagine-se em um projeto de software de uma nave espacial que será construída pela NASA.
24. Aponte a câmera para o
código e acesse o link do
conteúdo ou clique no
código para acessar.
25.
26. Saiba +
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Técnicas de levantamento de requisitos
Profissional explicando as técnicas de coleta de requisitos de
software, apresentando quais e como são utilizadas as técnicas
existentes. Também é explicado o momento certo de utilizar
cada técnica.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Preenchimento do documento de requisitos
Uma aula demonstrando o preenchimento de um documento de
requisitos, apresentando uma situação de criação de um
software.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
O que é requisito funcional
Neste artigo, você irá entender o que são os requisitos
funcionais em uma linguagem de fácil entendimento e com
exemplos simples para facilitar o aprendizado.
27. Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Priorização de requisitos
Priorizar é uma questão de viabilizar as coisas - o que
prioritário vem primeiro, o que não é, espera.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Uma abordagem para a priorização de requisitos em ambientes
ágeis
Apresenta alguns conceitos sobre priorização de requisitos da
página 51 até 53. Além disso, os itens de 1.10 até 1.17
apresentam uma visão bastante abrangente que foca no
desenvolvimento de software com metodologias ágeis. Trata-se
de uma leitura muito interessante, principalmente no contexto
atual onde os métodos ágeis e suas técnicas estão cada vez mais
presentes.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.