Software design isn’t just about the tools and technology. Many people think business requirements and functional requirements are most important.
The MOST import aspect of a software development project is ‘fit for the organisation’. It needs to fit eh business and functional requirements, yes, but it needs to get completed in reasonable time and budget.
I have seen SSSOOOOO many clients interview every manager, write huge specifications, order loads of software, hardware, project managers, and hundreds of hours of business analyst hours. Documents are thick and free flowing. Everyone right up to the board thinks things are well organised and documented.
The only problem is that the project is incomprehensible. No one personal can point to something in the requirements, and say its correct, as its a committee decision via many interviews and interpretation from the business analysts. This is the problem with asking users what they want, and attempting functional decomposition – fat documents that can’t be comprehended.
Then those documents are so big, that no development team can understand them, let alone quote, and heaven forbid attempt to execute on time and on budget.
Its one thing to have a good idea, and document the hell out of it. But a completed project is worth 1000 projects that are documented.
The design needs to fit not only business requirements, but available resources and skills to execute.
Here are some of our older software projects, under our software brand.
portal for_BodyCorp
b2b application for CoverMore insurance
RedBull portal
B2B workflow for insurance company