Os requisitos de software são descrição dos recursos e funcionalidades do sistema alvo. Requisitos transmitir as expectativas dos usuários do produto de software. Os requisitos podem ser evidentes ou escondidas, conhecidas ou desconhecidas, esperado ou inesperado do cliente do ponto de vista.

O SRS é um documento que foi criado pelo sistema analista depois que os requisitos são recolhidos a partir de várias partes interessadas. SRS define a forma como o software irá interagir com o hardware, interfaces externas, a velocidade de operação,manutenibilidade, velocidade de recuperação após falhas, segurança.
SRS deve vir para cima com as seguintes características:

• Os requisitos são expressos em linguagem natural.
• Requisitos técnicos são expressos em linguagem estruturada, que é usado dentro da organização.
• Descrição do projeto deve ser escrito no Pseudo-código.
• Formato dos formulários e GUI impressões de tela.
• Condicional e notações matemáticas DFDs etc.

Processo elicitação requisito pode ser representado usando o folloiwng diagrama:

• Coleta de requisitos - os programadores discutir com o cliente e os usuários finais e conhecer suas expectativas através do software.
• Organizar os requisitos - Os desenvolvedores priorizar e organizar os requisitos em 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 nos requisitos de diversas partes interessadas, se eles são, em seguida, é negociado e discutido com os interessados. Requisitos podem então ser priorizados e razoavelmente comprometida.
• As exigências provenientes das diversas partes interessadas. Para remover a ambigüidade e os conflitos, eles são discutidos para maior clareza e exatidão. Exigências irrealistas são comprometidos razoavelmente.
• Documentação - todas as ocasiões formais e informais, funcionais e não-funcionais os requisitos estão documentados e disponibilizados para a fase seguinte.

Requisitos são as bases para todo projeto, definindo o que as partes interessadas de um novo sistema necessitam e também o que o sistema deve fazer para satisfazer as suas necessidades. Os requisitos guiam as atividades do projeto e normalmente são expressos em linguagem natural para que todos possam obter o entendimento. Além dos requisitos definirem os problemas e soluções também devemos definir os riscos e prover soluções satisfatórias casos esses riscos venham a falhar. Dessa forma, os requisitos definem as bases para:

• Planejamento do Projeto
• Gerenciamento de Riscos
• Testes de Aceitação
• Controle de Mudanças

Requisitos: requisitos pobremente organizados, muito mal expressados, probremente relatados para as partes interessadas, mudanças muito rápidas ou desnecessárias, expectativas não realistas.

Gerenciamento de Problemas de Recursos: incapacidade de ter dinheiro suficiente e falta de apoio ou fracasso para impor disciplina e planejamento. Muitas delas surgem pela falta de controle de requisitos.

Politicas: Contribui para o primeiro e segundo problema.

a engenharia de requisitos é o processo pelo qual os requisitos de um produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software. Os requisitos de software são uma das principais medidas de sucesso de um software, visto que se eles atendem aos objetivos e requisitos para os quais foi construído o software e está totalmente de acordo com as necessidades dos clientes. Requisitos são a base para estimativas, modelagem, projeto, implementação, testes e até mesmo para a manutenção. Assim, os requisitos estão presentes ao longo de todo o ciclo de vida de um software. Já no inicio de um projeto temos que levantar os requisitos, entende-los e documentá-los. Como os requisitos são extremamente importantes para o sucesso de um projeto, devemos também realizar atividades de controle da qualidade para verificar, validar e garantir a qualidade dos requisitos. Outra medida fundamental é gerenciarmos a evolução dos requisitos, visto que os negócios são dinâmicos e não temos como garantir que esses requisitos não sofrerão alterações. Dessa forma devemos manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto.

Esta é a fase inicial do processo de engenharia de requisitos. Nessa atividade levam-se em conta as necessidades dos usuários e clientes, informações de domínio, sistemas já existentes na organização, regulamentos vigentes, leis, etc. O objetivo nessa fase é entendermos a organização como um todo, seus processos, necessidades, possibilidades de melhorias e restrições existente. Dessa forma, nos preocupamos na descoberta dos requisitos. Essa fase é bastante complexa e também exige obtermos informações dos interessados, consultar documentos, obter conhecimentos do domínio e estudar o negócio da organização.

Após a atividade de Levantamento de Requisitos inicia-se a atividade de Análise de Requisitos, que é onde os requisitos levantados são usados como base para a modelagem do sistema. Os requisitos são escritos tipicamente em linguagem natural, no entanto, é útil expressarmos requisitos mais detalhados do sistema de maneira mais técnica através de diversos tipos de modelos que podem ser utilizados. Esses modelos são representações gráficas que descrevem processos de negócio, o problema a ser resolvido e o sistema a ser desenvolvido.

Os requisitos e modelos capturados nas etapas de Levantamento de Requisitos e Análise de Requisitos devem ser descritos e apresentados em documentos. A documentação é uma atividade de registro e oficialização dos resultados da engenharia de requisitos. Como resultado, um ou mais documentos devem ser produzidos. Essa documentação escrita de uma boa forma apresenta diversos benefícios como facilidade na comunicação dos requisitos, redução no esforço de desenvolvimento, fornece uma base realista para estimativas, boa base para verificação e validação, entre outros benefícios. O Documento de Requisitos deve conter uma descrição do propósito do sistema, uma breve descrição do domínio do problema e listas de requisitos funcionais, não funcionais e regras de negócio, tudo descrito em linguagem natural. Desenvolvedores, clientes, usuários e gerentes utilizam esse documento.

Essa fase deve ser iniciada o quanto antes no processo de desenvolvimento de software. Os requisitos são a base para o desenvolvimento, dessa forma é fundamental que eles sejam cuidadosamente avaliados. Portanto, os documentos produzidos durante a fase anterior devem ser submetidos à verificação e validação de requisitos. A diferença entre verificação e validação é que verificação assegura que o software esteja sendo construído de forma correta. Por sua vez a validação assegura que o software que está sendo desenvolvido é o software correto. Portanto, a verificação assegura que os artefatos produzidos atendem aos requisitos e a validação assegura que os requisitos e o software que foi derivado desses requisitos atendem ao uso proposto. A validação envolve a participação do usuário e do cliente, pois apenas eles possuem condições de confirmar que os requisitos atendem aos propósitos do sistema.

Mudanças nos requisitos ocorrem durante todo o processo de software, desde o levantamento de requisitos até durante a operação do sistema em produção. Isso ocorre devido à descoberta de erros, omissões, conflitos, inconsistência nos requisitos, melhor entendimento dos usuários sobre as suas necessidades, problemas técnicos, mudanças de prioridades do cliente, mudanças no negócio, concorrentes, mudanças econômicas, mudanças no ambiente de software, mudanças organizacionais, etc. Para minimizar os problemas causados por essas mudanças é necessário gerenciar requisitos. O Processo de Gerencia de Requisitos envolve atividades que ajudam a equipe a identificar, controlar e rastrear requisitos e gerenciar mudanças de requisitos em qualquer momento ao longo do ciclo de vida do software. Portanto, os objetivos do processo são gerenciar alterações nos requisitos acordados, gerenciar relacionamentos entre requisitos, gerenciar dependências entre requisitos e outros documentos produzidos durante o processo de software

Luis
Thiago Miranda