requirements document

[jcarmody]

Hi,

I work in a Test Engineering department on the Manufacturing/Operations side of the "wall", with Design Engineering on the other side. There is a disconnect in the way the Design teams specify their requirements and we end up shooting at moving/unclear targets; the result being that our ATEs are often delivered behind schedule and over budget. We'd like to make a generic requirements document that would gently guide them toward providing a specification that we can hang our hats on. If we can accomplish this early in the process we might have a shot at controlling scope-creep. Granted, late design changes will require us to readjust, but we'd be able to specifically say how much time & money will be required to comply if we had a good plan.

Another area to consider (that I've been hurt by) is custom test equipment purchased by the Design team that gets thrown over the wall when the product is ready for production. I'm about to release one ATE for limited production use after spending > 200 hours reverse-engineering and modifying the software to the latest test requirements. I'd like to be able to get Design Engineering to follow our guidelines when working with an outside vendor, at least if they're going to use "future production use" as part of their justification for the purchase. Our design team is in the process of quoting a new piece and I'd like to get my two cents in early.

I recall having an NI District Sales Manager give us a presentation on the help they offer folks developing large projects (it's impressive). One of the biggest things I took away was his point that a missing specification is a big risk at the outset of a project. I've sure seen the truth in this. Do you have a template that you would share with me? I'd appreciate any advice you can offer, and I'll compile whatever help I receive and post it back here.

Thank you,

Jim

PS - Our walls aren't very high and we do have cross-functional teams working on all development projects. I'm just trying to help guide our operation toward Standard Work in this area.

[PaulL]

There are some IEEE templates that we use as a starting point, although these are pretty generic....

Paul

[crelf]

G'Day Jim,

You certainly aren’t alone in the issues you are facing As an integrator that delivers both design validation and manufacturing test equipment, we understand the differences (cycle time, coverage, etc) and often are faced questioning requirements when one system is meant for both but not all parties are appropriately represented in the requirements and design reviews. We also often find requirements to be incomplete at the start of the project and have implemented requirements training and templates internally to make sure both the client and us are on the same page. As an aside, it's a fact of life that requirements can change during a project, so we use tools and processes to track the impact of those changes both in dollars and schedule impact.

That said, we view our templates to be somewhat proprietary, but have done requirements training and delivered standard templates for clients in the past. In addition we provide process consulting to help clients streamline workflow and improve results. Let me know if you want to start a dialog...

[nhollenback]

Hi Jim,

I have a friend who lives and breaths System Engineering and writing and refining requirements and he recommends the following text:

"Writing Better Requirements" ISBN 0-321-13163-0

But that is just a book - consider starting that conversation with crelf!

Best of luck!

[crelf]

QUOTE (nhollenback @ Oct 13 2008, 09:39 PM)

I have a friend who lives and breaths System Engineering and writing and refining requirements and he recommends the following text: "Writing Better Requirements" ISBN 0-321-13163-0

That's a great book! (yeah, I'm a geek) But it only covers a part of the issue - the quality of the requirements. You also need to consider methods of testing the requirements, basing testable designs around the requirements, etc. Another challenging part is getting everyone on board to understand, at least, the overall value of good process, and the micro area that they will be involved in - to have them take ownership of it because they beleive that doing so will be valuable to them, as well as the organization.

QUOTE (nhollenback @ Oct 13 2008, 09:39 PM)

But that is just a book - consider starting that conversation with crelf!

I agree! :thumbup: We have a an extremely capable and sizable systems engineering team here that get all excited about this sort of stuff, and they're just waiting for your call

[jcarmody]

QUOTE (crelf @ Oct 13 2008, 12:40 PM)

Let me know if you want to start a dialog...

I do want to talk further about this, but I want to make sure I'm not getting in over my head. I'm accustomed to receiving specifications, not writing them, so I'd like to get someone else's perspective. I'm going to discuss this with the senior test guys and my manager; we'll see if they're as interested as I am.

Thanks,

Jim

[crelf]

QUOTE (jcarmody @ Oct 15 2008, 05:59 AM)

I do want to talk further about this, but I want to make sure I'm not getting in over my head. I'm accustomed to receiving specifications, not writing them, so I'd like to get someone else's perspective. I'm going to discuss this with the senior test guys and my manager; we'll see if they're as interested as I am.

Hopefully they are - it's an important topic No worries - let me know if I can help.

[Daklu]

QUOTE (jcarmody @ Oct 15 2008, 02:59 AM)

I'm accustomed to receiving specifications, not writing them, so I'd like to get someone else's perspective.

Who knows better what a spec should contain (i.e. how to write it) than the person who has to use it to implement tests?

Ideally, specifications (engineering requirements) flow naturally from product definition (customer requirements.) My experience is that poorly-defined and changing specs are often due to an inadquate product definition. Unfortunately marketing/product planning has no idea how to properly define customer requirements. (I've seen the requirement "our product needs to perform as well as competitor-x" too many times to count.) In my opinion, you're not going to get a good specification unless design and test are involved at the very beginning of the project, when marketing/product planning is first defining the product.

In other words, a document template probably isn't going to help you much. It sounds like there are deeper organizational problems there. (I spent 5 years at my last job trying, without success, to get into the product definition phase so I could help them create a meaningful product definition.) In fact, spending your political capital on applying a band-aid to a broken arm could end up hurting your work reputation.

[crelf]

QUOTE (Daklu @ Oct 15 2008, 03:20 PM)

Who knows better what a spec should contain (i.e. how to write it) than the person who has to use it to implement tests?

What the spec should contain and how to write it so that it's testable are two very separate things. I don't agree that the implementer is necessarily the best person to create the test system requirements (they might be, but it's not always the case). That said, the implementer is usually the more appropriate person to write their domain-knowledge area of the system design.

QUOTE (Daklu @ Oct 15 2008, 03:20 PM)

Ideally, specifications (engineering requirements) flow naturally from product definition (customer requirements.) My experience is that poorly-defined and changing specs are often due to an inadquate product definition.

Sure, and that's why it is so important to close the loop with the customer in three key areas: design, production and test (there are others, but they are less important in the context of the discussion that we're currently having). ...and that's just inside the organization. As you're suggesting, there's another (sometimes more) level beyond that - the end customer.

QUOTE (Daklu @ Oct 15 2008, 03:20 PM)

In my opinion, you're not going to get a good specification unless design and test are involved at the very beginning of the project, when marketing/product planning is first defining the product.

I couldn't agree more :thumbup: In continuing this discussion, I think that specification and requirements are two separate things: the former refers to the UUT and the latter refers to the test system.

[PJM_labview]

One think I will add that while the specifications (Software Requirement Specification) and the design description (Software Design Description) are usually different documents, the SDD is not a test plan.

Typically, while the SRS defines "what" the software must do, the SDD defines "how" the system will be designed to implement the SRS. The SDD is the document that the programmer(s) will need to write/implement the code. The SDD does not define any test methodology or test vectors. Other document(s) (such as a test plan for instance) are used for this.

Note (to the original poster): if you do some search on the web with SRS and SDD you will get some info about this.

PJM

[crelf]

QUOTE (PJM_labview @ Oct 16 2008, 09:56 AM)

One think I will add that while the specifications (Software Requirement Specification) and the design description (Software Design Description) are usually different documents, the SDD is not a test plan.

Right - that's what an Acceptance Test Plan is for. While all of these items are really important, it's even more important to understand how they all fit together. If you want to do some introductory reading, take a look at the Enitity Vee Model and how it relates to the Double Vee Model - we use a modified version of that here at V I Engineering, Inc.

[Dan DeFriese]

Hi jcarmody,

I noticed in your profile that your working in aerospace. If your company has an account with ARINC you may want to check out "ARINC 625-1 Quality Manangement Process for Test Procedure Generation". The back of this manual contains a fairly decent TS example and some development checklists.

~Dan