astrid_welcomeFor my Large Scale Software Architecture Engineering course (ENGG 4450) we had to implement a user requested feature for an open-source software project.

We chose Astrid which is a popular list and task management app on android and iOS. The feature we implemented was the ability to mark tasks with different statuses such as “in progress”, “waiting on someone’s response” and “not yet started”. This was the most popular user requested feature at the time. Not only did we do the feature implementation but also followed the entire software development lifecycle and performed requirements analysis, goal modelling, domain modelling, robustness analysis, testing etc. My group consisted of Julian Di Leonardo, Robert Boss, Shane Gautreau, Michael Pawlak and myself.

In order to perform a thorough and accurate requirements analysis, the feature must be broken down into various models and properties. These include the system requirements which are things in the application domain that we wish to be made true, by delivering the proposed system, the domain properties which are things in the application domain that are true, whether or not we build the proposed system and the software specification which is a description of the behaviors that the program must have, in order to meet the requirements. The following lists the various models and properties for our chosen feature implementation:

(System) Requirement: Allow users to set a task as “in progress” or “waiting for someone’s response” and “not yet started”, at any time.

(Assumptions) Domain Properties:

  •  Tasks have a “Status” field
  •  This field can be set to  “in progress”, “waiting for someone’s response” or “not yet started”
  •  This field can be changed at any time in the task options or creation
  •  This field is displayed in the main list of tasks

(Software) Specification: The user will set a task as “in progress” or “waiting for someone’s response” or “not yet started” once they select the “Status” field.

For our implementation it was decided that the new status feature can be modelled as an already existing feature for simplicity and ease of coding, and this was due to the fact that no one in our group has had any previous android development experience. It was first decided that we should model it as the “Importance” feature of Astrid as seen in the “Details” of a task. Going this route however, we became quickly road blocked as it was realised that there was no easy way to assign a task status from the UI and development point of view. We thus had to rethink our approach. Further analyzing the existing Astrid features it was finalized that we should model the task status feature as how “Lists” in Astrid are implemented.

“Lists” in an Astrid’s task “Details” menu, allow the user to create “Lists” and assign it to tasks in a popup showing all the available “Lists”. This is similar to how the new status feature will be implemented whereby in the Astrid’s task “Details” menu, the user can select a “Status” from a predefined list and assign it to a task.

Firstly, how task “Lists” are controlled by Astrid had to found. By searching for key elements relating to the existing lists feature, this was found to be implemented in the “” class. This class was duplicated to act as the new status feature’s control class. Next, was linking this new control class to the UI. A new option to set a status was added to the “Details” tab of a task, called “Status”. This was done by linking the newly created status control class to the class “”. Next was testing this current implementation as it is expected to behave exactly as the “Lists” feature which it did. Thus, the next step was modifying our duplicated “Lists” feature to act as the new status feature.

To accomplish this task, a lot of modifications had to be made. Firstly a new tag array containing our predefined task statuses of “In Progress”, “Waiting For Someone’s Response” and “Not Yet Started” was created. This was used to replace the existing function of listing available lists so that these statuses are always shown. In testing the static list, it was however found that saving the selected “Status” overwrote the existing lists. Fixing this involved creating a temporary array whereby the users status selection was appended to the existing “Lists”. Once this was done the functionality was once again tested. In testing it worked as expected, however it was found that a selected “Status” also added a new “List” of the same name. Before trying to fix this we considered whether this was a bug or feature. It was found that by having this added functionality the users can group existing tasks of the same “Status” aiding in task organization and efficiency.  The completed feature can be seen below:

astrid_statusNew Task Status Detail and Status Selection Popup

In conclusion, the new Astrid Task Status feature was implemented successfully. Not only did the set of functions add significant extra value to end-users but it added more functionality than expected by inheriting some of the “Lists” feature existing organization functions.

Some of the results of our requirements analysis used in implementing this feature include:

goal_modelGoal Model Diagram



Domain Model used to keep track of key domain concepts.


robustnessRobustness Analysis Diagram