Validação
Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.
À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.
A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.
Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:
- Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.
- Consistência: não devem existir conflitos entre os requisitos identificados.
- Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.
- Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
- Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
- Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.
- Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.
- Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.
http://pt.wikipedia.org/wiki/Engenharia_de_requisitos
2015
O gerenciamento de requisitos em grandes sistemas envolve o processamento de grandes volumes de informações sobre requisitos, o que exige o uso de apoio automatizado. As ferramentas de software para esse gerenciamento devem ser escolhidas durante a fase de planejamento de gerenciamento de requisitos. As ferramentas de apoio são usadas, principalmente, para
a) identificação de requisitos, classificação de requisitos e gerenciamento de mudanças.
b) classificação de requisitos, armazenamento de requisitos, validação de requisitos e gerenciamento de rastreabilidade.
c) armazenamento de requisitos, gerenciamento de mudanças e gerenciamento de rastreabilidade.
d) classificação de requisitos, validação de requisitos e armazenamento de requisitos.
e) identificação de requisitos, armazenamento de requisitos, classificação de requisitos e gerenciamento de mudanças.
2012
A gestão de requisitos é um conjunto de atividades que tem como principal objetivo ajudar a equipe de projeto a
a) utilizar ferramentas de engenharia de software para modelar os requisitos do sistema, através da UML.
b) identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue.
c) construir um modelo técnico refinado de funções, características e restrições do software.
d) negociar com os clientes os conflitos de prioridade de requisitos e identificar e analisar os riscos associados a cada requisito.
e) avaliar os requisitos quanto à qualidade, garantindo que ambiguidades, inconsistências, omissões e erros tenham sido detectados e corrigidos.