I'm writing a Design Specification Document for a college project and wondering about the tense I should use. The development on the project has not yet started, I'm just writing the UI design section.
Should I use:
This app is built around a two column layout, with a header element.
or
This app will be built around a two column layout, with a header element.
I will obviously continue whatever tense is best throughout the document.
Edit to clarify what I'm actualy writing
The course module discriptor says this:
A detailed ‘design specification’ based on the requirements specification. The completed design specification should be comprehensive and should allow a third party to use your design specification as the basis for implementation. It therefore should be clear, concise and detailed. It may contain: a navigation map to clearly show how you propose how to link various pages or screens; a series of detailed storyboards to illustrate page layout, colour schemes, typography (fonts, sizes, styling, alignment), use of media elements (eg icons, graphics, sound, video, animation) or interaction styles. Justification of design decisions should also be present.
Best Answer
It depends on what you're writing.
If you're writing requirements, then the answer is "neither". Another question here on Software Engineering addresses the use of "shall" and "must" when writing requirements. The guidance that I use at work is that "shall" is used to denote any requirements that must be met for the software to be acceptable to the customer, "should" marks off desired characteristics, "may" is used to identify anything that is optional, and "will" is anything that can be relied upon after the mandatory and any desired or optional characteristics are implemented. If you're not writing your requirements as statements, but using use cases or user stories, you'll want to follow the conventions of that format.
If you're writing about software that already exists, then you should be using the present tense. The software already exists, so it "is" something or "does" something.
If you're trying to define requirements and document a design approach at the same time, I would recommend not doing that and understanding the value of separating what functions the software must expose and the non-functional attributes of the software versus documenting how the software is decomposed or how to use the software. Separation of requirements, technical design, and usage (user's manuals) is very important.
To address your specific needs, I think the best thing to do would be is to ask your course instructor or someone else who understands what they are looking for. In my experiences, this type of document doesn't exist in any form of modern software development, so asking professional software engineers how to produce a document that is acceptable to your particular customer (in this case, your professor or grader) won't get you the best answers, especially since I don't think that the answer of "don't do this, it's not good practice, look at your development methodology and approach instead" will get you very far in the course.
The requirements specification is the basis for implementing the software, either by an internal or external team. It should not only have your functional characteristics, but design constraints, performance and other quality attributes, user characteristics, required interfaces, and so on. The requirements specification is the agreement between the customer and software supplier.
What you're being told to put into the document is indeed design information. However, it's consistent with "big design up front" approaches to software development where you don't write code until you "finished" your design. However, I'm not aware of very many organizations that embrace this approach.