thesis: add quality requirements
Parents:
900f2bc1 file(s) changed
- monografia/chapters/app.tex +80 -0
monografia/chapters/app.tex
1 1
\chapter{Nexo}
2 2
3 3
O aplicativo proposto por esse trabalho, denominado "Nexo", se propõe a ser uma
4 4
aplicação para dispositivos móveis, de forma a preencher essas lacunas
5 5
demonstradas tanto pelo questionário, quanto também tentando preencher as
▸ 202 unchanged lines
208 208
209 209
\hline
210 210
\end{longtable}
211 211
\source{Elaborado pelo autor (2026)}
212 212
213 +
\subsection{Requirementos não funcionais}
214 +
215 +
De acordo com \cite[p.~89]{sommerville:2010}: "Requisitos não funcionais são
216 +
restrições sobre os serviços ou funções oferecidas pelo sistema". Ou seja,
217 +
definem os critérios de qualidade que o sistema deve seguir, abrangendo
218 +
aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,
219 +
destacam-se especialmente a preservação da privacidade do usuário, a
220 +
transparência proporcionada pelo código aberto e a possibilidade de utilização
221 +
offline, o que garante acessibilidade mesmo em contextos de conectividade
222 +
limitada.
223 +
224 +
\begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
225 +
\caption{Requisitos não funcionais}
226 +
\label{tab:requisitos_nao_funcionais}
227 +
\hline
228 +
N° &
229 +
Requisito &
230 +
Descrição \\
231 +
232 +
\hline
233 +
234 +
[RNF01] &
235 +
Usabilidade &
236 +
237 +
O sistema deve possuir uma interface intuitiva e acessível para
238 +
usuários leigos em tecnologia, com navegação fluída e confirmações
239 +
visuais após cada interação importante \\
240 +
241 +
\hline
242 +
243 +
[RNF02] &
244 +
Desempenho &
245 +
246 +
O tempo de resposta entre a entrada do usuário e a resposta do sistema
247 +
deve ser inferior a 1 segundo; O carregamento do histórico semanal e
248 +
visualizações de ciclos anteriores deve ocorrer em no máximo 2
249 +
segundos. \\
250 +
251 +
\hline
252 +
253 +
[RNF03] &
254 +
Segurança &
255 +
256 +
Os dados do usuário devem ser armazenados de forma criptografada; O
257 +
sistema deve exigir autenticação segura para acesso; A exportação de
258 +
dados deve sempre exigir a confirmação do usuário \\
259 +
\hline
260 +
261 +
[RNF04] &
262 +
Confiabilidade &
263 +
264 +
O sistema deve garantir a persistência dos dados, mesmo em casos de
265 +
falha de energia ou conexão; Os dados registrados devem ser armazenados
266 +
automáticamente e sincronizados quando ouvir conexão \\
267 +
268 +
\hline
269 +
270 +
[RNF05] &
271 +
Portabilidade &
272 +
273 +
Todos os dados do usuário podem ser exportados a qualquer momento, em
274 +
um formato de texto que permita que ele possa ler e interpretar,
275 +
mediante compreensão mínima da linguagem/formato utilizado \\
276 +
277 +
\hline
278 +
279 +
[RNF06] &
280 +
Privacidade &
281 +
282 +
Nenhuma informação sensível do usuário deve ser compartilhada com
283 +
terceiros e o sistema deve fornecer uma política de privacidade clara e
284 +
acessível; Quaisquer alterações à mesma demanda que o usuário seja
285 +
notificado \\
286 +
287 +
\hline
288 +
\end{longtable}
289 +
\source{Elaborado pelo autor (2026)}
290 +
291 +
Com essas definições em mãos, pode-se avançar para a etapa de modelagem do
292 +
sistema, usando os requerimentos apresentados como fundação para o sistema.