Browse files

added basic requirements

  • Loading branch information...
1 parent 77ac2b9 commit 6b77bb5d4c6b1195cb5bea8c279535129ded5a47 @shantanubala shantanubala committed Sep 12, 2012
Showing with 15 additions and 53 deletions.
  1. +15 −53 architectural_design/architectural_design.tex
@@ -270,74 +270,36 @@ \section{Stakeholders}
and analyze data provided by the STS to make informed business decisions.
- Define each of the key stakeholders and stakeholder groups, explaining
- their interest, needs and concerns for the system.
- A stakeholder is anyone who has an interest in or concern about in the
- system documented in the AD. Consider the following stakeholder
- groups.
- \begin{itemize}
- \item Acquirers, who pay for the system.
- \item Assessors, who check for
- compliance.
- \item Communicators, who create documents and training.
- \item Developers, who create the system.
- \item Maintainers, who evolve and
- fix the system.
- \item Production Engineers, who are responsible for the
- deployment environment.
- \item Suppliers, who provide parts of the
- system.
- \item Support Staff, who help people to use the system.
- \item System Administrators, who keep it running.
- \item Testers, who verify
- that it works.
- \item Users, who have to use the system directly.
- \end{itemize}
- And of course the architect is also a stakeholder in the AD.
\section{Overview of requirements}
- Summarise the key functional and quality property (non-functional)
- requirements for the system.
- Functional requirements define what the system is required to do (for
- example, update customer name and address details). Quality properties
- (aka non-functional requirements) define how the system must behave at
- run-time or design time (for example, it must respond to requests
- within three seconds under a given load; it must be available 99.99\%
- of the time; it must be possible to extend the system to meet certain
- types of new requirement without having to undertake a major
- redesign).
- Avoid going into too much detail which is presented elsewhere; refer
- to external sources, such as requirements documents, SLAs, existing
- systems and so on, wherever possible. Requirements should be numbered
- so that you can refer to them unambiguously elsewhere.
\begin{tabular}[h!]{| p{0.2\textwidth} | p{0.7\textwidth} |}
Reference & Requirement description \\
- R1 & \\
+ R1 & The system must provide business administrators with a detailed
+ history of the location of every truck in the STC fleet. \\
- & \\
+ R2 & The system must be able to receive and store 1,000 GPS datapoints per
+ second. \\
+ \hline
+ \hline
+ R3 & The server interface for storing the trucks' location data musst have
+ an availability of at least 99 percent uptime.
+ \hline
+ R4 & The tracking units present on each of the trucks must have a fallback
+ when data cannot be sent in real-time due to bad network coverage.
+ \hline
+ R5 & The server interface must be capable of receiving an individual data
+ point (the truck's location) or a series of data points (the truck's
+ location history over a period of time).
\section{System scenarios}

0 comments on commit 6b77bb5

Please sign in to comment.