Identificar e Analisar Requisitos de Software
Consiste na análise dos requisitos dos softwares a serem desenvolvidos.
O ponto de partida para a identificação e análise dos requisitos de software é a identificação dos requisitos do software. Isso implica no estabelecimento de uma relação bastante próxima entre os desenvolvedores e o cliente, uma vez que esse processo é reconhecidamente complexo em função das diferenças de linguagem entre esses atores. Sugere-se utilizar as matrizes de especificação do produto para desenvolver descrições textuais dos requisitos do software.
Uma vez estabelecidos os requisitos, passa-se a elaborar casos de uso para o software do produto. Isso significa que é necessário identificar os atores que utilizam o software e seus respectivos papéis na operação do produto. O usuário do produto realiza diversas operações com o software, cada operação deve ser considerada um papel. Há comumente casos de uso relacionados com a interface entre o software e outras partes do produto ou mesmo outros softwares do mesmo produto.
Uma vez estabelecidos os requisitos, passa-se a elaborar casos de uso para o software do produto. Isso significa que é necessário identificar os atores que utilizam o software e seus respectivos papéis na operação do produto. O usuário do produto realiza diversas operações com o software, cada operação deve ser considerada um papel. Há comumente casos de uso relacionados com a interface entre o software e outras partes do produto ou mesmo outros softwares do mesmo produto.
As funções executadas por software nos subsistemas que compõem o produto devem ser identificadas e analisadas através de métodos de engenharia de requisitos.
A engenharia de requisitos se ocupa basicamente de identificar as informações a serem processadas pelo componente de software do produto, assim como alocar funções e comportamento a esse componente. O objetivo da engenharia de requisitos é assegurar que o software a ser desenvolvido atenda com propriedade as necessidades do cliente. Dependendo da complexidade do software, em especial quanto à interface com o usuário, deve-se estabelecer processos rigorosos de levantamento de requisitos. Em sistemas simples, baseados em linguagem assembly e que comportem apenas funções de interface controladas por painéis com botões e sinais luminosos e sonoros, pode-se utilizar apenas de cenários de uso do produto.
Os principais métodos de engenharia de requisitos de software são: a orientação a objetos, para a qual o sistema deve ser modelado com base nas entidades (objetos, classes e tipos) que realizam operações no sistema; e a análise estruturada que parte das funções a serem desempenhadas pelo sistema e a partir delas especifica a estrutura de dados necessária.
Uma vez que o software desenvolvido para os produtos mecatrônicos tem uma intrínseca relação com o hardware do equipamento e todo o sistema é especificado com base no conceito de funções, optou-se por adotar o método de análise estrutura para a sistematização dos requisitos de software.
REF.: PRESSMAN, 2001 apresenta todo o escopo da engenharia de requisitos abordando os dois principais métodos utilizados. BOOCH, 2000 apresenta uma análise detalhada do processo de especificação de software baseado em orientação a objetos. McMENAMIM & PALMER, 1991 discutem com grande detalhe o método de análise estruturada.
A engenharia de requisitos se ocupa basicamente de identificar as informações a serem processadas pelo componente de software do produto, assim como alocar funções e comportamento a esse componente. O objetivo da engenharia de requisitos é assegurar que o software a ser desenvolvido atenda com propriedade as necessidades do cliente. Dependendo da complexidade do software, em especial quanto à interface com o usuário, deve-se estabelecer processos rigorosos de levantamento de requisitos. Em sistemas simples, baseados em linguagem assembly e que comportem apenas funções de interface controladas por painéis com botões e sinais luminosos e sonoros, pode-se utilizar apenas de cenários de uso do produto.
Os principais métodos de engenharia de requisitos de software são: a orientação a objetos, para a qual o sistema deve ser modelado com base nas entidades (objetos, classes e tipos) que realizam operações no sistema; e a análise estruturada que parte das funções a serem desempenhadas pelo sistema e a partir delas especifica a estrutura de dados necessária.
Uma vez que o software desenvolvido para os produtos mecatrônicos tem uma intrínseca relação com o hardware do equipamento e todo o sistema é especificado com base no conceito de funções, optou-se por adotar o método de análise estrutura para a sistematização dos requisitos de software.
REF.: PRESSMAN, 2001 apresenta todo o escopo da engenharia de requisitos abordando os dois principais métodos utilizados. BOOCH, 2000 apresenta uma análise detalhada do processo de especificação de software baseado em orientação a objetos. McMENAMIM & PALMER, 1991 discutem com grande detalhe o método de análise estruturada.
Os casos de uso identificados são transformados em listas de funções a serem posteriormente codificadas. Essa lista de funções é organizada em subsistemas do software que devem ser agrupados em: (1) subsistemas de entrada de dados; (2) funções de processamento e controle; (3) funções de processamento de interfaces; (4) subsistemas de saída de dados; e (5) subsistemas de manutenção e auto-diagnóstico.
A partir da identificação dos casos de uso, com suas listas de funções, e da arquitetura do software, passa-se à análise estruturada propriamente dita. Deve-se confeccionar um diagrama de fluxo de dados de contexto do sistema identificando os principais atores que executam papéis de entrada no sistema e as principais saídas dele. No diagrama de contexto, o software é apenas um círculo demonstrando todas as interfaces de entrada e saída necessárias, passa-se, então a detalhar o sistema confeccionando um diagrama no qual as principais funções que implementam os subsistemas de software identificados na arquitetura aparecem, assim como os principais repositórios de dados. Esse diagrama de nível 1 é desdobrado em um de nível 2 e assim por diante, até que se tenha funções que possam ser testadas isoladamente a título de validação do sistema. As principais entidades do sistema são modeladas através de modelos entidade-relacionamento (MER). Elas são extraídas das descrições das operações realizadas pelos atores sobre o sistema, assim como podem ser identificadas no desdobramento das funções do software.
A partir da identificação dos casos de uso, com suas listas de funções, e da arquitetura do software, passa-se à análise estruturada propriamente dita. Deve-se confeccionar um diagrama de fluxo de dados de contexto do sistema identificando os principais atores que executam papéis de entrada no sistema e as principais saídas dele. No diagrama de contexto, o software é apenas um círculo demonstrando todas as interfaces de entrada e saída necessárias, passa-se, então a detalhar o sistema confeccionando um diagrama no qual as principais funções que implementam os subsistemas de software identificados na arquitetura aparecem, assim como os principais repositórios de dados. Esse diagrama de nível 1 é desdobrado em um de nível 2 e assim por diante, até que se tenha funções que possam ser testadas isoladamente a título de validação do sistema. As principais entidades do sistema são modeladas através de modelos entidade-relacionamento (MER). Elas são extraídas das descrições das operações realizadas pelos atores sobre o sistema, assim como podem ser identificadas no desdobramento das funções do software.
Enfim, é confeccionada uma especificação do comportamento do software. Essa especificação deve ser realizada através de uma tabela de ativação de processos. Nela os eventos que ativam processos do software são relacionados com as funções do nível 1 do sistema.
Os modelos entidade-relacionamento, de arquitetura, de fluxo de dados e de especificação do comportamento do sistema, assim como a descrição das necessidades dos usuários e os casos de uso compõem o documento de análise de requisitos de software. As entradas básicas para essa atividade são o mapa de componentes mecatrônicos e as especificações do produto.
A atividade pode ser posteriormente retomada caso seja detectado no gate que é necessário produzir melhorias na arquitetura do produto.
Os modelos entidade-relacionamento, de arquitetura, de fluxo de dados e de especificação do comportamento do sistema, assim como a descrição das necessidades dos usuários e os casos de uso compõem o documento de análise de requisitos de software. As entradas básicas para essa atividade são o mapa de componentes mecatrônicos e as especificações do produto.
A atividade pode ser posteriormente retomada caso seja detectado no gate que é necessário produzir melhorias na arquitetura do produto.
