Effective Engineering 
                Consulting Services
                                           "Helping Engineering Excel!"

Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
Our People
Contact Us


Back to e-Newsletter Archives:

 Effective Engineering e-Newsletter – 9/25/2003

This is your bi-weekly e-Newsletter from Effective Engineering Consulting Services (www.effectiveeng.com).  If you would like to receive Effective Engineering e-newsletters as they are published, please send an email to e-newsletter@effectiveeng.com, and we will add you to our distribution list.


Development Methodology: Requirements
  By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]

Development Methodology is a broad topic.  In two previous e-Newsletters, I described the basics of development methodologies (see eN-030828 – Development Methodology Basics: Stages of Development, and eN-030911 – Development Methodology Basics: Management of Development).  Those e-Newsletters were able to cover only very broadly the elements of development methodologies.  Starting with this e-Newsletter, and in more to follow, I will start to fill in some more details, although these will still not delve very deeply into these topics.  In the Stages of Development, the first stage is Requirements & Architecture.   These will be covered separately, with this article concentrating on Requirements, which I described as defining the WHAT, WHO, and WHEN of product development.  This e-Newsletter will concentrate only on the WHAT area of Requirements.  The WHO will be covered separately in articles on resource planning and allocation, and the WHEN will be covered in yet other articles on project planning and project management.

Product Definition – This high-level requirements document has been addressed in eN-030619 – What Do Your Customers Really Want?, and in eN-030703 – Product Definition: Define What It Is and What It Isn’t!.  I won’t spend more time here on this. 

Functional Requirements – This document specifies, at a fairly high-level, the product’s features and how it functions.  The level of detail will vary with the complexity of the product.  It is a step down in detail from the Product Definition document.

Architecture Requirements – Architectural decisions made up front will greatly impact the product later.  This critical area will be covered separately in more detail in the next e-Newsletter (see eN-031009 – Development Methodology: Architecture).

Interface Requirements – This document specifies the characteristics of all product interfaces – inputs and outputs, as well as between modules in the product.  This includes physical interfaces, communications protocols, programming interfaces, etc. 

Performance Requirements – You can’t tell if you’ve achieved your performance goals, unless you know what those goals are.   All too often, performance is an afterthought, and a lot of time is spent later in the development trying to improve the performance of what you’ve ended up with.  If time is spent, up front, defining what performance goals are required, proper performance can be designed in from the outset. 

Usability Requirements – This is another area that is often ignored or minimized.  A product will often succeed or fail based on how comfortable customers are with it.   It needs to be easy to use, operate consistently and logically, and “feel good”.  By spending time to specify usability up front, many problems will be avoided downstream. 

Design Requirements (High-Level to Detailed Design) – These are the documents that, as you zoom down into more and more detail, specify the design in more and more detail.  The better the specifications here, the simpler the implementation later.  

Test Requirements – Products are tested in many ways, including Unit, Integration, Functional, System, Performance, Usability, Regression, etc.  By thinking through how the product will be tested up front, the actual testing effort will be streamlined.

Technical Documentation Requirements – Products must be made user-friendly and usable, but they also require user documentation.  A consistent documentation approach and plan must be thought out up front, and again streamlines the actual user documentation effort later. 

Release Requirements – Before a product can be shipped, it has to be released to manufacture.  This is true whether the product is mechanical, electronic, software, or a combination of all of the above.  The requirements to release the product, to release updates, patches, etc. must be specified, and the sooner that is done, the better.

Customer Support Requirements – Any product that gets to customers hands must be supported, whether this is simply answering questions, or addressing problems, or fixing defects.  This document specifies the approach to handle this. 

Other – Depending on the product being developed, other requirements must also be specified up front as needed.

I’ve been barely able to touch on the many requirements areas that need to be addressed.  The better the job that is done in thinking through and specifying requirements up front, the more straightforward and streamlined will be the actual implementation when that phase is reached.  By doing Requirements right, Build & Test can be that much easier, and done with significantly higher quality.  The impact of time spent here cannot be overstated.  Do not short-change this extremely critical stage! 

Copyright © 2003 Effective Engineering Consulting Services, All Rights Reserved

Back to e-Newsletter Archives:


Society of Professional Consultants


Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved