Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Game Physics: Lacking Non-Functional Requirements #53

Open
Mornix opened this issue May 3, 2018 · 3 comments
Open

Game Physics: Lacking Non-Functional Requirements #53

Mornix opened this issue May 3, 2018 · 3 comments
Assignees

Comments

@Mornix
Copy link
Collaborator

Mornix commented May 3, 2018

Section 5.2 is very vague and lacking with respect to the non-functional requirements. The section could be greatly expanded.

@smiths
Copy link
Owner

smiths commented May 3, 2018

Hello @Mornix. To make these issues easier to address, could you include more information? What is the title of section 5.2? What are some examples of missing non-functional requirements. What else should be added? If it makes sense, this issue could be split into multiple issues.

@Mornix
Copy link
Collaborator Author

Mornix commented May 4, 2018

(Issue #29)

The Game Physics SRS mentions which nonfunctional requirements (Section 5.2) are a priority, but never details what the requirements for those categories are.
screen shot 2018-05-04 at 12 06 40 pm

For example:

  • Performance: What are the performance requirements? My thoughts would be something along the lines of "Compute a simulation x rigid bodies with no step taking more than y milliseconds on hardware. Where hardware may be something similar to "Minimum Requirements" specified when purchasing a game.
  • Understandability: What is this with respect to? Is this the understandability of the API and use of the library? Is this the understandability of the implementation? How is this measured?
  • Portability: What is meant by portability? Is this the set of standards this should adhere to? Perhaps some version of POSIX? What systems is this targeted to run on? Recent common operating systems? Game consoles? Mobile? To what extent should this library be portable?
  • Reliability: What is reliability with respect to a game physic engine? Does that just mean the library won't cause the application to crash?
  • Maintainability: How is maintainability measured or checked? What does it mean for it to be maintainable?

@smiths
Copy link
Owner

smiths commented May 7, 2018

@Mornix, please add the nonfunctional requirements that you have mentioned to the SRS. This would improve the documentation. In some cases you mention the NFRs, but include questions on how they are measured or checked. If you could make an attempt at how they might be written as requirements, that would be great. We can review as you go along. We don't have to have perfect NFRs, but you have noticed a weakness in the original documentation that should be improved upon.

Once the new NFRs are in place, we will have to create another issue to port these changes to the Drasil version of the Game Physics SRS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants