There’s nothing quite so terrifying as a blank piece of paper so here’s how to get started.
Generally you will not be writing requirements for your own amusement so a great place to start are the stakeholders. These are normally the grown-ups sponsoring the project or their representatives who have been made accountable for the success of the project. Typically you will need input from all facets of the organisation for any project of a reasonable size. These should cover Sales and Marketing, Finance, Operations, Change, Compliance, Security and Data Protection to name a few but the exact structure will depend on your organisation. There will also be subject matter experts that will support these stakeholders and provide additional specialist knowledge. With the help of this assembled group it should then be possible to produce your requirements.
The next step is to identify a list of actors for your application. These will be the internal and external people and systems that will interact with your application. The following are examples of types of actors.
External actors:
- Customer (if you have direct sales channels through apps or a website)
- Third parties who you do business with who need access.
External systems might include:
- Payment providers
- Vendors
- Governing bodies
Internal actors:
- Call centre agents and managers (if you have a call centre).
- Operations staff to make configurable changes.
- Product managers using dashboards to manage performance.
Internal systems:
- Accounting systems.
- Complaints.
- Other business applications.
Once you have this list you can examine each of the actors to determine how they will interact with the application documenting the requirements as you go. This will provide you with an initial set of use cases which can also be thought of as epic stories.
You can then review each of these and break them down into more detailed user stories as you go. You will have completed this process when you have no more epics. However the key point that you need to reach is that you have broken down all of the epics that are ‘must do’ as these are the ones that must be completed to make your project a success.
When producing this initial set of requirements it is not necessary to go into too much detail. You really just need enough to ensure that everyone understands what the requirement is, who owns it, how important it is to the organisation, an idea of the effort that it might take to deliver and finally any dependencies that exist between this requirement/user story and any other ones that you have defined.
The reason for not investing too much effort at this stage is two-fold. First it is quite possible that should the requirement not be that important to the success of the project it may never get developed. In this case you don’t want to waste time on it. Also fully developed user stories tend to go stale. By that I mean that due to the transient nature of application behaviour the basis that a user story was written on may no longer apply by the time that you come to play the user story. It is therefore better not to write user stories in any great detail i.e. by defining the acceptance criteria or decomposing an epic until you are ready to play them. The obvious caveat here is that you will need to decompose all epics that are part of your MVP (minimum viable product) to ensure that you understand how big they are so that you can ensure you ave the necessary resources to complete your project.
When you are ready to develop the requirements further this can be achieved by considering all areas of the application that are impacted by the requirement that you wish to implement. This can start with the transactions that are impacted through the various channels and then each of the other system components that are impacted within each of these transactions. Please read my BLOG anatomy of a business application to understand all of the application components that you need to consider when completing this impact assessment.