The Art Of Software Development (part 1): Understanding Need - The Write Stuff

(Page 4 of 6 )

Once you have some idea of the customer's needs, the next step is to outline these broad requirements in a document. This document contains an overview of the features to be included in the software, and serves to demarcate the scope of the project. It also helps to give your customer confidence that you've understood his or her needs, and that you have the skills necessary to take things to the next stage.

The level of detail in this document varies from project to project and company to company, and depends on the level of complexity inherent in the project, and the amount of time and staff available to compile the data obtained into a structured report. If you're an independent developer or a project manager with a small team, you might prefer a smaller, simpler document; if, on the other hand, you have a full-fledged team behind you, work in a large, process-driven organization and/or have a complex project to tackle, you might prefer a document that drills down to the very last level of detail.

Let's take a look at some of the components of a typical requirements document.

1. Introduction: This section provides an overview of the project, its background and purpose. It also includes definitions of the acronyms used in the document and a list of references, if applicable.
2. System overview: This provides the "big picture" view of the project - the product perspective, user characteristics, high-level requirements, expected hardware and software environment, and so on. It also includes a broad overview of product functions and features, lists assumptions and dependencies, and includes context diagrams where required.
3. Software requirements: This is the meat of the document, capturing the requirements of the software in various categories. Typically, this section is further divided into various sub-sections, including sections on the application's behavioural requirements, performance requirements, external interfaces, user interface, maintainability, security, availability and portability. Each requirement is listed separately, and is accompanied with a detailed description, including references, dependencies, input and output examples, and performance specifications.
4. Functional specifications: Building off the previous material, this section describes the basic functions to be built into the application, and illustrates them by means of flowcharts and diagrams. These diagrams come in handy to describe the interaction and relationship between different components of the product to be built. A detailed description of the working of each function should also be included.
5. Requirements traceability matrix: This is a matrix mapping each requirement in two directions: backwards, to the original goals of the project, and forward, through the different phases of the software development cycle. This makes it possible to easily isolate each requirement, understand it in the context of the overall goal, and trace its development through the various phases of the project.

Don't get too caught up in the nitty-gritty details of what a requirements document must and must not contain - there's no one-size-fits-all format, and different organizations structure it differently as per their needs. The important thing is that it must clearly communicate - to both vendor and customer - what the final deliverable is, and thus serve as the basis for all future activity.

Next: When Time Is Money... >>
 

More Practices Articles
More By icarus, (c) Melonfire

Comments On: The Art Of Software Development (part 1): Understanding Need

>>> Be the FIRST to comment on this article!