Practices
  Home arrow Practices arrow Page 3 - The Art Of Software Development (part ...
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Actuate Whitepapers 
Moblin 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
PRACTICES

The Art Of Software Development (part 1): Understanding Need
By: icarus, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 6
    2002-08-28

    Table of Contents:
  • The Art Of Software Development (part 1): Understanding Need
  • Word Games
  • Hard Talk
  • The Write Stuff
  • When Time Is Money...
  • Endgame

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    The Art Of Software Development (part 1): Understanding Need - Hard Talk


    (Page 3 of 6 )

    In order to ensure that your project is a success, you need to engage your customer in each of the stages described previously, and ensure his or her active participation in the process. And since most of this customer communication takes place over email, it's very, very important that you learn, right from the word go, the importance of being able to convey your thoughts and decisions clearly and effectively in writing.

    This ability to communicate is key to one of the first things you need to do when considering a Web application project: requirements analysis.

    This might sound a little scary, but it's actually pretty simple. Requirements analysis is the process of understanding the customer's needs, and capturing them in a formal document. It's easily the most important phase of any project, as it gives both customer and vendor clarity on the final deliverable, and allows for a meeting of the minds on the various components of the project. A requirements document also sets the direction for the developer or development team and provides the basis for the software testing procedure.

    Requirements analysis is a largely iterative process; the end result is a document outlining the broad requirements of the customer. You can begin this process by asking your customer some basic questions - these are the ones I've found to be most useful:

    • What is the vision for the product?
    • What are the business cases against which the software is to be developed?
    • What is the target market for the product? Which types of users are being targeted? Is there a profile available for each user type?
    • What are the ten most important functions or features the software must support?
    • Are there specific hardware or software constraints for the product? For example, will it run on a proprietary operating system or proprietary hardware?
    • Are there specific performance or security constraints for the product? For example, do all users have access to the same functionality within the application, or do some users have extra privileges? Is the application to be optimized for narrowband or broadband connections?
    • Are there specific user interface requirements for the product? For example, must the product interface conform to particular branding rules? Is there a specific colour scheme to be followed?
    • Name three of the proposed product's closest competitors, and list the top five features of each.
    • Are there any specific requirements to be kept in mind when designing, developing or testing the product?
    • How often do you plan to update the software?
    • Do you have a specific timeline or launch date for your product?
    Based on the answers you get, further questions will arise and need to be answered; this iterative learning process should result in you obtaining a fairly clear overview of the items to be addressed in your document. This information will also play a critical role in helping you estimate the likely time and cost for the project.

    More Practices Articles
    More By icarus, (c) Melonfire


     

       

    PRACTICES ARTICLES

    - 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
    - Basic Ideas




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway