Jump to content

requirements document


Recommended Posts

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.

Link to comment

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...

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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

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.

Link to comment

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

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.