The system provides the user with the ability to link in the description of a task
to multiple other task notes. These task notes are then considered subtasks of this task

The user is able to set a due date for a single task or an entire task list by
adding a widget for the due date over a menu button and/or a shortcut text. The Widget will
be located somewhere next to the task/task list. If the tasks consists of subtasks (see 3.1) then
the system will set the default due date to the maximum due date of all the task in the subtasks.

I think some classes need some serious clean up.
As a starter (suggestions, of course...):

• Merge everything that is not really specific to Tasklist or Task (e.g. constructors, textiters, ... but also adding priority and/or duedate, at least as abstract if not via Start property) into AttributedTask
• Move Handlers and GUI out of the TaskManagerNote. I think it would be much clearer, if those things were separated from the rest (e.g. a Handler and a GUI-Initializer or sth...)

I have started with the first point, but it is a somewhat unsatisfying yet important (also keeping in mind that the grading criteria include such stuff) task so feel free to join the fun ;)

[Quote=Yu Pei]
In the section of Scope, words like "possible" or "possibility" seem to be improper, since a requirement specification is expected to give a precise description of the system requirement.
[/Quote]

I think this is also an issue for some other parts, though.
It should be clear in the specific requirements (where you just put a lower priority if it is 'optional', but I think that's OK so far).

Are we including now an import function as low priority or not?

Last thing I heard was this:

=> Zum import: I würds weder zu de Features, no zu de "nid" -Features tie. Was hautet der dervo, s eifach bi de usecases mit Priority "3" und Risk "Low" dri z tue? So aus "nice to have", aber "very low priority"...

"Ja das wär ok. wobii me denn sich ebe muessti gedanke mache über vo was chanme importiere und wie handled mer überhaupt denn de import will me muess ja denn notes dezue alege d.h. welli tasks gönd in welli note etc."

check in requirements text that its conform to the names in the definition

"Was die Addins betrifft: weiss nöd ob das mol no jemand usprobiert hät, aber eigentlich bruched mr kes Makefile hani usegfunde, mr muen einfach in de projectpreferences bim build de outputordner/dll-name agäh und s xml als resource agäh, dänke das wäri dän alles im .csproj inä. aber jo isch jetzt mal vorläufig nöd so wichtig."

The user has the possibility to order the task lists according to various criteria,
like due date, priority, date added etc.

Will there be user documentation?
Where will it be saved?
I have added this to the nonfunc. reqs with priority 1, since I think we should provide at least a draft, because our goal is to get it into the official release, where it will be nice to have.
Also I will have to rewrite the requirement, it's not good as it is now ^^

Parser is making too much tasklists.
Fix this, rewrite the code in some more readable/less error prone fashion.

The system shall visualize the due date (if set) to the user. It will, based on
the current date, change the text color of the date: If it is far in the future it will be green, if
the day is in near future or even in the past the text color will be red.

[Quote=Yu Pei]
Section 2.1 is not necessary for a requirement specification. If you want to include the part to make the document self-contained, you need to make it short.
[/Quote]

I totally agree with this. Maybe just the last part where the general idea (that there have been prior projects to fulfill task management) is explained is enough, maybe together with some references. I don't see a reason to mention concrete examples or what they evolved into ;)

I get the following assertion failures upon deleting a node and during some other occasions whose commonalities I could not yet find out:

(tomboy:2218): Gtk-CRITICAL **: gtk_text_buffer_apply_tag: assertion `tag->table == buffer->tag_table' failed

Although these warnings/errors(?) are ugly, they don't seem to affect the default behavior of tomboy/taskmanager. Could it be that this has to do with the fixing-stuff?

Create the Index Chapter

If a tasks consists of subtasks in which all tasks are marked as done then the
system will autmatically mark the super task as being done.

http://java-csharp-eth-2010.origo.ethz.ch/node/25

All functional and non-functional requirements are associated with reasonable priorities:

* Also, what do you plan if your system just doesn't respond within 1 second, even though you stated that? 

The quality measures for the non-functional requirements are testable, justified, and relevant:

* Justified and relevant means, that the non-functional requirements of the form "should respond in 1 second on an Intel 486" are justified (e.g., why is 1 sec. important; couldn't it be 2 seconds?) 

Upon deleting the complete name of a tasklist, the buffer goes fubar.
Probably this is because the description is empty or the tags are messed up.

internationalization requirements should be more specific

If we can't fix this, maybe have a compiler directive or something similar?

Jan and me discussed this earlier. We argued that there should be some statement about this at least somewhere ;)
Probably it would fit nice into the 'software interface' section?

• TaskList
• Task List
• TaskLists
• Task Management

...

Do Spell checking before sending out the final version.

[Quote=Yu Pei]
4. What's the difference and/or relation between Priority and Risk in your specific requirements? In what situations may the two properties diverge, e.g. for a task with low Priority to have high risk?
5. In R.6, what's the format of your XML file?
6. R.8, R9, and some others are not detailed enough. You may want to elaborate things like: how tasks and task lists can be converted between each other; is priority/due time applicable also to a task list as a whole? If yes, how? Things like open/save should be considered too, but maybe in product perspective.
7. You need to provide more information about visualization.
[/Quote]

This basically includes all parts, e.g. also those already mentioned in language and licensing

We only agreed on the following:

• When task with subtasks is marked done, also mark subtasks as done
• When a subtask is finished, update supertask, if necessary.

We did not discuss these:

• What to do upon marking a task with subtasks as not done (from previously done)
• What to do if completed subtask is not completed any more (because of toggled one or more not done anymore)

My suggestion: only first 2 (completion > not completion), maybe with options for later

• When is a property needed, when a field?
• Replace the structure

private X someX;
public X PropertyX{
 get {return someX;}
 set {someX = value;}
}

by

public X PropertyX{
 get; set;
}

http://java-csharp-eth-2010.origo.ethz.ch/node/25

[Quote=Yu Pei]
In your Glossary, the concept of "Subtask" is defined as, at least it seems to me, the dependence between tasks, rather than the components of a task. Regarding "Task List", I am not sure whether it refers to the whole list of tasks, or simply some selected tasks.
[/Quote]

I think we already mentioned this in a mail yesterday.

Do this at the very end...

I think we have to rewrite some parts to make it consistent.
I don't know how they expect us to do that, but from what I remember, they said, it's OK to adapt the reqs if we find out sth. is technically not possible or something... (not sure about this, though)

Don't forget to recompile and add revision to header

From the grading criteria:

===Documentation===

• Developer documentation is well written, useful

** e.g. includes class diagrams and API description

• Unit tests (See other issue...)

** We check code coverage

** We don't require unit tests for GUIs

• Known bugs are declared
• User documentation quality: document is well written with respect to the target user
• Installation guide or something similar exists

NOTE: I added this mainly so I won't forget it - We may discuss this later today...

As the title states it seems to me that it is not clear how 'optional' features (those we are not sure whether they are implementable or not) are declared in the document.
This refers basically to:

• Import
• Note overview window (sorting by due date/prio)

And what we actually said we would not do is recursive functions such as finding minimum date oder calculating % of finished tasks, because of circular dependencies.
However, if there is a way to follow the links efficiently, this seems to me to enable a lot of nice features, thus we might keep this open for the future? (e.g. if missing loc)

Every Requirement needs a priority and risk reference and they'll have to be consistent throughout all the documents.

The user gets various possibilities to handle completed tasks. He can hide them, and he can show them after the completed tasks. + crossed out (already done)

Fix no page break between requirements.

The user can query for a list of notes by setting constraints which involve search-
ing for notes who have unfinished tasks or contain tasks which are over their corresponding due
date.

Add GPL in appendix

The system shall visualize the priority of a task by displaying the priority as a
number in a text color which is unique to this particular priority.

[Quote=Yu Pei]
In Section 2.2, you could cover more aspects (refer to the provided sample sections). It would be better to accompany Figure 2 with a short description to help understanding.
[/Quote]

As mentioned in the skype meeting:

• It would probably be more user friendly to add a separate menu entry rather than putting everything into the 'rocket'(/cog).
• Perhaps in the same step add the missing entries such as sorting, ...

I suggest we introduce a single page/directory or whatever it will be, where we can exchange and collect useful resources like links (howtos, FAQs, ... so far Addin howto, tomboy directories and other interesting things from GNOME live), files that do not directly need to be placed as sources into the git (for better overview), etc. The wiki might be a good place for this, what do you think?

Duedate does not copy strikethrough property when inserted/changed freshly.
Make tagupdate after or better copy all tags.

The requirements document seems to be broken.
Maybe revert to basic functionality? (pdflatex)

We talked about a preferences dialog usecase once...