We can’t control customer behaviour. But what we can control is our approach. Today, we talk about : Business Requirement Analysis and Why It’s Important
Many people embarking on a new project will ask why business requirements analysis is needed. Some may even advocate just “getting started” on the project – a very tempting proposition when the budget has been approved and the project team is enthusiastic and ready to go. But Business Requirements must be documented to ensure the agreement of all parties involved and that the final product meets the needs of the business and delivers a discernible, measurable improvement.
First, there is a set of knowledge someone should have to do analysis on some projects, but it depends on what you are building for who. In other words, it makes a big difference if you are modifying an enterprise application for a Fortune 100 corporation, building an iPhone app, or adding functionality to a personal webpage.
Second, there are different kinds of requirements.
- Objectives: What does the user want to accomplish?
- Functional: What does the user need to do to reach their objective? Non-functional: What are the constraints your program needs to perform within
- Business rules: What dynamic constraints do you have to meet?
Third, the ways to gather requirements most effectively can be:
- Read the agile manifesto – working software is the only measurement for the success of a software project
- Get familiar with agile software practices – study Scrum, lean programming, xp etc – this will save you tremendous amount of time not only for the requirements gathering but also for the entire software development lifecycle
- Keep regular discussions with Clients and especially the future users and key-users
- Make sure you talk to the Persons understanding the problem domain – e.g. specialists in the field
- Take small notes during the talks
- After each CONVERSATION write an official requirement list and present it for approving. Later, it would be difficult to argue against all agreed documentation
- Make sure your Clients know approximately what are the approximate expenses in time and money for implementing “nice to have” requirements
- Make sure you label the requirements as “must have”, “should have” and “nice to have” from the very beginning, ensure Clients understand the differences between those types also
- Integrate all documents into the latest and final requirements analysis (or the current one for the iteration or whatever agile programming cycle you are using …)
- Remember that requirements do change over the software life cycle, so gathering is one thing but managing and implementing another
- KISS – keep it as simple as possible
Last but the most important, get feedback!
