Looking for volunteers to join your project? Need help with a script but can't afford to pay? Want to offer your services as a volunteer to build up your portfolio? This is the place for you...
matthijs wrote:So has the design/frontend part been taken yet?
If not, I might be of help, if needed.
We'll need front-end people in two respects:
1. To develop and maintain highly flexible HTML with pure CSS layout .. Something along the lines of CSS Zen Garden. No layout whatsoever should be coded into the HTML, it should be entirely semantic markup.
2. To develop a demo shop with fancy graphics and layout based on the HTML and CSS from point 1.
Indeed. I'm trying to read up on use cases as I would like to do this as 'by the book' as possible for a learning experience if anything.. I take it use cases are for defining requirements?
Jenk wrote:Indeed. I'm trying to read up on use cases as I would like to do this as 'by the book' as possible for a learning experience if anything.. I take it use cases are for defining requirements?
I'd actually say that Use Case diagrams are for specifcation more than requirements. I've always written requirements as a list of everything I would expect the application to achieve, then written the specification as a formal outline of how the application would achieve the required features .. all the required data fields, code elements, design assets, etc. Not sure if that's the standard way of doing things or not though.
Anyway, I hate UML and everything associated with it.
I have to applaud you guys for building this by holding off on the urge to start coding and creating the specification and such documents first. It does a spidermoddy proud.
to get things started we should really just start with a bunch of bullet lists where we group requirements (e.g article, cart...). at a later stage we can build some more refined things upon that.
what i am trying top say is that we should not think too much about how we write / organize requirements but rather get things rollin'. it will evolve by time (sort of requirements refactoring (; )
chris
Last edited by sike on Tue Sep 05, 2006 6:49 am, edited 1 time in total.
sike wrote:to get things started we should really just start with a bunch of bullet lists where we group requirements (e.g article, cart...). at a later stage we can build some more refined things upon that.
chris
We've got that. The main page of the Wiki is a list of general features, which I'm in the process of linking to seperate pages that give a more detailed list of requirements for the individual items. It's slowly going to build into a complete list of requirements. Unfortunately work is getting in the way of my fun right now.
sike wrote:what i am trying top say is that we should not think too much about how we write / organize requirements but rather get things rollin'. it will evolve by time (sort of requirements refactoring (; )
I don't really agree. Jumping into the code at this stage, prior to knowing what's really needed, will slow things down and lead to a similar sort of spaghetti mess OSCommerce is in at the moment. That's exactly what this project is trying to avoid. I realise it's not so glamorous and it's a bit boring for people who prefer to be coding than documenting, but experience has taught us that documentation first is very much the right way to go on a large project.