Formal list of nonfunctional requirements?

[jimjfletcher]

To refine the supplementary specification, I really need a list of formal nonfunctional requirements.

A couple of things to consider for the list:

Accessibility

• Will we worry about any sort of handicapped accessibility?
• Will we offer the app in any languages except English?

Compatibility

• How will the app respond when installed or launched on a device with incompatible hardware (e.g. no GPS)

Reliability

• Availability requirements and MTBF need to be defined by the customer or removed from the supplementary specification.

I'm sure there's more that needs to be included, but that's the limit of what I have.

[hjc]

If I'm not mistaken, nonfunctional requirements would also include things like application size. So keeping the application size to a reasonable amount, compared to other phone apps, would be a requirement. Additionally the app should load fast and not put a drain on the user's phone data.

If the device has no GPS, their location could be found with WiFi, though I doubt there will be enough wireless networks around for it to be accurate. In that scenario, the user should be able to enter the stop they are at and their desired destination. If they have internet we can give them the map.

Handicapped accessibility, like in? Reading the text? Read directions? Not 100% sure what you mean.

If other languages were to be supported, I would think supporting Chinese (I guess Mandarin) first would be the best idea. But that is outside our scope.

Anything else you can think of. Or just things, like the app shouldn't cause seizures due to flashing lights. Or the app shouldn't reload the image every other second. Anything that seems like it should be a given can go in there.

If anyone else has ideas, post them.

[jimjfletcher]

Keep in mind that they need to be as specific as possible. Saying that the app needs to be kept to a "reasonable size" doesn't really mean anything. Same with saying that it should load quickly. There need to be clearly defined, measurable requirements. Arbitrary measurements and ambiguous definitions are basically useless.

My artifact already included everything I could think of, that's why I posted my question here. In a real-world scenario, there would be a list of clearly-defined requirements agreed upon by management to be included in a supplementary specification.

And by handicapped accessibility I meant things like text-to-speech and voice input. It may or may not fall out of the scope of our application.

[hjc]

I think they are generally around 5 MB, so we should aim for our final product to be around that size.

For load quickly, 5s is generally considered more than a reasonable amount of time to download and render an entire web page, so a goal of 5s to load and render any changes needed should be good.

Dealing with handicapped accessibility is definitely beyond the scope of our project.

[jimjfletcher]

If you want me to make up more nonfunctional requirements, fine. I was, however, under the impression that the professor intended work on this project to simulate actual work on an actual project. And that would mean that leadership would have an agreed upon list of nonfunctional requirements for me to use.

[hjc]

I apologize for any perceived snark, I was merely giving some substance and background to my two nonfunctional requirements. I cleaned up the posts so it is only the facts, and the other stuff is left out. Again, I apologize, that is just my normal personality coming through. I will do my best to restrain myself and post about only the facts.

We do not currently have a list of agreed upon nonfunctional requirements. I will see if Robert knows of any and try to think of some tonight as well.

[hjc]

Just forwarded you some of Roberts nonfunctional requirements.

I will send McDonald an e-mail today asking him if he has any, no guarantee we will get a response today.