Loading ...
Sorry, an error occurred while loading the content.

Re: [mendenyo] Re: Let's design a survey of our computers and Internet access

Expand Messages
  • Samwel Kongere
    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
    Message 1 of 8 , Aug 4, 2008
      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.

      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

      Hi 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
      (how/where/how much/etc).

      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
      customer's requirements.

      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.


    Your message has been successfully submitted and would be delivered to recipients shortly.