4.6. Summary and Checklist
This section has shown that establishing the requirements of stakeholders as part of the design of an MLE is readily achieved by using well established systems design methodologies.
We have looked at examples of procedures and tools to identify the key users and stakeholders in your planned MLE. We have also shown how the construction of a conceptual model of the intended system is essential, both for explaining the uses and benefits of the MLE to stakeholders and also evaluating their requirements of the system to successfully carry out their role.
You will have seen that there are many different ways in which information can be gathered about the needs of the intended users and stakeholders of your MLE. The full range of techniques looks daunting, but in fact only a few will have to be used to get the information you need, the choice being determined by the constraints of the working patterns of stakeholders in your organisation.
The other characteristic of the process that you will have noticed is that it is iterative and yields an increasingly refined definition, not only of user requirements, but of the conceptual model from which the requirements are derived. As you develop a richer picture of the form and functionality of your MLE, greater detail will emerge of how individual components can be optimised to satisfy the requirements.
As each requirement specification is articulated it is tested with the initiating stakeholder and the particular activity it is intended to support. You will be looking to ensure that the action in the MLE it triggers reliably satisfies the stakeholder need without conflicting with any other activity and is optimal, in terms of efficiency and effectiveness, compared with alternative solutions.
In the latter part of this process you will be constructing prototypes of system components and use cases of their application in order to test their effectiveness with stakeholders. This will lead directly into the design phase of the project.
We conclude this section with a checklist of the key activities involved in the construction of a comprehensive MLE requirements specification.
Checklist
| Activity | Action Required |
| Deciding the Requirements Gathering Methodology | Agree, with the MLE design team, the preferred systems design methodology to be used. Decide the extent of the requirements gathering activity dictated by the chosen? methodology. Create a requirements gathering plan, resource specification and budget. |
| Identifying the Key Stakeholders | Identify, with the MLE design team, the main users of the MLE and other stakeholders who are affected by the system. Set limits to the boundaries of the stakeholder group. Continuously review these limits as the MLE specification is refined. |
| Constructing a Conceptual Model of the MLE | Construct, with the MLE design team, a descriptive model of the intended system that would enable each of the stakeholders to understand its overall purpose and functionality. Ensure that each stakeholder is clear about their interaction with the MLE and can specify their requirements of such a system. |
| Gathering Stakeholder Needs Information | Employ an appropriate mix of information gathering methods to identify potential stakeholder requirements. Create a plan for this activity which will generate the required information within a workable timescale. Provide an appropriate budget and resources. |
| Creating a Requirements Specification | Use the stakeholder needs information and their intended use/interaction with the MLE to create draft requirements specifications. Document use cases for all stakeholder functions. |
| Testing and verifying the Requirements Specification | Apply prototyping techniques with the use cases for each stakeholder to test the effectiveness of each requirement in meeting the identified need. Confirm validity and viability of each requirement. |
Conclusion
This section has provided a set of procedures designed to help you specify the user requirements in the design of your MLE. Each procedure is derived from established systems analysis and design techniques which have been shown to lead to consistent and optimal outcomes. A range of references and resources have been cited which will provide further detail in each aspect of the process should you want to look at them in more depth.
A number of terms have been used in this section which will be familiar to those who are involved with systems design. For the non-specialist, clarification of these terms might be helpful and we conclude here with a brief glossary.
Glossary
| Term | Meaning |
| Systems analysis | A methodology for developing a management plan for a project. Systems analysis techniques provide a structured route through the specification, design, development and implementation process. |
| Conceptual model | A description of the intended system. The conceptual model would describe the purpose and functionality of the system without, initially, specifying the means of achieving this. As the development progresses, the practical implementation and the role of each stakeholder will become defined. |
| Stakeholder | All people who interface with the system, either as users or as people who affect or are affected by its operation. |
| Prototype | A sub-set of the conceptual model which describes the viewpoint of a particular stakeholder and their interaction with the system. |
| Use case | A description of a particular work scenario involving the stakeholder and the system which identifies a specific need and leads to a requirement specification. |
| Requirement | A function that the system has to perform to satisfy a specific need of a system stakeholder. |
