Background • Located in Dannevirke • Specialised in Research & Development, Design, and engineering metal products for a wide range of industries such as transport, meat, dairy, hor)culture, and avia)on • Supply locally ( NZ only)
Our Role • To set up a network database – for the tracking and ongoing management of sheet and sec)onal raw materials from arrival on site to complete use and scrapping. • NEED: -‐ Integrate with other soRware • HAVE: -‐ Scope for con)nuous improvement and development • MUST: -‐ Accessible through mul)ple terminals -‐ User friendly interface ( for non-‐computer users)
Deﬁciencies with Current System • Excel – cannot scale, and cannot provide enough func)onality. • IT staﬀ could not convince CEO for a development
Beneﬁts of Mee)ng Client -‐ The actual process was quite diﬀerent from that described in the documenta)on -‐ Gain user-‐ input from all of the diﬀerent ‘programmers’. -‐ Simple fact: Face to face communica)on beats e-‐mail when it comes to requirements elicita)on.
Func)onal Requirements Off-Cut Managment System 188.8.131.52 Administration Normal User 184.108.40.206 220.127.116.11 Floor Personnel Functions Functions Functions 18.104.22.168.1 22.214.171.124.1 Update Location Enter New New Job Material 126.96.36.199.2 Key Update Job Primary Func&onali&es 188.8.131.52.3 Secondary Functionalities Generate Report Order Offcut
• 3.2 Non func)onal requirements • Opera)onal • The system should record the date which the material would be available aFer it has been ordered. • The default loca&on of material should be “in transit”. This would mi&gate the event of re-‐ordering an oﬀ-‐cut which is on the way to the shop. • Log in – This provides access to the system for three diﬀerent classes of users; Administra&on, Normal User, Floor Personnel. Each user will have a unique ID and password. • Performance • Mul&ple users should be able to access and update the database simultaneously. • Security • The system should have a log in ID for each user so the system keeps a record of who made par&cular changes. • Floor staﬀ should only have access to the “update loca&on” func&on. • Cultural/ poli)cal • No special cultural or poli&cal requirements are an&cipated.
Overview of The Project Limita)ons: -‐ The dura)on of )me -‐ The requirement being too broad -‐ Lack of programming (Ruby on Rails) knowledge -‐ Client’s being long distance – poor communica)on and slow start.
In hindsight… -‐ More synchronous communica)on such as conference calls. -‐ Narrower scope from the outset -‐ Another trip to Dannevirke to view processes in ac)on. -‐ More intensive programming training or more developers -‐ And of course; more )me, more money and more manpower.