Design e Modelagem do sistema

4.2.3.3 Elaboração do Documento de Requisitos do Sistema Entrada: Esboço dos requisitos do sistema.

O engenheiro de requisitos juntamente com os especialistas técnicos analisam o esboço dos requisitos verificando a viabilidade técnica de cada um dos requisitos de acordo com suas especialidades.

Com base nesta análise o engenheiro de requisitos constrói um documento descrevendo as funcionalidades do sistema em alto nível, para que todos os membros da equipe saibam o que é o sistema e que serviços ele deve prover. Neste documento estão listados os requisitos funcionais e não funcionais do sistema.

Saída: Documento de requisitos do sistema.

4.3

Design e Modelagem do sistema

4.3.1 Objetivo

O objetivo desta etapa da abordagem é com base nos requisitos identificados para o sistema definir os sub-sistemas e os requisitos para cada sub-sistema.

28

CAPÍTULO 4 AGILES: UMA ABORDAGEM ÁGIL PARA O DESENVOLVIMENTO DE PROJETOS DE HARDWARE E SOFTWARE INTEGRADOS

4.3.2 Papéis e Responsabilidades Pode-se identificar os seguintes papéis e suas responsabilidades:

- Engenheiro de software, representa o papel técnico que detém o conhecimento sobre as tecnologias de desenvolvimento dos componentes de software. Este papel é responsável pela definição da arquitetura e tecnologias que serão utilizadas no desenvolvimento do software.

- Engenheiro de hardware, representa o papel técnico que detém o conhecimento sobre as tecnologias de desenvolvimento dos componentes de hardware. Este papel é responsável pela definição da arquitetura e tecnologias que serão utilizadas no desenvolvimento do hardware.

- Design de software, representa o papel técnico que detém o conhecimento sobre as tec- nologias de desenvolvimento dos componentes de design. Este papel é responsável pela definição e prototipagem do design da interface software/usuário.

- Design de produto, representa o papel técnico que detém o conhecimento sobre as tecnolo- gias de desenvolvimento dos componentes de design. Este papel é responsável pela definição e prototipagem do design do produto.

- Usuário, elemento ou papel que irá manusear o sistema em seu dia a dia. A participação deste usuário é fundamental na definição do design da interface e do produto. Ele também pode influenciar nas decisões técnicas tomadas durante a definição da arquitetura.

- Especialista técnicos, conjunto de especialista nas áreas técnicas que serão cobertas du- rante o desenvolvimento do sistema (hardware e software). Com sua experiência e conheci- mento eles ajudam na definição da arquitetura e do design do sistema.

4.3.3 Atividades 4.3.3.1 Refinar os Requisitos Entrada: Documento de requisitos do sistema.

Esta etapa consiste na análise dos requisitos e organização deles em grupos relacionados. Saída: Requisitos organizados em grupos relacionados.

4.3.3.2 Identificar os sub-sistemas Entrada: Requisitos organizados em grupos relacionados.

Nesta etapa, de acordo com os requisitos organizados em grupos relacionados é possível fazer um levantamento dos subsistemas necessários para o funcionamento do projeto.

Saída: Lista de sub-sistemas.

4.3.3.3 Relacionar sub-sistemas e requisitos Entrada: Documento de Requisitos e lista de sub-sistemas.

Nesta etapa cada conjunto de requisitos comuns agrupados serão relacionados com os sub- sistemas onde serão implementados.

4.3 DESIGN E MODELAGEM DO SISTEMA 29

4.3.3.4 Especificar as funcionalidades dos sub-sistemas Entrada: Especificação do sub-sistemas.

Os requisitos dos sub-sistemas estão até o momento descritos de forma geral em alto nível. Nesta etapa cada requisito ou serviço será desmembrado e a partir deste desmembramento serão encontrados outros requisitos para os sub-sistemas relacionados ao requisito. Várias técnicas podem ser utilizadas para fazer este desmembramento. Neste trabalho propomos a utilização de Casos de Uso [31] para especificação de requisitos mais simples e a análise de Cenários [42] para tarefas mais complexas, que podem dar origem a muitos requisitos ou pertencer a mais de um sub-sistema.

Saída: Especificação do sub-sistemas.

4.3.3.5 Definir as interfaces dos sub-sistemas

Entrada: Especificação para cada sub-sistemas e Documento de requisitos do sistema.

Nesta etapa será feita uma análise dos requisitos de cada sub-sistema para compreender os serviços que cada um deles irá implementar e identificar como cada um destes serviços influen- cia o ambiente e os outros componentes do sistema. Com base nesta análise os engenheiros irão montar um diagrama que retrata os relacionamentos, entradas e saídas que devem ser providas para cada sub-sistema. Este diagrama é considerado a arquitetura do sistema.

Saída: Especificação dos sub-sistemas (o documento é incrementado com as interfaces de entrada e saída para cada subsistema) e Documento de Requisitos do sistema (atualizado com a arquitetura do sistema).

4.3.3.6 Definição da Arquitetura do Sistema

Entrada: Documento de requisitos do sistema e especificação para cada sub-sistema.

Nesta etapa a equipe técnica se reúne e define a arquitetura de cada sub-sistema. A ar- quitetura de cada sub-sistema é formada pelas tecnologias de hardware e software necessárias para que os serviços providos por cada sub-sistema possam ser desenvolvidos. A arquitetura de hardware consiste numa análise minuciosa de que equipamentos podem ser integrados ao sistema, se tal equipamento já existe no mercado, custo, impacto no design, etc. A arquite- tura de software consiste na definição da linguagem que será utilizada, como o sistema vai se comportar e se relacionar com o hardware para prover os serviços necessários.

Saída: Especificação do sub-sistema (este documento é incrementado com a Arquitetura dos sub-sistemas).

4.3.3.7 Definição dos critérios de aceitação Entrada: Especificação dos sub-sistemas.

Nesta etapa serão definidos os critérios de aceitação para implementação de cada um dos requisitos especificados para os sub-sistemas, ou seja, qual o critério para se considerar um requisito implementado de uma forma aceitável ou não.

Saída: Especificação dos sub-sistemas (este documento é incrementado com os critérios de aceitação dos requisitos).

30

CAPÍTULO 4 AGILES: UMA ABORDAGEM ÁGIL PARA O DESENVOLVIMENTO DE PROJETOS DE HARDWARE E SOFTWARE INTEGRADOS