We posted our project on the two main freelance websites. As we would like this to be handeled as a project rather than hiring a bunch of developers around the world and do it ourselves, we decided against using a providers that specializes in individual contributors.
After creating an account with both of them, we posted our project. The project description was only 2 lines and included an Excel spreadsheet containing User Stories and some non-functional requirements. This was all the infromation on top of which we expected to receive bids. The only information regarding the User Interface was that we expect it to be Web 2.0 interactive and contemporary looking.
Now this all might sound quite foolish, but we are keeping the information deliberately broad. We are planning on using an agile development approach and as such we don’t want to define the project too narrow from the beginning. In order to find a company that is able to handle an agile development project, we can’t be too prescriptive but have to allow the developers to be invloved in the development process. In another post we will talk about why we think agile development is the right approach in this situation.
All bids have to come back within 2 weeks. More then..
Requirements gathering is one of the most important early steps in a software development project. Let’s assume company A has an outstanding software product idea and they hire company B to write that software. Requirements communicate what A wants B to create for them. It’s like an architect handing over the blueprint to the construction company and they build it, right?
Unfortunately some characteristics of software make the analogy of the requirements to the blueprint quite a stretch:
- Software is intangible which makes it inherently difficult not only to come up with all detailed requirements before development starts but also to communicate them to another person or group.
- Software represents dynamic workflows. The definition of a workflow consists of what one wants to happen, what one does not want to happen and how to deal with it in case it does happen. That is a lot to think about at once without a feedback mechanism.
Therefore change is an integral part of a software development process. Not to speak of the incredible boredom when spending hours, days and weeks meticulously defining requirements in every possible detail using well known formalized approaches.
We don’t want to get bored with what we are doing, so we decided to use an agile approach. Here requirements are used as a basis for discussion between A and B rather than exact instructions what to do. This approach also takes change into account and change requests can be integrated easily.
We expect the following from this approach:
- Shorter initial requirements gathering phase
- Increased communication with the developers should lead to less misunderstandings and also better control over the development process
- Increased ability to act on changing requirements
- Shorter time to market
