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:

  1. Know what to build
  2. Know how to build it
  3. Actually build it
  4. Make sure it does what it should do and it does it correctly
  5. Maintain it

Traditional vs. Agile

traditional 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…

agile 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 Comprehensive documentation
  • Customer collaboration over Contract negotiation
  • 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.

Knowing What

traditional 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.

agile 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.