SRS

[FasilCheema]

Please review my SRS :)

[smiths]

@mirzaim please review the SRS.

[mirzaim]

Hi @FasilCheema, I really enjoyed your project. Here are all my reviews. I'm not 100% sure that many of them are correct. I've marked the most important one in the following issues:

9, #10, #11, #12, #13

" Why are you converting the general optimization problem into a minimization problem? Instead, you could prompt the user to specify whether they want to minimize or maximize the function. This would require only a small preprocessing step in the system.

Some user responsibilities could be easily removed or checked. For example, your software interface could be designed in a way that allows users to simply enter a quadratic function, relieving them of that responsibility. Additionally, determining whether a function is positive semidefinite (PSD) or not could be handled within the implementation. For instance, if you're using Numpy, you could check like this: np.all(np.linalg.eigvals(x) > 0)

I believe the library's responsibilities should be more high-level. Tasks like "Updating the values of the current iteration according to the specific algorithm" and "Determining the step size for the particular algorithm (if applicable)" seem more like intermediate steps to reaching the result. I'm unsure if you should mention them in the software's responsibilities or not.

Regarding section 3.3, I'm unsure if restricting demotion to six is a system constraint or an assumption. How did you arrive at the number six? If it's related to the system requirement, could it be a constant in your software that can be adjusted as needed?

For some terminologies mentioned in the section "Terminology and Definitions," since your software is a math library, it might be better to define these terms more formally and specifically. For example, when defining terms like PD (positive definite), PSD (positive semidefinite) matrices, or quadratic forms, providing equations and stating the required structure might make them more understandable.

In the goal statement, all the algorithms you mentioned are guaranteed to converge given your assumptions, but they may not necessarily reach the exact global optimum. Therefore, it might be beneficial to mention that they converge to the global optimum within a specified error margin (epsilon).

In the theoretical model, such as TM:CON, it's better to specify the types of variables and the input-output relationships of the functions. For example, specifying that lambda is in R, x1 and x2 are in R^n, and f: R^n -> R.

I believe TM:CON is more of a data definition rather than a theoretical model, but I'm not entirely certain.

For both instance models mentioned, you should provide more concrete explanations. Specify exactly how the input is related to the output.

I anticipated that in the instance models, you would explain the 'David-Fletcher-Powell (DFP), Fletcher-Reeves Conjugate Gradient, and the Broyden-Fletcher-Goldfarb-Shanno (BFGS) algorithms' that you mentioned at the beginning of the document. However, the instance models remained at a high level and did not delve into this level of detail.

When it comes to functional requirements, they seem too general. It might be more helpful to provide a specific to-do list for your software, such as "Check input, perform optimization with Algorithm 1, perform optimization with Algorithm 2, and return the results to the users.

Regarding NFR4, specifying "any system that can host an operating system" could be more specific, such as mentioning Linux, Mac, and Windows operating systems. "