"Dear seedot.com,

Please provide a quote to build my portal. I want, banner ads, e-commerce and by the way, when can you get it done and how much will it cost? One more thing, take a look at www.amazon.com and model it after that."

This is only a slight exaggeration. We receive many emails from individuals and companies similar to the above. If you are someone who wants the services of seedot.com then this page we will explain how to get from the first email ( like the one above) to the finished product.

We hope the lessons we have learned from our experiences will make the development of your site easier and better, and at the same time, accelerate the development for the seedot.com team here i Sofia, Bulgaria.

Because we are in Bulgaria and our projects are mostly from the USA, we have developed some expertise in dealing with people on the other side of the globe while using email only. We know we must become process centric to produce quality results for our customers.

Some of what we have learned is explained in the 10 step process that is outlined below. But this is just the tip of the iceberg. Our process run throughout our company.

1. We receive your email request for an estimate.
We will usually return the email and ask a few questions or we will ask you to complete:

Client Questionnaire Form - For those who are very serious about the services of seedot.com

To give you a rough estimate we need enough information to make a guess about the number of hours of work and the completion date. The above mentioned two forms have been created to gather two levels of information.

2. Agree on Terms and Conditions
Once both of us agree on the cost to complete your project we must then make sure we are both clear about what is expected. We usually emphasize at this point that our work is done by the hour. We provide an estimate only to give a rough idea of the cost.

We work by the hour because of the changing nature of web development. We have discovered that so many changes and additions take place during the course of development that it is too difficult to estimate accurately. We cannot give an accurate bid.

Working on an hourly basis provides the client freedom to make changes while the project is underway.

3. Project Report
If it is a complex site you may want a more accurate estimation. If this is the case we can prepare a report that will take from 10- 30 hours to prepare. We require payment in advance for this report. Once you have this report you can take it to other web development companies if you choose.

Our estimate will provide the approximate number of hours to complete the job. We calculate by the hour and bill by the hour. This is IMPORTANT. We only provide the estimate of the number of hours so that you can approximate the cost.

We bill only by the hour because we have discovered that the project evolves and changes. The client always wants to change colors, ad functions, add content, add products etc as the project is being developed.

4. Client Review Estimate and Evaluates
After we return the estimate of the number of hours involved in the project the client usually wants to make sure seedot.com is a good company. They can take a look at our portfolio section.

5. Deal
Once both parties agree on the terms of the deal a document can be prepared to clarify exactly what is to be done. seedot.com prepares an email with instructions on where to wire or send the money.

Some clients may employ seedot with very little needs for estimates or documentation, others may wise the opposite. Either way is acceptable. But it does help us to get the job done if we have good information and communication.

6. Requirements are Analyzed
Once a client decides to have a website developed by seedot.com and wires or mails at least half of the payment upfront, the development process begins.

The client must make their best efforts to communicate his/ her requirements clearly. Since seedot.com bills at an hourly rate, this effort now will save time and money later.

Our in-house Development Process

PHASE I - Define

In this phase, the objective is to understand clearly the voice of the prospective customer. When doing business on the Internet, we realize the importance of being clearly understood, to provide the best solutions to our customers.

Typically we start of when we get an email enquiry or a Quick Quote (on our internal sites) from a prospective client.

The request is examined. To understand the requirements better, some questions are emailed back to the prospective client, or the client is advised to fill in the Client Questionnaire on our site.

The clarifications are given. The client questionnaire is duly filled and forwarded.

The request is now re-examined for any further details required at this stage. If not, then a rough estimate of the time and costs involved in the project is made. In case of large web applications and database driven websites, a proposal for doing a detailed analysis for a fee of $2000 is emailed to the client. The deliverables here are the following:

- Requirements Document
- Level 1 Work Breakdown Structure and Project Schedule
- Payment schedule
- Draft of the contract of Agreement.

The client seeks clarifications (if any) on the terms and conditions and approves the documents and the contract of agreement. After this, the client gives a go-ahead for the project.

The amount to be advanced and the mode of payment is specified

