0% found this document useful (0 votes)
59 views15 pages

Lab. Report #1 - Project Blastoff Req Inception: P T T C N R G

This lab report discusses the initial requirements for a new project to create a software application. The application aims to help users find and book local services. Key points discussed include: - The purpose is to make it easy for people to find and book quality services locally such as repairs or painting in a fast and safe way. - Stakeholders include developers, testers, designers, service providers, service receivers, banks, and users. - Initial constraints include supporting mobile operating systems and limited initial budget and users. - Risks are identified as potential lack of resources, time constraints, and difficulty promoting the new app. - In conclusion, while challenges are acknowledged, the project is seen as

Uploaded by

Moetez Skouri
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views15 pages

Lab. Report #1 - Project Blastoff Req Inception: P T T C N R G

This lab report discusses the initial requirements for a new project to create a software application. The application aims to help users find and book local services. Key points discussed include: - The purpose is to make it easy for people to find and book quality services locally such as repairs or painting in a fast and safe way. - Stakeholders include developers, testers, designers, service providers, service receivers, banks, and users. - Initial constraints include supporting mobile operating systems and limited initial budget and users. - Risks are identified as potential lack of resources, time constraints, and difficulty promoting the new app. - In conclusion, while challenges are acknowledged, the project is seen as

Uploaded by

Moetez Skouri
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Lab.

Report #1 – Project Blastoff


Req inception

TABLE OF CONTENTS

1 INTRODUCTION ............................................................................................................................... 1
2 PURPOSE OF THE PROJECT ............................................................................................................. 1
3 THE SCOPE OF THE WORK ............................................................................................................... 2
4 THE STAKEHOLDERS ....................................................................................................................... 2
5 CONSTRAINTS ................................................................................................................................ 2
6 NAMES ........................................................................................................................................... 2
7 RELEVANT FACTS AND ASSUMPTIONS .............................................................................................. 2
8 RISKS ............................................................................................................................................. 3
9 GO/NO GO DECISION ....................................................................................................................... 3

1 INTRODUCTION
The issue of searching someone to repair something broken, or a wall painter is becoming more and more
common.
In order to make it easy for everyone, we propose to develop a software that helps service receivers to solve
their problem.

2 PURPOSE OF THE PROJECT


Our Project is intended to give the services that people need easily and fastly.
This project Is helping the service receivers to guarantee that they will get the quality they want and to pay
safely, an helping the service givers to find a job.

1
3 THE SCOPE OF THE WORK

THE STAKEHOLDERS
--Developer.
--Tester.
--Designer.
--Service giver.
--Service receiver.
--Bank.
--User.

4 CONSTRAINTS
*The mobile operating system.
*Limited Budget.
*Limited number of users.

5 NAMES
SG: Service Giver.
SR: Service Receiver.

6 RELEVANT FACTS AND ASSUMPTIONS


This program can only be used on Phones for the first period.
This program will have regular maintenance

2
7 RISKS
*Lack of human resources (4team members)
*Lack of time to create a web application.
*Lack of contacts to promote the app.

8 GO/NO GO DECISION
As every project, we will face challenges, but our project is profitable and it is a good idea since it will make
peoples life easier
---------------------------------------------------------------------------------------------------------------------------------------------

Lab. Report #2 – Needs Finding and Initial Concept

1 INTRODUCTION .............................................................................. ERROR! BOOKMARK NOT DEFINED.


2 PERSONAS .................................................................................... ERROR! BOOKMARK NOT DEFINED.
3 SCENARIOS ................................................................................... ERROR! BOOKMARK NOT DEFINED.

Lab. Report #3 – Interview Protocol


1 OVERARCHING QUESTION
Do you find it a burden to make the analysis of the data you gather ?
Do you think that this process can be automated in a way that it becomes more accurate ?
2 INTRODUCTION
Hello, we are the developer team of myEvaluator, we’re having this interview with you to know more about features
and
functionalities this app should have as it is still in the requirements development phase.
During this interview we will discuss courses evaluation in general and features you specifically would like to have in
this
app to make it as suitable as possible to your needs so that we can subsequently know what we should actually
consider
implementing and what not to.
This interview is going to be quite short as it will last between 10 and 15 minutes.
All that will be stated during this interview will remain confidential and will not be shared nor discussed after the
interview other than in the scope of the project with the agreement of all participants to grantee the confidentiality of
the process and the best results.
As you are volunteering for this interview you need to know that you can skip questions that you find personnel or
inconvenient. You may also leave if you feel somehow uncomfortable or have any other issues at any time.
We may get back to you after this interview to get further information if need be and we will keep you up to date with
the development of the project.
Also we would like to get your approval of the usage of an audio recorder.
3 MAIN INTERVIEW
3.1 WARM-UP QUESTIONS
How many times in a semester do you have to make this analysis ?
Are you satisfied with the current methodology you use to do the evaluation process ?
To what extend are you satisfied with the current process ?
3.2 CORE QUESTIONS
Do you think that the process can be improved ?
How much time do you usually take analyzing data from an evaluation survey?
Do you think this process could be simplified or shortened?
Do you find it a repetitive task to retrieve and represent data in graphs and analyze them ?

