: Re: Documenting software requirements As a self-taught developer the only requirement documents I've ever been privileged to read are those of hackerrank and the sort. However the more and more I

@Welton431

Vote Up Vote Down

There are almost as many ways to document software as there are to program it, and the important thing to remember is to keep focus on what you are actually trying to achieve with it: To provide aid and support to the development and use of software.

Typically the goal is to develop two key documents:
1. A functional specification, describing what is to be done.
2. A technical specification, describing how something is to be achieved.

Both of these documents should at all times attempt to answer why decisions are made. [The details of why something should be done one way, or why something was important is frequently overlooked in software development. While the answer may appear painfully obvious at the time the decision is made, it frequently not documented, and readily forgotten. This risks eventually developing some very nasty little bugs down the road, or difficulty in tracking down issues.]

Without details on the nature of the system being designed, it is difficult to provide specific details on what these documents should look like or firm guidelines on how to write them.

A general starting point however is to layout the core 'minimum viable system', strip back every last thing you can from the software you're thinking of to the very core purpose of what you are attempting. From that point you can begin revisions as you expand the functional specs, from which you can build out the technical specs.

Whether you break these documents down on functions, screens, widgets, or some other manner will depend on what the software is doing, and how it works.
- A screen focused documentation style is unlikely to serve a project to build an environmental logging system that packages data to be sent out over the network.

(0)

Login to post a comment!