General introduction to software development and focus on the first step – knowing what to build.
Software Development Phases
During every software development project, we need to:
- Know what to build
- Know how to build it
- Actually build it
- Make sure it does what it should do and it does it correctly
- Maintain it
Traditional vs. Agile
Traditionally, a software project consists of sequential steps, careful planning and estimates. Typical representative is the Waterfall methodology. There has been a growing criticism of this practise in recent years, mainly due to the fact, that it is really hard (if not impossible) to plan everything upfront, especially the requirements. This is because, most of the time, customers do not really know what they want until they see some delivery and can say: this is ok, or: this is not ok, what we actually need is this…
To overcome this problem, agile methodologies (e.g. Scrum), try different approach and instead of planning and delivering everything at once, they embrace the iterative development, meaning that the requirements evolve over the course of time, as customer has access to partially built (but always working) software and their feedback is an important part of the development process.
These ideas were expressed in the Agile Manifesto:
- Individuals and interactions over
Processes and tools
- Working software over
- Customer collaboration over
- Responding to change over
Following a plan
Let’s discuss the first phase in more detail now and discuss how it looks like when using traditional and agile methodologies.
A software project starts by doing a Requirements Analysis, resulting in Functional Requirements document. The document should describe all the desired product functionality (very often in form of use cases), without going into technical details. Use cases should give developer all the information and context necessary for the development, see an example of a use case. The document must be fully finished and signed off by the stakeholders before moving further in the process. Stakeholders (product owners) are people (usually customer employees) who have the most knowledge of the processes.
The product owner writes user stories (usually with the help of the development team). These are then prioritized and added to the product backlog. User story is one or more sentences explaining what a user needs to be able to do as a part of their job, for example:
As a user, I want to search for companies by their VAT ID.
Very important feature of a user story is, that it is a product feature that can be independetly scheduled and implemented. Due to the fact, that the user story wording might be quite imprecise and not give enough context to developers, it is extremely important to be able to talk to the customer (via product owner) during the actual development. It should be almost like the user is constantly looking over the developer’s shoulder.