Home Evaluation Summary for programmers Product limitations Goals of Axisbase Quick start Installation Using the launchpad and opening databases Connecting to a sample database Using building blocks Planning Define the purpose Define the requirements Borrow existing work Determine the architecture Design the data model Design the process model Deploy and maintain the product
building blocksPerforming a mailmerge Bulk e-mailing
ProgrammingSingle-threaded progress indicator in c#
Database menu itemsImport XML Save Copy As Integrity Check Change Password
Database Properties windowOpening the database properties window Record types tab Display types tab Roles and Users tabs Sidebar tab Database ID/Links tab Counters tab
Building blocksBuilding blocks window Editing grids and cells Hyperlinks and nesting Data Subset window Data Outsource window List window Window window Report window Bulk Operation window Label Printer window Choosing a data source
Special topicsExpression syntax Browse records Storing building blocks within other building blocks Programming Using custom code in building blocks Using Axisbase as an embedded database Axis1.Util namespace reference Axis1.Data namespace reference (Fishnets) Axis1.Data namespace reference (other) Axis1.Forms namespace reference
Define the requirements
While the purpose statement is a sentence or two about the basic scope of the project, the requirements list the specific business needs. Requirements can span from one page (for a one-week project) to 50 or more pages for projects that have a lot of data points. A project of one man-year in size can often list requirements in 5-10 pages.
People often confuse "design" with "requirements". They are very different. The table below can help distinguish the two. The table also separates out technical requirements (relating to the available resources and policies, and pre-existing limitations) from business requirements (all others).
Modeling data in the requirements phase
A "data model" as explained in a later section, is an exact specification of data types, and properties of those types. For example, a "person" is a data type, and "date of birth" is a property of a person. The requirements phase should be the first step in designing the data model, but there is no need to design it all yet. For example, you could list in requirements:
Store households in survey area. Store the drivers in each household (name only), and their vehicles (year, make, model, VIN). Each vehicle is stored with the household, not attached to a particular driver.
In the data model design, you will later formalize this requirement to:
type "household" has properties (address)
type "driver" has properties (reference to household, first name, last name)
type "vehicle" has properties (reference to household, year, make, model, VIN)
And you would include specifics like maximum lengths and data types of each property. The main point here is to avoid mistakes, like erroneously associating the VIN property to the person type. Also, be clear on what goes with what - in this case, the vehicle could have been assigned to a specific driver instead of the household. If that were done, you would have to decide how to record vehicles with multiple owners. Deal with the relationships in the requirements phase, and the specifics of each property later.
It often helps to draw screens on paper, especially for visual thinkers. This can help you think of all the things that will need to be entered and what the relationships between the data are. But after you list everything, throw away the drawings, because they aren't truly business requirements. A common mistake in software development is the attempt to follow early drawings after requirements change or after the design phase results in the need for a different data entry process.
In some cases, requirements are used as the basis of contracts. If you are the buyer, it's a good way for you to hold the vendor to the results that you are paying for.
However, requirements take time - up to a quarter of the total time spent on a project. If you expect the vendor to write requirements before signing a contract, the vendor is assuming all the risk. Companies that do that have to charge you eventually in some way to make up for that risk and expense.
On the other hand, if you expect the vendor to provide a fixed quote before writing requirements, they will have to charge a lot extra up front for taking the risk of not knowing the eventual scope of the project.
There are a couple ways around this: One is to pay for requirements separately, so that both parties have limited and shared risk, and you end up paying only for the requirements that end up in the scope.
The second solution to this dilemma is to write a contract for the total project based on preliminary requirements, which only characterize the quantity of work rather than the details. For example, "the system will account for 30 data points, and have up to 8 report formats". If in the course of the final requirements process, you find that more work will be needed, both parties have a fair basis for changing the price.