The IT Specialist registers the
users and gives various users accounts. Registration involves inputting
username, password, email.
Logging in involves inputting
username and password.
The system accepts inputs entered by the
user in form of material requisition.
Feature: Project manager –
Inputting material requisition fields
Scenario:
Required information for material requisition
Given
the Project manager wants to send a request form to procurement manager. The
inputs include.
Employee
name, date, material, quantity, unit cost and extended cost
Then
the project manager should be able to send the request form.
The system accepts inputs entered by the
user in form of operation cost.
Feature: Project manager –
Inputting operation cost.
Scenario:
Required information for operation cost.
Given
the Project manager wants to enter operation cost. The inputs include.
Employee
name, Payroll type, payroll, description of work.
Then
the project manager should be able to generate operation cost.
Response to illegal inputs:
Please
enter figures
The system accepts inputs entered by the
user in form of operation cost.
Feature: Project manager – Inputting
Fleet condition
Scenario:
Required information for fleet condition
Given
the Project manager wants to enter fleet condition. The inputs include.
Employee
name, company, vehicle condition, vehicle number.
Then
the project manager should be able to check fleet condition.
Response to illegal inputs:
Please
enter all fills.
The system accepts inputs entered
by the user in form of appointment or meetings.
Feature:
Project manager – Inputting appointments
Scenario:
Required information for appointments.
Given
the Project manager wants to enter an appointment to meet other employees. The
inputs include.
topic,
place, date, members.
Then
the project manager should be able to create appointments meeting.
Response
to illegal inputs:
Please
enter all fills.
The system accepts inputs entered
by the user in form of attendance list.
Feature:
Field supervisor – attendance list
Scenario:
Required information for attendance list.
Given
the Field supervisor or Foreman wants to enter an attendance of employees. The
inputs include.
Employee
name, date.
Then
the Foreman should be able to create an attendance list.
Response
to illegal inputs:
Please
enter all fills.
The system accepts inputs entered
by the user in form of time sheet.
Feature:
Field supervisor – a time sheet
Scenario:
Required information for a time sheet.
Given
the Field supervisor or Foreman wants to enter a time sheet form. The inputs
include.
Employee
name, days worked, situation occurrences, total days
Then
the Foreman should be able to create a time sheet.
Response
to illegal inputs:
Please
enter all fills.
The system accepts inputs entered
by the user in form of attendance list.
Feature:
Field supervisor – materials
Scenario:
Required information for materials.
Given
the Field supervisor or Foreman wants to enter remaining materials after field
activities. The inputs include.
Item
number, Item name, Item description.
Then
the Foreman should be able to create an material report.
Response
to illegal inputs:
Please
enter all fills.
The system accepts inputs entered
by the user in form of photo description text.
Feature:
Field supervisor – photo description
Scenario:
Required information for photo description.
Given
the Field supervisor or Foreman wants to enter remaining materials after field
activities. The inputs include.
Item
number, Item name, Item description.
Then
the Foreman should be able to create an material report.
Response
to illegal inputs:
Please
enter all fills.
The system accepts inputs entered by the
user in form of attendance list.
Feature: Procurement manager –
deliver note
Scenario:
Required information for Delivery note.
Given
the procurement manager wants to form a delivery note for materials. The inputs
include.
Item
number, Item name, Item description, unit, quantity, senders name, receivers
name.
Then
the procurement manager should be able to create a delivery note.
Response to illegal inputs:
Please
enter all fills.
This
section includes the requirements that specify all the fundamental actions of
the software system.
2.4.1.1 Functional requirement 1.1
ID:
FR1
TITLE: Download mobile application
DESC: A user should be able to
download the mobile tablet application through either an application store or
similar service on the mobile tablet device. The application should be free to
download.
RAT: In order for a user to
download the mobile application.
DEP: None
2.4.1.2 Functional requirement 1.2
ID:
FR2
TITLE: Download and notify users of
new releases
DESC: When a new/updated version or
release of the software is released, the user should check for these manually.
The download of the new release should be done through the tablet device in the
same way as downloading the mobile application.
RAT: In order for a user to
download a new/updated release.
DEP: FR1
2.4.1.3 Functional requirement 1.3
ID:
FR3
TITLE: User registration - Mobile tablet
application
DESC: Given that a user has
downloaded the mobile application, then the user should be able to get registered
through the mobile application. The user must provide Full names, user-name,
password and e-mail address.
RAT: In order for a user to
register on the mobile application.
DEP: FR1
2.4.1.4 Functional requirement 1.4
ID:
FR4
TITLE: User log-in - Mobile
application
DESC: Given that a user has registered,
then the user should be able to log in to the mobile application using username
and password given to him by IT Specialist.
The log-in information will be
stored in the tablet device and in the future the user should be logged in automatically.
RAT: In order for a user to
register on the mobile application.
DEP: FR1, FR3
2.4.1.5 Functional requirement 1.5
ID:
FR5
TITLE: Retrieve password
DESC: Given that a user has
registered, then the user should be able to retrieve his/her password by contacting
an IT Specialist.
RAT: In order for a user to
retrieve his/her password.
DEP:
FR1
2.4.1.6 Functional requirement 1.6
ID:
FR6
TITLE: Mobile application - tasks
DESC: Given that a user is logged
in to the mobile application, then the first page that is shown should be the
home page. The user should be able to view various tasks performed by the
various stake holders of the company. The project manager should be able to
view particular contracts that the company has won and they should be given a particular
contract to manage. A procurement officer should be able to select the
suppliers that are willing to supply various materials for project
implementation. The manager should be able to add comments on field activities.
RAT: In order for a user to view tasks
for various stake holders.
DEP:
FR4
2.4.6.1 Functional requirement 6.1
ID:
FR24
TITLE: Mobile application – make Advice.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to advice various stake holders
on their performances at various sites and activities performed.
RAT: In order to advice
stake holders on their activities performed.
DEP:
FR4
2.4.6.2 Functional requirement 6.2
ID:
FR25
TITLE: Mobile application – write Comment.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to write
Comment on the various works of the stake holders.
RAT: In order to write
comments.
DEP:
FR4
2.4.6.3 Functional requirement 6.3
ID:
FR26
TITLE: Mobile application – view Captured Image.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to view
captured images on the various works at the remote sites.
RAT: In order to view
captured images.
DEP:
FR4
Mobile
Context: When using computer tablets applications the user is not tied to a
single location. They may also be interacting with nearby people, objects and
environmental elements which may distract their attention.
Connectivity:
Connectivity is often slow and unreliable on tablet devices. This will impact
the performance of tablet applications that utilize these features.
Small
Screen Size: In order to provide portability tablet devices contain relatively
limited screen size and so the amount of information that can be displayed is
limited.
Different
Display Resolution: The resolution of tablet devices is reduced from that of
desktop computers resulting in lower quality images.
Limited
Processing Capability and Power: In order to provide portability, tablet devices
often contain less processing capability and power. This will limit the type of
applications that are suitable for tablet devices.
Data
Entry Methods: The input methods available for tablet devices are different
from those for desktop computers and require a certain level of proficiency.
This problem increases the likelihood of erroneous input and decreases the rate
of data entry.
By
default, when the system is first installed, it contains only one user who has
been given the (username and password) for security reasons, the password can
be changed through an IT Specialist name who assigns usernames and passwords to
users of the application, Then the user logs onto the dashboards in which he
can view various tasks performed in various departments and then he is
restricted to access certain modules if he/she is not given access to access
that module.
This
section contains all of the functional and quality requirements of the system.
It gives a detailed description of the system and all its features.
A
first-time user of the mobile application should see the log-in page when
he/she opens the application, see Figure 1. If the user has not registered,
he/she should be able to do that on the IT Specialist page.
If
the user is not a first-time user, he/she should be able to see the Home page
directly when the application is opened, see Figure 2. Here the user chooses
what he/she wants to conduct.
The EDT application communicates with the
database in order to get the information about the Employees. The between the
database and the tablet application consists of reading and modifying the data operations.
The communication between the different
parts of the system is important since they depend on each other. However, in
what way the communication is achieved is not important for the system and is therefore
handled by the underlying operating systems for both the tablet application and
the database
The requirements in this section provide
a detailed specification of the user interaction with the software and
measurements placed on the system performance
ID:
QR1
TITLE: Prominent task feature
DESC: The task feature should be
prominent and easy to find for the user.
RAT: In order to for a user to find
the task feature easily.
DEP: none
ID:
QR2
TITLE: Prominent task feature
DESC: The task feature should be
prominent and easy to find for the user.
RAT: In order to for a user to find
the task feature easily.
DEP: none
ID:
QR3
TAG: ResponseTime
GIST: The fastness of the task
SCALE: The response time of a task
METER: Measurements obtained from
1000 tasks during testing.
MUST: No more than 2 seconds 100%
of the time.
WISH: No more than 1 second 100% of
the time.
ID:
QR4
TAG: SystemDependability
GIST: The fault tolerance of the
system.
SCALE: If the system loses the connection to the
Internet the system gets some
strange input, the user should be
informed.
METER: Measurements obtained from
1000 hours of usage during testing.
MUST: 100% of the time.
Development tools used to implement the
system, notes on anomalies, module and integration details
ID:
QR5
TAG: HardDriveSpace
GIST: Hard drive space.
SCALE: The application’s need of
hard drive space.
METER: MB.
MUST: No more than 20 MB.
PLAN: No more than 15 MB.
WISH: No more than 10 MB.
MB: DEFINED: Megabyte
ID:
QR6
TAG: ApplicationMemoryUsage
GIST: The amount of Operate System
memory occupied by the application.
SCALE: MB.
METER: Observations done from the
performance log during testing
MUST: No more than 20 MB.
PLAN: No more than 16 MB
WISH: No more than 10 MB
Operate System: DEFINED: The
Android Operate System which the application is running on.
MB: DEFINED: Megabyte.
TAG: ProjectManagerLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a project manager tries to log in to the application
with a non-existing account then the project manager should not be logged in.
The project manager should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR14
TAG: ForemanLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a Foreman tries to log in to the application
with a non-existing account then the Foreman should not be logged in. The
Foreman should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR15
TAG: CEOLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a CEO tries to log in to the application
with a non-existing account then the CEO should not be logged in. The CEO
should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR16
TAG: UserCreateAccountSecurity
GIST: The security of creating
account for users of the system.
SCALE: If a user wants to create an account and the
desired user name is occupied, the user should be asked to choose a different user
name.
METER: Measurements obtained on
1000 hours of usage during testing.
MUST: 100% of the time.
The report document has been
developed out of the design document and the readers of this document are:
The software developers, the system
analysts, the Users, the programmers
In order to get a view of how to
divide the requirements into different releases and what requirements should be
included in which release, a prioritization of the requirements is needed. This
section discusses the choice of prioritization methods and gives a suggestion
of how the release plan for these requirements could look like [1].
When prioritizing the requirements
the ten most important ones were picked out first. This was done with a simple
“1 to 10” ranking method, with one being “not important” and ten “very
important”. Based on the elicitation meetings, and the perceived ideas of what
was important to the different stakeholders, a number was set for each
requirement. The numbers were then summed up for each requirement and the ten
with the highest score were chosen to be prioritized with the cost value
approach. The results, which are red-marked, can be seen in Appendix I and as
shown, it turned out to be five functional requirements and five quality
requirements. These requirements were then prioritized according to the cost
value approach and the results can be viewed under Appendix II [2].
The remaining requirements were
prioritized according to the “Five-Way Priority Scheme” as shown in Appendix
III. This method was chosen since it gives the different stakeholders the same
importance and has an enough wide range for determining which requirement is
more important than the other [3].
However, in this prioritization
process, the development team was not included as a stakeholder since the different
features were not considered to be as important to them as for the other
stakeholders. Other methods for
prioritization, such as the hundred-dollar test and the yes-no vote, were also considered.
The hundred-dollar test is quite similar to the five-way priority scheme, since
it also gives a wide range for ranking the requirements. However, it is more
easily misused since someone could save all their money and put them on a
requirement that they think is very important [4]. Others might not agree that
this requirement is important but it might still get the most votes since one
person cared about
The
yes-no vote method might be fairly simple to carry out, however the range is
too narrow. For
instance,
if two requirements are not very important it would be hard to determine which
of those requirements that is more important than the other [4].
In
conclusion, weighing the disadvantages and advantages of these methods against
each other lead us to choose the five-way priority scheme.
Table 2 – Select of ten
most important requirements
DBK
files
HEX
files
PWI
files
Plg
files
BAK
files
Opt
files
C
files
The
application will be obtained from Google place store on your tablet, tap the
play store icon to open the store. The main page in the store will offer you
access to various applications then you can be able to search for this
application and download it by tapping the button on top.
NO
USER MANUAL
Maintenance phase deals with fixing
the issues that were fronted by the mobile users and also involve development/
releasing new features, which can be implemented using mobile application
development life cycle. Integrating new requirements in the use cases,
projecting, developing and finally testing improves the overall caliber of the
application when a systematic procedure is being implemented
Finding and fixing issues.
Make sure developer monitors the
ene to end performance of the application and understand where issues are
occurring before they become major problem for users. Don’t wait for bad
reviews and low ratings to find that your application is having functional
issues.
Communicate with users.
Let the users know what you are
doing and why and most importantly, why everything you do is aimed at making
their experience better and rewarding.
Production consideration: crash and
error reporting.
Chash and error reporting is a
requirement not only for the development of your application but also for testing
and production. There are quite few crash reporting tools available like
BugSense and TestFlight are capable of reporting fatal errors in an
application.
Production consideration: Analytics
and instrumentation
Smart executives are data driven
and mobile application can be a plethora of business intelligence
CHAPTER 7: CONCLUSION AND RECOMMENDATIONS
The
report includes requirements analysis framework which were used for analyzing
requirements used to implement a system. It describes the process with steps
starting with a vague description of a scenario, and then detailing the
scenario description through definition of roles and tasks. These tasks are
then analyzed using Cost-Value Approach.
Although
the framework has been tested against real-world scenarios, and it has been
implemented. The works
included
validating the framework within mobile software system design and testing it as
well.
and
finally performing a performance maintenance and phase out.
