.. (לתיקייה המכילה) | ||
Which description (if any) should we provide about the GUI? | |
By default there is NO need to get into the GUI details in the SRS phase. However, You should elaborate on GUI in either of the following cases: (a) The client had explicitly requested specific GUI elements (b) A non-standard GUI (c) A highly complex GUI |
Should the system distinguish between users or user types? | |
The client did not say anything about these issues. So, basically he expects the system to be as simple as possible without the headaches of a multi-user facility. Thus, if your analysis suggests that you DO need several types of users, (or: have some restrictions on the usrer's behaviour) you should state it in the SRS document. |
Should my solution support multi-processing and/or remote access of some sort (Web application? Client-server?) | |
No. The client uses a stand-alone Windows machine. No concurrency/no distributed processing is needed. |
What size of data is the system expecred to handle? What is the expected work-load? | |
The client was not aware of these issues when he wrote his description of the system. If your system has limitations, which are relevant for the client, put an appropriate statement in the SRS document. |
How can I describe variations, exceptions in a use-case description? | |
The use-case template (in the SRS template) does not include the variations and excetions paragraphs. You are expected to list these issues as alternative flows. However, if you feel that a variations (and/or exceptions) section is more suitable for the use-case you are describing, you can add such a section. |
Is the client expected to define Saturday as an "off" day? | |
No. Saturdays are "off" by defualt. |
Should I add support for import of data from text files? | |
No |
I am having troubles deciding on the look of the system's GUI. What is required for this system? | |
No need to make it pretty. Just make it functional. |
Do I need to add a description of relevant part of the GUI in each use case? | |
No. You may do so if it is complex/non-standard or if it significantly clarifies the textual description. (See also the first FAQ) |
Regarding the information in 2.2-2.4 (in the client's description of the system). Is it defined on a per-employee basis? | |
No. This information is global and is relevant for all employees |
What is "Top thershold" (item 2.1.3)? It is not used in the example. | |
Item 2.1.3 is a mistake, you should ignore it. |
Should the system support the calculation of a salary for periods of less than a month? | |
No. Each salary is computed for a whole month. |
Should the system record all changes in the global definitions (tax levels, hours per day, ...) ? | |
No only the most recent values should be kept. |
(a) Is it possible for the system's user to look at the salaries of previous months/years? | |
(a) Yes. (b) As far-back as practical. Please state any relevant restrictions in the SRS document |
Regarding the batch system (item 4.2 in the functionality section). where should I place the output: one file for all reports ? A dedicated file per report ? per employee ? | |
Whatever (in your opinion) is most convenient for the client |
Do we have to sumbit a CD in addition to the electronic submission? | |
No CD submission. Hardcopies are also not needed. |
What do you mean by "scope" (SRS, 1.2) ? | |
Scope: Describes where the system "ends". Having read this section the reader should be able to grasp which entities/elements are considered to be "external", and which tasks/responsibilites are not handled by the system. |
Do we need to describe the coding guidelines, or is it enough to say "standard java coding guidelines" (SRS, 4.2.4) ? | |
If you are referring to a well known term/concept there is no need to define it. |
Is the batch mode supposed to be a stand-alone executable -or - a command line argument - or - just another button that generates the report to a file? | |
All these options sound OK. The key issue with the batch processing is that it will require minimal interaction with the user |
What do you mean "References" (SRS, 1.3) ? | |
(a) Other documents which are explicitly mentioned in the SRS (summaries of meeting, budgets, SRS of external systems,...). (b) Other relevant documents which can help the reader understand the SRS (API sepcifications, descriptions of protocols, ...) |
I am confused. The homework document states that GUI description is worth 30%, but the FAQ says that by default GUI description is not needed. Which is it? | |
It is not a mandatory requirement to describe the GUI. But, if you decide to describe the GUI and place a bad description - or - if you decide NOT to describe the GUI although the use-case is complex/non intuitive, you will get up to 30 points reduction. |
Which section of the SRS document should describe the GUI? | |
Item 8.1 ("User interface") is for a general overview of the GUI (description of the interfaces/look and feel/main rationale). Detailed description should be placed as an appendix. |
In a specialized use-case, should we provide a description of the generalized use-case? | |
No. But make sure you place a proper reference to the generalized use-case. |
How do we describe a generalized use-case in the SRS document? | |
You describe only the parts/tasks it does. In the description of the more specialized use-cases you define the additional behavior |
Should the system support editing of the employees table (1.1 in inputs)? | |
No |
How is requirement 6 (Output to text file) different than requirement 4.2 (batch processing) ? | |
A batch activity is an activity that runs with very little interaction with the user. Typically, the user starts the activity, allowing the program to produce its output automatically. So, Item 6 deals with whatever view/window the user is currently looking at. Item 4.2, is about producing a full salary report with a single-click (or very-very few clicks) |
What is the limit on the size of the SRS document? | |
No upper limit. No lower limit. |
How will you evaluate the SRS document? | |
The primary issue is that the client should feel that everything he asked for is described correctly. If the document is too long or too complicated the client will not approve the SRS (since he cannot understand it). On the other hand, if key requirements are missing, the client will (again) not approve it, since he does not want to pay for something that he does not need |
when displaying a salary, is it for a specific month? | |
Yes |
Regarding item 5, what do you mean by defining Fridays/Holidays/etc. ? | |
The user should be able to define for each day whether it is a special day. (In a special day the employee gets a higher salary per hour). The client will (probably) like your system much better, if the system could automatically define all Saturdays + all Fridays as special days. |