Rina,
This is useful further information, but I am still wondering what would make the users think that any new device is better than the iPAQ? If I may quote you, you said "they always have problems with Active Sync, slow reaction time, If using multiple applications, the hand held gets real slow." Is speed of processing the sole measure? How will that benefit the business? (The users may like it, but for the people paying for it, what will they think? What measures will they apply to say "the replacement is a good replacement"?).
I appreciate the candour that "at the time we decided to go with HP iPAQ, we didnt get a device accroding to the requirements. It was more like, this is the device, put your applications on it." but this begs the question "what are the requirements?" If we know what measures the people who are paying for this change (or who can make the decision to accept or reject the new device) are going to apply and what target values they have, we can select those devices that will achieve the tagets (functionally or otherwise) and they (the sponsors of the change) will be happy.
This will need careful work as you are probably aware that there are lots of potential groups and individuals who can make the decision to accept or reject the new device - but only some of those will be able to make decisions which will be enforced on others. Having identified those (hard enough!) you will then need to get definitive answers from them about what target values must be achieved. Vessela makes a good point about this: "If it is hard to obtain this from the stakeholders, let them compare their [...] expectations with the current version of the system."
By the way, I would be very interested to know what do your users do in the field that makes a handheld device so useful? That knowledge might help identify measures as well.
- Guy
Hi Vessela,
You talked about Interface requirements. Could you describe more about it?
Below is the background on the strategy we are following, could you suggest me on how can I go about writing my requirement document while covering each section.
The strategy we are going to follow is: First I'll gather the requirements for the kind of device users want. Then the next step would be getting them approved. After that we would take those requirements to the Procurement/IT infrastructure dept. where they would marry the requirements and the device together. After doing that, they would hand over couple of devices to test. Once we test all of them and find the best solution, we would then present the device to Business where they would then approve the device before training,communication,user manuals are written.
Based on this: What I am trying to do in my next meeting is: Meet with the users and classify the business requirements into Hardware,software, networking, performance, security and Interface requirements.
After that come up with Functional requirements.
Please suggest, as this is my first shot at documenting requirements for device and I dont want to mess it up!
brought to you by enabling practitioners & organizations to achieve their goals using: