Nueronic Consulting

Firstly, take a look at these sites: BBC,ITV,Channel 4,Five even this ERT, Antenna TV and then compare it with this site: CYBC also known as the  Cyprus Broadcasting Corporation. This has been  bugging me for quite some time and wanted to write a review on the CYBC or ΡΙΚ as it is known in Greek. Simply because it seems that the rest of the world is up to date with the “online movement” whereas in Cyprus in some sectors we seem to be still be behind, which to me it’s a shame because Cyprus has nothing less than other countries in the world in fact Cyprus has a number of advantages that other countries don’t (location, EU member etc). So to have a  visually strong, content rich web site is not a big deal today,and it doesn’t cost much nowadays to have one; maybe it did a couple of years back and CYBC’s policy was clear on that (you should have seen other version’s of the site before!), but now in 2007/2008 to have a good web site is very very simple.

You can argue that ”you can’t compare big multimillion TV channel’s like BBC,Channel 4, iTV etc with a Cyprus Channel; why? why not? what does money have to with it?  I am sure that if you pay 10,000 pounds,dollars,euros for a site, and when you pay half that you can get “overall” the same results. It will not be that different in terms of looks and content, maybe the hardware you put behind it and the software to manage the content is more complicated but let’s face it it all comes down to uploading content,good visual design,usability,site features and other items that make the difference-it is not the complexity of the software behind it.

However some of these things are not that simple. I agree that some things cannot be done with simple tools. But you can have the basics with open source or custom tools. Like CYBC have done, using Joomla (change the favicon guys). The site now does have better navigation-some taxonomy has been incorporated which is good. However the  content is not great if not minimal to non existent, the site is not regularly updated, it is not w3c validated and does not conform to basic validation rules.

It seems that CYBC has missed the point of “content is key”. Have a look at the blogs section, -oh no, no content there- you need to navigate form the drop down menu. What is the actually point of embedding the entire blog in the site and not have nice individual blogs for  each subject? Same with the  learn Greek section what does this have to do with the services?

To me it seems like CYBC have a web site for the sake of having a web site and finding the easy way out, add the title page, embed some videos,write  a bit of text and some blogs find a nice design template and who cares-users will not mind. It’s a shame really, users are changing and so should you.

Am not sure how many of you know or have heard of Joel Spolsky,his blog and his books. I have been following Joel for over a year now and hi’s writing and ideas are i have to admit very “attention-grabbing” would  be the best way to describe them. I have also bought his two books which i have read within a couple of days. The content focuses on software writings “And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity”, as he describes it. Excellent content and the perfect reading for this year.

You’ll find the books below:

The Best Software Writing I: Selected and Introduced by Joel Spolsky

Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those … or Ill-Luck, Work with Them in Some Capacity

Requirements, requirements, requirements; one of the most important factors to the success or failure of a project. Eliciting them correctly from the beginning is a very difficult task that is hard to master. Writing them correctly however is another issue that can affect the way the project is deliver in terms of time, costs and quality. Writing requirements in a structure way which is understandable by  developers, clients and you is a critical milestone to the success of the project. Imagine the situation in which a developer does not understand a requirement, you (let’s say as a Business Systems Analyst)can’t explain it correctly because you haven’t written it correctly and did not understand it well and the client-being a client cannot remember what he actually specified and actually changes the requirement. You can understand the mess this will create!
However there is a solution-understand and write requirements correctly from the beginning. There is no doubt the requirement will change at some point you should take that for a fact, however the way you write and describe the requirement does affect of what is actually delivered.

This is usually my approach to writing requirements:
1. Above all-simplicity. Use simple and short sentences to write requirements, e.g. The user shall sort records by date
2. No jargon. Do not use complex vocabulary, technical terminology.  Try to think that you will explain the requirements to a 10 year old, it should be  that simple!
3. Who are the users? Where applicable include the type of user/actor in the requirement, e.g. – The systems administrator shall have admin rights in the system.
4. Break up long/complex requirements.  Break down complex requirements into smaller more manageable pieces. Don’t worry about the number of requirements identified, the simpler your requirements the more understandable they are by the rest of the project team.
5. Identify hidden requirements. This does go hand to hand with scope creep. I would recommend doing some prototyping on a white board with the client to identify hidden requirements, a simple example is a  client requesting a login page for the users to securely login. Is that simple as “The system shall provide a login page for users to login”? or is it more complex such as to provide a forgot your password link, to send users an e-mail to reset their password,  or e-mail validation etc  and other  requirements that go hand to hand with user authentication?
6. Define acceptance criteria. Requirements need to be verifiable to ensure that they meet clients meet. Acceptance criteria need to be specified (usually in the use cases).
7. Avoid speculation (e.g or,maybe,usually,often etc) or join requirements with and,together with etc.
8. Do not use vague vocabulary and terms. Like user friendly, usable, effective, efficient, modern etc.

All the above are just the start, and only a small piece of the pie however if you have a structured approach  and apply that process throughout the project you will be able to manage the requirements process correctly and avoid bottlenecks later on.
Some of books on the subject i would definitely recommend:

• Writing Effective Use Cases (Crystal Series for Software Development)
• Writing Better Requirements
• Mastering the Requirements Process