General Notes:

The current documents are very rigid, i.e. the documents should be ‘live’ for longer, don’t need to be
‘closed’ essentially.

Discuss where the current system fails

Asks for lots of information, sometimes it’s not all complete before a project is rushed ahead

Can look at the whole process holistically, but need to focus on design brief first and get that sorted.
If we try to fix the whole thing at once nothing will get done.

Requirements very often change on the fly, not everyone is on the same page at the start of a
project. Requirements not clearly outlined

Move away from large documents with lots of information and refer to more of a ‘checklist’ style to
trigger requirement thoughts/decisions?

There’s a need to clarify terminology…

A Product Specification / Requirement Specification addresses the “what”

Design Specification addresses the “how”

Requirements must be able to be validated.

The role of design specification in the design process is recognised as significant. In the
specification document, the description of the desired solution is described by a set of requirements. A
clear description of the desired solution is important because it will increase the probability to achieve
a successful design. In order to have a clear description the number of requirement statements must be
sufficient to guide design engineers to proceed from the abstract to the concrete solution so as to fulfil
the aim of the product. Once the problem has been identified, the criteria for selection of feasible
concept are established in the form of a design specification, consisting of a list of requirements to be
met by any solution to the problem. Thus the role of specification is twofold: First, to set up the
solution space for design engineers to design a product and: second; to evaluate proposed solution to
ensure that they fall within the acceptable boundaries.
Key requirements moving forward:

Traceability of requirements (identify at START of project)

Provide a record of communications/outcomes (i.e. issues log, signoff of tasks/outcomes)

Balance high level documentation for PM’s vs detailed engineering data

Develop clear priorities

Problem statement

Focus on business case of product development (ROI, QTY’s, occurences?)

Target costs

Will a customer benefit from the product?

Growth forecasts?

Will it be profitable?

Technically feasible?

Work on better understanding the actual requirements instead of creating a solution to potentially
the ‘wrong’ problem.

Outline assumptions

Allow ‘rejection’ of requirements

Accountability for decisions

Traceability for communications

Issues log, closing out actions/requirements.

Engineers probably still need to keep their own concept records, have some sort of guidelines for
this? Only ‘issued’ concepts move to the “Project/Design Journal”.
Current:

Process is rigid,

Confusing when you get to a DS stage and ‘new’ requests are introduced and it re-opens a feasibility.

Realistically, there’s no point listing off 100 headings for someone to fill out. You’re not going to
know the answers to half of them. Better off having a check list to trigger topics to consider when
writing requirements.

Design Brief

_There’s lots of information in the DB that isn’t relevant to “will this project go ahead”

Design Feasibility

Design Summary

You have to read all 3x documents to get the full picture.

Documents often don’t get updated when scope changes.

No prompting for traceability when something changes, few people have implemented their own
little methods but nothing consistent.

Specifications are generally “outputs”, i.e. we have a product specifications manual.

Proposed:

What is the requirement of a brief: (maybe call it a “business case” as stage 1)

_To decide whether a project will proceed or not.

_Should be very simple list of requirements (why we need xxx), inventory check,

_IDC can completed estimated hours/development/tooling costs as well as overall project

risk. IDC will also comment on requirements and approve/reject working on them based on
unknowns and hours required to develop.

“High risk” projects require more feasibility time.

“Low risk” projects i.e. a bracket update can be ‘accepted’ easily to proceed if all the requirements
are clear and known.

Brief might start as a word document but turn into an excel during the project? (simple migration of
data).

Excel;

Can include many of the ‘auxiliary’ documents we have, everything is in one place.

Engineers really like working in Excel. (Will be formatted so that PM’s can find what they need easily.

Can be formatted to be clearer and more concise without sacrificing detail where required.

Highlight risks involved in project at request stage, high risk = more feasibility time.

Product specification – what is required (start)

Technical specification - what the product does (finish)

Capture “reasons why” a requirement is there.

More centralised project data

An output ‘that adam can read’, i.e. very summarised with only the most critical data.

Document includes requirements/issues/communications traceability.

Flexibility in project flow, allows for separating out project ‘flows’, i.e. parts/systems that are
approved for development while others remain in feasibility stage.