“Uma declaração que identifica uma capabilidade, característica física ou fator de qualidade que define a necessidade de um produto ou processo para o qual uma solução será buscada” (Hood et al., 2007).
“Objetivo mensurável ao qual uma solução deve atender, especificando uma capabilidade ou condição que deve ser satisfeita” (Baki et al., 2009, p. 110; Durugbo, 2013, p. 115).
“Um requisito é uma capacidade que um sistema deve possuir para atender às necessidades dos usuários” (Fernandes & Machado, 2016)
“Requisitos são características necessárias a um produto ou serviço para satisfazer uma necessidade e gerar valor a um cliente ou usuário e deve ser constituído por um atributo e sua respectiva especificação (mensurável)” (Echeveste et al., 2020).
Um requisito é uma condição necessária para estar presente em um produto, serviço ou resultado (de um projeto) para satisfazer uma necessidade. Requisitos, explícitos ou implícitos, podem vir dos stakeholders, um contrato, políticas organizacionais, padrões ou órgãos reguladores, ou uma combinação entre essas fontes (PMI, 2021).
Segundo a norma ISO/IEC/IEEE 24765 (ISO/IEC/IEEE, 2010), um requisito é:
- uma condição ou capacidade de que alguém necessita para resolver um problema ou alcançar um objetivo;
- uma condição ou capacidade que um sistema (ou seu componente) deve possuir ou verificar para satisfazer um contrato, norma, especificação ou outro documento formalmente imposto;
- uma representação documentada de qualquer condição ou capacidade descrita em (1) ou (2).
- uma condição ou capacidade que deve ser atendida ou possuída por um sistema, produto, serviço, resultado ou componente para cumprir um contrato, norma, especificação ou outro documento formalmente imposto. Os requisitos incluem as necessidades, desejos e expectativas quantificadas e documentadas do patrocinador, cliente e demais partes interessadas.
Explicando os elementos da definição:
1. Necessidade do usuário: Corresponde ao requisito como uma condição ou capacidade demandada pelo usuário (ou outra parte interessada) para solucionar um problema ou atingir um propósito específico. Aqui, o foco recai no valor do negócio e na usabilidade (compare com as definições de “necessidade do cliente” e “requisitos dos clientes”).
2. Capacidade do sistema: Trata-se de um requisito que descreve o que o sistema (ou componente) deve efetivamente fazer ou possuir para cumprir obrigações contratuais, atender a regulamentos, padrões ou especificações técnicas. É a dimensão técnica do requisito, garantindo conformidade e desempenho (compare com a definição de “requisitos do produto”).
3. Representação documentada: É a forma oficial (escrita ou registrada em ferramenta) que consolida o requisito. Visa registrar, de maneira rastreável e verificável, a condição ou capacidade tanto do usuário quanto do sistema. Essa documentação serve de referência para as fases de desenvolvimento, validação, testes e manutenção, garantindo que os requisitos sejam efetivamente gerenciados ao longo de todo o ciclo de vida do projeto ou produto.
4. Cumprir um contrato: Este elemento é uma variação do elemento (1) e é praticamente idêntico ao elemento (2). Na versão anterior (vejo o quadro abaixo), este elemento não existia. A única diferença entre os elementos (2) e (4) é que o (2) cita “satisfazer acordos” e o (4) cumprir contratos. É quando existe uma relação contratual que especifica os requisitos. No entanto, o elemento (2) já diz “”ou outro documento formalmente imposto”. Isso na prática faz com que o elemento (4) seja redundante. A frase final do elemento (4) pode se relacionar a todos os outros elementos. Ela explicita que os requisitos podem incluir outras informações.
| Observe que o elemento (1) desta definição incluem as necessidades do usuário (ou outro stakeholder) como sendo requisito.
A norma ISO/IEC/IEEE 24765 – Systems and software engineering – Vocabulary (ISO/IEC/IEEE, 2010) é uma evolução e substituiu a norma IEEE 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (IEEE, 1990). |
Os requisitos descrevem (Cockburn, 1998 apud Wundenberg, 2015):
- as funcionalidades em nível do usuário,
- as propriedades gerais do sistema ou produto,
- as restrições específicas do sistema ou produto,
- as restrições do desenvolvimento.
Definição da ISO 9000:2015 com as notas da própria norma
“Requisito é a necessidade ou expectativa que é declarada, geralmente implícita ou obrigatória” (ISO 9000:2015)
- Nota 1: “Geralmente implícita” significa que é costume ou prática comum para a organização e partes interessadas (stakeholders) que a necessidade ou expectativa sob consideração esteja implícita.
- Nota 2: Um requisito especificado é aquele que é declarado, por exemplo, em informação documentada.
- Nota 3: Um qualificador pode ser usado para indicar um tipo específico de requisito, por exemplo, requisito de produto, requisito de gestão da qualidade, requisito do cliente, requisito da qualidade.
- Nota 4: Requisitos podem ser gerados pelas diferentes partes interessadas ou pela organização propriamente dita.
- Nota 5: Ele pode ser necessário para atingir uma alta satisfação do cliente, para atender a uma expectativa do cliente mesmo que ela não esteja expressa nem implícita de forma geral ou obrigatória.
Em inglês: requirement
| Leia mais na flexM4i sobre: – a definição de “Necessidade do cliente” – a definição de “Requisitos do produto” – a definição de “Requisitos dos clientes” – a definição de “Engenharia de requisitos” – a definição de “Gestão de requisitos”, que é comparada com engenharia de requisitos. |
Baki, B. et al. (2009). An application of integrating SERVQUAL and Kano’s model into QFD for logistics services:A case study from Turkey. Asia Pacific Journal of Marketing and Logistics, v. 21, n. 1, p. 106–126, 2009
Cockburn, A. (1998). Sample system requirements document. Retrieved January 27, 2014, from http://alistair.cockburn.us/Sample+system+requirements+document (não está mais acessivel em 23/01/2025, mas a citação foi encontrada em Wundenberg, 2015 p.4)
Durugbo, C. (2013). Integrated Product-Service Analysis Using SysML Requirement Diagrams. Systems Engineering, v. 16, n. 1, p. 111–123, 2013. doi:10.1002/sys.21229
Echeveste, M. Cannarozzo, M; Sastre, R. (2020) Engenharia de requisitos em sistemas produto-serviço: do modelo de negócio ao conceito. R-PSS: métodos e casos. Marcavisual Editora e Projetos Culturais Ltda. 126p.
Fernandes, J. M., & Machado, R. J. (2016). Requirements in engineering projects. Springer International Publishing.
Hood, C., Wiedemann, S., Fichtinger, S., & Pautz, U. (2007). Requirements management: The interface between requirements development and all other systems engineering processes. Springer Science & Business Media.
IEEE (1990). IEEE standard glossary of software engineering terminology (IEEE Std 610.12-1990). Institute of Electrical and Electronics Engineers.
ISO/IEC/IEEE (2010). ISO/IEC/IEEE 24765: 2010 – Systems and software engineering – Vocabulary. International Organization for Standardization; International Electrotechnical Commission; Institute of Electrical and Electronics Engineers.
ISO 9000:2015. Sistema de Gestão da Qualidade – Fundamentos e vocabulário.
PMI (2021). PMBoK – Guide to the project Management body of knowledge. 7th. ed. Pennsylvania: Project Management Institute, Inc.
Wundenberg, S.-M. (2015). Requirement engineering for knowledge-intensive processes: Reference architecture for the selection of a learning management system. Springer Gabler.
« retornar para home do glossário