Glossário de Termos

Este glossário tem por objetivo reunir o conhecimento existente sobre a terminologia da Engenharia de Requisitos e definir a terminologia essencial de maneira criteriosa e consistente. Nos casos em que houver mais de uma definição, ou quando algum termo é definido de modo diferente quando visto a partir de perspectivas diferentes, incluímos múltiplas definições ou perspectivas. Para termos que têm tanto um sentido genérico quanto um sentido específico no contexto da Engenharia de Requisitos, definimos ambos os sentidos. Termos importantes são acompanhados de comentários e informações adicionais.

Este glossário complementa os livros-texto endossados pelo International Requirements Engineering Board (IREB). As definições encontradas no livro Requirements Engineering Fundamentals, de Klaus Pohl e Chris Rupp, a ser publicado brevemente, foram formuladas em conjunto com as definições neste glossário.

Fonte: IREB - International Requirements Engineering Board (adaptado)

TERMO	DEFINIÇÃO
Aceitação	O processo de avaliar se um ↑sistema atende todos os seus ↑requisitos.
Adequação (de um requisito)	Característica que expressa até que ponto um ↑requisito expressa os verdadeiros desejos e necessidades dos ↑stakeholders (isto é, aqueles que efetivamente tinham em mente ao formular o requisito)
Análise de requisitos	1. Análise de ↑requisitos elicitados para compreender e documentá-los. 2. Sinônimo de ↑Engenharia de Requisitos
Análise estruturada	Uma abordagem para especificar a ↑funcionalidade de um sistema com base em uma hierarquia de ↑diagramas de fluxo de dados. Os fluxos de dados e dados persistentes são definidos num dicionário de dados. Um ↑diagrama de contexto modela as fontes dos fluxos de entrada, bem como os destinos dos fluxos de saída
Analista de negócio	Sinônimo de Engenheiro de Requisitos. Pessoa responsável por elicitar, documentar, gerir e manter os requisitos de projeto. Também atua na gestão do projeto.
Área de negócio	Considerado um Stakeholder do projeto. São as pessoas responsáveis por repassar todo conhecimento da área que atuam para a equipe que irá implementar a solução.
Artefato	Um resultado intermediário ou final do ↑desenvolvimento de sistemas; por exemplo, uma ↑especificação de requisitos
Ator	1. De forma genérica na ER: Uma pessoa, um ↑sistema ou um dispositivo técnico no ↑contexto de um sistema que interage com o sistema. 2. Especialmente na ER orientada por metas: uma pessoa, um ↑sistema ou um dispositivo técnico que pode agir conforme certas informações e processar informações para alcançar determinadas ↑metas.
Atributo	Uma propriedade característica de uma ↑entidade
Baseline	Uma ↑configuração estável de ↑artefatos, sujeita ao controle de mudanças. Baselines têm aplicação para o planejamento e a definição de ↑releases, bem como para fins de gerenciamento de projeto, tais como estimativas de custo
Baseline dos requisitos	Uma ↑baseline para um conjunto de ↑requisitos
Bug	↑ Defeito
Cardinalidade	1. Na modelagem: O número mínimo e máximo de objetos num relacionamento. Em ↑UML, o termo multiplicidade é utilizado para cardinalidade. 2. Na matemática: O número de elementos em um conjunto
Caso de uso	Uma descrição das possíveis interações entre ↑atores e um ↑sistema que agregam valor quando executados. Casos de uso especificam um ↑sistema a partir da perspectiva de um ↑usuário (ou outro ↑ator externo): cada caso de uso descreve alguma funcionalidade que o sistema deverá fornecer para os ↑atores envolvidos no caso de uso
Cenário	1. A descrição de uma sequência potencial de eventos que levam a um resultado desejado (ou indesejado). 2. Uma sequência ordenada de interações entre parceiros, particularmente entre um ↑sistema e ↑atores externos. Pode ser uma sequência concreta (cenário "instância") ou um conjunto de sequências potenciais (cenário "tipo", ↑caso de uso).
Checking (de requisitos)	Compreende a ↑validação dos ↑requisitos e verificação desses requisitos em termos de qualidade como ↑não-ambiguidade ou compreensibilidade. Vale assinalar que certas fontes definem a validação de forma mais ampla, considerando os termos checking e validação como ↑sinônimos
Classe	Representa um conjunto de objetos do mesmo tipo pela descrição da estrutura dos objetos, e os meios pelos quais os objetos podem ser manipulados e como se comportam
Cliente	Uma pessoa ou organização que recebe um produto ou serviço. Ver também ↑stakeholder.
Comitê de controle de mudanças	Uma comissão de representantes do cliente e do fornecedor que decide sobre ↑solicitações de mudança
Comitê diretivo	Um comitê que supervisiona um projeto.
Compliance	A capacidade de um ↑artefato de cumprir ↑normas, padrões, regulamentos, leis ou outros documentos formalmente impostos. Os ↑sistemas com frequência precisam cumprir normas, padrões, regulamentos e leis que restringem o domínio onde o sistema atua. Tal cumprimento somente pode ser assegurado de forma sistemática se a verificação do cumprimento já estiver presente desde o início nos ↑requisitos.
Completude (de requisitos)	1. Para um único requisito: expressa até que ponto um requisito contém todas as informações necessárias. 2. Para uma especificação de requisitos: expressa até que ponto uma especificação contém todas as informações necessárias para desenvolver um sistema que atenda aos desejos e necessidades dos ↑stakeholders.
Componente	1. Em geral: Uma parte delimitável de um ↑sistema. 2. Na arquitetura de software: Um conjunto delimitado de objetos ou ↑classes coerentes que fornecem um serviço. Observação: Quando visto isoladamente, um componente é um ↑sistema em si
Confiabilidade	A capacidade de um ↑sistema de conservar um nível especificado de ↑funcionalidade e desempenho quando utilizado em condições especificadas. A confiabilidade pode ser expressa como um ↑requisito de qualidade.
Configuração	Um conjunto consistente de unidades logicamente coerentes. As unidades são ↑artefatos individualmente identificáveis ou partes de artefatos (por exemplo, ↑requisitos) com, no máximo, uma versão por unidade.
Conformidade (de requisitos)	Característica que expressa até que ponto uma ↑especificação de requisitos está em conformidade com determinados regulamentos em alguma ↑norma ou padrão
Consistência (de requisitos)	Característica que expressa até que ponto um conjunto de ↑requisitos está isento de afirmações contraditórias.
Contexto	1. Em geral: O conjunto integrado de pensamentos e significados necessários para compreender fenômenos e afirmações. 2. Especialmente na ER: A parte de um ↑ambiente de sistema relevante para compreender o sistema e seus ↑requisitos. Contexto nesse segundo significado também é chamado de ↑contexto do sistema.
Contexto do sistema	A parte de um ↑ambiente de sistema que é relevante para a definição e a compreensão dos ↑requisitos de um ↑sistema a ser desenvolvido.
Correção	Característica que expressa comprovadamente que uma informação contida em um ↑artefato é verdadeira. Na ER, o termo exatidão é utilizado com frequência como sinônimo de ↑adequação.
Daily Scrum	É a atividade de inspecionar o progresso rumo ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planejado que se aproxima.
Defeito	Um ponto num ↑artefato que é incorretamente descrito ou construído. Sinônimo: defeito (fault), bug
Descoberta de requisitos	→ Elicitação de requisitos
Diagrama de atividades	Um tipo de diagrama em ↑UML que modela o fluxo de ações em um ↑sistema ou em um ↑componente, incluindo fluxos de dados e áreas de responsabilidade, quando necessário.
Diagrama de caso de uso	Um tipo de diagrama em UML que modela os ↑atores e os ↑casos de uso de um ↑sistema. O limite entre os atores e os casos de uso constitui o ↑limite do sistema.
Diagrama de classes	Uma representação diagramática de um ↑modelo de classes
Diagrama de transição de estados	Uma representação diagramática de uma ↑máquina de estados.
Diagrama de fluxo de dados	Um diagrama que modela a ↑funcionalidade de um ↑sistema ou de um ↑componente por meio de processos (também chamados de atividades), bancos de dados e fluxos de dados. Os fluxos de dados que entram no sistema desencadeiam processos que então utilizam os dados recebidos, transformam os mesmos, lêem/escrevem dados persistentes em bancos de dados e posteriormente produzem novos fluxos de dados, os quais podem ser resultados intermediários, que desencadeiam outros processos, ou resultados finais que vão sair do sistema.
Diagrama de sequência	Um tipo de diagrama em ↑UML que modela as interações entre um conjunto selecionado de objetos e/ou ↑atores na ordem em que essas interações ocorrem
Diagrama do contexto	1. Uma representação diagramática de um ↑modelo de contexto. 2. Na ↑análise estruturada, o diagrama do contexto é a raiz da hierarquia do diagrama de fluxo de dados
Diagrama entidade-relacionamento	Uma representação gráfica de um ↑modelo entidade-relacionamento.
Documento de requisitos	Um documento consistindo de uma ↑especificação de requisitos. Com frequência usado como sinônimo de ↑especificação de requisitos.
Domínio	Um escopo de aspectos relevantes para determinada questão; por exemplo, um ↑domínio de aplicação.
Domínio de aplicação	Aqueles elementos do mundo real que são relevantes para determinar o ↑contexto de um ↑sistema
Efetividade	Característica que expressa até que ponto algo acontece da maneira como efetivamente deveria ocorrer. Na ER, tipicamente expressa até que ponto um ↑sistema efetivamente capacita seus ↑usuários a alcançarem suas ↑metas, conforme especificadas nos ↑requisitos do sistema
Eficiência	Característica que expressa até que ponto um resultado é alcançado com mínimo consumo de recursos.
Elicitação (de requisitos)	→ Elicitação de requisitos
Elicitação de requisitos	O processo de procurar, capturar e consolidar ↑requisitos nas ↑fontes de requisitos disponíveis. Pode incluir a reconstrução ou criação de requisitos. Sinônimo: Descoberta de requisitos
Engenharia de Requisitos	Uma abordagem sistemática e disciplinada para a ↑especificação e gerenciamento de ↑requisitos com as seguintes ↑metas: (1) Conhecer os ↑requisitos relevantes, alcançar um consenso entre os ↑stakeholders a respeito desses ↑requisitos, documentar o acordo com os padrões estabelecidos e gerencia-lo de forma sistemática, (2) Compreender e documentar os desejos e necessidades dos ↑stakeholders, (3) Especificar e gerenciar os ↑requisitos para minimizar o risco de entregar um ↑sistema que não atenda aos desejos e necessidades dos ↑stakeholders. Abreviação: ER Observação: As três metas contemplam importantes facetas da ER: (1) a orientação para o processo, (2) o foco no stakeholder e (3) a importância das considerações de risco e valor agregado.
Engenheiro de requisitos	Uma pessoa que, trabalhando em conjunto com os ↑stakeholders, elicita, documenta, valida e gerencia ↑requisitos
Entidade	1. Em geral: um elemento ou conjunto de elementos que pode representar qualquer item concebível, por exemplo, um ↑sistema, uma parte da realidade, uma coisa, uma organização, um processo. 2. Na modelagem entidade-relacionamento: um objeto individual que tem uma identidade e não depende de outro objeto
Erro	Uma discrepância entre o comportamento ou resultado observado e o comportamento ou resultado especificado. Um erro tipicamente é um sintoma da existência de um ↑defeito em algum ↑artefato. Em linguagem coloquial, às vezes não há distinção entre erro e defeito.
Escopo (de um sistema)	O leque de aspectos que podem ser formatados e projetados durante o desenvolvimento de um ↑sistema.
Especificação	Uma descrição sistemática das propriedades de uma ↑entidade atendendo a determinados critérios. Pode tratar-se de propriedades exigidas (↑especificação de requisitos) ou de propriedades a ser implementadas (por exemplo, uma especificação técnica de produto)
Especificação de requisitos do cliente	Uma descrição esboçada em linhas gerais, contendo as capacidades exigidas de um ↑sistema a partir da perspectiva do ↑cliente, geralmente fornecida pelo próprio cliente
Especificação de requisitos	Uma coleção de ↑requisitos, representada de forma sistemática, tipicamente por um ↑sistema ou ↑componente, atendendo a determinados critérios. Em algumas situações é feita uma distinção entre ↑especificação de requisitos do cliente e uma ↑especificação de requisitos do sistema ou ↑especificação de requisitos de software (escrita pelo fornecedor). A especificação de requisitos pode também referir-se à própria atividade de especificar os requisitos.
Especificação de requisitos de software	Uma ↑especificação de requisitos relacionada a um software.
Especificação de requisitos do sistema	Uma ↑especificação de requisitos relacionado a um ↑sistema. Com frequência considerado um sinônimo de ↑especificação de requisitos
Feature	1. Uma característica delimitável de um ↑sistema que agrega valor para os ↑stakeholders. 2. Normalmente abrange vários ↑requisitos, sendo utilizada para comunicar-se com os stakeholders em um nível mais alto de abstração e para expressar características variáveis ou opcionais
Ferramenta (na engenharia de software)	Um ↑sistema (software) que ajuda a desenvolver, operar e fazer a manutenção de ↑sistemas. Na ER, ferramentas fornecem apoio para o ↑gerenciamento de requisitos, bem como para a modelagem, documentação e validação de ↑requisitos
Fonte de requisitos	A fonte da qual um ↑requisito foi obtido. Fontes típicas incluem: ↑stakeholders, documentos, ↑sistemas existentes e observações.
Fornecedor	Uma pessoa ou organização que fornece um produto ou serviço a um ↑cliente
Funcionalidade	As capacidades de um ↑sistema conforme expressas por seus ↑requisitos funcionais
Gerenciamento de requisitos	O processo de gerenciar ↑requisitos existentes e ↑artefatos relacionados a requisitos. Inclui especificamente o armazenamento, a mudança e o rastreamento de requisitos (↑rastreabilidade).
Glossário	Uma coleção de definições de termos relevantes para algum ↑domínio. Com frequência, um glossário também contém referências cruzadas, ↑sinônimos, ↑homônimos, acrônimos e abreviações
Homônimo	Um termo idêntico a outro, mas com significado diferente. Por exemplo, em inglês, bill como uma cédula de dinheiro e bill como uma lista (bill of materials) são homônimos.
Incremental	Processo de desenvolvimento de software em que a cada período de tempo é desenvolvido uma parte inteira do software. Esse parte geralmente é entregue a cada Release.
Inspeção	Um tipo de ↑revisão onde o ↑artefato sob revisão é inspecionado por um grupo de especialistas de acordo com determinados critérios. As considerações dos especialistas são então coletadas e consolidadas.
Iterativa	Processo de desenvolvimento de software que em cada iteração, se avança no conhecimento do projeto, novos requisitos são elicitados e a arquitetura do software é revisada.
Limite do contexto	Limite entre o ↑contexto de um ↑sistema e aquelas partes do ↑domínio de aplicação que são irrelevantes para o ↑sistema e seus ↑requisitos. O limite do contexto separa a parte relevante do ambiente de um sistema a ser desenvolvido da parte irrelevante, isto é, da parte que não influencia o sistema a ser desenvolvido e que, dessa forma, não precisa ser levada em consideração durante a ER
Limite do sistema	O limite entre um ↑sistema e o ↑contexto ao seu redor. O limite do sistema separa o ↑sistema a ser desenvolvido de seu ambiente; isto é, ele separa a parte da realidade passível de modificação ou alteração pelo processo de desenvolvimento, dos aspectos do ambiente que não podem ser alterados ou modificados pelo processo de desenvolvimento
Linguagem	Um conjunto estruturado de sinais para expressar e comunicar informações. Sinais são elementos usados para comunicação, por exemplo: expressões em determinada linguagem, símbolos e gestos.
Linguagem de especificação	Uma ↑linguagem artificial criada para formular especificações
Linguagem de modelagem	Uma ↑linguagem para expressar ↑modelos de um determinado tipo. Pode ser textual, gráfica, simbólica ou alguma combinação entre esses elementos.
Manutenibilidade	A facilidade com que um ↑sistema de software pode ser modificado para corrigir ↑defeitos ou para adaptar o sistema a diferentes necessidades. A manutenibilidade, ou mantenabilidade, pode ser expressa como um ↑requisito de qualidade.
Máquina de estados	Um ↑modelo descrevendo o comportamento de um sistema ou ↑componente por meio de um conjunto finito de estados e transições de estados. As transições de estados são desencadeadas por eventos, podendo por sua vez desencadear ações e novos eventos. Termos relacionados: Uma máquina de estados com estados atômicos é chamada de autômato finito. Máquinas de estados com estados hierarquicamente e/ou ortogonalmente decompostos são chamadas ↑statecharts.
Meta	Um conjunto de situações, eventos ou estados que um ↑stakeholder deseja alcançar. As metas descrevem as intenções dos ↑stakeholders, podendo assim estar mutuamente em conflito
Modelo	Uma representação abstrata de uma realidade existente ou de uma realidade a ser criada. Essa definição abrange o uso mais frequente na Engenharia de Requisitos, mas é um pouco estreita. Em termos mais gerais, um modelo é uma representação abstrata de uma ↑entidade existente ou uma entidade a ser criada, sendo que entidade denota qualquer parte da realidade ou qualquer conjunto concebível de elementos ou fenômenos, incluindo outros modelos. A entidade é chamada de original em relação a um modelo. Na ↑Engenharia de Requisitos, ↑requisitos podem ser especificados por modelos. Vale lembrar que o termo ↑entidade nessa definição está sendo usado em seu significado mais geral, que é diferente daquele utilizado no termo ↑Modelo entidade-relacionamento
Modelo de classes	Um modelo constituído por um conjunto de classes e os relacionamentos entre as mesmas
Modelo de comportamento	Um ↑modelo que descreve o comportamento de um ↑sistema ou ↑componente, por exemplo, em uma ↑máquina de estados.
Modelo de contexto	Um ↑modelo que descreve um ↑sistema em seu ↑contexto
Modelo de metas	Um ↑modelo que representa determinadas ↑metas como uma estrutura ordenada de submetas
Modelo de requisitos	Um ↑modelo criado com o propósito de especificar os ↑requisitos.
Modelo entidade-relacionamento	Um ↑modelo de dados relevantes para um ↑sistema, ou dos dados de um ↑domínio de aplicação. Um modelo entidade-relacionamento é constituído por um conjunto de tipos de entidades, cada um dos quais caracterizado por ↑atributos e interligados por relacionamentos
Modificabilidade (de um artefato)	Característica que expressa até que ponto um ↑artefato é passível de modificação
Multiplicidade	→ Cardinalidade
Não ambiguidade (de requisitos)	Característica que expressa até que ponto um ↑requisito está formulado de modo a evitar que seja compreendido de alguma outra maneira por diferentes pessoas.
Padrão	Um regulamento uniforme para observar, fabricar ou executar algo
Ponto de visão	Determinada perspectiva sobre os ↑requisitos de um ↑sistema. Pontos de vista típicos são as perspectivas de um ↑stakeholder ou grupo de stakeholders (por exemplo, a perspectiva de um usuário final, ou a perspectiva de um operador). Porém, também pode haver pontos de vista específicos, como a perspectiva da ↑segurança (security). Vale lembrar que essa definição é um pouco diferente da definição do ponto de vista arquitetural no Padrão ISO/IEC42010: 2007 (IEEE Std 1471-2000)
Portabilidade	A facilidade com a qual um ↑sistema pode ser transferido para outra plataforma (ao mesmo tempo preservando sua ↑funcionalidade). A portabilidade pode ser expressa como um ↑requisito de qualidade.
Prioridade (de um requisito)	A importância de um ↑requisito comparado a outros requisitos, de acordo com determinados critérios.
Product Backlog	É uma lista emergente e ordenada do que é necessário para melhorar o produto. É a única fonte de trabalho levada a cabo pela Scrum Team. Nessa lista são inseridas todas as tarefas que precisam ser executadas ao longo do projeto.
Product Goal	Descreve um estado futuro do produto que pode servir de meta para a Scrum Team delinear o seu planeamento. O Product Goal está no Product Backlog. O resto do Product Backlog surge para definir "o que" o Product Goal irá cumprir. O Product Goal é o objetivo a longo prazo para a Scrum Team. Devem cumprir (ou abandonar) um objetivo antes de assumirem o próximo.
Product Owner (PO)	Pessoa responsável por maximizar o valor do produto resultante do trabalho da Scrum Team. ● Desenvolver e comunicar explicitamente o Product Goal; ● Criar e comunicar claramente os itens do Product Backlog; ● Ordenar os itens do Product Backlog; e, ● Assegurar que o Product Backlog é transparente, visível e compreendido Em alguns casos pode ser sinônimo de Engenheiro de Requisitos ou Analista de Negócios.
Protótipo	1. Na produção industrial: uma unidade construída antes do início da produção em série. 2. Na engenharia de software: Um software executável que implementa aspectos críticos de um ↑sistema antecipadamente. Na ↑Engenharia de Requisitos, os protótipos são utilizados como meios para ↑elicitação e ↑validação de requisitos.
Qualidade	Dimensão que expressa até que ponto um conjunto de características inerentes a uma ↑entidade atende aos ↑requisitos. A entidade pode ser um ↑sistema, um serviço, um produto, um ↑artefato, um processo, uma pessoa ou uma organização. Por característica inerente entende-se uma característica ou propriedade distintiva de uma entidade, inerente à própria entidade e que não lhe foi atribuída de forma explícita. Este é o conceito de qualidade geralmente utilizado na indústria. Vale lembrar que qualidade nessa definição simplesmente significa adequação para algum uso pretendido, conforme especificado nos requisitos, em contraste com o conceito coloquial de qualidade e sua típica conotação de excelência.
Rastreabilidade (de requisitos)	A capacidade de rastrear um ↑requisito tanto (1) de volta até sua origem, como também (2) para a frente, até sua implementação em projeto e código, ou (3) para outros requisitos dos quais ele depende (e vice-versa). A origem pode estar nos ↑stakeholders, em documentos, na justificativa para o requisito. A rastreabilidade de um requisito de volta até sua origem também é chamada de rastreabilidade pré-especificação de requisitos. Inversamente, a rastreabilidade de um requisito para a frente, até sua implementação em projeto e código, é chamada de rastreabilidade pós-especificação de requisitos. Às vezes a rastreabilidade de um requisito até sua justificativa é considerada uma categoria de rastreabilidade à parte.
Redundância	Ocorrência múltipla da mesma informação ou recurso
Release	Uma ↑configuração liberada para instalação e uso pelos ↑clientes.
Requisito	1. Uma condição ou capacidade necessária para que um ↑usuário possa resolver um problema ou atingir um objetivo. 2. Uma condição ou capacidade que precisa ser atendida ou apresentada por um ↑sistema ou ↑componente do sistema para cumprir um contrato, uma norma, um padrão, uma especificação ou outros documentos formalmente impostos. 3. Uma representação documentada de uma condição ou capacidade como em (1) ou (2). Observação: A definição acima é a clássica definição da IEEE Std 610.12 de 1990. Como alternativa, também apresentamos uma definição mais moderna: 1. Uma necessidade percebida por um ↑stakeholder. 2. Uma capacidade ou propriedade que um ↑sistema deverá ter. 3. Uma representação documentada de uma necessidade, capacidade ou propriedade
Requisito de desempenho	Um ↑requisito que descreve uma característica de desempenho (por exemplo: prazos, velocidade, volume, capacidade, produtividade). Requisitos de desempenho são considerados uma subcaracterística dos ↑requisitos de qualidade neste glossário, mas podem também ser considerados uma categoria própria dos ↑requisitos não-funcionais.
Requisito de qualidade	Um ↑requisito relacionado a uma questão de qualidade não coberta pelos ↑requisitos funcionais.
Requisito do sistema	Um ↑requisito relacionado a um ↑sistema ou ↑componente de um sistema
Requisito funcional	Um ↑requisito relacionado a um resultado de determinado comportamento a ser fornecido por alguma função do ↑sistema (ou de um ↑componente ou serviço).
Requisito não funcional	Um ↑requisito de qualidade ou uma ↑restrição. ↑Requisitos de desempenho podem ser considerados uma outra categoria de requisitos não-funcionais. Neste glossário, requisitos de desempenho são considerados uma subcategoria dos requisitos de qualidade. Sinônimo: Requisito extra-funcional
Restrição	Um ↑requisito que limita o espaço da solução além do que seria necessário para cumprir os respectivos ↑requisitos funcionais e ↑requisitos de qualidade
Revisão	Uma atividade formal e organizada para a verificação de um ↑artefato por um grupo de especialistas. A revisão pode verificar tanto o conteúdo quanto a conformidade do artefato.
Risco	Um evento que ameaça o sucesso de uma atividade, por exemplo, o desenvolvimento ou a operação de um ↑sistema. Um risco tipicamente é avaliado em termos da probabilidade de sua ocorrência e do seu potencial de causar danos.
Scrum Master	O Scrum Master serve a organização de várias formas, incluindo: ● Liderar, formar e treinar a organização na sua adopção do Scrum; ● Planear e aconselhar implementações de Scrum dentro da organização; ● Ajudar funcionários e stakeholders a compreender e adoptar uma abordagem empírica para trabalhos complexos; e, ● Remover barreiras entre stakeholders e Scrum Teams Em alguns casos o Engenheiro de Requisitos ou Analista de Negócios pode assumir essas funções.
Segurança de uso (Safety)	A capacidade de um ↑sistema de garantir um nível aceitável de probabilidade de que sua operação não resultará em danos físicos, patrimoniais ou ambientais. Em outras palavras, o sistema não oferece perigos. Requisitos de segurança (Safety Requirements) podem ser expressos como ↑requisitos de qualidade ou como ↑requisitos funcionais.
Segurança (Security)	A capacidade de um ↑sistema de proteger (a) seus dados e recursos contra o uso não autorizado, e de proteger (b) seus legítimos ↑usuários contra ataques de negação de serviço (denial of service). Em outras palavras, o sistema está protegido de perigos.
Semântica	O significado de um sinal ou um conjunto de sinais em determinada ↑linguagem
Semi-formal	Algo formal até certo ponto, mas não completamente. Um ↑artefato é considerado semi-formal se algumas de suas partes, mas não todas, estiverem formalizadas. Tipicamente, um artefato semi-formal tem uma ↑sintaxe definida, ao passo que sua ↑semântica está apenas parcialmente definida
Sinônimo	Uma palavra com significado idêntico a outra palavra.
Sintaxe	As regras para construir sinais estruturados em determinada ↑linguagem.
Sistema	1. Em geral: Um princípio de ordenação e estruturação. 2. Na informática: Um conjunto coerente e delimitável de ↑componentes que fornece serviços por meio de ações coordenadas. A ↑Engenharia de Requisitos trata da ↑especificação de ↑requisitos para sistemas constituídos por ↑componentes de software, elementos técnicos (por exemplo, hardware, dispositivos, sensores) e elementos da organização (por exemplo, pessoas, funções, processos comerciais). Observe que um ↑sistema pode incluir outros sistemas. Assim, ↑componentes ou serviços de um sistema também são considerados sistemas
Solicitação de mudança	Na ER: Uma requisição fundamentada para modificar um ou mais ↑requisito(s) de uma ↑baseline.
Sprint	Período utilizado para a conclusão de uma parte de um projeto desenvolvido por meio da metodologia ágil conhecida como Scrum.
Sprint Backlog	É composto pelo Sprint Goal (porquê), o conjunto de itens do Produto Backlog selecionados para o Sprint (o quê), bem como um plano acionável para a entrega do Increment (como). O Sprint Backlog é um plano de e para os Developers. É uma imagem altamente visível e em tempo real do trabalho que os Developers planejam realizar durante o Sprint, a fim de alcançar o Sprint Goal. Consequentemente, o Sprint Backlog é atualizado durante o Sprint à medida que se vai aprendendo mais. Deverá ter detalhe suficiente para que possam inspecionar o seu progresso na Daily Scrum.
Sprint Goal	O Sprint Goal é criado durante o Sprint Planning e depois adicionado ao Sprint Backlog. Durante o trabalho da Sprint, os Developers mantêm o Sprint Goal em mente. Se o trabalho se revelar diferente do que esperavam, colaboram com o Product Owner para negociar o âmbito do Sprint Backlog dentro do Sprint sem afetar o Sprint Goal.
Sprint Planning	Planejamento feito para determinar o trabalho a ser realizado. Este plano resultante é criado pelo trabalho colaborativo de toda a Scrum Team
Sprint Retrospective	Atividade que consiste em planejar formas de aumentar a qualidade e eficácia do processo de trabalho que foi executado na Sprint anterior.
Sprint Review	Atividade realizada para inspecionar o resultado do Sprint e determinar adaptações futuras. A Scrum Team apresenta os resultados do seu trabalho aos principais stakeholders e são discutidos os progressos rumo ao Product Goal
Stakeholder	Uma pessoa ou organização que exerce uma influência (direta ou indireta) sobre os ↑requisitos de um ↑sistema. Influência indireta também inclui situações em que uma pessoa ou organização é impactada pelo sistema.
Statechart	Uma ↑máquina de estados com estados hierarquicamente e/ou ortogonalmente decompostos.
Tabela de decisão	Uma representação tabular e sistemática de uma decisão complexa, que depende de múltiplos critérios
Template de requisito	Um padrão para a estruturação sintática de ↑requisitos individuais. Obs: um ↑template de sentença é um template específico de requisitos, para escrever requisitos em ↑linguagem natural
Template de sentença	Um template para a estrutura sintática de uma sentença que expressa um ↑requisito individual em ↑linguagem natural.
Teste de aceitação	Um teste que avalia se um ↑sistema preenche todos os seus ↑requisitos.
Tipo de requisito	Existem diversos tipos de ↑requisitos. A ↑Engenharia de Requisitos ocupa-se principalmente os ↑requisitos do sistema. Além desses, existem também os requisitos de projeto e os requisitos de processo. Requisitos são tipicamente subclassificados em ↑requisitos funcionais, ↑requisitos de qualidade e ↑restrições. Os dois últimos também são denominados ↑requisitos não-funcionais.
Tolerância a falhas	A capacidade de um ↑sistema de continuar operando normalmente apesar da presença de ↑defeitos (de hardware ou software). A tolerância a falhas pode ser expressa como um ↑requisito de qualidade.
UML	Abreviação de Unified Modeling Language, uma linguagem padronizada para modelagem de problemas e soluções
Usabilidade	A capacidade de um sistema de ser compreendido, aprendido, utilizado e apreciado por seus ↑usuários. A usabilidade (total ou parcial) pode ser expressa como ↑requisitos de qualidade
Usuário	Uma pessoa que usa a ↑funcionalidade fornecida por um ↑sistema. Também chamado usuário final
Usuário final	→ Usuário
Validação (de requisitos)	O processo de verificar se os ↑requisitos documentados são compatíveis com as necessidades dos ↑stakeholders. Vale assinalar que certas fontes definem a validação de requisitos de modo mais amplo, também incluindo nela a verificação (↑checking) de requisitos em termos de qualidade como ↑não-ambiguidade ou compreensibilidade, considerando dessa maneira os termos validação e ↑checking como ↑sinônimos.
Verbo de processo	Um verbo que caracteriza a ação exigida de um ↑requisito escrito em ↑linguagem natural.
Verificabilidade (de requisitos)	Característica que expressa até que ponto o cumprimento de algum ↑requisito por um ↑sistema implementado pode ser verificado, por meio da definição, por exemplo, de testes de ↑aceitação, mensurações ou procedimentos de inspeção
Versão (de uma entidade)	Se uma ↑entidade existe em ocorrências múltiplas e consecutivas, onde cada ocorrência foi criada a partir da modificação de sua antecessora, cada ocorrência é considerada uma versão daquela entidade.
Visualização	Um segmento extraído de um ↑artefato, contendo apenas aquelas partes de interesse atual. Uma visualização pode abstrair ou agregar partes de um artefato.
Walkthrough	Uma forma de ↑revisão onde o autor de um ↑artefato sob revisão apresenta o artefato sistematicamente, passo a passo – (ou seja, walk through) – para um grupo de especialistas. As considerações dos especialistas são então reunidas e consolidadas.