3
Do you find it a struggle as a professor to perform this task?
How long does an average student take to answer the survey?
Do you think you are able to trust an AI or an automated system to perform this task in stead of you ?
Does this analysis overlap with your work(Teaching) or with your personal activities ?
Do you usually need third parties to analyze your data?
Do you get complaints caused by the length or quality of the survey?
Are you passionate about analysis and data science ?
Do you find automated systems and Ai interesting or not ?
4 OBSERVATION
4.1 THINK ALOUD PROTOCOL
The interviewee is then presented the application and asked to describe by detail what he thinks about the usage of the
application. The next section is how the interviewee described the usage of the application.
“The login screen is very intuitive, you just need to enter your professional email and password and press the login
button.
But first I think I need to create an account right ? So how do I do that ? Ah here is the ‘create account‘ button ! So Why
I
have to enter my email and create a password then pick the list of courses I am teaching . This takes some time ! What
Happens if I forget one course ? okey now normally I should press on create account ! yeah this is pretty intuitive. So
now
I should specify whether I am a teacher or a professor. Mmm but wait didn‘t I specify my email and which subjects I am
3
teaching this should normally mean that I am a professor ! But anyways let‘s continue… So I have a menu in front of me
that specifies whether I should create a new form or extract generate analysis for an existing form. Let‘s create a form.
So I get to specify the number of open questions. Then click on submit . Then I click next . Probably if I start directly by
typing the questions, it would be faster. When I try to get the analysis it creates a PDF file that contains charts and
results
which I find a good way to present output.
4.2 OBSERVATION QUESTIONS
As we performed the think aloud protocol on a user, we were able to make questions based on the observation:
Do you think the create account button should be clearer in the interface ?
Do you think that courses you take or teach should be automatically be filled as the data already exists in
administration?(moodle)
Do you think that depending on the email you should directly specify the user as teacher or professor ?
Do you think that the form creation can be made in less steps ?
What output types you prefer to have (xml,json) or simply pdf files ?
5 CONCLUSION
In this part we will conclude by saying thanking the interviewee and by summing up the main points we gathered from
him .
“Finally we would like to thank you. Your answers are really valuables for us and for our improvement. If we sum up the
main points, so mainly what bothers you is the user experience and you think that it would be better if the application
had less steps, and if there is any chance to automate some tasks we would better do it since it will improve user
experience. “

Lab. Report #4 – Initial Prototype


1 CREATE PAPER PROTOTYPE
In preparation for your first user test, you will produce a paper prototype. Regardless of how you produce the
screens for your prototype (hand-drawn), the screens and supporting elements will need to be rendered onto
paper for your user test. The paper prototype needs to cover all user interactions. Each task should include at
least 3 “correct” interactions, and it is a good idea to include screens for any “wrong” interactions or paths that
you think are reasonably likely for the user to pursue.
Remember to include “data” in your low-fi prototype. That is, make sure that dynamic elements in your
interface, such as drop-down lists, search results, shopping carts, etc. have realistic data that is relevant to the

4
selected tasks, which can either be included directly in the sketches or included in “overlays” that are place on
top of widgets depending on user interactions during the test.

2 DESIGN USER TEST


The final activity is to create the plan that you will use for your user test.
It will be important to think about how you will record your user test sessions so that you can review them
thoroughly. With paper prototyping, recording user interactions is somewhat challenging. The best solution is
to use a video camera (you can use your phone)! It’s less important to get the participant’s face in the frame,
and it’s not important at all to capture the test moderator (i.e., you).
+++ video !

Lab 5 goal model !

5
Lab. Report 6 – Requirements Analysis

6
7
8
Page 1

9
LOW-FIDELITY USING BALSAMIQ MOCKUPS : APP FEHA KEN INTERFACES

Modeling :
Precess-flow

10
11
Data flow
Example

12
Req management:

13
14
15

You might also like