Effective Engineering e-Newsletter – 9/25/2003
This is your bi-weekly e-Newsletter from Effective Engineering Consulting
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to firstname.lastname@example.org,
and we will add you to our distribution list.
Development Methodology: Requirements
Tom Dennis – President, Effective Engineering [email@example.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.
– 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.
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.
– Architectural decisions made up front will greatly impact the product
critical area will be covered separately in more detail in the next
e-Newsletter (see eN-031009 – Development
– 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.
– 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.
– 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
By spending time to specify usability up front, many problems will be
(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
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.
– Products must be made user-friendly and usable, but they also require user
A consistent documentation approach and plan must be thought out up
front, and again streamlines the actual user documentation effort later.
– 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.
– 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.
– Depending on the product being developed, other requirements must also be
specified up front as needed.
been barely able to touch on the many requirements areas that need to be
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!
Effective Engineering Consulting Services, All Rights Reserved