4Chapter1 • Introduction to Software Development
1.1.2Writing Functional Specifications
Functional specifications may consist of one or more documents. Functional specification
documents show the behavior or functionality of a software product on an abstract level. Assum-
ing the product is a black box, the functional specifications define its input/output behavior.
Functional specifications are based upon the product requirements documentation put forward
by people who have contact with the enduser of the product or the customers.
In larger products, functional specifications may consist of separate documents for each
feature of the product. For example, in a router product, you may have a functional specification
document for RIP (Routing Information Protocol), another for security features, and so on.
Functional specifications are important because developers use them to create design doc-
uments. The documentation people also use them when they create manuals for end users. If dif-
ferent groups are working in different physical places, functional specifications and architecture
documents (discussed next) are also a means to communicate among them. Keep in mind that
sometimes during the product development phase you may need to amend functional specifica-
tions keeping in view new marketing requirements.
1.1.3Creating Architecture and Design Documents
When you have all of the requirements collected and arranged, it is the turn of the techni-
cal architecture team, consisting of highly qualified technical specialists, to create the architec-
ture of the product. The architecture defines different components of the product and how they
interact with each other. In many cases the architecture also defines the technologies used to
build the product. While creating the architecture documents of the project, the team also needs
to consider the timelines of the project. This refers to the target date when the product is required
to be on the market. Many excellent products fail because they are either too early or late to mar-
ket. The marketing and sales people usually decide a suitable time frame to bring the product to
market. Based on the timeline, the architecture team may drop some features of the product if it
is not possible to bring the full-featured product to market within the required time limits.
Once components of the product have been decided and their functionality defined, inter-
faces are designed for these components to work together. In most cases, no component works in
isolation; each one has to coordinate with other components of the product. Interfaces are the
rules and regulations that define how these components will interact with each other. There may
be major problems down the road if these interfaces are not designed properly and in a detailed
way. Different people will work on different components of any large software development
project and if they don’t fully understand how a particular component will communicate with
others, integration becomes a major problem.
For some products, new hardware is also required to make use of technology advance-
ments. The architects of the product also need to consider this aspect of the product.
After defining architecture, software components and their interfaces, the next phase of
development is the creation of design documents. At the architecture level, a component is
defined as a black box that provides certain functionality. At the design documents stage, you