03.Eng de Software: Etapas da Eng de Requisitos

03.Eng de Software: Etapas da Eng de Requisitos

1. A engenharia de requisitos reúne as primeiras atividades a serem realizadas nos diversos modelos de processo de software. Seu objetivo é definir o que deve ser feito, e não a forma como será implementado o sistema. Esse campo do saber serve como ponte entre o projeto e a construção do software, definindo as bases do contrato entre o desenvolvedor e o cliente.

   • A meta é sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa do sistema para elaboração do DERS.
     • A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar suas necessidades, negociar uma solução adequada ao seu problema, validar a especificação e administrar os requisitos, na medida em que eles são transformados em um sistema em operação. Para isso, ele é realizado por meio de sete etapas distintas,com base em Pressman (2006) e Sommerville (2007).
       • Concepção ou estudo de viabilidade do sistema
         • De acordo com Sommerville (2007), o estudo de viabilidade é um estudo breve, direcionado, que se destina a responder a algumas perguntas:
           • O sistema contribui para os objetivos gerais da empresa?
           • O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e prazo?
           • O sistema pode ser integrado com outros sistemas já em operação?
         • Para isso, são recomendadas algumas perguntas, tais como:
           • Como a empresa se comportaria se esse sistema não fosse implementado?
           • Quais são os problemas com os processos atuais e como um novo sistema ajudaria a diminuir esses problemas?
           • Que contribuição direta o sistema trará para os objetivos da empresa?
           • As informações podem ser transferidas para outros sistemas e também ser recebidas a partir deles?
           • O sistema requer tecnologia que não tenha sido utilizada anteriormente na empresa?
           • O que precisa e o que não precisa ser compatível com a empresa?
           • Quem vai usar o sistema?
           • Após obter essas respostas, deve-se preparar um relatório de viabilidade.
       • Levantamento dos requisitos
         • Nesta etapa deve-se descobrir mais informações sobre o domínio da aplicação, que serviços o sistema deve oferecer, qual o desempenho exigido, dentre outros fatores. O levantamento de requisitos pode envolver diferentes tipos de pessoas na empresa, ou seja, os stakeholders.
         • Frequentemente os clientes não sabem na realidade o que querem do sistema computacional, a não ser em termos muito gerais. Eles costumam expressar os requisitos utilizando seus próprios termos e com o conhecimento implícito de sua área de atuação.
           • Diferentes stakeholders têm em mente diferentes requisitos e podem expressá-los de maneiras distintas. Além disso,
             • Fatores políticos podem influenciar os requisitos do sistema
             • O ambiente econômico e de negócios
             • O ambiente se modificando durante o projeto
             • Novos requisitos podem surgir por parte dos novos stakeholders
       • Análise de requisitos
         • As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante a análise (ou elaboração) de requisitos. Esta atividade da ER tem por objetivo desenvolver um modelo técnico refinado das funções, características e restrições do software, sendo guiada pela criação e refinamento de cenários do usuário, que descrevem como o usuário final (e outros atores) vão interagir com o sistema
           • Segundo Sommerville (2007), as etapas de levantamento e análise de requisitos são conhecidas em conjunto como elicitação de requisitos, e envolvem:
             • Compreensão do domínio:
               • Os analistas devem desenvolver sua compreensão do domínio da aplicação. Por exemplo, se for um sistema para uma loja, o analista deverá descobrir como operam as lojas de varejo.
             • Coleta de requisitos:
               • É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. Certamente a compreensão do domínio tem um maior desenvolvimento durante essa atividade.
             • Classificação:
               • Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes.
             • Resolução de conflitos:
               • Quando múltiplos stakeholders estão envolvidos, os requisitos podem apresentar conflitos.
             • Definição das prioridades:
               • Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve a interação com os stakeholders para descobrir os requisitos mais importantes
             • Verificação de requisitos:
               • Os requisitos são verificados, a fim de se descobrir se eles são completos e consistentes e se estão em concordância com o que os stakeholders realmente desejam do sistema.
       • Negociação dos requisitos
         • A negociação categoriza e organiza os requisitos em subconjuntos relacionados. Neste passo as seguintes perguntas devem ser respondidas:
           • Cada requisito está de acordo com o objetivo global do sistema?
           • Todos os requisitos foram especificados no nível de abstração adequado?
           • O requisito é realmente necessário ou representa uma característica adicional que pode não ser essencial para o objetivo do sistema?
           • Cada requisito é limitado e não ambíguo?
           • Cada requisito tem atribuição? Será utilizado por alguém?
           • Algum requisito apresenta conflito com outro(s)?
           • Cada requisito é realizável no ambiente técnico?
           • Cada requisito pode ser testado quando estiver implementado?
           • Qual é a prioridade de tal requisito?
       • Especificação dos requisitos
         • A especificação de requisitos geralmente é um documento escrito, que contém o detalhamento do sistema, os requisitos funcionais e não funcionais e os modelos do sistema que podem ser representados por meio de diagramas, como o IDEF0 (Integration Definition for Function Modeling), os diagramas de casos de uso da UML (Unified Modeling Language), os diagramas de classes preliminar e os diagramas de sequência e prototipação.
       • Validação dos requisitos