Structuring a Technical Task

There is a typical structure for a technical task to be considered for each master oder bachelor or diploma thesis. Not all steps are mandatory, but there should be a consequent decision on which steps not to take or do. The emphasis on the steps however may vary strongly. More conceptual tasks will require to focus especially on the requirement definitions and the functional decomposition, whereas tasks more focussed on execution will consider requirements which are most likely well defined in the beginning and then afterwards execute and realize on the go.

Especially when it comes to very scientific-oriented development work, there will be the need to go very much into the details of execution (in those cases: mathematical, analysis, simulation), but even those require a framework for orientation. So do not be mislead that this structure is also applicable there.

Types of projects for master-, bachelor- or project-works.

There are four types of works. Usually they can be distinguished as

1. Execution Tasks
2. Conceptual Tasks
3. Product Development Tasks
4. Validation Tasks

The best way to describe their focus is with the V-cycle.

Toolbox (chronological order) for a typical thesis (master/bachelor/practical)

* For a conceptual project task, consider a factor of 2 or 3 in weeks for these steps. Conceptual tasks have the tendency to focus mainly on literature research, basic considerations and testability for the requirements. So the above mentioned steps needs to be done in much high depth and with much more care than for an execution project or a development project.

Timeline:

 If your supervisor is asking you for a time-planning, the expectation is to receive a Gantt-diagram/table. Target of your planning is to identify and become aware of the tasks to be done, and the time you are (probably) going to need for those. You will have to align with suppliers (e.g. material you need) and people assisting (e.g. workshop or labs) to adjust your timing and plan proper periods for e.g. order of material. Creating a timeline is a task of its own, plan one or two working days to get the framework aligned with everyone involved, and update it regularly at least once a week!. On top it will allow you to inform the parties assisting in your work about the time-window you are probably going to need their involvement. Such a level of transparency usually helps a lot to get commitment, other than if everything is simply "urgent" if you did not manage to inform ahead of time.

From a very practical point of view it is strongly recommend to plan from back-to-front. Means, start with what you want to achieve and go backward in time to think as detailed as possible of the things you need to do. Summarize those tasks in groups of action which are usually covering a week. Include major milestones (e.g. model done, simulation executed, design finished, theses written,...) to guide yourself in the planning process.

Always bear in mind: You are responsible for your timing, you should be able at any point in time to confirm that you will achieve a target in time or escalate if this is not possible. In real live there are hardly people willing to wait a little longer simply because of an improper planning. So estimating a timing and being able to work towards this timing is a key skill of every engineer! Of course, estimations may be wrong, but this is no reason not to give it a try and improve with every project you do!

Technically for visualization this can be done in multiple ways (Excel, MS-Project, JIRA BigPicture). Confluence is offering also such an option.

Choose  in the toolbar when editing an area and select draw.io . There you can choose "Tabellen" and one of the proposed variants of the Gantt chart.

The result will look like this.

Typically a weekly planning is sufficient for most thesis works.

Requirements

Are you aware of what you want to achieve? Are you aware of the expectations of your supervisor? The key tool to change this is the creation of a requirements-list (Lastenheft / Pflichtenheft), which is sometimes also called "feature-list" when it comes to very software-centric developments. This requirements-list is to align expectations and to give orientation when checking the concepts and the final functionality against a reference. Be aware, emotionally your supervisors will never be happy to commit/align this list - nor are any customers -, because they then need to be definite on what they want.

Structure of a requirement:

A requirement typically consist of several features:

Areas requirements may come from

Within literature on design there are always checklists which should help to tailor the requirements and to prevent missing a specific topic or area while creating the lists. I personally like the lists of "Pahl Beitz", although they may need to be extended beyond the technical features a bit.

Requirements lists

There are database-management systems which have been programmed to align requirements (e.g. "DOORs"). However on a university-level and for most small to medium-size companies Excel-Lists do typically do very well. 

This excel-list should have columns for all aspects of the requirements, like that one below for orientation. It is okay to summarize requirements or spread them. It is a common approach that there is something which needs to be achieved (e.g. a force) but it would be great to have an even bigger force. Make two lines then, one with a mandatory requirement, one with an optional one.

To give you an idea: Typical requirements for even small development projects or architectural tasks in BA or MA thesis easily count up to 30 or 50 items. A whole system may have hundreds. If your tasks is focussing on simulation and testing you may still have 20 or more aspects for your testing and simulation requirements. Take care and think deep!