We reflect on our Functional Specification, which outlines the technical requirements of ezsh.
Well, as stated earlier, the functional specification document is essentially a detailed analysis and technical description of the system to be developed. In our case, this is a shell. In putting this document together, it’s imperative we describe the problem to be addressed along with the solution we hope to provide. Along with this, a high-level description of the system design and a preliminary schedule were required from us.
The following headings were mandatory to all documents handed in for marking;
- General Descriptions
- Functional Requirements
- System Architecture
- High-Level Design
- Preliminary Schedule
This document was worth 10% of the project total, and the deadline for this deliverable was 5pm on 7/12/2019, at the time of writing, this was last Friday. So how did we go about writing this document together?
The first step of writing a functional specification is not putting pen to paper. It’s brainstorming the nitty gritty of the project, the ways in which the group hopes to acheive it’s objectives. It’s not about the “what” (that was the proposal), but rather the “how”. How do we go about realizing the potential of this project? How do we split up our sprints to ensure this is acheived?
So yes, before we wrote down any information in our functional specification document, when brainstormed. Just myself, Connor, a whiteboard a two markers. This is where we drew out the system architecture, how the subcomponents mean to link and pass data. If we are being honest, the system architecture went through a few interations.
In general, we are really happy with our final result. The idea is that the shell will consist of multiple panes managed by a single multiplexer. Each of these panes plays host to a different section of the shell. These sections are the
Explorer, and the
Infographic. A server runs behind all of this, using Unix Sockets to pass information from one process to another.
Each of our diagrams went through a number of iterations, as we revised each one carefully. We knew that the language of this document, in one way or another, revolved around the information presented in the diagrams.
Finally, we put pen to paper! We copied over a nice skeleton from a sample functional spec from years gone by. Our document was written in markdown and we used HackMD for this. HackMD works just like Google Docs, multiple people can make changes at the same time. This was incredibly useful in the writing of this document as we could see what changes were made and who made them at any given time.
As mentioned earlier, our language in the functional spec was heavily shaped by our diagrams. This meant that it was easier to stay on topic as we didn’t stray away too much from what was concrete and laid out in front of us.
We plan on writing the majority of our project using the C programming language, with aid of the ncurses library to help boost the interactivity of the shell. As mentioned in our document, this will require some further upskilling in the language.
Below you’ll be able to view the preliminary schedule we hope to follow while developing ezsh. Some of this may be subject to change due to any number of constraints. If this occurs, it will be written about in a further blog post.
The Functional Specification document can be found here. The document was submitted on the deadline day, Friday the 7th of December 2018.
Reflecting upon the document itself, both Connor and I feel we performed well, citing the fact that we both evenly contributed to each stage of describing and designing the relevent diagrams. We took two meetings with our project supervisor in relation to this document, and we feel we paced ourselves well. Moving forward we hope to continue this trend when following our preliminary schedule as we begin to develop ezsh!