Usualy, this kind of document is called software requirements ,contains more details and is writen from the technical point of view. User Stories^? are way to achieve the similar thing, but from the user point of view. In short: User Stories are tasks that need to be acomplished by the software, from the user point of view. Since i'm both one of the users and the creator of this software, it's primarily my task task to write those tasks/stories.

We'll use twiki (twiki.org) as an example, since it is a first application whose provision we're automating using StAc. Equally, it could be any application in its place. Our goal is to have as much of our software tools provision as possible automated by StAc. That will give us time to focus on the end users and software tools, and cut boring repetitive technical tasks. It will also provide us with coherent web servers, which a significant advantage over ad-hoc (usual) way.

We need to provide a twiki. that means: install it, configure(customize) it, activate it, test it.
This is sometimes called software deployment.

• To install means to create a functioning copy of it on one of our servers, with the identical file layout to all other instances of twiki we have already installed.

• To configure means to set certain parameters during the install (functionality ie plugins, visual look ie skins), or immidiately after it, in the way in which end user requested, or by using default setting. To meet this, we need to provide a form with cutomization options that user fills when requesting a twiki, or some other user input method.

• To activate means to make it available to the end user that requested it. Which means having it running under a working web servers and with the correctly resolving DNS entry.

• To test means to make sure it works before we inform the end user about, or before we hand it over to end user.

We need to back it up, bot for us and for the end use to be able to download a compressed file containing the his complete twiki.

(3) upgrade a twiki functionality

Most software tools have some way of adding functionality. Twiki uses plugins to do so. We need to add these plugins to already installed twiki's.

(4) update all installed twiki's

We need to update all installed twiki's when the new version comes out. Before that is done, both new version of twiki and the update process need to be thoroughly tested. In some cases update will not be possible or necessary. In some cases, when update isn't simple, we might want to do partial updates, updating only those end users for whome we know that they need features available in new version.

(5) de-activate a twiki

We need to be able to remove access to twiki, when and if end user (or some authority we have no powers to contest) requests so.

(6) de-install a twiki

We need to be able to remove completely the copy of a twiki, when and if end user (or some authority we have no powers to contest) requests so.