Chapter 10
Master Server Requirements—round one

Author Note

This is early draft material, barely more than a stream of consciousness and notes.

We took a general look at requirements in Chapter 9. Before diving into requirements we should first think about why we want them. We start with a need, usually in the form of a problem, usually a problem blocking progress toward some goal. Now our project needs:

  1. A central repository for our:
    • changes (issues etc.),
    • documentation,
    • code, and
    • configuration.
  2. A means of deploying configuration (build out of machines, ensuring those machines remain consistent with project needs, etc.)

The central repository does not have to be one repository, but should be accessible to all members of the project team.

The current requirements are all technical and focussed on the system development support system. There is a low communication barrier between the customer and the development team (they are basically the same in this context).

We are fortunate that we have no operational constraints at the moment. If we had an operational environment to think about we would need to account for this in our requirements. Perhaps taking in documentation and instructions about how to deliver into production, starting the liaison with operations (getting suitable representatives from operations on the project to ensure that whatever we intend to deliver will be acceptable).

  • “The master server must have Salt installed”
  • “We want SSH installed so we can log on in order to control the Salt master”

These are questionable requirements as they specify technical solutions. However this is to be expected in a technical domain. Arguably we could step back and express the first requirement as “I need a way to manage the system configuration”, but this feels unnecessary at this point.

Before finalizing these requirements though we have others to satisfy;

  • “I need to store documents”
  • “I need to be able to identify specific versions of documents”
  • “I need to be able to build and test versions of the system”
  • “I need to be able to control different environments”

In other words our project needs some document management before anything else.

From these high level “needs” we need to derive requirements specific enough that our development team can implement them. This is a rather vague statement, but necessarily so because the amount of effort required will vary according to circumstance.

If we are specifying requirements internally (developer specifying the build system for use by the development team, for example) then we need to invest less effort than if we were writing requirements between different organisations or parts of the business (the marketing department writing requirements for a new campaign management system to be implemented by an external development agency).