At this point we have a rough idea of what our project should deliver. We know that we're producing some sort of system, which might include a bit of software, new hardware, revised processes, or a combination of all three.
The system is likely to require more than one person's input to design, and probably more than one person to install it in the workplace. As potential users begin to understand the benefits of an integrated information system, they will often make demands for extra features that they would like.
It is therefore very easy to fall into the trap of reacting to ad hoc requirements rather than working strictly to the original specification, with the potential of jeopardising the whole project.
We can control this area of risk by identifying the boundaries of the new system. If we know what things should be inside the system, and what things will be outside of the system, then we are able to agree this as a part of the requirements specification with the customer. Once that has been agreed, both parties can move forward together.
Identifying the system boundary also helps us when we are planning the design of a system. Internal things in the system will be the things that we have to create. On the other hand, we won't be concerned with creating things external to the system, but we will probably have to ensure that our system will be able to 'talk' to them.
Some projects will have defined
boundaries that are obvious to see. This is good and allows us to move forward
quicker. However a lot of projects will have muddled boundaries, that are
not so clearly defined. Whatever the scenario, the easiest approach is to
identify the things inside and outside of the system. We can do this by considering
'actors'
and 'use cases'.