Confirmation on the payment is intimated to seedot.

seedot confirms initial payment.

PHASE II - Design and Develop

Methodology - The evolving iterative approach.

We use the evolving iterative approach to web development. In this methodology, once the preliminary requirements are clarified, the next step is to quickly build the prototype of the website/web application. From then on, it is the continuing evolutions of this prototype until it become the final product, exact to specifications.

Visibility - The key Advantage.

This is a revolutionary, new approach to software development and extremely suited to offshore development and outsourced services. When you outsource your requirement of web solutions to us, we are sensitive to the fact that you require high visibility of the WIP (work in progress). This is the reason why we have adapted this methodology to our web development process. At each stage along the development, the website/web application evolves before your own eyes. Here are the broad milestones in this process:

Prototype: The first and crucial phase. The prototype shows you the shape of things to come. This is much more than just a visual representation. It represents all the screen elements in the final solution. This is the mould into which we start to breathe the breath of life! Feedback from the client is taken and required modifications are incorporated.

Functional Specifications Document: Before starting to actually develop the functionalities, we document all the functional specifications. The client reviews it and gives feedback again and with this, the requirements specifications are fully captured.

The Proof of concept: The prototype evolves to its more complex level of existence. Many parts of the prototype spring to life. We have this intermediate delivery before the final delivery to establish the proof of concept. The client can now almost feel the solution that he/she had entrusted us to develop. What remains now is just formality. Our production engine hauls the project to completion.

Final Delivery: The final product is delivered after testing. There are no surprises, and no tense expectations on the date of delivery. For, you had seen it evolve!

PHASE III – Deployment

Performance of the site is monitored for a period of one month if there is no site maintenance agreement.

Any problems found during this period will be solved, without any additional cost to the customer.

Site Promotion
The Site Promotion Process is implemented.

Re-engineering and re-designing depending on promotion needs, to make the site a success.

Site Maintenance
The Site Maintenance Process is implemented.

Operations workflow at seedot Systems:
The flow chart visually describes the workflow and the processes that are a part of any project undertaken at seedot Systems.

The marketing team acquires the project from the client and forwards it to the Operations team – the Chief Technical Officer and the Project Leaders. Projects are delegated to the project leaders who in turn assign tasks to team members who then work on the project within the schedule allotted to them.

All deliverables are passed through a Quality Assurance team who decides whether the process is iterative or not. If satisfied, the Quality Assurance team passes the completed project to the project leader who then hands out the deliverables to the client. Client feedback and satisfaction is given first hand consideration and all deliverables are reworked upon to ensure a completely satisfied customer.

============================

 

What is a Requirement

A good set of requirements is needed for any project, especially computer system projects, to be successful. This is where many projects fail, in that they do not specify correctly what the system should do. In fact many systems have just been given a deadline for delivery, a budget to spend, and a vague notion of what it should do.

The root of this problem is:

Computer systems developers rarely have as good an idea of how a business runs and should run, compared with a business user, Business users have little idea of what a computer system could achieve for them.

As a result paralysis sets in and business management time is concentrated on meeting timescales and budgets, rather than what is going to be delivered.

Requirements Definition

The truth is that you do not need a great deal of technical knowledge to specify requirements; in fact it can be a big disadvantage. A requirement for a computer system specifies what you want or desire from a system. For a business in particular this is, What you want or desire from a system, which you believe will deliver you a business advantage.

This advantage need not just be a reduction in costs, in fact many systems justified on a reduction in operating costs, fail to deliver as low skilled but relatively cheap staff, have to be replaced by high skilled, and more expensive staff. The advantage can be a reduction in time to process something, which will lead to a reduction in costs, or being able to better use the unique knowledge base belonging to a business.

As you start to specify what you want or desire, you hit up against technical language of requirements. Fear not, this is quite straightforward:

Functional requirements

• are what you want a system to do.

  Non-functional requirements

• are restrictions on the types of solutions that will meet the functional requirements.

Design objectives

• Are the guides to use in selecting a solution.

