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.
eN-030925:
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
