Software is an intangible artifact.
Like all artifacts, you can’t just start building software and expect the end result to be how you envision it, especially when working in a team. Everyone of your team members might have a different idea of what the application should do.
But also when working solo on your project, it’s easy to hit a stumbling block and forget about the big picture.
One way to have the clear goals in mind right from the start is by performing a careful requirement analysis. At the end of it you’ll have a clear frame within which you’ll be able to operate.
The first thing to realize is that there are many stakeholders in any application.
- The users that will use the application in the end
- The person that required this application to you
- The team lead
- The domain experts
- The investors
The needs of each stakeholder might overlap, but in general you’ll have different needs assigned to each different stakeholder.
This should be the first phase of any software project, and it will involve a lot of conversations and discussion.
At the end you will write a document with all the data you need. I generally do this simply, in a plain text file with this information, for each of the stakeholders
- their name and role
- their goals and needs
When thinking about the end users, you should ask yourself some key questions:
- Who should our app be for?
- What is our ideal user?
- Why should they use our app? What’s their end goal?
- How can the app serve they best?
Also describe this information in the text file.
Any project has constraints. You need to factor them into your analysis, and find ways to workaround them, if needed.
Document those constrains too.
The next phase is what is generally called use cases.
Document all the use cases for your application. In a todo app, the main use cases could be
- adding a todo
- checking the list of things to do today
- organizing the todo list for tomorrow
- marking a todo as “done”
Describe them in detais in the document.
Many tools exist to help project managers to do this task. I prefer to keep things simple, but needs might differ and you might use advanced project tailored for the task.
If you have a product manager, it’s great to contribute to the process to gain as much insights to the project as you can.
As mentioned in the previous lesson, you don’t just gather the requirements and you are “done”. This is an ongoing and iterative process, especially on projects with a long time frame, like SAAS applications or desktop applications that might be used for 10 or 20 years by your customers.