Non-Functional requirements specification



  • I'm working on a college software project. The whole purpose of the software is to test the application. The teacher is focusing on non-functional requirements, so we have to present metrics, indicators for reliability, usability, performance and maintainability. The thing is, this application will only run in locally and is designed only for one user. I'm having problems coming up with metrics and indicators, considering I don't have a point of reference. I see many examples but I'm sure the teacher will ask why I picked the numbers I did. I asked him, but he told me I'll just have to do some research, which I did, but couldn't manage to apply them to this case.

    Do you have any links that provide this kind of information?



  • Welcome to the evil realm of nonfunctional requirements.

    The core information your teacher gave you is, in other words, "No idea, go figure something out, and I will decide if I agree with it." And this is what happens most of the time in real world projects.

    Focusing on your information: one user, local environment, we already have some valuable points to analyse. What you need are use cases. What are your users suppose to be doing with the program, where is the focus of its use?

    Examples:

    Reliability:

    The program doesn't crash, if if you do X. X is your metric here, which you can brak down to e.g. "normal stuff", "extra stuff (running other programs in background, chaning focus,..), "evil things" (you want to leave these things out, because if a user decides to run the program on a laptop in a marathon race, blindfold, jumping on one leg and having pi calculated in the background to the 10^20000 decimal).

    Usability:

    The user can work with the program, ..X. X as metric again: "...and is able to use all functions after no more than 3 clicks/windowchanges"(simple), "...and a new user is able to complete the program within a certain timeframe of x minutes" (evil)

    Performance:

    Loading time for the program(

    Maintainability:

    How should updates, bugfixes be handled? How often? (Like: once a year, updated must not require a full reinstall, ...)

    It all depends on the scenario you whish to use the program in. Your other issue, defending the metrics, requires some kind of evidence that you did not make these values up. My suggestion is to conduct a field analysis of those who should later use the program(assuming the user is at all in the scope of the program's design). Take times for performance issues, confront users with "this was 5s, are you sure you are satisified with this speed just for a scroll down action?". Just watch out that you are using realistic values: 0,01s reaction time is nice, but is it necessary for the aim of the program?

    Good luck!



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2