Skype: theneemtreegroup
Phone: (Australian callers) 02-8003-4624
(international callers) +61-2-8003-4624
Email: http://neemtree.com.au/contact
Creating your web concept
As mentioned in our "How We Do It" section, we prefer to use the Define, Design/Develop, Test, and Deploy methodology. There are many project management schools of thought, but we prefer this proven success maker.
For many of our clients this is their first experience with purchasing software services and we have found ourselves having to repeatedly spend some time educating them as to the importance of accurately capturing their project's needs (requirements definition), and what that entails. This time investment in our clients and their projects will probably continue, so we've decided to publish the materials we use for this purpose.
Why spend time defining requirements?
The subsequent diagrams will demonstrate why requirements analysis benefits your project. Clearly defined requirements are necessary:
- For the client to convey what their detailed goals are
- For the implementers to confirm their understanding of the client's goals
- To prevent ad-hoc testing and ensure that the tests cover all the goals
There are many requirements specifications templates available, but we're going to look at what is specific to a medium sized web project. In fact, we're going to step through an example/case study:
- The client would would like to implement an online community for urban bicyclists and bike commuters
How to get it wrong
In this scenario, the requirements are unclear and incorrectly understood. The client begins with a request for an online community for bicyclists and provides ad-hoc details as to navigation, functionality, and presentation. If the implementer is diligent, they clarify the meaning of some terms. Other descriptions are inaccurately understood. Many clarification iterations later, a solution is delivered. However, this does not meet the client's expectations, resulting in an unsuccessful project for everyone.
How to correctly define requirements
An upfront effort to express requirements details using industry standards such as:
- functional requirements (e.g. users must be able to register and login),
- non-functional requirements (e.g. visual: the visual design must incorporate existing branding, performance: the site must handle 20 simultaneous user sessions),
- wireframes (diagrammatic representation of the elements that need to be accounted for on each webpage), and
- workflows (flowchart representation of user scenarios)
facilitates clearer communication of expectations and results in a successful solution.

Let's look at some examples so that the benefits of using matrices, wireframes, and other industry standards becomes self evident:
Functional requirements
| Requirement | Priority MH: Must Have NH: Nice to Have FP: Future phase |
|---|---|
|
Roles: Users are granted priveleges based on their roles, which are of type Member, Moderator/Super User, or Administrator. |
MH |
| Registration: Users must be able to register and receive login details via email. | MH |
| Member blogs: Registered users must be able to create their own blogs. Blogs may contain text/HTML, images, embedded videos, and uploaded audio/MP3s. | MH |
| Biker group commutes: An event of type 'biker group commute' must have the following fields* filled in: Start time, trail map. * Also see wireframe 3.a | MH |
| ... |
Workflows
Biker group commutes

Wireframes
Searching for biker group commutes

- See requirement #2
- Primary menu items: Home, Member blogs, Events, Forum, Register/Login/Logout
- Secondary menu items (dependent on selected Primary menu item): Biker group commutes, Escape the city weekenders, Bike repair workshops
- Pre-defined values: Biker group commutes, Escape the city weekenders, Bike repair workshops
- Only shown if 'Biker group commutes' is selected. Pre-defined values: (See requirement #14)
- Pre-defined values: Biker group commutes, Escape the city weekenders, Bike repair workshops
- See requirement #17
The bottom line
By putting in the upfront effort to create detailed requirements specifications, the implementation will be quicker, therefore more cost effective, and more likely to meet client expectations.



























Comments
Post new comment