I'm assuming you're talking about a hardware/firmware/software combo
here.
I can't exactly give you a table of contents without having your
proprietary information in front of me, but in a nutshell, you could
start with something like this:
I. Overview.
A general description of your product(s), what they will be used for,
who will use them, who your market is, how the individual pieces will
work together, and how they will integrate with third-party products.
II. Purpose.
The purpose of the document. If this document is to be used for
testing, ddevelopment, compliance, etc.
III. Diagrams.
Diagrams showing how your product will work.
1. Physical Diagram. If your product contains more than one physical
piece, you'll want to illustrate how they will physically work
together. For example, if you are building a multiplexer that can be
controlled via a workstation , show how the multiplexer is connected
to outside lines, to the workstation, and to any third-party equipment
your product is designed to communicate with.
2. Logical Diagram. This will change throughout your development
cycle, but your logical diagram is a classic programmer's type flow
diagram, showing processes, decisions, etc.
IV. Elements.
A breakdown of the various elements of your system, including
software, hardware, firmware, etc.
1. Individual Element Sections.
Detailed descriptions of the individual elements. Repeat this
section for each element of your product.
a. Overview.
An overview of the individual element.
b. Technical Specs. Specs for any protocols you're employing.
Include these as appendices, and excerpt any sections that you expect
to be problematic for you in this section. I'm assuming you already
have these specs, but if you don't, feel free to ask for a
clarification, and I can help you find them.
c. Technical Design Requirements. This includes required
functionality and throughputs, acceptable error rates, heat tolerance,
safety requirements, etc.
d. User Interface Requirements. This includes both hardware and
software. For hardware, mention any size and weight requirements,
accessibility requirements (e.g., location, size, and function of
controls; access to DIP switches; and any design factors that might be
applicable.) For software, this includes user interface standards such
as what, if any, GUI design standards you'll use and whether you'll
have a single design or unique designs for supported OSes; what
structure and functionality requirements you'll have for any firmware
CLIs; and so forth.
e. Portability and Compliance. Any technical or design standards
you must comply with fully in order to either maintain portability
with third-party products or for certifications.
f. Use Cases. For testing both during and after development of
your products, you need to have a number of use cases available as
models. For example, you might set various levels of throughput and
task complexity and then measure times and error rates for each of
these set cases. Or you might indicate a specific administrative task
for a user, and see how many steps and/or how long it takes the tester
to accomplish that.
IV. Interoperability.
This section will describe how the individual elements above work
together.
1. Design.
Design factors include any applicable factors that might serve to
make the individual elements look and work as a cohesive product. This
can include color schemes, logos, and consistent terminology.
2. Portability and Compliance.
This is a sort of microcosm of the "Portability and Compliance"
section in the Individual Elements section above. In this section,
though, describe how the individual elements of your product work
together, individually. So, if you have Part A, Part B, and Part C,
include one section each describing how Part A works with Part B, how
Part A works with Part C, and how Part B works with Part C.
3. Use Cases.
Again, almost exactly like the Use Cases in the above section, but
in this case, test the product as a whole, rather than the individual
pieces separately. In this section, focus on the internal operability
of your own products, and test them as a whole rather than
individually.
APPENDICES.
Add all applicable technical specs to the end of your document as
appendices. Also include any design notes, test results, etc., that
you come across along the way that you think might be helpful.
I know that this is fairly vague, but, as I said, I don't know your
product in detail, so I can't be too specific.
If you're looking for industry standards, they do exist, but I've
worked for several major telecommunications companies, and I can tell
you strictly from experience that most of the 'official' document
templates and so forth are so mired in bureaucracy that nobody uses
them.
If you'd like to learn more about requirements documents, I'd suggest
picking up a book on the subject.
My favorite is Practical Software Requirements by Benjamin L. Kovitz.
Its focus, as its title implies, is on software, but it's an excellent
guide to the domains and pitfalls in the area, and it provides an
excellent overview of how to think about your requirements before,
during, and after development in order to save time and money. Also,
he's a good friend of mine, and a really smart guy. I figure I'd
better mention that or I'll have the Feds knocking down my door for
market manipulation or something like that.
Here it is on Amazon:
http://www.amazon.com/exec/obidos/ASIN/1884777597/qid=1025310930/sr=8-1/ref=sr_8_1/002-2727334-5776804
Other, more prolific authors, you might want to look at are below.
They're mostly focused on software, but the principles apply well to
pretty much any domain:
Michael Jackson (not the singer OR the beer guy, but a software
analyst, etc.)
http://dspace.dial.pipex.com/jacksonma/
Ed Yourdon (again, primarily concerned with software)
http://www.yourdon.com
Jakob Neilsen (usability expert)
http://www.useit.com
There are about a million others, so if you're really interested in
the topic, feel free to ask, and I can give you more.
And again, if you want more detailed info, or have other related
questions, let me know and I'll try to get you what you need.
Good luck,
Lisa.
PS: The search terms I used were -"Michael Jackson" requirements
software- to find Michael Jackson's home page, "Ed Yourdon" to find Ed
Yourdon's, and I searched on "Kovitz" at Amazon.com to find the link
to the book. |
,
0 Comments
)