Functional Requirements

These are the type of behaviour you want the system to perform. If you were buying vehicles for a business your functional requirement might be:

The vehicle should be able to take a load from a warehouse to a shop.
Similarly for a computer system you define what the system is to do. For example:

The system should store all details of a customers order.
The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered.

Non-Functional Requirements
These often lead to much mystical mumblings, implying that a high priest of the computing fraternity is the only person who can understand them. They are however quite simple; they are the restrictions or constraints to be placed on the system and how to build it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Non-functional requirements can be split into two types: performance and development.

Performance Constraints
These constraints are how the system should perform when it is delivered. The vehicle example, without any constraints, might result in solutions being offered for everything from a large truck to a sports car. To restrict the types of solutions you might include these performance constraints:

It must take a load of at least one ton.
The load area must be covered.
The load area must have a height of at least 10 feet.
You may include more. Similarly for a computer system you might specify values for these generic types of performance constraints:

The response time for information to appear to a user.
The number of hours a system should be available.
The number of records a system should be able to hold.
The capacity for growth of the system.
The length of time a record should be held for auditing purposes.
For the customer records example these might be:

Information should be made available and be stored in a maximum of 3 seconds.
The system should be available from 9am to 5 pm Monday to Friday.
The system should be able to hold a 100,000 customer records initially.
The system should be able to add 10,000 records a year for 10 years.
A record should be fully available on the system for at least 7 years.
The important point with these is that they restrict the number of solution options that are offered to you by the developer.

Development Constraints
In addition to the performance constraints you may include some development constraints. These mainly fall in the field of project management, but are still a restriction on the types of solution that can be offered. There are three general types of development constraint:

Time

When a system should be delivered is the obvious time constraint.

Resource

How much money is available to develop the system is obvious, but a key resource would be the amount of time business staff could spend in briefing system development staff.

Quality

Any standards which are used to develop the system including project management, development methods etc.

Design Objectives

Design objectives assist in selecting a solution from a number that are offered to you. Only you know what is the most important feature of a new system, whether it should be fast, have large storage, be easy to use, or whatever. Unfortunately you cant have all you want; compromises have to be made.

Experiments with teams of developers in the 1970s showed that they will deliver a system according to what is defined as the top design objective. A number of teams were given an identical set of functional requirements, but each had a different design objective: some had to make the system fast, some small to use only a small amount of computer storage, some easy to use, etc. Each team delivered a system that met their top objective fully, and other objectives to a lesser degree.

If you do not produce a set of design objectives, which are in a priority order, the developers will produce their own, and these might not be what you want. For the customer records example the top design objective could be that it easy for users to find customer information.

Bad Types Of Requirements
The above are all good types of requirements and will allow a development team to provide you with a number of options from which you can select a suitable solution. However many sets of requirements given to developers are polluted with design and implementation solutions. This means that the customer has told the developer how to conduct their business!

Examples of design solutions are:

The system should run on our existing network of computers.
The structure of a customer record must have a separate field for the first, and last names of a customer.

Examples of implementation solutions are:

The customer record systems should run on a SQL database.
The system should be built using the Java programming language.
Each of these says HOW the system should be built, not WHAT the design should deliver, and you may miss out on a better solution, due to you making these design decisions.

There may be good reasons for some of these statements, but until you have seen a number of designs, you do not know if they are valid for you.

Prioritising Requirements

When a set of requirements has been produced it is often large and complex. The realities of times scale and resource mean that it won't all be delivered, at least not the first time out. The customer should prioritise the requirements to specify what they most want, and what is nice to have. A method of doing this is the MoSCoW technique. If the customer does not prioritse then it will be done by the developers, who may select the parts of the process which are easiest to produce, or that are technically challenging, but not taking into account the needs of the organisation.

Conclusion

A good set of requirements consists of prioritised sets of:

Functional requirements, Non-functional requirements, and Design objectives.

And does NOT have any design or implementation decisions.

Producing these will enable you to get systems that will deliver a business advantage.