Home arrow Practices arrow Page 4 - The Art Of Software Development (part 1): Understanding Need

The Write Stuff - Practices

Wondering why your software projects are always late, buggyand over budget? Well, this might come as a surprise to you, butprofessional software development involves a lot more than just writingcode. Over the course of this five-part tutorial on software developmentprocesses and practices, find out what you've been missing, and how youcan streamline your development to be more efficient and effective. Thisintroductory article discusses the analysis and documentation ofcustomer requirements.

TABLE OF CONTENTS:
  1. The Art Of Software Development (part 1): Understanding Need
  2. Word Games
  3. Hard Talk
  4. The Write Stuff
  5. When Time Is Money...
  6. Endgame
By: icarus, (c) Melonfire
Rating: starstarstarstarstar / 6
August 28, 2002

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement
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.

 
 
>>> More Practices Articles          >>> More By icarus, (c) Melonfire
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: