New Software Requirements

Australia & New Zealand Homebrewing Forum

Help Support Australia & New Zealand Homebrewing Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

fraser_john

Go Pies
Joined
17/1/06
Messages
2,477
Reaction score
374
Location
Victoria
Over the last two years I have been documenting requirements for replacing my existing software setup for the RIMS system. Further to that, I have contacted a University and they have agreed to offer it as a 4th year project to engineering students in 2009. Out of this I want to get the absolute best quality software product for my home brewery. I will be responsible for providing all equipment needed to get the software up and running, including electronic components if new hardware interfaces need to be built.

So, I am going to chuck the document out here for people to take a look at. I know there are some very talented people out here that have great ideas, so I am looking forward to hearing from you all!

View attachment Brewery_Requirements.doc
 
good stuff, keen to see the results.

If you include level inputs for HLT, mash tun and kettle you can incorporate safety systems like no power to element until it is immersed and a fully automated fly sparge system.

and flow sensor will allow the system to alarm if the flow stops for some reason whilst recirculating.
 
I'd love to see it developed as kind of an open-source brewing system to be shared/updated by all.

I have included a flow rate sensor on the outlet of a pump, thanks for that.

As for the level sensors, I batch sparge so probably wont include it, but it made me think about the design. Would'nt it be nice if it could be developed as a plug-in kind of system, where you can add extra features such as level sensors as you need them!

I'll raise that when I start meeting with the students assigned to the project next year and see what they think, it might be a little large in terms of scope.
 
Hey fraser_john,

keep up the good work.

i've been working on a simular project of late here:

http://www.halfluck.com/automation

pretty much planning on doing the same thing, make it as cheap/flexible as possible and release it under the opensource

so any budding brewer can have a play

Rob.
 
frase_john, great idea, best of luck getting the eng students to do this, I think you'll have them hooked simply because it's all about the beer. :D

randyrob, just checked out your page, have you set it up for a wide screen? I think your code needs a tweak to get all the pics/writing hanging on the right hand side over to the left underneath the menu tabs. ;)
 
I taught EE for 10 years and supervised a lot of student-run projects (but none nearly so dear to my heart as this). The first thing I recommend is to drop most or all of your actual written-in-stone h/w requirements. The reason is that you have an idea in mind of what it should be which is based on your previous experiences - this 'blinds' you to what can perhaps be a better method or procedure. A student(s) just may come up with a far superior method of obtaining measurements or running the thing, but it will be thrown out because it doesn't meet your requirements.

I'd leave it very open ended. Start off with a 'dummies guide to mashing' so they can understand what is involved. Offer to host a brewing session for any groups that show interest in the project. This will go a long way to helping you to get the best possible solution. Draw lots of pictures - they help the most as almost everyone will skim the words and closely examine pictures.

List general requirements. e.g.
- either standalone or PC-based (or mac I suppose, if that's what you want) mashing control system
- must haves:
- monitor temperature in ..........
- chosen temperature measurement method must not contaminate the wort in any way, shape or form - wort is food product! [I'm thinking lead solder - you'd be surprised what I've seen over the years]
- system must tolerate temperature and humidity extremes - probes must tolerate being immersed
- pump control (on/off or on/variable speed/off - your choice)
- RIMS heater control
- HLT heater control
- water flow control - for filling HLT automatically - must also measure volume of water in HLT - could be level or mass based measurement (google iLoad sensors for some really nice mass sensors)
- PID temperature control - what is controlled can be switched (either mash tun temp, RIMS outflow temp, inflow temp, etc.) - this is a nice to have feature because it allows you to 'customise' the unit in s/w
- ability to manually override anything at any time (VERY IMPORTANT)
- nice to haves:
- alarm clock feature that will have the HLT filled and preheated by the time you wake up in the morning
- automated water routing/pumping so that you don't have to manually throw valves - could also aid in automation
- alarms:
- low/no flow (perhaps automated backflush to try and clear a stuck mash?)
- self test/sanity check for all sensors, valves, etc.
- how are alarms made known to the operator? flashing light, annoying buzzer, email a text message to your mobile phone, etc.
- if an alarm condition is encountered, what is the failsafe? in other words, what should the system do to mitigate damages?
- graphical point-and-click mash temperature vs time input [something I wish I have - use your mouse to drag & drop rest temps, ramps, etc]
- pH measurement

Then state that some instrumentation/equipment is already on hand - the sensors, SSRs, whatever. Just don't limit them to what you have on hand as like I said, they may find something far superior. They'll probably elect to use what you have, but allow them free reign to investigate alternatives.

Good luck - sounds like a VERY good real life engineering problem.
 
I would have to agree with what newguy said. To me, this reads like a design document, not a list of user requirements.

If you're dealing with Engineering students, they are going to be more interested in coming up with how it works than just writing the code. If you just want code written, I would head to the Computer Science department instead.

Ideally, what I think you should be saying is that you want something that performs all the functions (see newguy's list), but that preference will be given to using existing hardware (eg. DS1820, SSRs, etc). Then, as the design develops you would be involved to keep them on track.

Also, when I did my 4th year projects, they were keen on projects that could be continued by other students in future years so you may end up having to wait a couple of years depending on how ambitious the students you end up with are.

Sounds like a pretty cool project though, and I don't think you'll have any trouble getting someone to take up the challenge.
 
As the guys have been saying, I think you're being too prescriptive in describing the solution and NOT detailing the actual requirements of the system. Detail hardware and software separately.

Factors to include when documenting this include:

  • Scope of the Requirements (Define the areas that the requirements encompass to ensure that the requirements documented are relevant to the need being addressed.)
  • Inclusions
  • Exclusions
  • Current Process Overview (Produce an overview that shows the current process - a flow chart would be a great idea)
  • Context
  • Diagram (Produce a context diagram that shows how the area being addressed interacts with other areas eg fermentation :) .

Here is a direct copy out of a section of a project requirements template:

Business requirements are defined in 3 sections,

1. Business requirements - these are the major requirements that are to be met by the solution;

2. Non functional requirements - these are the non functional requirements that need to be addressed by the solution; and

3. Additional requirements these are requirements that are not related to a business objective.

Each business requirement documented must be within the scope as previously defined and must relate the a business objective detailed in section 3.2 of this document. Each business requirement should meet the following criteria:

The requirement is clearly and specifically stated;
The requirement is realistic and achievable;
The requirement is sufficiently defined such the requirements can be verified; and
Each requirement must be unique.

Attributes of the business requirement:

Business Requirement ID number to uniquely identify each requirement. Use BR1, BR2 as the numbering sequence.
Business Objective ID: which business objective this business requirement relates to (users need only detail the relevant ID number). Note that for additional requirements, no Business Objective ID will be specified. Rather additional requirements are those requirements that are not related to an objective they include timing and performance requirements, expected life time of solution, financial / budgetary constraints, documentation that is required for the solution etc.
Business Requirement Title: a brief title for each requirement;
Description: a clear description of the requirement;
Owner: who owns this requirement (note that this may not be an individual, it could also be a business unit);
Classification: classification of requirement into common area groupings (usability etc)
Business Area Impacted: classification of the business areas affected by this requirement (e.g. Loan Processing Centre);
Priority: classification of the level of importance of the requirement (mandatory, highly desirable, desirable, nice to have). Prioritising requirements, will assist in the solution design process;
Verification: statement that the requirement can be verified and how; and
Measures of success: the key success criteria / key performance criteria for the project.

If you specify user enablement of functions you will be able the functions built as part of the design, but allow them to be enabled by the individual brewer to fit their particular setup eg you batch sparge but I fly, therefore you turn off the water height/volume function, but I enable it. Similar situation for things like mash stirrers. this would also allow brewers to start with a basic system & grow it over time as budget & desires allow.

I'd add in things like ability to create, name, store and load different schedules eg a weizen mash would have different charactistics to a pale ale.

It might be an idea to take the class to your place for a brew day so they can see a setup in action. It would make the challange real world, instead of just being perceived as just a theoretical excercise necessary to pass the course.

Drop me a PM with your email & I'll send you a couple of templates which may help (I work as a project manager so business requirements are very important to me when defining a projects scope). ;) There are a lot of good "project requirements template"s online eg this one

Crozdog
 
Further to that, I have contacted a University and they have agreed to offer it as a 4th year project to engineering students in 2009.

Genius :lol:

+1 for the above and Im very interested to see how this turns out... god knows what they will come up with.
 
It's looking better now. There's more room for creativity but it still appears to have all of your needs in there (I won't comment on that because I'm only running a very simple 'brewery'... for now).

Also the requirements are what would generally be considered 'bad' -- ambiguous, not testable, inconsistent terminology, dual requirements etc. However I don't think this is a problem for a Uni project, since that just means they need to do a bit more work to figure out exactly what is needed.

You'll just need to be careful to keep track of how they are going so that you do end up with what you want, i.e. don't expect to be able to hand this over to the Uni and just get back your software in 12 months. Sounds like you're pretty keen to be involved somewhat anyway so this won't be a problem. Good luck!
 
I would have thought that they should use your requirements as the basis for their own requirement gathering on the assumption that a) they are the professionals and B) they have a certain standards that requiements have to conform to ensure a quality product.
Perhaps you could suggest that to them when you hand it over you know "I've done my best, got advice but I reckon you might have to work with me tweak them". because these budding engineers are just children, you might have to encourage them to form a productive relationship with you, where they are willing to ask questions and accept guidance on the brewing aspects.

Ask them to see a project plan and weekly status reports as a way of getting something to discuss with them.

Also, its not clear to me what the scope of the project is. Are they supplying hardware to you? Or just the software to control existing hardware?

But it looks pretty good to me.

Ask them for a traceability matrix, tracing their tests to your requirements.
Ask them for a test report.
And ask them to include User Acceptance Testing in their project plan. You user acceptance testing may include doing all the verifications you've got in your doc.
That's one way to ensure you get the product you need.

OK ... I know I'm running ahead from requirements to project management issues but .. things will go better if you're prepared.
 
Ask them for a traceability matrix, tracing their tests to your requirements.
Ask them for a test report.
And ask them to include User Acceptance Testing in their project plan.
Maybe as part of the assesment each student gets to come & do a brew with you to "test" their solution?
 
Maybe as part of the assesment each student gets to come & do a brew with you to "test" their solution?

well they should do a before and after and tweak the requirements after the before and become their own "users/customers" during the after. Its a great idea!
 
What about an IP connection, rather than USB,

then you could telnet your rig from work.... :icon_cheers:
 
But the whole things gonna be controlled from a PC right? So if the PC was a webserver then ...
And if the software had a web interface then that would make it even nicer.
 
Wow. It's been AGES since I've been on the forum. So, I take a little time out from my working day (IT project) to find an IT project has occupied my leisure time!
This looks very interesting, but I agree with some of the comments above regarding the current state of the requirement doc. For me there is nothing more important in terms of a productive client/business outcome, then adequate requirement gathering and UAT (With large chunks of Project mgt in between)

It's good to see the process flow. But if I was new to brewing I wouldn't know what you are trying to achieve with over the top of it. You're not customising an existing product with known benefits, so you should be VERY clear regarding what your expectations are, at a high level.
eg: Decrease manual intervention. Maintain/increase current recipe & style flexibility. Decrease average time spent in Mash processing...etc.

This may just seem like common sense, but believe me - it's important. If you are not clear in about the high level goals, you may find you have a product that meets all your detail requirements, but takes twice as long to run.

I also think the requirements are jumping into solution mode. Keep it based in process.
eg:
"All temperatures are to be displayed for every sensor available in the system"

I'd ask why that is? The answer might be you need to monitor temp levels at all stages of the mash, to ensure compliance to the recipe. State that as the requirement & let the engineers work out the solution.

Having said that, someone will disagree with me. Requirements are always contentious.

Good luck!

Cheers
Paul
 
I have just been re-reading this thread..

Is the rig supposed to be a "stand alone dedicated PC" to run the system ( that you can also access remotely via Telnet/SSH/VNC etc )...or...are you wanting the PC to be able to run remotely and interface via IP/USB, because this would create two very seperate outcomes...

I also do believe that it would be a better outcome if you stated what the software was required to do, and why and leave the hardware component as seperate, because I can see a lot of students asking " why do we have to use this specific hardware, when I could do it with this other hardware..."

The challenge would be designing the software that could run using various different hardware options...

Coming from a maint/install/repair technical background, it is always frustrating when software is tied to a particular piece of hardware.
 
Sorry I missed the new document until now. It's much better. As braufrau has said, much of your involvement with the students will be hand holding/steering. Gently guide them toward a solution, but be very open to any deviations from your idea that they may have as it just may be cheaper/faster/better. Also don't expect the moon; it was pretty common for our 4th years to have a completion rate on their final design project of ~50% - through to something finished/kind of working. Of those 50%, the number that actually had a really good outcome (ie something I'd be happy with as a customer) was much less.
 
Back
Top