eletrotupi / tcc/ commit / 11192d3

thesis: add quality requirements

Pedro Lucas Porcellis porcellis@eletrotupi.com 1 month ago 11192d365abd4e4bf1cac55085657d3ce9c8262b
Parents: 900f2bc
1 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 +
&
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.