Re: [mendenyo] Re: Let's design a survey of our computers and Internet access
- Hello to all,I am back in Nairobi and will have time to meet Ebby Kosgei of Ncomputing company from Korea, their unit is using minimal power and it is very vital to the rural Kenyan community.I had good time meeting with Jacton and Peter Ongele although, i tried calling Francis but he was not online. Our Discussion was well and they are going to be good model in using the DIY solar as we try other solar panel options for the community. Already the electricity tariffs in Kenya is high and the rural communities cannot afford. However, the rural electrification initiative was started by the government there is still too much monopoly from Kenya Power and Lighting company. The price for kerosine is up even and something has to be done help the poor.I will call David Mutua while here and meet to discuss other details.Thanks all for your brilliant emails, am going through the mails this morning.Cheers,Sam
ms@... wrote:Hi Ricardo, please can you do a second draft of the survey, with a short
version and a long version? I have marginal Internet access (fitting
within the hours of the Chicago Public Library) and I appreciate your
leadership! Kofi, thank you for your warm letter! can you research the
contacts for us? and I would approach them. Andrius
in the survey part of your message, it wasn't clear
whether you are pressing on with the survey work or whether you
wanted me to create a new survey page or something. In our recent
phone chat, I think we agreed you would lead the survey work, while
I got on with Includer technology research. Is that correct?
I just wrote this reply to make sure we aren't both sitting there,
expecting the other one to take the next step with the survey.
Will the survey involve a very large number of MS members, making a
lot of manual cutting and pasting of answers hard work? If so, is it
much work for you to design a web form to collect answers? It may
help to keep the answers in a consistant format too.
I read your initial list of survey questions. It's good for
capturing information on how people access the internet at the
moment (the Status Quo).
We will also need some questions that related to future
possibilities with the Includer, such as "Do you have a mobile-phone
signal where you live?", making GPRS internet access possible. The
Includer device can be simple and cheap without GPRS, but 'walking
to the internet' could mean just walking to one laptop+GPRS phone in
a village, or a short distance away, not a conventional internet
That's just one example question, about what would be technically
possible under that person's local conditions. We can both think of
some similar questions. We can ask how people would use an Includer
if they had one, such as "How would you re-charge the batteries
We need to keep the number of questions to a managable number of
course, so as not to over-stretch the respondents.
Can we just clarify the 'role' of this survey?
For a product with a single customer, you would hold talks with that
customers to start finding out their requirements, or read documents
from them. For a product with multiple customers, like the Includer,
the Survey fulfills a similar role, of starting to find out the
I'd like to set out a typical engineering process for designing a
new product, to show how the survey fits into the whole requirements
capture, analysis and design process.
The survey tells us a lot about the Customer or User/Purchaser of
any Includer device and about the Operating Environment for each
The survey results then allow us to write the first draft of the
Requirements Specification for each type of Includer device. The
Requirements phase of a project doesn't pre-judge what design
choices will be made for hardware/software in the Design Phase. It
states the requirements in a stable way, no matter how the
requirements are eventually implemented. It states WHAT the Includer
does, not how it does it.
However, it can include 'Constraints' on the later design choices,
if the Includer must have some particular interface to other
equipment or some particular unalterable user-interface constraint.
For a single product, several alternative designs are considered
with different electronic hardware and software, and one design is
chosen, with the best cost-benefits or money-is-no- object best
The Design Specification, covers HOW the Includer fulfills the
requirements, and those requirements can be divided into Hardware
and Software Requirement Specifications.
You can see how a large 'problem' (requirements) is addressed by a
technological 'solution' (design).
In a large system, as you break down the system into sub-system and
sub-sub-systems, modules and units, you make design choices among
alternative designs. There are therefore repeated analysis and
design, analysis and design phases, etc, at system, sub-system, sub-
sub-system level, etc.
So, the survey lets us write the first draft of the requirements
specification. Then we can check the requirements for errors and
ommissions, then ask more survey questions if neccessary, until the
Requirements Specification is complete and consistant, reviewed
within 'the company' (MS) and signed off by the project manager, and
reviewed and signed off by the customer (perhaps a small group of MS
memebers in Africa and potential Includer users).
It's very important to finish off and freeze the requirements
specification. It's the interface to the customer and the basis of
the contract. After that, the other design and testing phases etc
can progress as 'internal activities' within the company (MS).
That's enough for now. I'm sorry to ramble on.
Please let me know if there's anything you want me to do, Andrius.