BUSINESS REQUIREMENTS | BUSINESS ANALYSIS
Obtaining business requirements is fundamental to any project. However, what stakeholders say they want has to be critically examined or they might end up unhappy.
Your first concentration is on what the stakeholders say they want. However, behind the scenes, you must organize their statements in relation to the purpose of the project. And, as you get farther along, you need to start creating the documents that will ensure the specifications can be developed. Use Cases, Data Model, ER diagram, class diagram, state diagrams, swinlane diagram, context diagram and so on.
You are not making decisions that should be made by the developers. You are making sure that what the stakeholders are asking for can be delivered.
If you think a request cannot be delivered, check with the eventual project developers and see if there is a way to do it. If there is not, you need to see if there are acceptable alternatives and go over them with the stakeholders.
Waterfall Example - Helicopter Support - Custom ERP
This client was the world's largest independent supplier of helicopter parts. Independent meaning they did not manufacture helicopters and could sell parts from all manufacturers.
They had a very complex set of requirements that moved them far away from any ERP package.
They spent 2 disciplined years developing their requirements before they found a vendor. I then spent 6 months on site to refine them and ensure they were complete.
The user specs were about 200 pages long. The behind the scenes diagrams I had created to ensure they could be programmed were about 50 pages long. The application was developed in a tight 9 month timeline, on time and on budget.
Prior to the application being on-line, they felt they had expanded as much as they could. After being on-line for 5 years, annual sales had doubled to $80 million with only a 30% increase in staff. After 9 years, annual sales had reached $200 million.
Agile - Custom B2C Websites
Outflow Technologies was a start up specializing in custom websites for businesses. Once the site was up, the clients would always see improvements they wanted. These were handled on sprints of two weeks. We would obtain the requirements and stage them to deliver the currently most important ones first.
Use Cases, ERD, UML (such as State Diagrams, Swimlane Diagrams, Context Diagrams)
Use Cases are fundamental to almost any project. The other documents that can be done during the requirements phase would normally be done on an as needed basis.
Most analysts think of doing these documents for two reasons:
1. It will be shown to the stakeholders to help their understanding.
2. It will be part of the permanent record to help the understanding of anyone who works on the system in the future.
However, there is an additional reason that they do not think of:
3. It is required to work out how the system will work. In order to guarantee the success of the system, there might be documents you need to do that will never be shown to anyone else. This is critical to the success of the project.